db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: RowLocation lifetime
Date Thu, 17 Nov 2005 13:13:41 GMT
>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> Øystein Grøvlen wrote:

    >>>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:
    MM> It is only stable while some sort of stable table intent lock is held.
    MM> Rows can move during a compress table operation.
    >> I understand, when a record is moved to another page, its RecordId
    >> will change.  Is this the only case where a RecordId will change?  If
    >> yes, I would think one could solve the problem for insensitive result
    >> sets by invalidating open result sets when an underlying table is
    >> compressed.
    >> Some questions to how compression works:
    >> - Will RecordIds ever be reused or will the sequence number continue to
    >> increase?
    MM> Derby now supports 2 different compression techniques, basically one
    MM> offline and one online.

    MM> SYSCS_UTIL.SYSCS_COMPRESS_TABLE() basically copies all rows from one
    MM> table to another, so recordId's may be reused.  This requires table
    MM> level locking and so is effectively offline.

Do not the new version of the table get a new container key?  If yes,
I would think that recordId's are not reused since container key is
part of the record id.

    MM> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE() moves records within the
    MM> same table, and will not reuse RecordId's, but a given record can
    MM> definitely change RecordId.  This requires row locks
    MM> for purged/moved rows for most of it's work.  Giving back space to
    MM> OS requires short time table level lock.

Good, I was not aware that there was an online version of compress.

    >> - How do you ensure that the old RecordIds are not encountered
    >> during recovery?  Does the compression include a checkpoint?
    MM> Neither really does anything special to stop old recordId's from
    MM> being encountered during recovery.   With offline redo recovery of
    MM> old table is basically a drop table so either the table is there
    MM> and we drop it again, or the table is already dropped and we do
    MM> nothing.  In online it is the normal case of redo or a record delete
    MM> or a record purge, in either case redo will either see a version of
    MM> the page where it can redo the delete or purge or it will see from
    MM> the version of the page that there is no work to do.


View raw message