Subject | RE: [ib-support] Re: WRONG PAGE TYPE IB6 ODS10 |
---|---|
Author | Alan McDonald |
Post date | 2002-09-08T22:03:13Z |
Some light reading
http://www.ibphoenix.com/main.nfs?a=ibphoenixApp&l=;IBPHOENIXAPP.KNOWLEDGEBA
SE;ID='320'
Now when the last person disconnects (and you are watching the filesystem
directory), you will notice the database receive the current datetime stamp.
It is always best practice IMHO and in my experience, even if you are sure
that noone is connected, to gbak the file and not copy the physical file.
When you say often move the location - how are you sure that noone is
connected?
As an "agent" if you have none, use
net stop "Interbase Guardian"
net stop "Interbase Server"
in a batch file before the scheduled tape backup, then net start "Interbase
Guardian" only command after the backup, you'll be sure of getting a file
copy of the gdb file without connections... BUT it's alway best practice to
instead do a gbak of the database before the scheduled backup and ignore the
gdb file in the backup routine. Only backup the gbak file.
When you say the backups have not been good - How do they know? Have they
ever tried to restore a backedup gdb file - Is that how they know? If so -
therein lies the reason for the corruption.
You should also think about scheduling regular (e.g. once a month) backups
and restores in the same operation, to flush the garbage out and restore
some nice shape to your database.
Alan
-----Original Message-----
From: goodieauk [mailto:andy@...]
Sent: Monday, 9 September 2002 6:55
To: ib-support@yahoogroups.com
Subject: [ib-support] Re: WRONG PAGE TYPE IB6 ODS10
http://www.ibphoenix.com/main.nfs?a=ibphoenixApp&l=;IBPHOENIXAPP.KNOWLEDGEBA
SE;ID='320'
Now when the last person disconnects (and you are watching the filesystem
directory), you will notice the database receive the current datetime stamp.
It is always best practice IMHO and in my experience, even if you are sure
that noone is connected, to gbak the file and not copy the physical file.
When you say often move the location - how are you sure that noone is
connected?
As an "agent" if you have none, use
net stop "Interbase Guardian"
net stop "Interbase Server"
in a batch file before the scheduled tape backup, then net start "Interbase
Guardian" only command after the backup, you'll be sure of getting a file
copy of the gdb file without connections... BUT it's alway best practice to
instead do a gbak of the database before the scheduled backup and ignore the
gdb file in the backup routine. Only backup the gbak file.
When you say the backups have not been good - How do they know? Have they
ever tried to restore a backedup gdb file - Is that how they know? If so -
therein lies the reason for the corruption.
You should also think about scheduling regular (e.g. once a month) backups
and restores in the same operation, to flush the garbage out and restore
some nice shape to your database.
Alan
-----Original Message-----
From: goodieauk [mailto:andy@...]
Sent: Monday, 9 September 2002 6:55
To: ib-support@yahoogroups.com
Subject: [ib-support] Re: WRONG PAGE TYPE IB6 ODS10
--- In ib-support@y..., "Alan McDonald" <alan@m...> wrote:
> out of interest -
> Does this mean you can not make any connections to the database at
this
> time?
Yes that is correct. If I could I would it is likely I cold do a
gbak of only the metadata and then datapump out the data to a new
database.
> Have you physically moved the gdb file at some stage?
This particular Gdb has stayed on the same drive in the same location
for at least 12 months.
I am intrested though why moving a GDB should be an issue as I
understand it a GDB is extremely portable and infact I often have to
move the physical location of GDB's on sites.
> Have you being doing regular backups and restores over this last
year?
Yes the Client has been doing backups. However against my advice
they have not been using backup software that has an IB Agent. The
result has been that the actual backups have not been good. Yes and
the Client does now except that the should be checking their backups.
Yahoo! Groups Sponsor
ADVERTISEMENT
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]