Subject | Restore problem (internal gds software consistency check / cannot start thread / failed to create database) |
---|---|
Author | Antti Nivala |
Post date | 2007-10-17T14:27:33Z |
We have encountered a problem at a couple of customer sites during
database restore. The systems are using Firebird Embedded 2.0.1.12855 on
Windows Server 2003 R2.
In all cases, we have received the following error message from
Firebird:
internal gds software consistency check (cannot start thread)
- failed to create database D:\TEMP\MFI5E9.tmp
(The file name of course varies.)
The sequence that leads to this problem is simple:
1. Back up the database (we use Firebird Services API).
2. Attempt to restore the backed up database to a temp-file named new
database (again, using Firebird Services API).
The backup phase runs fine, but in the very beginning of the restore
phase, we get the error message. Sometimes the problems disappears if we
restart the process. However, we now have a customer case where the
problem occurs repeatedly. The database is about 1.5 GB, and the backup
file is about 700 MB.
I have verified that file system access rights cannot be the problem.
Our process is running using the Local System account, and the folder
"D:\Temp" has its rights set to "Everyone Full Control". With FileMon,
we see that the process succeeds in creating the temp file (e.g.
D:\TEMP\MFI5E9.tmp), but does not actually write to it before the
restore operation fails.
Any ideas what could be causing this problem?
Antti
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/
database restore. The systems are using Firebird Embedded 2.0.1.12855 on
Windows Server 2003 R2.
In all cases, we have received the following error message from
Firebird:
internal gds software consistency check (cannot start thread)
- failed to create database D:\TEMP\MFI5E9.tmp
(The file name of course varies.)
The sequence that leads to this problem is simple:
1. Back up the database (we use Firebird Services API).
2. Attempt to restore the backed up database to a temp-file named new
database (again, using Firebird Services API).
The backup phase runs fine, but in the very beginning of the restore
phase, we get the error message. Sometimes the problems disappears if we
restart the process. However, we now have a customer case where the
problem occurs repeatedly. The database is about 1.5 GB, and the backup
file is about 700 MB.
I have verified that file system access rights cannot be the problem.
Our process is running using the Local System account, and the folder
"D:\Temp" has its rights set to "Everyone Full Control". With FileMon,
we see that the process succeeds in creating the temp file (e.g.
D:\TEMP\MFI5E9.tmp), but does not actually write to it before the
restore operation fails.
Any ideas what could be causing this problem?
Antti
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/