 | |
#11
 
| |||
| |||
|
Re: implementing a database log -
04-21-2008
, 04:58 PM
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#12
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#13
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#14
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#15
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#16
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#17
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#18
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#19
| |||
| |||
|
|
Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. |
basically i think your #4 is the same as my #1 or #2.
My problem is that one single insert can be split in up to 3 or even
more file operations, depending on the size of the B+Tree index (it
has to be split, if a page overflows, etc). I don't have an atomic
"insert(key, value)" operation.
And in that case, i have to log 3 (or more) different file events. And
that brings me back to my question - do i log the whole modified page
(usually a page is between 16kb and 64kb), or just the modified region
in the page...
#20
| |||
| |||
|
|
Brian, On Apr 21, 11:00 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: Why not go with #4: 4. a physical log based on modified rows. Whenever a row is modified, added or removed, it is logged. Then you could also implement row versioning--just add a row version field to the physical rows. I believe that this what snapshot isolation is built on. It's not an SQL database, i don't even have the notion of "rows", but basically i think your #4 is the same as my #1 or #2. |
have been affected by an update. #2 doesn't log the entire changed record,
but only bits and pieces. I would think that limiting the units of change
to individual records--entire records--would simplify the process of marking
and isolating units of work while at the same time guaranteeing consistency.
Quote:
|
My problem is that one single insert can be split in up to 3 or even more file operations, depending on the size of the B+Tree index (it has to be split, if a page overflows, etc). I don't have an atomic "insert(key, value)" operation. |
Quote:
|
And in that case, i have to log 3 (or more) different file events. And that brings me back to my question - do i log the whole modified page (usually a page is between 16kb and 64kb), or just the modified region in the page... |
discard the notion of logging pages or segments of pages--instead, log
records or sets of records. It is not enough in a concurrent environment to
reconstruct a snapshot of the physical media at a particular point in time.
An update may encompass many file operations; therefore, a reconstruction of
just the snapshot will almost certainly be inconsistent and will require
rolling back or rolling forward the result of any transactions that were
outstanding at the point in time of the snapshot.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.