--- In firebird-support@yahoogroups.com, "Artur Anjos" <artur@a...>
wrote:

> > Don't we have this just now and is'nt it called "shadow"?
>
> No, we don't. You must stop the database before you copy the shadow.

At that

> time, it will be more easy to copy the database.

Arthur. No, I must not :-P I can simply delete references to shadow
from main database using gfix -kill. Can't remember exactly will
shadow be physically deleted or not, but my sclerosis tell me - no, it
will be deleted only by Drop Shadow isql command. Even if sclerosis
swindle me, I should stop server for a very short time just to move
shadow into inaccessible for server location. If file is not opened by
server, last can't trace it's rename even on *nix. To be honest,
personally I never experimented with killing healthy shadow on the fly
having in mind to use it as copy and can't surely say this copy will
be usable. I hazily recall there is article by Dalton Calford
somewhere on this subject by can't find link.

> Do you know anyone using a shadow in production? :-) ).

Yes. It's me :) Not just now, but I used shadow in 1998-2000 with
IB4 on SCO and at least two times it saved half a day of work for my
company when primary HD was damaged.

> Think of it as "creating on the fly a new database file freezed in

time".

>
> Shadow is dinamic.

Sorry, but I can't think about page-level copied on the fly database
freezed in time on background of regular user's activity. Perhaps I'm
getting too old :) And I backup my 6Gb database in less than half an
hour now, it's not a problem and I have a doubt page-level copy will
be significantly faster. Problem is - I never can be sure .gbk is
restorable and control restore reqiures more than 4 hours. I think
creating a shadow and one minute stop of service to rename and kill it
is enough to solve the problem you mentioned.

> (
> Maybe we should continue this in Firebird-general. I love to see

Helen

> wearing that beatifull hat, but she is to busy now with the book
> )

Helen and Artur, sorry, I did'nt moved the discussion because of 2
reasons - I'm extremely busy this week and I can't see further
evolution of discussion just now - I reminded forgotten old feature
and suggested features on which no one reasonable person will not
object but not for nearest perspective.

Best regards, Alexander.