|
|
Install Solaris on your hardware as per the installation instructions or as you normally would. The version you choose isn't critical because Sybase works well with all versions (so far). Later versions (like Solaris 8) should be preferred because of their added functionality, but its not mandatory. Solaris 8 does provide slightly more memory for user applications due to changes in the way memory is managed by the OS. I highly recommend this version. You only need to be mindful of the filesystem layouts when working with a limited number of disks. This is due to the fact that Sybase requires raw partitions for best operation and Solaris is restricted to 8 partitions on a disk. One of these is usually reserved as the backup partition (slice 2), which leaves 7 partitions for end user use. For a production system, a minimum of two disks is suggested. This will allow for mirroring to be implemented. Stay away from large disks unless working with a volume manager like Veritas (SEVM). With large disks, its likely that a lot of disk space may end up being wasted otherwise. This, however, really depends on the database requirements. Ordinarily, the more disk spindles the better (both for performance and device layouts). Two 18GB disks would present more headaches than eight 4GB disks without the use of SEVM. For example, the following layout:
is one where the 2GB disk has two OS partitions allocated and three assigned to Sybase (the remaining two are reserved for later use). The system this disk belongs to has another 2GB disk. On this, the layout more or less matches the above, with two filesystems on the first two partitions and the Sybase devices mirrored onto the last three partitions. The Sybase master and sysprocsdev devices have been combined into one to conserve partitions. The output from the df command on this server looks like:Total disk cylinders available: 2733 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 943 700.62MB (944/0/0) 1434880 1 swap wu 944 - 1145 149.92MB (202/0/0) 307040 2 backup wm 0 - 2732 1.98GB (2733/0/0) 4154160 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 1978 - 2058 60.12MB (81/0/0) 123120 6 unassigned wm 2059 - 2597 400.04MB (539/0/0) 819280 7 unassigned wm 2598 - 2732 100.20MB (135/0/0) 205200
With more disks, or when using a volume manager like Veritas, there are no real restrictions. The use of Solstice DiskSuite is generally not recommended, since it works off physical disk partitions and takes some for its own use. This only exacerbates the partition problem. However, the latest version (v. 4.2.1) now has support for "soft partitions", which are equivalent to Veritas' logical volumes. The following is an example of a 36GB disk configured for use with SDS:Filesystem kbytes used avail capacity Mounted on /dev/dsk/c0t0d0s0 674471 587366 87105 88% / /dev/dsk/c0t1d0s0 336863 31117 305746 10% /opt /dev/dsk/c0t1d0s1 480919 345186 135733 72% /sybase swap 226600 8 226592 1% /tmp
Here, partition 4 is a one cylinder slice holding the SDS MetaDB and partitions 6 and 7 hold the SDS soft partitions.Total disk cylinders available: 24620 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 - 640 904.22MB (641/0/0) 1851849 1 unassigned wm 641 - 1349 1000.15MB (709/0/0) 2048301 2 backup wu 0 - 24619 33.92GB (24620/0/0) 71127180 3 unassigned wm 1350 - 1388 55.02MB (39/0/0) 112671 4 unassigned wm 1389 - 1389 1.41MB (1/0/0) 2889 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 1390 - 13004 16.00GB (11615/0/0) 33555735 7 unassigned wm 13005 - 24619 16.00GB (11615/0/0) 33555735
When using the whole disk for Sybase devices (and not using Veritas) skip the first cylinder so as to avoid overwriting the disk's partition map stored on the first block of cylinder zero. For example:
Here the first partition starts at cylinder one.Total disk cylinders available: 3880 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 1 - 949 1000.90MB (949/0/0) 2049840 1 unassigned wm 950 - 1898 1000.90MB (949/0/0) 2049840 2 backup wu 0 - 3879 4.00GB (3880/0/0) 8380800
After installing Solaris, install the latest patches for the OS. The simplest way to do this is by going to the SunSolve site and downloading the recommended patch cluster. If you have a support contract, log in and download the Patchdiag tool. Use the latest cross-reference file to work out the required patches. Note any recommendations Sybase makes in the ASE Installation Guide.
The only other required system configuration change is to configure Solaris to allow shared memory - which is required by Sybase. Edit the /etc/system file and add the lines:
towards the end of the file. This configures the maximum shared memory size allowed by the Kernel. The value can be set as large as desired or larger, since it doesn't have any physical effect until shared memory is requested by a process. The value is in bytes. Of course, a process shouldn't request more than is physically available. The above value is only a suggestion.* * Set maximum shared memory segment size allowed, * for use with Sybase SQL Server. * set shmsys:shminfo_shmmax=131072000
There may be other administration related changes that you may need to make to the Operating System or Kernel configuration but none of these would be in relation to Sybase. Do these now as a reboot is required for the Kernel config changes to take effect.
Download some useful tools from the Sunfreeware site. Read the instructions therein to download the appropriate versions. I recommend, at the very least, that gzip, less and top be downloaded. Solaris 8 now includes the first two of these.
Sybase is a Client/Server database application. As such it is normal that it
would run in a network environment. When installing Solaris, you will be
prompted for whether the host machine is part of a network. If so, you will be
required to give it an IP address and a network mask. Consult your Network
Administrator for the details. On a large network, DNS may be used. On Solaris
version 2.6 and below, select "Other" as the networking option. For Solaris 7,
a DNS network option exists at install time. However, the gateway is still not
prompted for, so this will need to be added manually. After the install is
completed and the OS boots, check these files in /etc: nsswitch.conf,
resolv.conf and defaultrouter. Under /etc/inet,
check these files: hosts and netmasks. Ensure that
the hosts file has a FQDN nickname after the machine's short name to prevent
sendmail from complaining.
Create a user account for Sybase (nominally called "sybase") using either tools like admintool or useradd or manually. Use this account to install the Sybase software and run the database server. The account's home directory should reside in /usr/sybase which links to the current installation directory (see below).
Warning: Avoid using the root account, especially if you intend to use the XP Server. This will open up a security hole.
On Solaris, Sybase ASE installs where ever the installer selects. There is no preference or default. I prefer to create a separate filesystem for Sybase and install it there. This has several advantages.
With a separate filesystem, the Sybase install is not tied in with the OS. So an OS upgrade will not affect the Sybase filesystem. This filesystem could also easily be NFS exported to another machine (although its not a good idea to run the server binaries from an NFS mount). It can also be dumped and/or loaded independently of the rest of the filesystems. This also makes it easier to create multiple installations if required. Rather than reinstalling on each machine, simply copy the filesystem over.
I prefer to install ASE into a subdirectory on this filesystem. Vis:
Here the target install directory will be "ase119" for ASE version 11.9.2. This method allows more than one version to be installed, if desired. The other directories will be explained later.drwxrwxr-x 8 sybase sybase 512 Sep 16 16:49 . drwxr-xr-x 23 root root 512 Nov 29 08:59 .. drwxr-x--- 30 sybase sybase 1024 Nov 17 15:43 ase119 drwxr-x--- 3 sybase sybase 512 Dec 7 20:09 backups drwxr-x--- 2 sybase sybase 512 Sep 17 15:38 config drwxr-x--- 2 sybase sybase 512 Sep 17 14:02 devs drwxr-x--- 2 sybase sybase 512 Sep 17 16:03 dumps drwx------ 2 root root 8192 Sep 10 12:05 lost+found
I then create a symbolic link in /usr to the current ASE install directory.
The SYBASE environment variable is set to /usr/sybase and doesn't change. If you wish to switch to another version of ASE, simply change the symlink in /usr.lrwxrwxrwx 1 root other 14 Sep 10 16:07 sybase -> /sybase/ase119
Next, set up the environment of the Sybase user. Sybase is not particular
about the shell used, so feel free to use whichever one suits you. Install your
rc scripts and configure the Sybase environment for that user.
When you are ready, log in as the Sybase user and insert the Sybase CD. For versions earlier than ASE 12.0 run the sybsetup program found on the CD. This is a GUI application, so a graphics head is required. If you don't have a Unix workstation running X available, try using an emulator on a PC. There are many kinds available (both commercial and free/shareware). X-Win and VNC are both recommended. Its also possible to install from the command line by using sybload instead.
For ASE versions 12.0 and above run the shell script install on the CD. This lauches a Java installation program called the Studio Installer. The above comments concerning graphics apply.
For versions of ASE below 12.0, when you have sybsetup running, ensure that it's install directory shows "/usr/sybase", then select the Unload Sybase Products option. You will next be prompted for the path to the CD-ROM image that sybload extracts from. You want the file sybimage on the CD as well as the path to it. When run, the process will present you with a list of products you are licensed for. Select the desired products and extract them. Also elect to install sybsetup itself. When done, quit the program and eject the CD. Next examine the installed files and directories. I find that I usually have to remove 2 dot files (.CMFILE and .PMFILE). Everything else should be correct. Next, if you have an EBF ready, install it. You can either get these from Sybase tech support or download them from Sybase's support web site.
When you are done, the Sybase home directory should look something like this:
drwxrwx--- 20 sybase sybase 1024 Dec 9 11:50 . drwxrwxr-x 10 sybase sybase 512 Dec 9 11:42 .. -rw-r----- 1 sybase sybase 1709 Aug 6 18:47 .alias -rw-r----- 1 sybase sybase 747 Aug 6 18:47 .cshrc -rw-r----- 1 sybase sybase 4612 Aug 6 18:47 .login -rw-r----- 1 sybase sybase 874 Aug 6 18:47 .tcshrc -rwxr-x--- 1 sybase sybase 92561 Oct 29 15:02 Cover.ROLL.8670 drwxrwx--- 2 sybase sybase 1024 Dec 9 11:22 bin drwxrwx--- 14 sybase sybase 512 Aug 6 18:56 charsets drwxrwx--- 3 sybase sybase 512 Aug 6 18:56 collate drwxrwx--- 2 sybase sybase 512 Aug 6 18:57 config drwxrwx--- 2 sybase sybase 512 Aug 6 18:56 devlib drwxrwx--- 7 sybase sybase 512 Aug 6 18:56 diag drwxrwx--- 2 sybase sybase 512 Aug 6 18:57 include drwxrwx--- 7 sybase sybase 512 Aug 6 18:56 init drwxrwx--- 3 sybase sybase 512 Dec 9 12:03 install drwxrwx--- 2 sybase sybase 1024 Aug 6 18:58 lib drwxrwx--- 5 sybase sybase 512 Aug 6 18:59 locales drwxrwx--- 5 sybase sybase 512 Aug 6 18:57 pad drwxrwx--- 4 sybase sybase 512 Aug 6 18:57 sample drwxrwx--- 3 sybase sybase 512 Nov 29 10:30 scripts drwxrwx--- 2 sybase sybase 512 Aug 6 19:00 setupxbms drwxrwx--- 8 sybase sybase 512 Aug 6 19:00 sybhelp drwxrwx--- 2 sybase sybase 512 Aug 6 18:57 symlib drwxrwx--- 2 sybase sybase 512 Nov 29 10:30 upgrade drwxrwx--- 2 sybase sybase 512 Aug 6 19:00 xappdefaults
For versions of ASE at 12.0 or above, the process is slightly easier. Simply enter the installation directory, select the type of install (for a custom install, select the desired products) and then let the installer install. Eject the CD when done. The installation directory might look something like this:
drwxrwxr-x 23 sybase sybase 1024 Aug 9 18:08 . drwxrwxr-x 8 sybase sybase 512 Dec 20 2000 .. drwxr-xr-x 16 sybase sybase 512 Aug 9 13:42 ASE-12_5 drwxr-xr-x 5 sybase sybase 512 Aug 9 13:38 ASEP-1_0 drwxr-xr-x 6 sybase sybase 512 Aug 9 13:42 CFG-1_0 -rw-r--r-- 1 sybase sybase 1643 Aug 9 15:36 Config.log drwxr-xr-x 2 sybase sybase 512 Aug 9 13:40 Host-1_0 drwxr-xr-x 5 sybase sybase 512 Aug 9 13:40 Installer -rw-r--r-- 1 sybase sybase 15233 Aug 9 15:36 Installer.log drwxr-xr-x 13 sybase sybase 512 Aug 9 13:53 OCS-12_5 drwxr-xr-x 6 sybase sybase 512 Aug 9 13:39 SQLRemote -rw-r--r-- 1 sybase sybase 690 Aug 9 18:34 SYBASE.csh -rw-r--r-- 1 sybase sybase 2994 Aug 9 15:00 SYBASE.env -rw-r--r-- 1 sybase sybase 578 Aug 9 13:53 SYBASE.sh drwxr-xr-x 6 sybase sybase 512 Aug 9 13:39 SYSAM-1_0 drwxr-xr-x 53 sybase sybase 1024 Aug 9 13:40 charsets drwxr-xr-x 4 sybase sybase 512 Aug 9 13:41 collate drwxr-xr-x 3 sybase sybase 512 Aug 9 13:41 config drwxr-xr-x 2 sybase sybase 512 Aug 9 15:12 configed drwxr-xr-x 2 sybase sybase 512 Aug 9 15:12 data drwxr-xr-x 2 sybase sybase 1024 Aug 9 15:00 installed -rw-r--r-- 1 sybase sybase 261 Aug 9 18:03 interfaces drwxr-xr-x 7 sybase sybase 512 Aug 9 13:45 jConnect-4_5 drwxr-xr-x 7 sybase sybase 512 Aug 9 13:46 jConnect-5_5 drwxr-xr-x 5 sybase sybase 512 Aug 9 13:44 jutils-2_0 drwxr-xr-x 11 sybase sybase 512 Aug 9 13:45 locales -rw-r--r-- 1 sybase sybase 3037 Aug 9 15:36 repository.cfg drwxr-xr-x 7 sybase sybase 512 Aug 9 13:53 shared-1_0 -rw-r--r-- 1 sybase sybase 45 Aug 9 13:31 studio_version.txt drwxr-xr-x 4 sybase sybase 512 Aug 9 13:38 sybcent32
The layout is significantly different to earlier layouts. The number of directories depends on the number of products selected for installation. Note the shell scripts provided to help you set up your environment. Several environment variables have been added to note the location of the various core directories under the main Sybase one. Add these to your environment.
Before you can proceed any further, some planning is required. Capacity planning should have been done for the database(s) which would determine the memory and disk capacity required. This is beyond the scope of this document. Once this is done, you should be in a position to create a server instance. However, you need to be clear on where you want to put things. Before you can start the install, you need to have raw devices ready for at least the Sybase master and sysprocsdev devices. These devices are seldom as busy as database and log devices, so they should go on the slower part of a disk. When formatting a disk manually, this is relatively easy to set up. Its much harder with Veritas and I don't recommend bothering to do it.
In the first example, a 100MB partition was created on the last slice of a disk. The intention here was that, with partitions at a premium, the master and sysprocsdev devices should be merged. When this is not the case, separate partitions should be created. For example:
the above layout shows a 60MB partition on slice 6 and a 30MB partition on slice 7. These sizes are the Sybase suggested ones prior to ASE 12.0. For later versions the sizes have increased. The 64-bit version requires slightly more space than the 32-bit version and, for ASE 12.5, the larger page sizes also require large sizes. Check the installation documents for details.Total disk cylinders available: 2733 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 unassigned wm 1 - 1348 1000.47MB (1348/0/0) 2048960 1 unassigned wm 1349 - 2022 500.23MB (674/0/0) 1024480 2 backup wm 0 - 2732 1.98GB (2733/0/0) 4154160 3 unassigned wm 2023 - 2090 50.47MB (68/0/0) 103360 4 unassigned wm 2091 - 2569 355.51MB (479/0/0) 728080 5 unassigned wm 2570 - 2610 30.43MB (41/0/0) 62320 6 unassigned wm 2611 - 2691 60.12MB (81/0/0) 123120 7 unassigned wm 2692 - 2732 30.43MB (41/0/0) 62320
The next step is change the ownership of the raw devices to be those of the Sybase user. Do this as root:
Do this for every raw device intended for Sybase. However, it need only be done for the master and sysprocsdev devices created initially. When using Veritas, change the ownership thru it instead. Use these specified Veritas raw device names (e.g. /dev/vx/rdsk/"group"/"volume") with Sybase.# chown sybase:sybase /dev/rdsk/c0t1d0s7
The next step is to run sybsetup again (it should have been installed in $SYBASE/bin. Ensure that this is in your path), for versions prior to ASE 12.0, or asecfg for version at ASE 12.0 or later. This time select the option Build new Servers. This pops up a new window titled srvbuild.
In srvbuild, select what type or types of server you want to create. You can select all four at this point since it has no detrimental effect. Clicking on each option allows for a server name. The default is the host name. You can call the servers anything you wish (the XP Server needs to end in _XP). Choose a suitable name for your server or pick a suitable naming convention and follow it thru when identifying your servers. When you click on the OK button the screen form changes to allow you to enter device and other details. Enter the raw device path for the master device. If you plan to merge the master and sybsystemprocs databases, use a file for the sybsystemprocs device initially. The errorlog path will show the actual physical path to the install directory. Change this to /usr/sybase/install/log."server name". Set the port number to your desired port. Click on the Edit Advanced Adaptive Server Attributes button if you wish set up two-phase commit or define the default backup server. Change the shared memory file directory to /usr/sybase/install.
Clicking on OK advances you the the backup server attribute form. On this form change the error log path to /usr/sybase/install/log."backup server name". Set the tape config file to /usr/sybase/install/."backup server name".cfg. Next set the port for the backup server. I use an offset of 50 from the server's port number. Alternately, you can use an offset that translates well into hex. This will help in decoding the TLI hex digit string. Advancing to the monitor server setup form, change the log path to point to /usr/sybase/install with the log name being log."mon server name". Start the config file name with a dot (.), like the backup server config file name. The shared memory directory is the Sybase install directory (as above). Increment its port number by the previously selected increment. The XP server form only requires a port number. Increment it by the same amount. Now you should be ready to build the servers. Click on the Build Servers! button.
A screen pops up displays the progress as the build progresses. When this is completed, you can either quit or do additional work like install auditing or configure your server further (by changing the sort order etc.). When you are completely finished, quit sybsetup and invoke isql on the command line. Login in as sa and issue the shutdown command. Some cleaning up is required at this point. In the Sybase home directory there will be quite a few files that need to be cleaned up. Assuming a Sybase server name of FOO there will be a few old config files that need to be removed. These will be named F00.0*. It is safe to remove these. You can also remove the file FOO.bak. You only need FOO.cfg. Move this file to the install subdirectory and then remove the other files. There may be old interfaces files as well. Remove any other files that start with interf apart from the interfaces file itself. I should point out here that sybsetup provides no facility to specify the location of the config file. Thus we need to go thru this extra effort to clean up the directory.
When you are done, there should only be one extra file in the home directory (based on the previous listing of the home directory. See above). That extra file will be the interfaces file. The config file has been moved to the install directory and all your other work will take place there. This allows security to be instituted on the install directory, especially if other users have access to the machine. They may require access to the Sybase binaries etc. but they do not need access to the install directory. So its permissions may be changed to only allow the Sybase user access. Here's what the install directory might look like:
In this case, its a snapshot from a running server (note the .krg file). Note that I have elected to rename the config file to start with a dot. All log files start with log. and copies are kept for historical purposes. The RUN scripts are standardised using a template. This makes it easy to change things. The dataserver run script looks like this:drwx------ 3 sybase sybase 512 Nov 12 18:40 . drwxrwx--- 21 sybase sybase 512 Dec 2 15:02 .. -rw-r----- 1 sybase sybase 5694 Nov 12 18:39 .FOO.bak -rw-r----- 1 sybase sybase 5694 Oct 31 12:11 .FOO.cfg -rw-r----- 1 sybase sybase 45 May 3 1999 .FOO_BACKUP.cfg -rw------- 1 sybase sybase 17 Nov 12 18:39 FOO.krg -rwxr----- 1 sybase sybase 514 Apr 29 1999 RUN_FOO -rwxr----- 1 sybase sybase 459 Apr 29 1999 RUN_FOO_BACKUP -rwxr----- 1 sybase sybase 605 Jul 13 20:13 RUN_FOO_MON drwxrwx--- 2 sybase sybase 512 Apr 29 1999 SPR -rwxr-xr-x 1 sybase sybase 1843416 Aug 14 1998 auditinit -rw-r----- 1 sybase sybase 19248 Dec 14 13:20 log.FOO -rw-r----- 1 sybase sybase 12994 Jun 30 11:00 log.FOO- -rw-r----- 1 sybase sybase 27031 Aug 6 10:33 log.FOO.0 -rw-r----- 1 sybase sybase 68822 Aug 30 07:36 log.FOO.1 -rw-r----- 1 sybase sybase 86281 Sep 1 20:03 log.FOO.2 -rw-r----- 1 sybase sybase 481747 Dec 15 21:56 log.FOO_BACKUP -rwxr-xr-x 1 sybase sybase 4362 May 5 1998 setperm_all -rwxr-xr-x 1 sybase sybase 605 Feb 4 1998 setperm_monserv -rwxr-xr-x 1 sybase sybase 644 Aug 14 1998 showserver -rwxr-xr-x 1 sybase sybase 13240 Aug 14 1998 startserver
#!/bin/sh
#
# Adaptive Server name: FOO
# Master device path: /dev/rdsk/c0t1d0s7
# Error log path: /usr/sybase/install/log.FOO
# Directory for shared memory files: /usr/sybase/install
#
SYBASE="/usr/sybase"
SYBINSTL="/usr/sybase/install"
MASTER="/dev/rdsk/c0t1d0s7"
SERVER=FOO
export SYBASE SYBINSTL SERVER MASTER
${SYBASE}/bin/dataserver \
-M${SYBINSTL} \
-c${SYBINSTL}/.${SERVER}.cfg \
-d${MASTER} \
-e${SYBINSTL}/log.${SERVER} \
-i${SYBASE} \
-s${SERVER} | /usr/bin/logger -p local0.info &
When using this template, only two lines need be changed. These are the lines
that set the values for the MASTER and SERVER variables. However,
I usually keep the comment lines at the top in sync with these. Take note of the
last line. The dataserver is invoked as a background task. This eliminates
having an extra shell running. Also note that I pipe the output of the
dataserver process thru logger. The dataserver process writes both to its
error log and to stdout. This is very useful since it makes log filtering
somewhat easier. In this case I simply use logger to write to the syslog daemon
which sends log output to my workstation console.
The backup server run script goes thru the same treatment:
#!/bin/sh
#
# Backup Server name: FOO_BACKUP
# Error log path: /usr/sybase/install/log.FOO_BACKUP
# Tape configuration file: /usr/sybase/install/.FOO_BACKUP.cfg
#
SYBASE="/usr/sybase"
SYBBIN="/usr/sybase/bin"
SYBINSTL="/usr/sybase/install"
SERVER=FOO_BACKUP
export SYBASE SYBBIN SYBINSTL SERVER
${SYBBIN}/backupserver \
-S${SERVER} \
-I${SYBASE}/interfaces \
-M${SYBBIN}/sybmultbuf \
-c${SYBINSTL}/.${SERVER}.cfg \
-e${SYBINSTL}/log.${SERVER} &
Some options are not really required (like the location of the interfaces file
and the sybmultbuf binary), but are useful to set if you need to change them
for testing purposes.
The Run script for the Monitor Server looks like this:
#!/bin/sh
#
# Monitor Server name: FOO_MON
# Related Adaptive Server name: FOO
# Adaptive Server SA user name: sa
# Adaptive Server SA password:
# Error log path: /usr/sybase/install/log.FOO_MON
# Configuration file path: /usr/sybase/install/.FOO_MON.cfg
# Shared memory directory: /usr/sybase/install
#
SYBASE="/usr/sybase"
SYBINSTL="/usr/sybase/install"
SERVER=FOO
MONSERVER=FOO_MON
export SYBASE SYBINSTL SERVER MONSERVER
${SYBASE}/bin/monserver \
-M${MONSERVER} \
-S${SERVER} \
-Usa -P \
-m${SYBINSTL} \
-L${SYBINSTL}/.${MONSERVER}.cfg \
-l${SYBINSTL}/log.${MONSERVER} &
Modify these values to suit and don't forget to add the sa password to the MON
script. There is no script for the XP server. Here is a downloadable copy of
the RUN scripts.
For ASE 12.0 and above, the scripts are reasonably similar. Here is a downloadable example of the RUN scripts for ASE 12.0 and above.
To use logger, add this entry to the /etc/syslog.conf file and restart the syslog daemon.
Replace "workstation" with your workstation's name.# # This entry sends Sybase Server's errorlog to "workstation". local0.info @"workstation"
You should now be ready to restart your database server. As the Sybase user, invoke the server RUN script in the install directory on the command line. It should background itself. If you are using logger, the server's logging output should be also going to your workstation's console. If everything works, you are now ready for phase 2. If there are problems review the situation and check against the above details.
At some point, if you are working with a EBF, you will also need to install
the EBF messages. This is as good a time as any. The script is called
instmsgs.ebf and is in $SYBASE/scripts.
While the setup script may contain Transact-SQL code, its not recommended that it be run directly thru isql. Rather, each command should be run individually and its results checked. The script starts by doing some basic clean up housekeeping:
Basically the sa password is first assigned. There is a bug that still hasn't been fixed that names the server as local rather than the name you gave it thru sybsetup. So, the local name has to be dropped and the correct one added. Use sp_helpserver before and after to check this. Note that the problems appears to have been fixed in ASE version 12.5. I usually drop the two redundant tape devices and then add the correct one for the local machine (if you have more than one, add all the ones you want to use).use master go sp_password null, "password" go sp_dropserver local go sp_addserver FOO, local go sp_dropdevice tapedump1 go sp_dropdevice tapedump2 go sp_addumpdevice "tape", "dds2_tape", "/dev/rmt/0cn", 7000 go
Next, I create the device for tempdb and configure it. Your layouts should have been decided before you run this in the server. The entry looks like this:
disk init
name = "tempdb_dev",
physname = "/sybase/devs/tempdb.dev",
vdevno = 4,
size = 25600
go
alter database tempdb
on tempdb_dev = 50
go
use tempdb
go
sp_dropsegment "default", tempdb, master
go
sp_dropsegment "logsegment", tempdb, master
go
sp_dropsegment "system", tempdb, master
go
In this example, the tempdb device is created as a file. Check the next
available vdevno by running sp_helpdevice first and assign it to the
tempdb device. Size your device as required. You can also create more than
one device for tempdb if required. In this example, there is only one device
and it is 50 MB in size. Next, issue an alter database on tempdb. And
then finally drop the segment allocations on the 2 MB slice of tempdb on the
master device. Note that starting with ASE 12.5 you can now specify sizes in
values other than pages with disk init. See the documentation for further
details.
If you need to reset tempdb for any reason and start again, download this script and install it.
Repeat this process for your user databases (except for the last section, which only applies to tempdb). For example:
disk init
name = "foobar_a_dev",
physname = "/dev/rdsk/c2t0d0s0",
vdevno = 5,
size = 512000
go
disk init
name = "foobar_b_dev",
physname = "/dev/rdsk/c3t0d0s0",
vdevno = 6,
size = 512000
go
disk init
name = "foobar_c_dev",
physname = "/dev/rdsk/c4t0d0s0",
vdevno = 7,
size = 512000
go
disk init
name = "foobar_d_dev",
physname = "/dev/rdsk/c4t1d0s0",
vdevno = 8,
size = 512000
go
disk init
name = "foobar_e_dev",
physname = "/dev/rdsk/c5t0d0s0",
vdevno = 9,
size = 512000
go
disk init
name = "foobar_f_dev",
physname = "/dev/rdsk/c5t1d0s0",
vdevno = 10,
size = 512000
go
disk init
name = "foobar_log_dev",
physname = "/dev/rdsk/c0t1d0s4",
vdevno = 11,
size = 153600
go
create database foobar
on foobar_a_dev = 1000,
foobar_b_dev = 1000,
foobar_c_dev = 1000,
foobar_d_dev = 1000,
foobar_e_dev = 1000,
foobar_f_dev = 1000
log on foobar_log_dev = 300
go
use foobar
go
sp_changedbowner foobar
go
creates six data devices and one log device for a database called foobar.
The last step sets the database owner. User logins should be added before this
step (and it explains why the script cannot be run as is). You need to
repeat this process for all the user databases you intend to create. Ensure
that your script is correctly laid out and that the device names you choose
fit with the names of the databases (maintaining consistency is useful).
The last steps are to take care of issues like automatic server starts on system boots and other related issues. For a server start when the system boots, a run script is required. It is usually installed in /etc/init.d with either a hard or soft symbolic link in /etc/rc3.d. The script in /etc/init.d can simply be called sybase but its link in /etc/rc3.d need to begin with an S followed by a run number. Links can be made in some of the other /etc/rc?.d directories for system shutdowns. These scripts should begin with a K and then the run number. Read the README file in /etc/init.d for some hints and examine the other scripts. Here is a simple sample script for the FOO server. It does not do any checking during start up or shutdown. This can be added at user discretion as well as anything else that may be required.
For version at ASE 12.0 or above, two scripts are required - one to start the license manager ASE uses and one to start the ASE server. The script to launch the license manager should start before the ASE server. Here is a sample file that contains scripts for both.
The config directory also contains other miscellaneous scripts for adding
logins, users and device mirroring etc. They should be kept and maintained so
that if the need ever arises they may be rerun. This comment also applies to
compiled objects like stored procedures and triggers and the data dictionary
itself - although it would be expected that the source code for these would
be kept elsewhere.