Automatic Restart

"Self-management" is very important in SQL Anywhere. It central to the Number One Hallmark of SQL Anywhere:

Embeddability: SQL Anywhere can be easily embedded inside other applications. It combines high performance with very small memory footprint. SQL Anywhere contains a range of features to enable self-management and maintenance in frontline environments, including features that enable optimization of computer resources, self-tuning for improved performance, and simplification of remote installation and support.

So why does SQL Anywhere grind to a halt and wait for a response when it throws an assertion? In a typical embedded application, there's no operator at the console, no DBA watching for something to go wrong.

In most shops, even those with DBAs, the action most often taken after an assertion is to restart the server. Nine times out of ten, perhaps 99 times out of 100, that's the right thing to do: Get the server up and running and responding to requests. Have a look at the assertion later.

In many shops, restarting the server is an absolute requirement: downtime is worse than damaged data. It should be possible to specify "restart immediately after assertion", perhaps not as the default behavior but definitely available, not like the current requirement to click, wait, fumble and hesitate through those mystifying dialog boxes.

"Why not use a Mirror Server?"

Because High Availability isn't appropriate for some small-footprint embedded applications.

Because High Availability isn't appropriate for some high-throughput applications which process gigabytes of data on an hourly basis.

Because High Availabliity doesn't get the failed partner server up and running after an assertion.

"It's too dangerous!"

Here... let me introduce you to Mr. CEO... you can tell him how that errant data page is critically important, how it's necessary to keep his applicaton offline while you figure out what went wrong... he'll give you a new definition of "dangerous".

What's worse than an assertion?

Well, if your SQL Anywhere engine has just thrown an assertion and ground to a halt, it might be hard to imagine something worse than an assertion.

But there is: It's when your SQL Anywhere server goes completely unresponsive, grinding to a halt without throwing any error message.

So there's another feature SQL Anywhere needs: "restart when server goes catatonic".

If "restart" is too hard, how about simply "stop after assertion" and "stop when unresponsive"? Then the dbspawn / dbsrv12 commands can be wrapped inside a command file GOTO loop that immediately starts the server after it stops.