Assertion failed 100910 - Error deleting transaction log file

[Former Member]

Hi,

Following was the error observed in one of our embedded sybase DB ERROR Assertion failed: 100910 (10.0.0.2465) Error deleting transaction log file

Could you please let me know the possibilities why it was trying to rename/delete the transaction log file ? There is no -m option used.Neither any db backup is also running

Following is the script for DB startup

start /D "<<path>>" dbsrv10.exe -qs -x tcpip(BroadcastListener=NO;host=XXX;port=8080) -qi -o "<<log file="" path="">>" -on 2m -n <<server name="">> "<<db name="">>"

[MarkCulp]

This assertion means that your transaction log file is corrupted due to a bug that was fixed on 2003 Dec. 19 - CR #341887 (i.e. more than 10 years ago).

Under certain circumstances, rows inserted by means of the wide
insert facility can contain string values that are longer than the
maximum imposed by the definition(s) of the underlying column(s). In
other words, the server can fail to truncate inserted column values,
as necessary. The un-truncated values are inserted in both the
database and the transaction log. Under normal circumstances, the
user is not likely to notice any problems with the database because
the values are properly truncated when they are read back later.
However, the un-trancated values in the transaction log can impose
problems for utilities that need to translate and/or replicate the
operations from the transaction log. In order for the corruption
to occur a wide insert with the following characteristics must take
place for one or more columns:

1. The column value in the first row  must contain be NULL,
2. A subsequent row must contain a string value that does not exceed
   the maximum size allowed for the column, and
3. The above must be followed at some point by a row containing a
   column value that needs to be truncated before insertion.

This problem has now been fixed. A new server assertion ( number
100910 ) has been added to prevent this corruption from happening in
the future.

You will need to rebuild your database.

---

I'll add that this assertion has long been removed from the software (in v11).

[jeff_albion]

There are only a few times during operation we attempt to 'delete' the log file during database operation.

1. Use the -m switch with dbeng or dbsrv on start-up. (There was an earlier issue with a similar assertion and -m, solved in CR #365147 - but you should have this fix in 10.0.0.2465)
2. Run a backup using dbbackup -x or dbbackup -r, or BACKUP DATABASE TRANSACTION LOG TRUNCATE or BACKUP DATABASE TRANSACTION LOG RENAME. Note that there was also a fix in CR #570650 regarding this issue in 11.0.1.2250 involving virus scanners/third party utilities touching the file - there is no fix available for 10.0.x).
3. Using dbmlsync -x, when synchronizing to MobiLink.

What other utilities do you have running on this system that may be touching the transaction log - virus scanners? Third-party backup software? Security auditing software?

You can use the Microsoft Sysinternals Tool 'Process Monitor' to scan for other processes touching the transaction log. (e.g. Filter » Filter... » [Path] [Is] 'c:\\database\\database.log' then [Include])

[VolkerBarth]

Just to add:

4. Using dbremote -x, when replicating with SQL Remote.

[Former Member]

Thank you Mark and Jeff !! 1) We suspected that a virus scanner process would have been scanning the transaction log file simultaneously when the system was trying to delete/rename it. We disabled the scanner process from touching the transaction log file and we haven't seen any re-occurence of the issue. But we are not sure - when would the system try to delete/rename transaction log file again ?

2) The startup command does not have any -m option used start /D "<<path>>" dbsrv10.exe -qs -x tcpip(BroadcastListener=NO;host=XXX;port=8080) -qi -o "<<log file="" path="">>" -on 2m -n <<server name="">> "<<db name="">>"

2) There is no backup utility running and there is no dbremote or dmlsync being used

Could you please let me know - are there any other possibilities as to when the system would try to delete the transaction log ?

[VolkerBarth]

Besides "no backup utility running" - are there other activities to do a backup (i.e. by issuing a BACKUP DATABASE statement or by an API-based way to do backups, say by using the DBTools DBBackup() function, or by means of a maintenance plan)?

As to other possibilites: Jeff has listed the relevant ones (one might still add a further log-scanning tool, namely the Replication Agent aka the Log Transfer Manager utility (dbltm), in the rare case you are using SQL Anywhere with the Sybase Replication Server).

However, I remember some third-party "clean-up" tools that try to erase files with the .log extension, just as these are often left over from installations and the like. We had users that corrupted their (non-running!) databases that way by losing their log. However, I would doubt that this would raise such an exception.

---

FWIW, your v10 version 10.0.0.2465 is a very old v10 version, IIRC, so there are bunches of newer fixes available, even though v10 has been EOL'ed in 2012. Possibly that error would not occur with a later version of 10.0.0/10.0.1...