Difference between dbeng and dbsrv when dealing with damaged files

[Former Member]

We had the following situation several times:

A computer was shutdown incorrectly due to a bluescreen. Afterwards, one of the database services could not be started, writing the following entry into the Windows Event Log.

Page 0x0:0x188761 for requested record not a table page

We created a copy of the file. That was possible. But several attempts to start dbsrv on the original database file, failed.

However, dvsrv could start with copies of the file. And when trying to use dbeng to start the original database file, this worked as well. The file was modified by dbeng. And after that, dbsrv could again open the file.

Using chkdsk on the computer, we found that the file system was damaged by the unexpected shutdown.

Question is now: Do dbeng and dbsrv a different behaviour with regard to opening database files that may be affected by a damaged file system after a hardware crash? Are there options to either tell dbeng to use the same behaviour as dbsrv or tell dbsrv to use the same behaviour as dbeng?

Some clarification:

I do not ask about the source of the problem. It is clear that the irregular Windows shutdown damaged the file system.

I am also not worried with restoring data from the database. The data in this database is highly transient. Lots of data is written and then within minutes processed and the results of processing stored elsewhere (sent to a different computer). Data is deleted from the database automatically within a couple of days.

The easiest step to repair this specific database is to replace it with an empty version.

Question is rather: How can I make dbsrv behave the same as dbeng and ignore or automatically repair the damages. Note that the dbsrv and dbeng from the same SQL Anywhere installation was used for the test. The test was done on the original computer where the problem occurred immediately after it occurred.

During the test there was also no other process active that would try to connect to the running dbsrv. dbsrv quit all by itself when started, while the first attempt to start dbeng succeeded and then also somehow repaired the database, because afterwards the same dbsvr that had failed to load the database could successfully load it after it had been accessed by dbeng once.

Some additional information:

This happened with SQL Anywhere 16.

The database only consists of one file. There is no sort of mirroring and using a transaction log is also disabled for this database.

[VolkerBarth]

Two questions:

1. When comparing the runs of dbeng16 vs. dbsrv16, do they run with the same user context, or is dbsrv16 run as a service?
2. Do you log the console log with -o? Of so, does that tell anything for the failing start with dbsrv16?

[Former Member]

What you are seeing is an "Assertion error". Specifically, that text indicates it is assertion number 201501.

This assertion can occur under a number of different scenarios so I cannot guarantee I know which one you are seeing.
Assertion errors are related to tests in the software for conditions that should never occur. The text of this
assertion indicates we are looking at a bad page (on disk or in cache) though the fact that it continues to
occur would tend to indicate a bad page in your system dbspace.

You should do a full validation of all copies of this database to confirm which files are broken.
{just because you don't see an assertion does not mean you don't have bad pages in the database files
... that just means you haven't needed to visit any pages that might be broken}

Depending upon under what conditions you are getting this, you could maybe side-step bad pages
by not copying the transaction log or avoiding some operation (possibly from other connections,
possibly from other database instances, when up in the production environment).

If you have switched software versions or builds (when you are testing your copies) you may have
side-stepped a bug. This particular assertion can come up in a few bugs that have had fixes.

Moving a file to a different file system or OS can also side-step failures in the media access which
can produce false assertions.

Either way I don't believe this is strictly a difference between those to binaries. If everything else
is the same those should behave in exactly the same way in regards to media access that could
produce this assertion.

[VolkerBarth]

If everything else is the same those should behave in exactly the same way in regards to media access that could 
produce this assertion.

That being said, AFAIK you should usually do a recovery with the same binary as was used before, because the recovery process might be somewhat affected by the particular features of the personal / network engine, such as different number of supported CPUs, concurrent connections and the like... - here's a quite long list of differences.

Say, if the engine has to recover from a situation where dbsrvX had more then 10 concurrent connections, the dbengX process simply would not allow for that.

(Apparently, that's not your issue here.)

[Former Member]

Thanks for the answer. I added some more information to the question to clarify the nature of the question and give some more background information.

[former_member186998]

FYI
1982519 - Assertion Failed : 201501 - Page for requested record not a table page
1959030 - How To Salvage Data When There are Corrupt Pages in the Database