DBA > Job Interview Questions > Sybase Interview Questions and Answers

How do I run multiple versions of Sybase on the

More DBA job interview questions and answers at http://dba.fyicenter.com/Interview-Questions/

(Continued from previous question...)

How do I run multiple versions of Sybase on the same server?

The answer to this relies somewhat on the platform that you are using.

Unix
ASE Versions Before 12.0

This applies to Unix and variants, Linux included. Install the various releases of software into logical places within your filesystem. I like to store all application software below a single directory for ease of maintenance, choose something like /sw. I know that some are keen on /opt and others /usr/local. It is all down to preference and server usage. If you have both Oracle and Sybase on the same server you might want /sw/sybase or /opt/sybase. Be a little careful here if your platform is Linux or FreeBSD. The standard installation directories for Sybase on those platforms is /opt/sybase. Finally, have a directory for the release, say ASE11_9_2 or simply 11.9.2 if you only ever have Sybase ASE running on this server. A little imagination is called for!

So, now you have a directory such as /sw/sybase/ASE/11.9.2 (my preferred choice :-), and some software installed under the directories, what now? In the most minimal form, that is all you need. Non of the environment variables are essential. You could quite successfully run

/sw/sybase/ASE/11.9.2/bin/isql -Usa -SMYSERV -I/sw/sybase/ASE/11.9.2/interfaces

and get to the server, but that is a lot of typing. By setting the SYBASE environment variable to /sw/sybase/ASE/11.9.2 you never need tell isql or other apps where to find the interfaces. Then, you can set the path with a cool

PATH=$SYBASE/bin:$PATH

to pick up the correct set of Sybase binaries. That reduces the previous mass of typing to

isql -Usa -SMYSERV

which is much more manageable.

You can create yourself a couple of shell scripts to do the changes for you. So if the script a11.9 contained:
SYBASE=/sw/sybase/ASE/11.9.2
PATH=$SYBASE/bin:$SYBASE

# Remember to export the variables!
EXPORT PATH SYBASE

and a11.0 contained:
SYBASE=/sw/sybase/ASE/11.0.3.3
PATH=$SYBASE/bin:$SYBASE

# Remember to export the variables!
EXPORT PATH SYBASE

you would toggle between being connect to and 11.9.2 server and a 12.0 server, depending upon which one you executed last. The scripts are not at all sophisticated, you could quite easily have one script and pass a version string into it. You will notice that the PATH variable gets longer each time the script is executed. You could add greps to see if there was already a Sybase instance on the path. Have I mentioned imagination?

ASE 12.0 and Beyond

Sybase dramatically changed the structure of the installation directory tree with ASE 12. You still have a SYBASE environment variable pointing to the route, but now the various packages fit below that directory. So, if we take /sw/sybase as the root directory, we have the following (the following is for a 12.5 installation, but all versions follow the same format):

/sw/sybase/ASE-12_5
/OCS-12_5

Below ASE-12_5 is most of the stuff that we have come to expect under $SYBASE, the install, bin and scripts directories. This is also where the SERVER.cfg file has moved to. (Note the the interfaces file is still in $SYBASE.) The bin directory on this side includes the dataserver, diagserver and srvbuild binaries.

The OCS-12_5 is the open client software directory. It means that Sybase can update the client software without unduly affecting the server. isql, bcp and other clients are to be found here.

It does take a little getting used to if you have been using the pre-12 style for a number of years. However, in its defence, it is much more logical, even if it about triples the length of your PATH variable!

That is another good part of the new installation. Sybase actually provides you with the shell script to do all of this. There is a file in /sw/sybase called SYBASE.sh (there is an equivalent C shell version in the same place) that sets everything you need!

Interfaces File
The only real addition to all of the above is an easier way to manage the interfaces file. As mentioned before, ASE based apps look for the interfaces file in $SYBASE/interfaces by default. Unix is nice in that it allows you to have symbolic links that make it appear as if a file is somewhere that it isn't. Place the real interfaces file somewhere independent of the software trees. /sw/sybase/ASE/interfaces might be a sound logical choice. Now, cd to $SYBASE and issue

ln -s /sw/sybase/ASE/interfaces

and the interfaces will appear to exist in the $SYBASE directory, but will in fact remain in its own home.

Note: make sure that interfaces file is copied to its own home before removing it from $SYBASE.

Now you can put symbolic links in each and every software installation and only have to worry about maintaining the server list, on that server, in one place. Having the interfaces file common to many physical servers is trickier, but not impossible. Personally I would choose to put it in a central CVS repository and use that to keep each server reasonably up-to-date.

NT/2000

