Jeff Lynn wrote:

> OK, Thanks! I am not ready to move on to FB 2.0 yet. So from what I
> gathered from all the postings, as long as I used my semaphore to
> regulate access to the embedded database file, then a file copy will
> work as all hard-drive caching will be flushed out to the actual drive
> when file copy takes place? Did I interpreted that right?

Not quite. Normally, when file caching is enabled, read and write
requests are satisfied from the cache without going to disk at all.
When forced writes are enabled, writes go through the cache to disk
directly, but the updated version of the page stays in cache and
reads continue to be served from the cache. Either way, your reads
will see the most recent version of data.

The problem that can occur is the independent garbage collect
thread. When a transaction finds a record version that is no longer
useful to any other transaction, it puts that record version on a
list for removal. Some time later, a special garbage collect thread
reads the list and removes the old version. That operation can
affect more than one page, but it's done in an order that minimizes
the effect of the change on concurrent operations - but doesn't
solve the copy problem.

Specifically, when an old record version is removed, the garbage
collector first zeros the pointer from the new record version to
the old. It then goes to the page with the old record version.
The page, like all data pages, has an index of the offset and
length of records, record versions, fragments, and blobs on the
page. The garbage collect thread sets the length and offset of
the old record version to zero.

So, what happens if your copy happens to pick up half of a
garbage collection operation? If the new record is on page
100 and the old version is on page 10000, there's a chance
that the garbage collector will change both those pages
after you've read page 100 with the old back pointer and
before you read page 10000. Your copy will have an invalid
back pointer.

Is that the end of the world? Maybe not. Running gbak with
the -g switch should allow you to create a valid backup of
your invalid copy, which you can restore and create a valid
logical copy.

Regards,


Ann