So far we have copied the software into the file system, now we will do the actual setup of a database server. First we need to make sure the sybase user is set up properly, then we can start the configuration utilities and enter the correct settings there.
To begin with, read the LICENSE file if it exists. Once you agree with this, continue down this list.
There are some useful steps done by the installation scripts in the RPM packages that you may want to do by hand if you installed with extra RPM switches or used alien. One is that directories in ASE 12.5 get shortcuts created with shorter names. ASE-12_5 gets a symlink named ASE, OCS-12_5 has a symlink named OCS. You can set these up yourself to save some typing later.
bash$ cd /opt/sybase bash$ ln -s SYBASE_ASE ASE bash$ ln -s SYBASE_OCS OCS bash$ ln -s shared-1_0 shared bash$ ln -s SYSAM-1_0 SYSAM |
Change the installation to be owned by the sybase user.
bash$ su - root bash# chown -R sybase.sybase /opt/sybase bash# chmod -R ug+w /opt/sybase |
Make sure you allow ASE to allocate the necessary amount of shared memory. Your current maximum is what you find from ipcs -lm (in KiloBytes) or cat /proc/sys/kernel/shmmax (in bytes) or sysctl kernel.shmmax (in bytes). This can be set with
sysctl -w kernel.shmmax=[number of bytes] |
echo [number of bytes] > /proc/sys/kernel/shmmax |
Make sure the sybase user has all relevant environment variables set correctly.
Table 4. Sybase environment variables
| Version | Variable | Set to |
|---|---|---|
| 11.0.3.3 and 11.9.2.x | ||
| $LANG | Must not be set! | |
| $LC_ALL | "default" | |
| $SYBASE | Top-level of installation, default is /opt/sybase/ | |
| $PATH | Add /opt/sybase/bin to the start of the existing $PATH | |
| $LD_LIBRARY_PATH | Add /opt/sybase/lib to the start of the existing $LD_LIBRARY_PATH | |
| $SYBPLATFORM | "linux" | |
| 12.5.0.x | All of the above plus | |
| $SYBASE_ASE | Subdirectory (not full path) to the ASE part of the installation | |
| $SYBASE_OCS | Subdirectory (not full path) to the Open Client / Open Server part of the installation |
sh/bash/ksh type shells
unset LANG export LC_ALL="default" export SYBASE="/opt/sybase/" export PATH="$SYBASE/bin:$SYBASE/$SYBASE_ASE/bin:$SYBASE/$SYBASE_OCS/bin: $SYBASE/$SYBASE_SYSAM/bin:$PATH" export LD_LIBRARY_PATH="$SYBASE/lib:$SYBASE/$SYBASE_ASE/lib:$SYBASE/$SYBASE_OCS/lib: $LD_LIBRARY_PATH" export SYBPLATFORM="linux" export SYBASE_ASE="ASE" export SYBASE_OCS="OCS" export SYBASE_FTS="FTS" export SYBASE_SYSAM="SYSAM" |
unsetenv LANG setenv LC_ALL default setenv SYBASE /opt/sybase/ setenv PATH $SYBASE/bin:$SYBASE/$SYBASE_ASE/bin:$SYBASE/$SYBASE_OCS/bin: $SYBASE/$SYBASE_SYSAM/bin:$PATH setenv LD_LIBRARY_PATH=$SYBASE/lib:$SYBASE/$SYBASE_ASE/lib:$SYBASE/$SYBASE_OCS/lib: $LD_LIBRARY_PATH setenv SYBPLATFORM=linux setenv SYBASE_ASE ASE setenv SYBASE_OCS OCS setenv SYBASE_FTS FTS setenv SYBASE_SYSAM SYSAM |
Prepare the data area.
Since the file system for the software is now prepared, we can decide where to locate the data storage used to hold the data inserted into the databases. The first decision is whether to use raw devices or file system. Traditionally, raw devices were used. You had to partition a disk and set a certain label to have it recognized as raw. Linux didn't have this previously and the Sybase virtual devices were instead written to files in a file system.
So, what is the difference between these approaches and when should you choose each? Unfortunately, it is one of the areas where the answer is a very clear and unambiguos "it depends". Raw devices were introduced first with kernel patches and then included in the 2.4 series. You use the command raw to create bindings between partitions and the /dev/rawn devices. This means that you will need to have a free partition on a disk. Changing this later can also be difficult. The advantages of raw devices are that you know exactly where on disk they are located - you can place them on the fastest cylinders if you like. Writes to the raw devices will be unbuffered, they will go directly to disk. In case of a failure (such as power outage, disk controller failure or process crash) the finished writes are guaranteed to be on disk instead of only having been written to a buffer waiting for the disk to be ready. Also, the ASE server will to asynchronous I/O on these devices. It can queue a series of I/O instead of having to do a single I/O, wait for it to finish and then do the next operation. While the I/O result is pending, the ASE server will perform other work. With a virtual device written to a file on a file system (ext2, ext3 and Reiserfs are all supported), the writes will normally be done to the file system buffers. The actual file may be located anywhere on the partition and may not be contiguous. Note that there is no need for a journalling file system since these will only log the changes to the inode, not the contents of the data blocks. The Sybase ASE transaction log will do exactly this kind of "journalling" of the data modifications for you. The buffering means that reading data not held in ASE cache may take place from the file system buffer instead of having to read it from disk, thereby speeding up these. However, writes will probably take longer time to finish since they have to pass through the file system driver layer. In order to have safe writes to file system devices you can configure ASE to open the device using the O_DSYNC flag, which will cause writes to be flushed to disc immediately when writing.
In ASE 11.0.3.3 ESD #6 there is support for raw devices. This will need certain patches shipped in the GPL directory, one for raw device access, one for KAIO. There are instructions for how to apply these to the kernels and distributions that were current at the time.
In 11.9.2.x it was decided not to include any experimental raw device support before the Linux kernel officially included and supported this. In order to guarantee safe writes, the O_DSYNC flag is always enabled by default. You can globally disable this with traceflag 1625; add -T1625 as a parameter to the RUN_SERVER file.
In ASE 12.5.0.x there was a change starting in 12.5.0.2 where the server is now compiled to use the kernel 2.4 functionality. That means you can create raw devices on OS level and configure ASE to use these without any special patches. If you prefer file system devices, you can set the O_DSYNC flag to be used with the dsync=true parameter when creating the device with disk init, or the sp_deviceattr stored procedure to modify it later.
To configure a SQL Server 11.0.3.3 you log in as the sybase user and start the sybinit utility. You can run this in a console, make changes and hit Ctrl-A for "accept" and Ctrl-X to go back to the previous menu.
In ASE 11.9.2.x and 12.5.0.x, you normally use the srvbuild command, but you will need an X server to display it. For those not using X, an option is to use the shell script "sybinit4ever", available on the web from SyPron, see the 3rd party utilities section later. This will give you a classic sybinit menu interface to the configuration process. An alternative from Sybase is the srvbuildres utility which uses a resource file containing all configuration options which you can edit with your settings, these options are described in an appendix of the Installation Guide.
The exact entries for configuring a server are described in more detail in the /opt/sybase/doc/howto/howto-ase-quickstart.html file from the ASE 11.0.3.3 documentation RPM, and in the "Configuration Guide for UNIX" for the newer versions. The information you will need for all versions are:
IP address of the interface which ASE will listen on. Use the network IP of the machine or 127.0.0.1 if you are only going to accept local connections.
TCP port which ASE will listen on. Choose any port not in use. Port 2025 was used before, 4100 is the current default. Use 1433 if you are trying to trick applications into believing this is an MS SQL Server.
Path to the master device (raw device or file).
Path to the sybsystemprocs device (raw device or file).
Character set and sort order for your data (you want to get this right the first time, changing it later involves copying all data out to files and load them back in). ISO_1 character set should be sufficient for most purposes. Unicode is only supported in the 12.5.0.x releases.
Logical server name - this is just a placeholder to identify an ASE instance. In the examples I have named the server SYBASE.
Once you have decided on these settings, start the configuration program. If you use srvbuild, you will need to set your $DISPLAY variable correctly. Type in the requested settings and let the configuration utility build the server. Some parts of this, such as creating the database devices and loading the system stored procedures, will take time. Once the process has finished, you server should have been built and be up and running, ready for requests.