We have been using SA12 for quite sometime now without any problems, yesterday morning we started experiencing server crashes every 30-60 minutes, they continue to happen today. I have applied the latest EBF 12.0.1.3519. I've read a number of posts on the forum and applied the following to the server startup options: -o "/usr/jobbeat/server_log.txt" -oe "/usr/jobbeat/server_start_log.txt" -os 1M When the server stops there are no error messages written to the log files, I've also run dbsupport -lc but it tells me there are no unsubmitted reports found, I've looked in the DB files directory and there are no dump files, I've also searched the rest of the system and could not locate any files. So it looks like the server shuts down without being able to write any log entries or create any dump files. So at this stage I have no idea what is causing the problem and how I can track it down. Any help greatly appreciated. Regards, Etienne. asked 16 Apr '12, 21:16 etienne |
Do the system event logs report anything for SQL Anywhere?
Can you post the tail lines of the server log?
If this is a critical application, you may want to contact support for direct one-on-one communication to help resolve the issue.
See: http://www.sybase.com/contactus/support/
Hi Tyson,
Thank you for your response it's much appreciated. Here are the last few lines before the crash and then the output on the restart of the server from the messages log these messages are the same as the one's written to the log file specified using the -o option:
The log that you have posted shows that you are using Linux. Since you are not seeing any core files check that you have set core file size to unlimited (i.e. ulimit -c unlimited) before starting your server - Since it appears that you are starting your server as a service you may need to edit the SA_jobbeatasa script in /etc/init.d to do this (i.e. just add "ulimit -c unlimited" to the script before it sources dbsvc).
Since you are seeing the crash fairly regularly I suspect that something has corrupted your database and the server is hitting this corruption every 30-60 minutes in a unexpected way and hence it is not being caught before the server dies. You may want to run dbvalid on the database to check for corruptions?
Hi Mark,
Thanks you for the suggestions, I will make the change to the service startup script as suggested.
I did a complete unload/reload into new database files last night as I thought there may be a corruption as well. Is this enough or should I still do the dbvalid?
Thanks again.
No need to do a dbvalid on the new database.... unless you continue to see the crash. If you do see the server crash (disappear) on the new database then you might be hitting a different problem and you will likely need to contact Tech Support to help you diagnose the issue.
It crashed again just now. I did set the ulimit(see below) and still no core files:
We have a support contract so I did try and contact support but they were unavailable (in Australia), I will try and contact them again.
Thanks.
Note that since you are running your server as a service the CWD of the process will be / ... so perhaps your core file(s) are being placed someplace else on your disk (if they are being generated). Check your /etc/sysctl.conf file (or /proc/sys/kernel/core_pattern) to see if a 'core_pattern' has been set on your system. Failing that you may want to run 'find . -name core\* -print' to find all core files on your system.
Customer Support is usually available 8 a.m - 6 p.m. (although this varies by country), Monday through Friday in your local timezone. See: http://www.sybase.com/contactus/support/ for details.