Chapter 2 Starting

and Stopping Servers

Chapter 4 Setting

Up Communications Across a Network

Configuring Adaptive Server for UNIX Platforms

Chapter 3 Configuring the Operating System for Adaptive Server

Chapter 3

Configuring the Operating System for Adaptive Server

This chapter discusses the operating system configuration settings that you can adjust after installing or upgrading Adaptive Server. Unless stated otherwise, the information pertains to all supported UNIX platforms.

Setting environment variables

It is crucial to the operation of Sybase products that the system environment variables are set correctly. Environment variables are set in the user's environment either interactively or by including them in the user's .login and .cshrc files (for C shell) or .profile file (for Bourne shell).

Only the file owner or the "root" user can edit a user's .login, .cshrc, or .profile file.

Table 3-1 describes the system environment variables for Adaptive Server.

To check the current value of environment variables on your system, at the operating system prompt enter:

setenv

System environment variables
Variable	Sample value	Function
DSLISTEN	IGNATZ	Used at Adaptive Server start-up; enables the specified Adaptive Server to listen for input from front-end software.
DSQUERY	IGNATZ	Defines the Adaptive Server to which local client applications connect.
PATH	/usr/bin:/etc: /usr/sbin: /usr/ucb: /usr/bin/X11:/sbin	Appends the full path to the Adaptive Server bin subdirectories.

DSLISTEN

The DSLISTEN environment variable defines the name used by Adaptive Server to listen for client connections, when no name is given during Adaptive Server start-up. If DSLISTEN is not set, and no name is given during start-up, the Adaptive Server name defaults to the server name given at installation.

DSQUERY

The DSQUERY environment variable defines the Adaptive Server name to which client programs attempt to connect when no Adaptive Server name is specified with a command-line option. If DSQUERY is not set, and you do not supply the Adaptive Server name with a command-line option, clients try to connect to the server name given at installation.

PATH

The PATH environment variable specifies which directory paths to search for executables. The Sybase executables are in the bin and install directories in the Sybase installation directory. The install program appends these paths to the current PATH environment variable.

The new executables are added at the end of the PATH variable. Verify that you do not have any old Sybase executables, instead of the new executables, in the PATH that will be invoked.

Using the stty setting

Setting the stty tostop option causes a background Adaptive Server to stop as soon as it tries to write to the terminal. To avoid this error, execute the following command before starting Adaptive Server:

stty  -tostop

If you are redirecting all Adaptive Server output to files, you do not have to change the stty setting.

Restoring correct permissions

Sybase software files and directories are installed with the correct access permissions. If you notice that the permissions are no longer correct, you can restore the correct permissions with the script setperm_all, located in the $SYBASE/install directory.

File descriptors and user connections

The number of user connections used by Adaptive Server cannot exceed the number of file descriptors available to Adaptive Server on the operating system. When configuring user connections on Adaptive Server, the System Administrator should take into account the number of file descriptors available per process. Although most of the open file descriptors are available for user connections, a few are used by Adaptive Server for opening files and devices.

For Digital UNIX

The number of file descriptors per process is determined by the operating system parameter open_max. The default value of open_max is 4096. For more information on setting open_max, see the Digital UNIX operating system documentation.

Adaptive Server can use a maximum of 1024 file descriptors, regardless of the value of open_max.

To obtain the current value of the open_max parameter, use the Korn or Bourne shell ulimit command:

ulimit -n

To obtain the number of current file descriptors, use the sysconf or getdtablesize function.

For HP-UX

The kernel parameters maxfiles and maxfiles_lim control the number of file descriptors available to any one process.

For IBM RS/6000

The number of file descriptors per process is determined by the operating system parameter open_max. The default value of open_max is 32767. Adaptive Server can use a maximum of 2000 file descriptors per engine, regardless of the value of open_max. For more information on setting open_max, see the AIX operating system documentation.

To obtain the current value of the open_max parameter:

Use the Korn or Bourne shell ulimit command:
```
ulimit -n
```

To obtain the number of current file descriptors programmatically:

Use the sysconf or getdtablesize function.

For Sun Solaris

For Sun Solaris you can set both "soft" and "hard" limits for file descriptors. The soft limit can be increased up to the hard limit by the user, but the hard limit can be increased only by someone with "root" permissions. The soft limit determines the number of open file descriptors available to an Adaptive Server engine.

Although most of the open file descriptors are available for user connections, a few are used by Adaptive Server engines for opening files and devices.

See the System Administration Guide for additional information on user connections.

Displaying current soft and hard limits

To display the current soft limit:

For C shells, enter:
```
limit  descriptors
```
For Bourne shells, enter:
```
ulimit  -n
```

To display the current hard limit:

For C shells, enter:
```
limit  -h descriptors
```
For Bourne shells, enter:
```
ulimit  -Hn
```

