How i can trace error?

[Former Member]

Hi All!

i have sybase sql anywhere 9 (9.0.2.3951) running on Centos 6.5, and every night the database stop working! Seeing the error log, i found only: 07/08 07:34:13. Fatal error: database error But i can't know what database has error or whats happening. How i can have more detailed error?

The command used to start database is this:

dbsrv9 -nserver9 -cl3g -ch7g -xTCPIP{myip=192.168.10.247} -ud -gl all -gd all -gk all -o/var/log/log_servidor -oe/var/log/log_servidor_error /dados/bancosdlt/Patrim/patrim.db /dados/bancosdlt/educa/Educa.db /dados/bancosdlt/compras/compras.db /dados/bancosdlt/estoque/estoque.db /dados/bancosdlt/Folharh/Folharh.db /dados/bancosdlt/Sapo/sapo.db /dados/bancosdlt/tributos41/integra.db

thanks a lot!

DRauber

[Former Member]

If you are only looking at th -oe log file that could be the reason for the lack of information.

Try adding -z -o var/log/console_log_servidor and see if that captures more information. [I believe the error will tell you the database file in that fail; with your version. ]

You can also turn on detailed request logging (-zr all) and see what was running/requested at the time of the fatal error.

All log files -o and -zo can be limited in size using the -os and -zos switches.

Best of luck.

P.S. it is unforturnate you cannot reproduce this error at will then you could just start up one database at a time ...

[Former Member]

@Nick

Yesterday i have used -zr all, and -o, but, the same line is writed to the normal log file: 07/08 07:34:13. Fatal error: database error No aditional information whas printed :/ Thanks

[Former Member]

Okay. But maybe you can narrow it down from the -zr information?

[Former Member]

Pretty hard! at 00:00 time, the system start a lot of processes for integration, export and import data. whit the parameter -zr all, my log for any night has more then 10.000.000 of lines. I was read some lines before the fatal erro, and sounds like no problem :/ Do you have any clue?

[Former Member]

I understand that it can be difficult to read a -zr all log output. In fact 10 million lines is not unbelievable. As Breck has already suggested technical support can help with that effort.

As to "any clue", one would need to be able to review the information gathered to offer any additional suggestions. If it helps any, I usually identify all of the connections that are still active/connected and work the last requests for each of those connections ... backwards ... usually there is only a handfull of those to be concerned with. Starting from the beginning just means you have to get past all the activity that is not [significantly] contributing to the issue/analysis.

[Breck_Carter]

It is possible you will not get any more information about this symptom, and your best hope may be to force SQL Anywhere to reveal some different symptom caused by the underlying problem.

Step 1: Make sure you have a current full backup (.db and .log) of each and every database.

Step 2: Try running dbsrv9 and dbvalid -f -o against each backup database, to see if there are any problems in the data.

Step 3: Run an extensive check of the RAM on the computer, to make sure there are no problems that can masquerade as application errors (where SQL Anywhere is just another application as far as the RAM is concerned). If the RAM check doesn't take a very long time to run, it's not worthwhile 🙂

Step 4: Try moving the server to a different computer (different RAM, different disk).

Step 5: Contact SAP Tech Support... maybe that should be Step 2, but you may encounter voices on the phone that insist you must upgrade to Version 17.

AFAIK SQL Anywhere 9 doesn't have the same "crash dump" facility later versions have.

[Former Member]

Breck is correct in noting that a version 9 dump is different from later versions. What is worse, there can be little to no ability to diagnose from those (depending upon exact version a build of the software being used). The dump file name (I believe) was sadump.dmp. It was usually found in the %windir%\\temp directory and you only get one; from the last/latest crash.

If none of our backups are good then I too would recommend going to new hardward to see if this is just an issue with your machine; as Breck has also suggested.

We always recommend validating or testing COPIES of backup files [as in Breck's Step#2).

Good luck