On one test system with 126.96.36.19956 on Win32, I cannot start the database after a regular machine shutdown. When starting the database server, it issues error SQLCODE -1006 (SQLE_FILE_BAD_DB, "Unable to start specified database: '%1' is not a valid database file"). Rather surprising, as the shutdown was a regular one.
Well, of course I have a backup, and the file has been validated successfully just before the backup was done (yep, I'm aware that validating the backup is even smarter...). Unfortunately, the backup file just issues the same problem.
FWIW: DBLOG doesn't work against the database file (it issues the same error), whereas the log can be translated successfully.
Are there any hints what might be the cause for the bad file? I do not have hints for disk problems, and the SQL Anywhere 12 installation seems o.k. - at least I can start other databases...
As said, it's a test system so there's no problem with lost data here, but I'd like to get to know what could have happened.
Sorry folks, I have not been very active on the forum lately and am therefore very late with my reply.
As Volker has already indicated in a different thread, the documentation states very clearly that a database should be backed up prior to upgrading and should be restarted immediately upon a successful upgrade. What the documentation does not state very clearly is that a failed upgrade WILL ALWAYS lead to an invalid database file. The reason is quite simple. At the start of the upgrade process, the server hammers the set of bytes in the database file that indicate whether or not this database is valid. These bytes are then restored at the end of the upgrade process provided the upgrade was successful. The whole idea is that if the upgrade is unsuccessful for whatever reason, then since we cannot be certain what state the database is in with respect to the partially updated catalog tables, procedures and options, we make it impossible for the user to continue using the database. Instead, we expect that the user will be able to revert to their backup copy.
Now, with respect to your failed upgrade Volker, I have reproduced the problem that you are seeing and have opened a support case to have the problem fixed.
answered 29 Jun '11, 07:32
Its hard to tell why/how your database file has become corrupted without looking at the file itself. Since you are getting the "... is not a valid database file" error message it would imply that page zero has become corrupted.
You may want to read the SQL Anywhere I/O Requirements for Windows and Linux whitepaper since a misconfigured computer can lead to this type of corruption.
answered 27 Jun '11, 10:02
Mark's idea is a good path to go down: if you type: "dbinit new.db" and compare the first 4096 bytes to the original database's 4096 bytes, are there any major areas on the original page that look like they might be missing? Opening a technical support case might be another good way to go, so that we can bring the file in and take a look.
answered 27 Jun '11, 11:05
Run a test to check for bad RAM.
Bad RAM can mimic, and then permanently cause, disk errors, so it is a huge deal. If you suspect bad RAM, and you care at all about the contents of your hard drives, shut your computer off immediately because ANYTHING you do can result in permanent damage.
Then get/build a bootable RAM checker like http://www.memtest86.com/
answered 27 Jun '11, 15:30
By trying to upgrade from 188.8.131.5224 to 184.108.40.20656 - at least in my case:(
Cf. the bunch of comments on Jeff's answer...
FWIW, I've attached the translated log from the
ALTER DATABASE UPGRADE PROCEDURE ON