Increasing the soft limit

To increase the soft limit:

For C shells, enter:
```
limit descriptors n
```
For Bourne shells, enter:
```
ulimit  -Sn new_value
```
where n is the current value for the soft limit, and new_value is the value to which you want to increase the soft limit.

The preceding commands can be used in your runserver file to increase the hard and soft limits. Because the runserver file is a Bourne shell script, be sure to use the Bourne shell versions of these commands in the runserver file.

Increasing the hard limit

To increase the hard limit, use a program like the sample program shown in "Sample program" .

To set up the sample program to increase the hard limit:

Create the ASCII file file_name.c (where file_name is the name you give the file), by using an ASCII text editor. Type the text shown in the sample.
Compile the file:
```
cc file_name.c -o program_name
```
where file_name is the name of the source file you created, and program_name is the name you want to give the program.
Change the program's permissions and ownership so that it will execute as "root":
```
chmod 755 program_name 
chown  root program_name
```
where program_name is the name of the compiled program.
The "root" user can use the program to start Adaptive Server with increased user connections by typing the following command at the operating system prompt:
```
# program_name dataserver  -d master_device_name
```
where program_name is the name of the compiled program, and master_device_name is the full path of Adaptive Server's master device. Instead of typing the command at the operating system prompt, you can add program_name preceding the dataserver command line in the Adaptive Server runserver file.

Sample program

The following example shows the source code that you can use to increase the hard limit:

#include <sys/time.h>
 #include <sys/resource.h>
 #include <sys/types.h>
 /*
 ** define  MAX_CONNECTIONS to a number less than
 ** 10000.  The number defined will then become the 
 ** maximum number  of connections allowed by an Adaptive 
 ** Server.
 */
 #define  MAX_CONNECTIONS 9999
extern int errno;
 
main(argc,argv)
char **argv;
 {
        struct  rlimit rlp;
        uid_t uid;
 
        rlp.rlim_cur = MAX_CONNECTIONS;
        rlp.rlim_max = MAX_CONNECTIONS;
 [nbsp  ]   /* set  the number of open file desriptors to MAX_CONNECTIONS */
        if  (setrlimit (RLIMIT_NOFILE,&rlp) == -1)
        {
            perror("setrlimit");
            exit(1);
        }
 
[nbsp  ]   /* reset  the user id to disable superuser privileges */
        uid = getuid();
        setuid(uid);
 [nbsp  ]   /* run  the program indicated as arguments to this program */
        execv(*++argv,  argv);
 }

For additional information on user connections, see the System Administration Guide.

Adjusting the client connection timeout period

Adaptive Server uses the KEEPALIVE option of the TCP/IP protocol to detect clients that are no longer active. When a connection to a client is inactive for a period of time (the timeout period), the operating system sends KEEPALIVE packets at regular intervals. If it does not receive a response from the client machine for any of these packets, the operating system notifies Adaptive Server that the client is no longer responding. Adaptive Server then terminates the client's connection.

The KEEPALIVE default timeout period is 2 hours (7,200,000 ms.). To display the current time value, use the command for your platform as shown in the following sections.

For Digital UNIX

To display the current timeout value, enter:

/usr/sbin/ndd -get /dev/tcp  tcp_keepalive_interval

To reduce the timeout period to 15 minutes (900,000 ms.), enter:

/usr/sbin/ndd  -set /dev/tcp tcp_keepalive_interval  900000

For HP-UX

To display the current timeout period, enter:

/usr/contrib/bin/nettune  -l

The switch is a lower case "l", not a numeral one (1).

The tcp_keepstart parameter specifies the length of time (measured in seconds) to keep an idle connection active before the system checks to see if the connection died.

To change the timeout period, use the nettune -s command.

For IBM RS/6000

To display the current timeout value, enter:

/usr/sbin/no -o tcp_keepidle

The tcp_keepidle parameter specifies the length of time (measured in half seconds) to keep an idle connection active before the system checks to see if the connection died. The default is 14,400 half seconds (7200 seconds, or 2 hours).

IBM recommends a value of at least 15 minutes.

For Sun Solaris

To display the timeout value, enter:

/usr/sbin/ndd  -get /dev/tcp tcp_keepalive_interval

To reduce the timeout period to 15 minutes (900,000 ms.), enter:

/usr/sbin/ndd  -set /dev/tcp tcp_keepalive_interval  900000

Checking for hardware errors

The following types of hardware error messages indicate problems that may lead to database corruption:

Disk read, write, or retry errors
Timeouts
System panics
Memory problems of any type

For Digital UNIX

Check the /var/adm/messages file on a regular basis. See the operating system documentation for more information on this file.

For HP-UX

Check the /var/adm/syslog/syslog.log file on a regular basis. You can view the file directly, or you can use the HP-UX dmesg command. See your operating system documentation for more information.

