It’s coming…
48 hours from now something big is coming!
Geek Spotlight: Michael Peppler
Sybase ASE on Ubuntu 8.04
Multicore Processors
VMware Virtualization
Logical Process Manager
Because Sybase has yet to address the GLIBC (LD_POINTER_GUARD) issue with any of their products on Linux, we are forced to find alternative ways of getting Sybase software to run on modern Linux distribution. In this situation, we will be using the Ubuntu 8.04 Just Enough OS (Ubuntu JEOS) Linux distribution.
After installing Ubuntu 8.04 Server JEOS on the physical or virtual machine, download the Ubuntu 7.04 Server iso image. Why Ubuntu 7.04? Ubuntu 7.04 is the last Ubuntu release that has an old enough GLIBC that Sybase software will work with.
% sudo debootstrap feisty /home/sybase file:///media/cdrom0
- Change the home directory of the sybase user to be /dbms/sybase by editing the /etc/passwd file
% sudo cp /etc/resolv.conf /home/sybase/etc/resolv.conf
% sudo cp /etc/hosts /home/sybase/etc/hosts
% sudo cp /etc/passwd /home/sybase/etc/passwd
% sudo cp /etc/shadow /home/sybase/etc/shadow
% sudo `cat /etc/apt/sources.list | sed -e ‘s/hardy/feisty/g’ > /home/sybase/etc/apt/sources.list`
% sudo mount –bind /dev /home/sybase/dev
% sudo mount –bind /proc /home/sybase/proc
% sudo mount -t devpts none /home/sybase/dev/pts
% sudo mount –bind /tmp /home/sybase/tmp
% sudo aptitude update
% sudo aptitude upgrade
% sudo aptitude install locales dialog wget debconf devscripts gnupg
% sudo aptitude install libstdc++5 libstdc++6 libaio
- If you’re installing v12.5x software, you will need to install an even older copy of libstdc++ (not needed for v15 or higher software):
% aptitude install libstdc++2.10-glibc2.2
- Install Sybase software into /dbms/sybase (as root in the chroot environment which you should still be in)
% sudo cp /dbms/sybase/SYBASE.sh /dbms/sybase/SYBASE.env
% sudo echo DSQUERY=MYASE >> /dbms/sybase/.SYBASE.env
% sudo echo sa_password > /dbms/sybase/.sapwd
% sudo chmod go-rwx /dbms/sybase/.sapwd
% sudo chmod u-wx /dbms/sybase/.sapwd
% sudo chown -R sybase /dbms/sybase
- Install the sybase_chroot script into /usr/local/bin and make it executable by root
- Install the sybase_ase rc script into /etc/init.d and make it executable by root
- Exit the chroot environment by typing ‘exit’
- create a symbolic link outside of the chroot environment to make /home/sybase/dbms appear as /dbms. This will allow you to access the Sybase software, notably OpenClient, as a normal user outside of the chroot environment.
% sudo ln -s /home/sybase/dbms /dbms
You are now able to start Sybase ASE using sudo /etc/init.d/sybase_ase start and stop Sybase ASE using sudo /etc/init.d/sybase_ase stop. Starting Sybase Replication Server, OpenServer, or similar Sybase software is simply a matter of copying the /etc/init.d/sybase_ase and tweaking the script copy.
If you feel this is way complicated and Sybase should just fix their software, let them know. Please point them to this page and refer to CR455393.
UPDATE: The GLIBC issue is fixed in v15.0.2 esd 4. It doesn’t seem to be working for everyone though. More information is needed about those systems where esd 4 doesn’t resolve the matter. No fix is available for 12.5x from Sybase.
UPDATE: Keep in mind, that the Sybase ASE 15.0.2 esd 4 patch is available only to Sybase customers with a current maintenance contract with Sybase.
Many of you may not know that Sybase openly lists the release schedules for ASE 12.5 and 15.0. The release schedules list not only when the estimated release date of the patches, but the list of bug fixes that are expected to be in each patch.
Targeted ASE 12.5.x Release Schedule and CR list Information
Targeted ASE 15.0 Release Schedule and CR list Information
How cool is that? Sybase has been providing this information for a number of years as you can still see the release schedule for the old 12.0 releases!
A word of caution: The release schedule and the bugs listed to be fixed in the patches are tentative and are not ‘set in stone’. Sometimes during testing issues are found with bug fixes (it might cause other issues) or some other thing might come up that might delay the bug fix or release of the patch.
Starting in ASE 12.5.2, Sybase added the with compression = X syntax, prior releases required the compress::X:: syntax. What is the difference?
In releases prior to 12.5.4 and 15.0.2, the two were functionally the same. Since 12.5.4 and 15.0.2, they are different:
ASE tells the backup server to load the zlib library and dump the database model to the file /tmp/model.dmp through the compress filter. The entire data stream is compressed. If you look at the dump file in a hex editor, then you will see the entire file is compressed.
ASE tells the backup server to load the zlib library and dump database model to the file /tmp/model.dmp but only the data volume is actually compressed. If you look at the dump file in a hex editor, you will see the first two volumes are mostly empty data (binary 0’s) but the embedded third volume is compressed.
You need to understand that whenever you dump a database to a file using this syntax, there are three volumes that are dumped. Two are administrative and the third is the data of your database.
ASE requires that the archive file, your database dump file, is dumped with the “with compression = X” format, if it is compressed, as it needs access to the administrative volumes.
So, how does this affect us as DBAs? If you dump a database with ‘with compression = X’ on 12.5.4 esd5, you will NOT be able to load it into 12.5.3 esd 5 without using the 12.5.4 backup server. This has bitten us in the past when we attempted to load the customers’ database dumps.
Don’t forget to look at Sybase’s manual from time to time
.