Subject | Re: [firebird-support] why does restore last so long?? |
---|---|
Author | Helen Borrie |
Post date | 2005-07-16T00:31:48Z |
At 01:16 PM 15/07/2005 -0400, you wrote:
the inventory of which is known only to the database engine). To the OS, a
database is a file; while to the database server it is a neighbourhood
with a map. Of course the map will tend to become invalid if something
external is moving the coordinates of arbitrary chunks of disk.
Of course don't defrag a partition that contains a file that is open for
reads and writes - as an open database is. The database engine can't be
predicted to write into the correct block if that block is moved by an
external operation. Just watch the graph during a defrag: the OS protects
its own files (system files) - they never get moved.
My comments about defrag were in the context of a Restore - why the Restore
was extraordinarily slow and part of a strategy to make the disk storage
more efficient. It's always a bad idea to hijack part of another thread
and run off at a tangent out of context.
./heLen
>Milan Babuskov wrote:Not. Defrag operates on FILES. The database operates on BLOCKS (pages -
> > Michal Rzewuski wrote:
> >
> >>BTW, Can I run defrag when the database is in use?
> >
> >
> > You can but it is a bad idea. It is almost certain that database will
> > get corrupted if you do.
> >
>
>What kind of Defrag system would let you defrag with it not being safe?
>It should work just fine.
the inventory of which is known only to the database engine). To the OS, a
database is a file; while to the database server it is a neighbourhood
with a map. Of course the map will tend to become invalid if something
external is moving the coordinates of arbitrary chunks of disk.
Of course don't defrag a partition that contains a file that is open for
reads and writes - as an open database is. The database engine can't be
predicted to write into the correct block if that block is moved by an
external operation. Just watch the graph during a defrag: the OS protects
its own files (system files) - they never get moved.
My comments about defrag were in the context of a Restore - why the Restore
was extraordinarily slow and part of a strategy to make the disk storage
more efficient. It's always a bad idea to hijack part of another thread
and run off at a tangent out of context.
./heLen