For IBM RS/6000

The errpt command includes several flags for limiting the report to events that match certain criteria. Use the errpt command on a regular basis. If errors appear, use the diagnostic tool diag to check your memory and disks. Or use the System Management Interface Tool (SMIT) to run the errpt command. This command may produce a lot of output.

For Sun Solaris

Check the /var/adm/messages file on a regular basis. If any of the types of hardware errors described in the beginning of this section appear, use the Sun Microsystems diagnostic tool, sundiag, to check memory and disks. See the operating system documentation for more information.

Monitoring the use of operating system resources

The Performance and Tuning Guide and the System Administration Guide discuss maintaining the optimal number of Adaptive Server engines for your workload and system configuration. To determine the optimal number, you need to monitor system and CPU usage.

For Digital UNIX

The following tools help monitor performance:

The iostat command reports the amount of I/O on terminals and hard disks and how CPU time is spent.
The vmstat command monitors virtual memory usage.
The netstat command monitors network status.
The ps command provides an accurate snapshot of accumulated CPU time and usage for individual processes. This can be very helpful in determining the load of the data server, engine, and processes.
The time command can be useful in determining the various user, system, and real-time resources used over a complete run.

For details about these tools, see your operating system documentation.

For HP-UX

HP-UX supplies many tools to help monitor performance, which include:

The sar command reports relative and absolute I/O throughput rates to each disk and controller.
The vmstat command monitors virtual memory usage.
The netstat command monitors network status.
The ps command provides a snapshot of accumulated CPU time and usage for individual processes.
The time command can be useful in determining the various user, system, and real-time resources used over a complete run.

For details about these tools, see your operating system documentation.

For IBM RS/6000

IBM RS/6000 supplies the following tools for monitoring performance:

The iostat command reports the amount of I/O on terminals and hard disks and how CPU time is spent.
The vmstat command monitors virtual memory usage.
The netstat command monitors network status.
- netstart -v displays Transmit/Receive Statistics. It is also used to determine if enough mbufs have been configured for network traffic.
- no -a displays current network options. It is also used for tuning mbuf pools.
The ps command provides a snapshot of accumulated CPU time and usage for individual processes.
The time command determines the various user, system, and real-time resources during a complete run.

For details about these tools, see your operating system documentation.

For Sun Solaris

Sun Solaris supplies the following tools to help monitor performance:

The iostat command reports the amount of I/O on terminals and hard disks and how CPU time is spent.
The vmstat command monitors virtual memory usage.
The netstat command monitors network status.
The ps command gives you an accurate snapshot of accumulated CPU time and usage for individual processes. This can be very helpful in determining the data server-, engine-, and process-specific loading.
The time command can be useful in determining the various user, system, and real-time resources used over a complete run.

For details about these tools, see your operating system documentation.

A sample C shell maintenance script

The following sample C shell script calls several isql scripts:

#!/bin/csh -f
if  ( -e dbcc_mail.out)
then
        rm  dbcc_mail.out
endif
foreach i (*.dbcc)
        isql  -Usa -Ppassword < $i > dbcc_out
        if  ( 'grep -c 'Msg 25[0-9][0-9]' dbcc_out' )
            then
            echo  "There are errors in" $i >> dbcc_mail.out
            cat  dbcc_out >> dbcc_mail.out
        else
            echo  "Backing up " $i:r >> dbcc_mail.out
            isql  -Usa -Ppassword < $i:r.backup
        endif
end
mail  -s "Backup Report" jjones < dbcc_mail.out

The first set of scripts (one for each database with a file name appended with .dbcc) runs dbcc checkalloc and dbcc checkdb for each database and sends the messages to an output file called dbcc_out.

For example, the script master.dbcc runs dbcc to check the master database:

dbcc checkalloc (master)
go
dbcc  checkdb (master)
go

The C shell script then runs the grep command to find 2500-level error messages in the dbcc output. The results of the grep command go into an output file called dbcc_mail.out.

Next, the script invokes an isql backup script for each database for which no 2500-level errors occurred and adds the "Backing up database_name" line to dbcc_mail.out . For example, the script master.backup backs up the master database:

use master
go
dump database  master to master_dump
go

You may want to add appropriate dump transaction commands to your scripts.

If there are 2500-level error messages, the script does not back up the database. At the end of the script, dbcc_mail.out is mailed to the System Administrator "jjones," who then has a record of fatal dbcc errors and successful backups.

You can tailor the sample shell and isql scripts to suit the needs of your installation.

To have the scripts execute automatically, edit the crontab file, and add an entry similar to this:

00  02 * * * /usr/u/sybase/dbcc_ck  2>&1

In this example, a C shell script called dbcc_ck executes daily at 2:00 a.m.


	Expand Search