Firstly, I have tried the following on W2K and it all works OK. I have read a number of reports of people having difficulty getting clean installs under NT. 11.5 and 12.0 mainly. I cannot remeber having a problem with either of those myself, but I only ever installed it to test that stuff I write runs on all platforms. I have no intention of upgrading to XP until MS pays me to do it. It looks like a cheap plastic version of an operating system and I pity anyone that is forced to use it.

NT is tougher than UNIX to run multiple instances on, mainly due to the fact that it wants to do stuff for you in the background, namely configure environment variables. The following worked for me with the following versions of Sybase ASE all installed and running on a single server: 11.5.1, 11.9.2, 12.5. I don't have a version of ASE 12.0 for NT. If I can persuade Sybase to send them it to me, I might be able to get that running too. Notably, each and every one of the databases runs as a service!!!

1. Start by installing each software release into its own area. Make sure that it is a local disk. (See Q2.2.3.) I chose to install ASE 12.5 into C:\Sybase12_5 and ASE 11.9.2 into C:\Sybase11_9_2 etc. When it asks you about configuring the server, select "no" or "cancel".
2. Add a user for each installation that you are going to run. Again, I added a user sybase12_5 for ASE 12.5 and sybase11_9_2 for ASE 11.9.2.
3. As a system account, edit the environment variables (On W2K this is Settings->Control Panel->System->Advanced->Environment Variables...) and remove any reference to Sybase from the system path. Make sure that you store away what has been set. A text file on your C drive is a good idea at this stage.
4. Similarly, remove references to Sybase from the Lib, Include and CLASSPATH variables, storing the strings away.
5. Remove the SYBASE, DSEDIT and DSQUERY variable.
6. As I said before, I do not own 12.0, so I cannot tell you what to do about the new Sybase variables SYBASE_OCS, SYBASE_ASE, SYBASE_FTS, SYBASE_JRE etc. I can only assume that you need to cut them out too. If you are installing pre-12 with only 1 of 12 or 12.5, then it is not necessary.
7. Login as each new Sybase user in turn and add to each of these a set of local variables corresponding to path, Include, Lib and set them to be the appropriate parts from the strings you removed from the system versions above. So, if you installed ASE 12.5 in the method described, you will have a whole series of variables with settings containing "C:\Sybase_12_5", add all of these to local variables belonging to the user sybase12_5. Repeat for each instance of ASE installed. This is a tedious process and I don't know a way of speading it up. It may be possible to edit the registry, but I was not happy doing that.
8. If you have made each of the Sybase users administrators, then you can configure the software from that account, and install a new ASE server. Remember that each one needs its own port. 11.5.1 and 11.9.2 did not give me an option to change the port during the install, so I had to do that afterwards by editing the SQL.INI for each server in its own installation tree.
9. If you are not able to make each user and administrator, you will need to work with an admin to configure the software. (ASE requires administrative rights in order to be able to add the service entries.) You will need to log in as this admin account, set the path to the appropriate value for each installation, install the software and then set the path to the new values, install the next ASE etc. On NT for sure you will have to log out and log in after changing the path variable. 2000 may be less brain dead. Just be thankful you are not having to reboot!
10. Log back in as your tame administrator account and go into the control panel. You need to start the "Services" applet. This is either there if you are running NT or you have to go into "Administrative Tools" for 2000. Scroll down and select the first of the services, which should be of the form
"Sybase SQLServer _MYSERVER".
Right click and select "Properties" (I think this is how it was for NT, but you want that services properties, however you get there.) In 2000 there is a "Log On" tab. NT has a button (I think) that serves the same purpose. Whether tab or button, click on it. You should have a panel that starts, at the top, with "Log on as" and a a pair of radio options. The top one will probably be selected, "Local System account". Choose the other and enter the details for the sybase account associated with this server. So if the server is ASE 12.5 enter "sybase12_5" for "This account" and enter the password associated with this account in the next two boxes. Select enough "OK"s to take you out of the service properties editor.
11. None of the installations made a good job of the services part. All of them added services for all of the standard servers (data, backup, monitor and XP), even though I had not configured any but XP server. (The NT installation is of a different form to the UNIX/Linux versions.) The 12.5 XP configuration was OK, but the pre-12 ones were not. You will have to go in and manually set the user to connect as (as described earlier). If you do not do this, the services will not start properly.
12. You should then be able to start any or all of the services by pressing the "play" button.
13. Finally, you need to re-edit the local copies of the path, Include and Lib variables for your tame admin account if you use that account to connect to Sybase.

It worked for me, as I said. I was able to run all 3 services simultaneously and connect from the local and external machines. There is no trick as neat as the symbolic link on Unix. Links under NT work differently.

(Continued on next question...)

Other Job Interview Questions