![]() | ![]() |
Home |
|
|
Installation Guide Adaptive Server Enterprise for Linux/Intel |
|
| Chapter 7 Starting and Stopping Servers |
Chapter 7
This chapter describes how to start and stop Adaptive Server, Backup Server, Monitor Server, and XP Server.
After you create the Adaptive Server or upgrade Adaptive Server using srvbuild or sqlupgrade, Adaptive Server, Backup Server, and Monitor Server are running. For information about running the Full-Text Search server, see the Full-Text Search Specialty Data Store User's Guide.
XP Server is not started by the installation process. XP Server is started only when any XP command is issued through isql.
The methods described here are used to start Adaptive Server, Backup Server, and Monitor Server after a shutdown for database maintenance, because of an operating system crash, or for some other reason.
You can start Adaptive Server, Backup Server, and Monitor Server on UNIX either by:
Entering commands from the UNIX command line, or
Configuring your operating system so that the servers start automatically when the operating system starts
You can start Adaptive Server, Backup Server, or Monitor Server from the UNIX command line by using runserver files and startserver commands. You can move the Adaptive Server shared memory files by adding a flag to the runserver file.
Each time a new Adaptive Server, Backup Server, or Monitor Server is installed, the srvbuild program creates a runserver file that contains the information required to restart that server. Runserver files are created in the $SYBASE/$SYBASE_ASE/install directory. For Adaptive Server, the runserver file is named RUN_servername, where servername is the name of the server.
For example, the runserver file name for an Adaptive Server named TEST is RUN_TEST. If the runserver file for your current Adaptive Server is named RUNSERVER, you must change the name to RUN_TEST during the upgrade process.
For Backup Server and Monitor Server, the runserver files are named RUN_servername_back and RUN_servername_mon, respectively, where servername is the name of the server.
Do not delete the runserver file that is created in $SYBASE/$SYBASE_ASE/install. This file is used to restart servers when you customize your installation. If you need the runserver file in another location, make a copy of the original runserver file in the new location.
To start a server from the command line enter:
$SYBASE/$SYBASE_ASE/install/startserver [ -f runserverfile ]
where $SYBASE/$SYBASE_ASE/install/startserver is the full path name of the startserver utility, and runserverfile is the full path name of the runserver file (usually $SYBASE/$SYBASE_ASE/install/RUN_servername).
If your Adaptive Server is named SYBASE, the runserver file specification is optional.
You must have read and write permissions on the master device for an Adaptive Server to start it with startserver. See Adaptive Server Enterprise Utility Guide for more information about startserver.
Although startserver runs Adaptive Server in the background, it does not return to the operating system prompt after restarting. After Adaptive Server has been restarted, press Return to return to the operating system prompt.
Use the monserver command to start Monitor Server from the UNIX command line. For details, see the Adaptive Server Enterprise Monitor Server User's Guide.
This section describes how to configure your operating system for automatic restart of Adaptive Server and Backup Server when the system restarts.
On production systems, Adaptive Server, Backup Server, and Monitor Server should restart automatically when the UNIX operating system starts. This is accomplished by making an entry for the server in the operating system start-up script.
Monitor Server must be listed after Adaptive Server in the start-up script. For more information on starting Monitor Server during the operating system restart, see the Sybase Adaptive Server Enterprise Monitor Server User's Guide.
The $SYBASE/install/sybinstall.sh script sets up a correct shell environment and installs a system run-level script in a Sybase user account. The script allows the automatic re-start and automatic shutdown of configured Sybase Server products such as Adaptive Server Enterprise, Backup Server, and Open Server.
To run sybinstall.sh:
Log in as root.
Run the sybinstall.sh script to perform the post-installation. Enter:
# $SYBASE/install/sybinstall.sh
Create the correct runtime links for shutdown and boot. Enter:
# /sbin/chkconfig sybase on
Only the System Administrator has permission to issue a shutdown command. Using a shutdown command minimizes the amount of work that automatic recovery needs to do when the servers are restarted.
The preferred method of stopping Adaptive Server or Backup Server is to use the Transact-SQL shutdown command. For Monitor Server, use the sms_shutdown command.
To shut down Adaptive Server:
Use isql to log in to an Adaptive Server account with System Administrator privileges:
isql -Usa -Ppassword -Sserver_name
Enter the following command to shut down the server:
1> shutdown 2> go
The default for the shutdown command is with wait. The with wait option allows Adaptive Server to finish executing SQL statements or procedures, perform a checkpoint in each database, disable new logins, and perform other shutdown tasks.
Issuing the shutdown command prints a message like this to the stderr file:
Server SHUTDOWN by request.The SQL Server is terminating this process. CT-LIBRARY error:
This is normal behavior. If the message indicates that Adaptive Server is waiting for processes to complete, and you need to stop Adaptive Server immediately, you can use the shutdown with nowait command. shutdown with nowait does not wait for currently executing statements to finish and does not perform checkpoints in every database.
To shut down a Backup Server:
Use isql to log in to a server with System Administrator privileges:
isql -Usa -Ppassword -Sserver_name
Enter the following command to shut down the specified Backup Server:
1> shutdown SYB_BACKUP 2> go
After you shut down a Backup Server, you must wait at least 30 seconds before restarting it.
Issuing the shutdown command prints a message similar to the following to the stderr file:
Backup Server: 3.48.1.1: The Backup Server will go down immediately. Terminating sessions.
This is normal behavior. If a message indicates that Adaptive Server or Backup Server is waiting for processes to complete, and you need to stop Adaptive Server or Backup Server immediately, you can use the shutdown with nowait command. shutdown with nowait does not wait for currently executing statements to finish and does not perform checkpoints in every database.
Using shutdown with nowait for Backup Server can cause inconsistent or incomplete dumps and loads. Use this command only when necessary.
For more information on the shutdown command, see the Reference Manual.
You must shut down Monitor Server before restarting Adaptive Server. If Adaptive Server stops, make sure that Monitor Server is shut down before you restart Adaptive Server. Monitor Server must be shut down to release resources. Otherwise, Adaptive Server may not be able to allocate enough resources to restart.
If the Monitor Server heartbeat feature is in effect, Monitor Server automatically detects the termination of Adaptive Server within the specified period and shuts itself down. Therefore, before attempting to restart Adaptive Server after a shutdown, either wait for the automatic shutdown of Monitor Server to occur, or explicitly stop Monitor Server.
For more information on stopping Monitor Server, see the Adaptive Server Enterprise Monitor Server User's Guide.
Warning!
Use the kill command in Adaptive Server and Backup Server only as a last resort.
When possible, use the Transact-SQL shutdown or shutdown with nowait command. Do not use kill with the -9 flag because it exits the server without running a checkpoint to ensure that all database changes are written to the database device. Adaptive Server may also exit without removing associated shared memory files and network handlers.
Because Adaptive Server and Backup Server are background processes, they can be killed from the operating system by their owner or by "root" with the UNIX kill command. The syntax is:
kill pid
where pid is the process identification of any dataserver or backupserver process, as determined by the showserver command. Killing one engine for a particular Adaptive Server kills all engines for that server.
If more than one Adaptive Server is running on the same system, you must be careful that the engine you kill is associated with the correct Adaptive Server. If your Adaptive Server is configured to use multiple engines (CPUs), each engine has an associated operating system process. The correct way to kill a multi-engine server is to specify the process ID for engine 0.
This
showserveroutput shows the processes for a four-engine server:
showserver
UID | PID | PPID | C | STIME | TTY | TIME | COMD |
jorge | 3320 | 1 | 80 | 10:31:40 | pts/4 | 302:15 | dataserver -dteamster |
jorge | 3321 | 3320 | 80 | 10:31:45 | pts/4 | 324:47 | dataserver -ONLINE:1 |
jorge | 3322 | 3320 | 80 | 10:31:45 | pts/4 | 326:02 | dataserver -ONLINE:2 |
jorge | 3323 | 3320 | 80 | 10:31:45 | pts/4 | 328:56 | dataserver -ONLINE:3 |
This example shows four running dataserver processes with operating system process identifications (PID) 3320, 3321, 3322, and 3323. (dataserver is the executable form of the Adaptive Server program.)
Child engine processes for the dataserver have the -ONLINE: argument.
Each child engine has a parent process identification (PPID) that is equal to the process identification (PID) of the parent. In the example above, the PID of the parent server is 3320. The other three engines spawned by the parent process have the same PPID.
If the PPIDs appear to be unrelated, and there is more than one dataserver process, then more than one Adaptive Server is running on the system.
When Adaptive Server is shut down in a normal manner, the shared memory files are automatically removed. If Adaptive Server crashes or is stopped with the kill -9 command, these files are not deleted. You need read and write permissions on these files to restart Adaptive Server after a crash or a kill -9 command, as Adaptive Server must be able to overwrite the previously created shared memory files.
Please consult the Linux ipcs(1) options for stale shared memory segment removal.
# ipcs -m
# ipcrm shm <shmid>
|
|