Configuring a SQL Anywhere server to autorestart after a fatal error
Configuring a SQL Anywhere server to auto-restart after a fatal error
TABLE OF CONTENTS
WINDOWS SOLUTION ..................................................................................................................................... 3
LINUX SOLUTION ............................................................................................................................................ 4
UNIX SOLUTION ............................................................................................................................................... 6
2
Configuring a SQL Anywhere server to auto-restart after a fatal error
SQL Anywhere is used in many unattended and 24/7 operations where the database server is configured to
run continuously without being monitored by a database administrator. However, sometimes unexpected
errors can cause the database server to terminate or enter a non-operational state, with no administrator
available ready to recover. It is therefore desirable to implement a process that automatically restarts the
database server whenever the server fails. Currently, SQL Anywhere does not have built-in support for
automatically restarting the database server after a fatal error. However, it is possible to emulate the autorestarting of a database server by using third-party utilities designed to monitor processes. In this document,
we provide examples of such solutions for Windows and UNIX.
General-purpose utilities cannot detect whether a running process is in an error state; however, they can
determine whether a process is no longer running. These solutions require that the database server be
configured to terminate fully on a fatal error. This is accomplished by including -uf abort as a startup
parameter.
While this article presents solutions specific to the SQL Anywhere database server, the general approach
can also be used to create monitor solutions for other database services, such as MobiLink.
WINDOWS SOLUTION
The Windows operating system provides the sc.exe utility to monitor the status of Windows services. The
database server needs to be run as a Windows service to make use of this utility. The utility cannot be
applied to database services that are autostarted, launched directly from a command line, or launched by
dbspawn. In addition, this solution does not apply to Windows CE, as the operating system does not support
services.
To begin, create the database server as a Windows service. In the following example, we create a Windows
service named myserver, which runs a network server with one database:
dbsvc -as -t network -w myserver “-uf abort c:\mydatabase.db”
By default, the service is to be started manually. However, we can configure the service to start
automatically:
dbsvc -as -t network -s Automatic -w myserver “-uf abort c:\mydatabase.db”
The dbsvc utility creates a Windows service with a SQLANYs_ prefix. In this example, the database service
myserver is identified by the operating system as SQLANYs_myserver.
The sc.exe utility allows the user to specify the action to take on each of the first, second, and subsequent
failures. The basic syntax of the command is:
sc failure service_name reset= time actions= action/delay/…
The reset= argument specifies the number of seconds to wait after the last failure before resetting the fail
counter. In other words, if two failures occur within this time threshold, they are considered consecutive
failures.
The actions= argument specifies failure actions. The value is in the form of action1/delay/action2/delay/…
where delay is the amount of time to wait, in milliseconds, before taking the action before it. An actionN/delay
entry specifies the action on the Nth consecutive failure. The last entry applies to all subsequent failures after
N failures.
Sample recovery actions for myserver include:
•
Restart the database service each time the service fails (with a five-second delay):
sc failure SQLANYs_myserver reset= 600 actions= restart/5000
3
Configuring a SQL Anywhere server to auto-restart after a fatal error
•
Restart the database service up to two times. If the service fails again, reboot the computer. The fail
count will reset to 0 after the service runs for 10 minutes:
sc failure SQLANYs_myserver reset= 600 actions=
restart/5000/restart/5000/reboot/5000
In this case, the server should be configured to start automatically.
•
Run a custom script c:\myscript.bat each time the service fails:
sc failure SQLANYs_myserver reset= 600 command= “c:\myscript.bat” actions=
run/5000
For more information see http://technet.microsoft.com/en-us/library/cc742019(v=ws.10).aspx
The auto-restart action is now configured. To start the database server:
dbsvc -u myserver
To stop the database service and disable monitoring:
dbsvc -x myserver
LINUX SOLUTION
On Linux platforms, you can restart a database server using Monit, a third-party utility that monitors
processes on UNIX. Monit is run as a UNIX daemon and periodically polls the processes being monitored.
Monit supports various actions, including starting and stopping the process, invoking custom scripts, alerting
the users using email notifications.
Monit can be downloaded from: http://mmonit.com/monit/
This solution uses the dbsvc utility for managing the database service. This utility is supported on the Linux
platform. The next section provides a general solution for other UNIX platforms.
To begin, use the dbsvc utility to create a database service named myserver, including the -uf abort startup
parameter:
dbsvc –as –t network –w myserver –n myserver -uf abort
/home/myuser/mydatabase.db
Next, start the database service:
dbsvc –u myserver
Monit identifies processes by matching the process with a process ID stored in a PID file. When dbsvc is
used to start a SQL Anywhere service on Linux, a PID file with prefix SA_ is created in the /var/run directory.
For example, the database service created in the previous step will have a PID file named SA_myserver.pid.
This file contains the PID of the process.
Monit uses a configuration file to define rules for checking and responding to changes to processes. Monit
comes with a default configuration file that can be edited. Alternatively, you can create your own Monit
configuration file.
Create a configuration file named monit.conf, as follows:
4
Configuring a SQL Anywhere server to auto-restart after a fatal error
--------------------- monit.conf --------------------# Start Monit in the background (run as a daemon):
set daemon
60
# check services at 1-minute intervals
# Enable access to the Monit daemon via HTTPD
set httpd port 2812
and use address localhost
allow localhost
# Monitor rules for the database server
check process myserver
with pidfile /var/run/SA_myserver.pid
start program =
"/home/myuser/sa16/bin64/dbsvc -u myserver"
as uid 100 and gid 100
stop program =
"/home/myuser/sa16/bin64/dbsvc -x myserver"
as uid 100 and gid 100
if not exist then restart
if 3 restarts within 10 cycles then unmonitor
In this configuration, the Monit daemon polls the database server every minute. If the database process is
not running, Monit restarts it on behalf of the user (assume uid=100). To prevent repeated unsuccessful
restarts, the process is stopped if three restarts occur within a 10-minute window.
In the configuration file, the entries start program and stop program define the commands invoked to
start and stop the database. The shell that Monit uses is different from a normal shell, and some environment
variables may not be defined in the Monit shell. Therefore, the commands above should be written using the
full path.
You can configure email notifications to be sent when Monit detects changes in a process or performs an
action, set the email server and the email addresses of the recipients in the configuration file:
set mailserver
set alert
smtp.mycompany.com port 25
admin@mycompany.com
To start monitoring, create the Monit daemon, running with root privileges. Use the -c parameter to specify
the path of the configuration file. If the -c parameter is not set, Monit will try to search the default locations for
a configuration file.
monit -c monit.conf
Once the daemon is created, start monitoring the service by calling the following command:
monit monitor all
To stop monitoring the service:
monit unmonitor all
5
Configuring a SQL Anywhere server to auto-restart after a fatal error
For more information about Monit functionality, see http://mmonit.com/monit/documentation/monit.html.
UNIX SOLUTION
On other UNIX platforms, you can also use Monit to restart a database server. The instructions are similar to
that described in the Linux section, with a few differences. Because the dbsvc utility is not available outside
of Linux, you need to invoke the executables directly to start and stop a database server.
To start a database server named myserver:
dbsrv16 -n myserver -uf abort /home/myuser/mydatabase.db
The PID file is stored in the temporary directory defined by the environment variable satmp. If the
environment variable is not set, the PID file is stored by default in the /tmp/.SQLAnywhere directory.
Therefore, the full path of the PID file for myserver is:
• [$satmp]/myserver /pid, or
• /tmp/.SQLAnywhere/myserver/pid
The following is a sample configuration file for Monit:
--------------------- monit.conf --------------------# Start Monit in the background (run as a daemon):
set daemon
60
# check services at 1-minute intervals
# Enable access to Monit daemon via HTTPD
set httpd port 2812
and use address localhost
allow localhost
# Monitor rules for the database server
check process myserver
with pidfile /tmp/.myuser/.SQLAnywhere/myserver/pid
start program =
"/usr/bin/env SATMP=/tmp/.myuser/.SQLAnywhere/
/home/myuser/sa16/bin64/dbsrv16 -n myserver –uf abort
/home/myuser/mydatabase.db"
as uid 100 and gid 100
stop program =
"/home/myuser/sa16/bin64/dbstop -c UID=DBA;PWD=sql mydatabase"
as uid 100 and gid 100
if not exist then restart
if 3 restarts within 10 cycles then unmonitor
6
www.sap.com
© 2015 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form
or for any purpose without the express permission of SAP SE or an SAP
affiliate company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products
marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in
the express warranty statements accompanying such products and services,
if any. Nothing herein should be construed as constituting an additional
warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop or release any functionality mentioned therein. This document,
or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform
directions and functionality are all subject to change and may be changed by
SAP SE or its affiliated companies at any time for any reason without notice.
The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking
statements are subject to various risks and uncertainties that could cause
actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which
speak only as of their dates, and they should not be relied upon in making
purchasing decisions.