|
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="">>" |
|
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). |
|
There are only a few times during operation we attempt to 'delete' the log file during database operation.
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... » Just to add: 4. Using dbremote -x, when replicating with SQL Remote.
(03 Jan '14, 10:10)
Volker Barth
Replies hidden
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 ?
(03 Jan '14, 15:27)
Shilpa
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...
(04 Jan '14, 05:54)
Volker Barth
|