Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.

Recently migrated one of our large customer from 7.04 to 12 on a Solaris Sparc box. About 100 or so users in the field all banging away on a dispatching web app that is highly transactional. Aside from outer join issues and having do rewrite some queries everything ran good for about 2 weeks. Yesterday we saw the dbsrv12 process disappear twice in a 2 hour period. We had to refire the DB and restart all of our client facing apps (webservers, app servers, etc.) to get it back up. Everything came back up but then it happened again. What is the best way to see what is causing this as their is nothing in any log files etc.? The last time I restarted it, I used the -oe command line switch to log the errors to a file. Is this the preferred method to capture fatal errors? Is there anything else we should have turned on? Any help is greatly appreciated.


asked 27 Apr '11, 09:53

Codecranker's gravatar image

accept rate: 20%

edited 28 Apr '11, 12:56

Martin's gravatar image


One thing that comes to mind is to verify that you have sufficient swap space to cover the maximum cache size that may be used by the server. Solaris allows memory to be overcommitted which means that if the server grows the cache and accesses new memory when there is no swap available, it will die with a SIGBUS. The default maximum cache size in v12 is significantly larger than it was in v7. You can add more swap space or control the max cache size by using the "-ch" command line option on the server. If you are not already providing a "-ch" parameter, you can determine what the server chose for the max cache size by looking at the messages written during startup (use -o switch, use Sybase central, etc) or SELECT property('MaxCacheSize') in SQL.

permanent link

answered 27 Apr '11, 10:04

John%20Smirnios's gravatar image

John Smirnios
accept rate: 37%


In addition to the cache, the temp file on Solaris would also consume swap space because it is usually stored in /tmp, which is normally set up as TMPFS (an in-memory file system). You can export SATMP=/path/to/somewhere/on/disk if you want to put your temp file on a real disk.

Out-of-memory situations seem most likely since there's nothing in your log file (meaning the process died very suddenly). However, the server might be crashing for other reasons. You might want to enable core files and have a look at the crash dump that gets generated. If you can't make sense of it, you can open a case with tech support and we would be able to look at it for you.

Another possibility is that the server is not crashing at all, but is being killed. We've seen cases where an unrelated process is running away in the background and "cleaning up" files and processes that it doesn't think should be there, thus causing the SA server to shut down unexpectedly. This is probably not what you're seeing, but we can't rule it out just yet.

(27 Apr '11, 11:17) Phil Mitchell
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 27 Apr '11, 09:53

question was seen: 2,833 times

last updated: 28 Apr '11, 12:56