Subject | Re: [firebird-support] Odd problem - inconsistent result set |
---|---|
Author | Helen Borrie |
Post date | 2008-07-09T23:00:02Z |
At 06:30 AM 10/07/2008, you wrote:
You should NOT use the -R switch for your restore.
You can run a gbak -B whilst users are connected. The backup runs in a snapshot transaction. Any changes that occur after the backup starts will not be in the backup.
A backup saves index definitions but not the indexes themselves.
After the backup finishes, use gbak -C to restore the database with a name that is different from the name of the active database. When you are certain that the restore has completed (use the -V and -Y options to get a log). Test the restored database. If it is OK, then do as follows:
1. Ensure all users are offline. Use shutdown with the -Force switch if necessary.
2. Rename the active database file. If renaming does not work then the shutdown has not worked or is still completing. Do not proceed until you are able to rename the file.
3. Now rename the restored file.
Note that, if a restore is interrupted during index creation, the result can be a database with some or all indices not created.
Allowing external programs such as disk-image copy programs, anti-virus and system backup to operate on an open database can corrupt databases. You must make sure that such applications are prevented from touching your database files.
./heLen
>Yes, I mean at run-time. Is there any way to know that my query will give anNo. Index corruptions are very unusual. Something external to the database engine would be the cause. You need to find out why this happens and fix it.
>inconsistent result because of an index corruption?
>>> I do [backup/restore] with a .BAT file, and rename the restored database to the original one. Would you be so kind to show how do you do it?You should NOT perform both backup and restore in a single .bat file.
You should NOT use the -R switch for your restore.
You can run a gbak -B whilst users are connected. The backup runs in a snapshot transaction. Any changes that occur after the backup starts will not be in the backup.
A backup saves index definitions but not the indexes themselves.
After the backup finishes, use gbak -C to restore the database with a name that is different from the name of the active database. When you are certain that the restore has completed (use the -V and -Y options to get a log). Test the restored database. If it is OK, then do as follows:
1. Ensure all users are offline. Use shutdown with the -Force switch if necessary.
2. Rename the active database file. If renaming does not work then the shutdown has not worked or is still completing. Do not proceed until you are able to rename the file.
3. Now rename the restored file.
Note that, if a restore is interrupted during index creation, the result can be a database with some or all indices not created.
>Sorry if was not clear, (my English doesn't help!!)Did you know that there is a Spanish-language support list? You can find it at http://firebirdsql.org/index.php?op=lists
>I meant: how often isIndices should not break and the database engine does not break them, so you are right to be worried.
>recomended to do a *backup-restore circle* in order to purge the database and
>reconstruc all its indices. I didn't know indices can broke in a database and
>I'm a bit worried about that !!
>By the way when should I be worried about bad indices?A client PC crash cannot damage them. A server crash could damage them if the crash was caused by a hardware defect, disk full condition, etc.
>A PC crash can damage them?
>An electrical energy cut?If you are running with Forced Writes off then a power cut can corrupt a database. Otherwise, a power cut can cause uncommitted data to be lost. However, a surge when power is restored can damage your hard disk.
Allowing external programs such as disk-image copy programs, anti-virus and system backup to operate on an open database can corrupt databases. You must make sure that such applications are prevented from touching your database files.
>a Hard disk full?Certainly.
./heLen