ASE on Linux FAQ
Index of Sections
• Sources and general information
The information on this page has been gleaned from the ASE on Linux list
(ase-linux-list@isug.com)
which is generously hosted by the International
Sybase User Group, as well as from the news://forums.sybase.com/sybase.public.ase.linux newsgroup.
The mailing list is archived and searchable at
http://mathforum.org/epigone/ase-linux-list
thanks to Aaron Ross.
The ASE on Linux home is at http://linux.sybase.com. You can download the current free release of ASE for linux directly from there.
Henrik Fuxelius has put together a
short "how to" for installing ASE 11.0.3.3 on Linux Slackware 3.6. The document
is at http://www.algonet.se/~fuxen/sybase.html.
In a recent post to the ASE on Linux mailing list,
Teresa Larson listed the major other
Sybase-related resources that are available on the net:
Well, the ase-linux list will also help with questions/problems/issues on
the Sybase server itself -- it's not a Linux-only list as Luc's response
shows. :-)
As for other resources, for self-help, Sybase provides their documentation
on-line at http://sybooks.sybase.com/
Other forums where you can post Sybase questions are:
comp.databases.sybase - This is a public usenet news group. It's been
around for a long time and you'll find people with lots of experience as
well as some really nice Sybase engineers participating.
SYBASE-L - This is a listserver mailing list that has been around for
years. Like comp.databases.sybase, you'll find people with lots of
experience along with really nice Sybase engineers. To join the list, send
a SUBSCRIBE message (SUBSCRIBE SYBASE-L ur_firstname, ur_lastname) to
LISTSERV@LISTSERV.UCSB.EDU
http://support.sybase.com/newsgroups - This site is hosted by Sybase and
has forums for a variety of topics (e.g.,
ase.general, ase.administration, ase.linux,
ase.unix, powersoft.public.jaquar.cts,
powersoft.public.powerbuilder.general ...). The site has instructions on
how to set up your browser to access the news groups.
Those are the biggies. I hope it helps.
Another resource that you should look for is the
Sybase FAQ
that includes a lot of information on various topics concerning
Sybase.
I have written a simple system pre-requisite checker that you can run
prior to installing ASE 12.5.x or later to validate that your OS configuration
is correct - better to find out about any problems before starting the
install...
The script is at ase-check-prereq.pl.
• Where do I get the software?
The current free release of Adaptive Server Enterprise for linux is available for
download from http://linux.sybase.com.
You will be asked to fill in a simple registration form after which you can proceed
with the download.
• Connecting to the server
There is a TCP/IP bug in the 2.0.xx linux kernels, where xx is lower
than 36. This bug has been fixed by Alan Cox for the 2.0.36
kernel.
If you need to connect to the server from a different
machine you should be running the 2.0.36 kernel, or the 2.1.122 (or
later) development kernel.
You can download the kernels from ftp://ftp.us.kernel.org.
This site is widely mirrored, and you can reach a site closer to you by
changing the us in the hostname to your country code (au for
Australia, uk for the UK, fi for Finland, etc.)
Note that this site can also be accessed via http at
http://www.us.kernel.org.
It is only necessary to upgrade the kernel on
the machine that is running the server. Clients can run earlier
versions of the kernel with no problems.
• Configuring memory
By default the linux kernel is limited to 32 megabytes of shared
memory. You will need to increase that value in order to install
Sybase ASE.
For 2.4.x kernels the simplest way is to edit /etc/sysctl.conf, and
add a kernel.shmmax line. The running /sbin/sysctl -p
applies the changes (and the changes get applied automatically at
boot). My /etc/sysctl.conf has the following line:
kernel.shmmax = 268435456
which sets the maximum shared memory segment to 256MB.
You can also update the value in the /proc filesystem directly,
via the following command:
echo 268435456 > /proc/sys/kernel/shmmax
You can place this command in /etc/rc.d/rc.local (or its equivalent
on your system) to have this run at boot.
The following is only valid if you are still using a
2.0.x kernel:
If you are using a 2.0.x kernel, you need to edit
/usr/src/linux/include/asm/shmparam.h and change the line that says
#define SHMMAX 0x2000000 /* max shared seg size (bytes)
*/
to
#define SHMMAX 0x4000000 /* max shared seg size (bytes)
*/
which would increase the maximum size of the shared memory segment
to 64 megabytes.
In addition it seems that linux by default will only recognize 64
megabytes of RAM. To go beyond that you have to add a "mem="
entry to the lilo.conf file, and then run lilo for it to take.
One correspondant tells me he has 256 MB RAM on his linux box, and
his lilo.conf looks like this:
boot=/dev/sda3
map=/map
install=/boot.b
prompt
timeout=50
image=/vmlinuz
label=linux
root=/dev/sda3
initrd=/boot/initrd-2.0.34-0.6.img
append="mem=256M"
read-only
Note the append="mem=256M" line
in extract above.
• Sybase rc scripts and IDENTITY columns
The rc scripts that are provided with the ASE 11.0.3.3 and 11.9.2 releases
use the killproc facility to kill the servers when you execute
the stop command (eg, on RedHat /etc/rc.d/init.d/sybase stop)
It turns out that this essentially tells the server to perform a
shutdown with nowait, which has negative effects on any IDENTITY
columns in your databases (ie causes large gaps in the values that are
generated).
The fix for this is to change the stop section in the sybase rc script
to perform a real shutdown instead of calling killproc. Change
stop)
echo -n "Shuting down Sybase ASE configured servers: "
killproc dataserver
killproc backupserver
killproc monserver
# Add your own openserver applications.
echo
;;
to
stop)
echo -n "Stopping Sybase SQL Server"
$SYBASE/bin/isql -Usa -P******* -S$DSQUERY <<STOPIT
shutdown SYB_BACKUP with nowait
go
shutdown
go
exit
STOPIT
killproc monserver
# Add your own openserver applications.
echo
;;
Obviously you need to edit the above to set the password to
isql correctly, and you need to make sure that $DSQUERY is set correctly
in the script (or you may want to hard code it). You also need to
duplicate the code if you have more than one SQL Server running.
Mike Chachich has pointed out to me that this shutdown technique
might not work well (or might take a long time) on a very busy
system. He suggests issueing checkpoint requests for each
database, kill all user processes and then issue a shutdown after
all user processes have exited. You would have to write a small
script (perl, anyone?) to do this, but it should be fairly
simple to do.
• Raw disk I/O
Raw disk I/O is available with ASE 11.0.3.3 and ASE 12.5 and later.
It is NOT available when using ASE 11.9.2.
The 11.9.2 and later releases use the O_SYNC flag for all the
open(2) calls when using filesystem devices, which forces the
kernel to flush the data from the filesystem cache to disk after each
and every write. This entails a significant performance hit, and can
be controlled on a per-device basis via the sp_deviceattr stored procedure
using the dsync option.
In addition, chattr +S <file> forces the O_SYNC flag to be used
for a file regardless of whether ASE has it enabled on not.
• Raw disk I/O doesn't work (RH 6.2, RH 7.x, SuSE...)
When Wim added Raw IO support to ASE 11.0.3.3 the beta Raw IO kernel
patch for RH 6.1 was using a specific device layout, which the RH engineers
then saw fit to change for RH 6.2 and later releases. SuSE and maybe others
also follow this device layout.
In RH 6.1 the Raw device administration to bind devices was via /dev/raw.
In RH 6.2 (and later) RH decided to reorganize this, using /dev/rawctl for
the device binding and a /dev/raw directory to hold the raw devices.
sybinit tries to use the original /dev/raw for binding the devices and a
/dev/sybase directory for the devices themselves, which fails under
RH 6.2 and later.
This can be fixed like this:
First, become root (and be careful what you do next!)
Go to the devices directory
# cd /dev
Make sure no raw device binding is active, and no servers that depend on
this stuff are running.
Move the 'raw' directory to 'sybase':
# mv raw sybase
Create a symbolic link for the administration device
# ln -s /dev/rawctl /dev/raw
Make sure you have the access permissions to the bind device, raw
devices and the partitions that are bound to raw devices set correctly.
You should follow the instructions from the CONFIGURE file from here.
Now if you restart sybinit it should automatically detect the
device size for the raw device bound to the partition that you want to use
as master device (or whatever...)
• Building Sybtcl on linux
Sybtcl builds
'out of the box' on Linux, assuming you have Tcl/Tk installed. Tcl
8.0 or higher is recommended. RedHat versions 5.1 and higher include
Tcl/Tk 8.0 as .rpm files.
To build Sybtcl, simply unpack the Sybtcl distribution, change to
the sybtcl-2.5/unix directory, and:
configure make make install
You must be 'root' to install into the /usr directories.
To install Wisqlite, simple copy 'wisqlite' from the ./samples
directory to /usr/bin. Edit /usr/bin/wisqilite and change the top
line to:
#!/usr/bin/wish8.0
• Connecting from Win NT/95/98
See the Draft HOW-TO on Connecting from Windows Clients by Shaun Lipscombe
for a fairly complete write-up.
Sybase normally distributes the Windows client libraries when you
buy a server for any platform.
The 11.9.2 release for linux includes the PC client tools (including
Sybase Central) and these can be used to connect to the linux server. I'm not
100% sure what the licencing issues are with this package - you can download
the Win32 client, but this is theoretically for development use
only. You are supposed to pay a licence fee for production use (at least for
the server - again I don't know what the situation is exactly for the Win32
client tools - Contact Sybase if you are in doubt.)
These files are available from http://linux.sybase.com
Geoff Winkless reports that when he tried to use these libs he was missing
the ctl3d32.dll DLL, but that this file is on the Windows distribution
CD.
There are ODBC drivers are available from Openlink software at
http://www.openlinksw.com and you can also use the MS-SQL drivers if you
configure the Sybase data source
as follows (submitted by Carol Lerche)
Using MSSQL's client support to access Sybase ASE on Linux:
First, realize that some applications/tools (such as the MS SQL
isql.exe) use the MS/SQL version of dblib directly, and some (such as
Perl DBI) use it through ODBC, so you probably should start by
configuring the Sybase server as a MS/SQL dblib client.
STEP 1: Execute the SQL Server Client Configuration Utility (could
appear in the Microsoft SQL Server 6.5 program group on your start menu
if that's the version you are running).
STEP 2: Under the 'Advanced' tab name your Linux/ASE server something
meaningful in the 'Server' field, eg MS2LINUX. In the DLL Name tab,
select 'TCP/IP Sockets'. In the Connection String field, enter the DNS
name and port matching your Linux ASE machine and its interface file.
Port number should be separated by a comma from the DNS name. E.g.
linux-sybase.anydomain.com,2345
Note that it doesn't matter which port you use, so long as you make it
match the port that Sybase is using on the Linux side, as specified in
your interfaces file.
Press the "Add/Modify" button to add this entry to the Advanced Client
Options list box. This creates a registry entry under
HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->MSSQLServer->Client->ConnectTo
with the name you gave (e.g. MS2LINUX) and a value of
"DBMSSOCN,linux-sybase.anydomain.com,2345" (assuming your dll for TCP/IP
sockets is named the same as mine).
STEP 3: (Here, I'm describing the NT procedure...there may not be a
distinction between user and system DSN in Windows 9x). Under
"Settings--Control Panels--ODBC" select the User DSN or System DSN tab
depending on whether only the logged on user or all NT users on this
machine should see the data source. Press the Add button.
STEP 4: In the resultant "Create New Data Source" window, select
"Microsoft SQL Server" or "SQL Server" (these are synonyms on my
system). Press Finish.
STEP 5: Supply a Data Source Name and Description (the name is
arbitrary, and doesn't need to match anything else, but should
presumably be mnemonic). Pull down the Server selection and choose the
server you configured in Step 2. This should properly set the Network
Address field as "linux-sybase.anydomain.com,2345" and the Network
Library field to DBMSSOCN (or "(default)") as well. Do not select "Use
trusted connection". Press OK or...
STEP 6 (optional): Press the Options button to configure a specific
database name, choose a language, and/or select other options. Dismiss
this window when you're done.
What won't work after you do this: any tool that has built in knowledge
of the details of MS/SQL server's platform-specific DDL/DML/SQL and
generates this for you through a GUI will eventually send the wrong SQL
if you try enough database administration functions. Also, we were
unable to make a Java JDBC client work against Sybase using the MS/SQL
ODBC drivers, although Perl DBI:ODBC does appear to work.
• Date Formats
This is for the 10.0.4 version of OpenClient (ie the one that is included in the
free 11.0.3.3 release.)
There is what I consider a bug in the locale handling of OpenClient on
linux. By default, when doing a "select getdate()" you get only "01/15/99"
in the result, instead of the more normal "Jan 14 1999 7:50AM" format
that you normally get on other platforms. This can be fixed (somewhat)
by editing /opt/sybase/locales/us_english/iso_1/common.loc and
commenting out the
dateformat=mdy
line.
Another option is to change the default date conversion format by using
the OpenClient API (e.g. cs_dt_info() for Client Library). Sybperl
provides access to this function, as does DBD::Sybase.
• Sybase Central on linux
Sybase 11.9.2 includes the Sybase Central GUI admin tool, but only for Win32
machines. For a native linux app you should check out Like Sybase Central
a freeware tool developped by Pascal Ginola,
available from http://perso.wanadoo.fr/laserquest/linux/
As of ASE 12.5 Sybase Central is written in Java, and runs fine under linux.
It is included in the 12.5 release.
• Placing tempdb on a RAM disk
First, add RAM disk support to your kernel by setting CONFIG_BLK_DEV_RAM = 1.
This can be done by running make menuconfig or make xconfig
in the /usr/src/linux directory and enabling RAM disk support in
the Block Devices section.
You need to rebuild your kernel for this to take effect.
Stefan Goebel wrote this on
sybase.public.sqlserver.linux:
- 1. The default max size of a RAM disk is 20mb. You probably want to
increase this by setting rd_size in drivers/block/rd.c from
204800 to 102400 (for a 100mb max size, for example).
- 2. Create the RAM disk, mount it, and then create the new Sybase device
for tempdb. Something like this should work to create the filesystem:
troll#> /sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
troll#> /bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
troll#> /bin/chown sybase:sybase /opt/sybase/tempdb
troll#> /bin/touch /opt/sybase/tempdb/tempspace.dat
troll#> /bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
Now we need to move tempdb from master to this new file. So we need to
create a Sybase device, and then extend tempdb to this new device:
1> disk init name="tempdbdev", physname="/opt/sybase/tempdb/tempspace.dat",
vdevno=XX, size=26000
(replace XX with the correct vdevno!)
2> go
Now to move tempdb off of master I suggest looking at the Sybase FAQ, Q1a.3
- 3. Finally, modify the startup scripts (/etc/rc.d/sybase) to
something like:
/sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
echo "Mounting ramdisk to /opt/sybase/tempdb..."
/bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
/bin/chown sybase:sybase /opt/sybase/tempdb
echo "Touching Tempspace..."
/bin/touch /opt/sybase/tempdb/tempspace.dat
/bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
case "$1" in
start)
echo "Initializing ramdisk..."
/sbin/mke2fs -q -m0 /dev/ram 52000 -F > /dev/null
echo "Mounting ramdisk to /opt/sybase/tempdb..."
/bin/mount /dev/ram /opt/sybase/tempdb -t ext2 > /dev/null
/bin/chown sybase:sybase /opt/sybase/tempdb
echo "Touching Tempspace..."
/bin/touch /opt/sybase/tempdb/tempspace.dat
/bin/chown sybase:sybase /opt/sybase/tempdb/tempspace.dat
stop)
echo "Shutting down Sybase ASE configured servers: "
/sbin/killproc ${SYBASE}/bin/dataserver
/sbin/killproc ${SYBASE}/bin/backupserver
echo "Dismounting ramdisk /opt/sybase/tempdb"
/bin/umount /opt/sybase/tempdb
Note that modifying linux kernel files may invalidate your enterprise
support contract with your Linux Support Vendor (e.g. Red Hat). Please
contact your support vendor for approval prior to making any kernel
source changes.
It should also be noted that using tmpfs for a RAM disk is preferable to
making a RAM drive. RAM drives require that the reserved space remain in
physical memory. Memory usage must be carefully monitored to prevent
memory starvation or excessive swapping of other processes.
See Using a tmpfs device for tempdb for details.
• Maximum number of file descriptors
- glibc-2.0.7-29 allows for a maximum of 1024 file descriptors
(ASE 11.9.2 for Linux was built on this)
- glibc-2.1.x allows for up to 16K file-descriptors
- due to CR# 202238 we are limited to 256 file descriptors per engine.
This was be fixed in 11.9.2.2
• Can I run more engines than CPUs?
- The default behavior of ASE is to query /proc/cpuinfo for the number of CPUs
- Set the SRV_CPUCOUNT environment variable to the
number of engines to override this behavior
$ setenv SRV_CPUCOUNT 8 <- up to 8 engines
• FreeBSD/other BSD derivatives
Wim ten Have has successfully started ASE 11.9.2 for Linux on FreeBSD 3.3
(taken from ase-linux-list@isug.com on October 7th, 1999)
I run the Linux/ASE 11.9.2 and Linux/OCS 11.1.1 on a FreeBSD setup
FreeBSD 3.3-RELEASE #1 with Linux bin compatibility support enabled.
It works.
% uname -a
FreeBSD calera.sybase.com 3.3-RELEASE FreeBSD 3.3-RELEASE #1:
Thu Sep 30 19:32:09 CEST 1999 root@calera.sybase.com:/usr/src/sys/compile
/SYBASE_KERNEL i386
% ps
PID TT STAT TIME COMMAND
10273 p0 Ss 0:00.10 -csh (csh)
10294 p0 R+ 0:00.00 ps
266 v0- S 35:47.04 dataserver -d./master.dat -sSYBASE
% ipcs
Message Queues:
T ID KEY MODE OWNER GROUP
Shared Memory:
T ID KEY MODE OWNER GROUP
m 196608 1761877794 --rw------- sybase group
Semaphores:
T ID KEY MODE OWNER GROUP
% isql -Usa -P
1> select @@version
2> go
Adaptive Server Enterprise/11.9.2/P/Linux Intel/Linux 2.2.5 i586/OPT/
Wed Aug 18 10:57:21 1999
*** Keep in mind that the distributed Adaptive Server Enterprise
software for "Linux Intel" is and was never intended / tested,
certified under such a setup. I run this parallel setup for
curiosity, debug/test and educational purposes ;-)
-- Wim ten Have.
• Client Library apps dump core on startup
On versions of linux that have glibc 2.1 (eg Red Hat 6.x) Client Library apps
(including sybperl's Sybase::CTlib and DBD::Sybase) will dump core on startup if
the context allocation routines fail. The context allocation routines load the locale
information, using the SYBASE, LANG and LC_ALL environment
variables to determine which locale information to load for date formatting and
other data conversions.
The locales.dat file looks like this:
[linux]
locale = ENGLISH, us_english, iso_1
locale = FRENCH, french, iso_1
locale = GERMAN, german, iso_1
locale = C, us_english, iso_1
locale = default, us_english, iso_1
The SYBASE environment variable is used to find the locales.dat file
(in $SYBASE/locales/locales.dat), and then the LANG or LC_ALL variables
are used to find the correct locale entry in the locales.dat file. To do so it
goes to the [linux] section of the file, and then looks for a line where the first
token after the locale = part matches the LANG or LC_ALL variable.
By default RedHat 6.x (and possibly other distributions) set LC_ALL
to a value that combines the country and the language. On my machine this
is us_EN (for USA, English). This value is not in the locales.dat
file, hence the problem.
On my system I've solved this by adding this value to the locales.dat
file, like this:
*** locales.dat.orig Tue Jan 18 17:48:32 2000
--- locales.dat Thu Dec 23 10:14:39 1999
***************
*** 166,171 ****
--- 166,172 ----
locale = default, us_english, iso_1
[linux]
+ locale = en_US, us_english, iso_1
locale = ENGLISH, us_english, iso_1
locale = FRENCH, french, iso_1
locale = GERMAN, german, iso_1
If your Client Library app fails on startup you should therefore check the settings of
these three environment variables, and make any adjustments that are needed.
• Can't connect to server from different host
You've installed Sybase on your linux machine, and you're certain that
it's running. You can ping the host where Sybase is running from other
hosts on your net, but you can't connect to the database server itself.
Chances are you are on a Red Hat 6.x system, where the standard installation
creates an incorrect /etc/hosts file with the hostname as an alias on
the localhost line, instead of on a line by itself. You can use
netstat -a -n | grep <sybase port> (where sybase port
is the port that Sybase is listening on) to verify that Sybase is listening
to the correct IP address.
Check your /etc/hosts file - if it looks like this:
127.0.0.1 localhost my_host
then you have a problem - change your /etc/hosts file to look like this
instead:
127.0.0.1 localhost
192.168.0.1 my_host
(obviously you need to use the correct IP address for your host, and the
correct host name!)
This should fix the problem.
An alternative solution is to change the hosts: entry in
/etc/nsswitch.conf so that DNS or NIS is used before /etc/hosts for hostname
lookups. By default /etc/nsswitch.conf has the following:
hosts: files nisplus dns
If you change that to something like
hosts: nisplus dns files
host name lookups should only access /etc/hosts if the information isn't
available anywhere else, and therefore give the correct IP address for the
hostname.
• Running ASE 12.5.x on RH 9
Added Aug 27 2003, thanks to Jason Froebe.
ASE 12.5.x fails to run on RH 9 because of a fix
added to glibc. This fix causes the dynamic linker to revert to the i386
version of glibc in situations where the binary being run accesses _errno
directly. The fix was done to ensure correct behavior for multi-threaded
applications. Unfortunately ASE isn't compatible with this fix. A solution
to this problem is provided below:
We now have a solution (courtesy of Jakub Jelinek from RedHat) rather than
just a workaround:
From the Rawhide branch:
http://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS
glibc-2.3.2-71.i686.rpm
glibc-common-2.3.2-71.i386.rpm
glibc-devel-2.3.2-71.i386.rpm
tzdata-2003a-2.noarch.rpm
Note - as these files are no longer available from Red Hat I have
made them available at http://www.peppler.org/downloads/RPM/redhat-9.0/.
1) ASE needs to use /lib/i686/libpthread.so.0 to run properly. The RedHat
patch makes us load /lib/libpthread.so.0 instead. On a default
installation of AS 2.1, the library /lib/tls/libpthread.so.0 was not
installed.
2) Only glibc < 2.3.2-31 should load /lib/libpthread.so.0 if the warning
is printed.
3) Later glibc 2.3.2-31 and higher, will correctly load the
/lib/i686/libpthread.so.0.
Thanks to everyone that was involved to resolve this issue!
• Running ASE 12.5.1 on Fedora
Fedora is the new name of Red Hat's "consumer" releases (as opposed
to their "Enterprise" releases).
ASE 12.5.1 requires a Java JVM to install. I downloaded mine from
http://java.sun.com/j2se/1.4.2/download.html.
There are some instructions on performing the JVM install at
http://fedora.artoo.net/faq/#Java.
Next, the dataserver binary is linked with some older libstdc++.so
libraries. To get these libraries you need to install
compat-libstdc++-7.3-2.96.118.i386.rpm. This is available in the Fedora
distribution.
Now you are ready to go ahead and install.
Note that the 12.5.1 installer doesn't create a "sybase" user for you,
doesn't install any rc files, and doesn't edit /etc/ld.so.conf, so you'll have
to do that yourself. Also remember to set the kernel.shmmax entry in
/etc/sysctl.conf and run /sbin/sysctl -p before building a new server.
• Using a tmpfs device for tempdb
From a post to ase-linux-list by Jason Froebe.
There will be significant gains in performance if you create a tmpfs
filesystem and put tempdb on it. tmpfs requires a recent 2.4 kernel
such as 2.4.18 or so.
Create a directory called /dev/sybase_tempdb as the sybase user and
change the permissons to 1700 as we only want Sybase to be able to
write to it but we don't want it to be accidentally deleted.
If you put the following entry in your /etc/fstab, it will create a
10GB tmpfs filesystem and mount it on /dev/sybase_tempdb.
/etc/fstab:
tmpfs /dev/sybase_tempdb tmpfs mode=700,rw,size=10G 0 0
Note that, whatever size you choose, you have to have swap be AT LEAST
1x the size of all your tmpfs mounts.
You would then create your tempdb like so:
isql (shows 12.5.1 syntax):
1> disk init name = "tempdb2", physname ="/dev/sybase_tempdb/tempdb2.dat",
vdevno = 8, size = "10G", dsync = false
2> go
1> alter database tempdb on tempdb2 = 10240
2> go
You would also have to modify your RUN_<server> file as any
time you reboot your Linux box, you will have an empty tempdb directory.
RUN_<server>:
touch /dev/sybase_tempdb/tempdb2.dat
dataserver .....
According to Sybase TechSupport, Sybase Engineering has no objections
to using tmpfs on Linux (it is used on the other unixes - not sure
about Mac OSX though)
• Trace flag 1650 (Migrating passwords from Solaris to Linux)
Normally it isn't possible to migrate passwords (from master..syslogins)
between platforms because the encryption is incompatible.
Trace flag 1650, available in 12.5.1, makes it possible for Solaris passwords
to be copied to Linux servers and used there.
From CR #324847:
"Passwords from Solaris 32-bit/64-bit can be migrated to Linux using
BCP or other data migration tools and used as such. Trace flag 1650 will turn
on the compatibility mode. This compatibility mode is available only on
Linux platform and only passwords from Solaris 32-bit/64-bit can be migrated."
• ASE 12.5.0.x and Async IO
ASE 12.5.0.3 will use asynchronous IO by default. However, the async IO
requests can sometimes block, causing "timeslice" errors to occur.
This can be fixe by starting the server with the -T1639 traceflag.
According to my information ASE 12.5.1 no longer requires this flag to be
set.
• Can't allocate more than 128MB (ASE 11.x, RH EL 3.x)
When starting Sybase ASE 11.x under RedHat Enterprise Linux 3.x it is
not possible to allocate more than 128MB of memory (sp_configure 'total memory').
This is due to a change in the format of /proc/self/maps which ASE
uses to determine where to place the shared memory segment.
The fix consists in tricking ASE so that it doesn't see this file.
Mike Zakharoff contributed the following method:
Here is how I did it using "vi -b" (binary edit), which worked
great. There are other binary editors available.
# cd /opt/sybase/bin
# cp -p dataserver dataserver.orig
# vi -b dataserver
search for the **FIRST** occurrence "/proc/self/maps", which
looks like this on my system:
/\/proc\/self\/
/proc/self/maps^@NULL^@key: 0x%lx id: %d file:
^@...^@^@0x%lx,0x%lx,0x%lx,0x%x^@os_create_keyfile
And change the "/proc" to something different... I used "/Proc"
NOTE: There is another "/proc/self/maps" entry, DON'T TOUCH
that one! Only change the one that is close to the
"os_create_keyfile" entry, as above.
I also changed the Sybase Boot information line to identify the
hacked dataserver binary:
Search for "P-FREE", which looks like this:
/P-FREE
SQL Server/11.0.3.3 ESD#6/P-FREE/Linux Intel/Linux 2.2.14
i686/1/DEBUG/Fri Mar 17 15:45:43 CET 2000
I then changed "P-FREE" to "PATCH1", which fits byte for byte.
• Full-Text Search Engine can't communicate with ASE on Fedora Core 1 (12.5.x)
Fedora Core 1 has a kernel that enables the Native Posix Thread Library (NPTL).
This is supposed to be 100% compatible with previous threading models, but
it turns out that it triggers a bug in the Full Text search engine where
a call to fcntl(..., F_SETOWN)
fails due to a permission error.
The fix here is to ask the kernel to run this process in a different mode,
using the LD_ASSUME_KERNEL environment variable:
[sybase@localhost install]$ LD_ASSUME_KERNEL=2.4.1 ./RUN_textsvr
Solution submitted by David Rees.
• Installing ASE 12.5.x fails on Fedora Core
In some circumstances ASE can fail to install with various "infected with 11"
errors. These can be caused by Async IO errors, in which case the server
must be started with traceflag 4061. As this can't be done in the RUN_xxx
file during the install you have to use a little bit of trickery:
% setenv SYBASE <your-sybase-release-directory>
% setenv SYBASE_ASE ASE-12_5
% setenv SYBASE_OCS OCS-12_5
% set path = ($SYBASE/$SYBASE_ASE/bin $SYBASE/$SYBASE_OCS/bin $path)
% cd $SYBASE/$SYBASE_ASE/bin
% mv dataserver dataserver.bootstrap
% cat > dataserver
#!/bin/sh
$SYBASE/$SYBASE_ASE/bin/dataserver.bootstrap $* -T4061
^D
% chmod 755 $SYBASE/$SYBASE_ASE/bin/dataserver
% srvbuild
Once the server has been built you can undo the above operation and add
the -T4061 traceflag to your RUN_xxx file.
Submitted by Wim ten Have (on the ase-linux-list mailing list)
• Installing/Running ASE on systems with glibc 2.4.x (Fedora Core 5, etc)
Note
David Wein posted in sybase.public.ase.linux that this problem, which was followed
by Sybase under CR 479363, is corrected in ASE 15.0.2 ESD4, and 15.0.1 Cluster Edition
ESD 2. So with those versions you should not have to fiddle with LD_POINTER_GUARD
anymore.
ASE (12.5.x, 15.x) will not run on a system with glibc 2.4.x (that's Fedora Core 5 and later,
among others). Here is a work-around, supplied by "Chris" in sybase.public.ase.linux:
Symptoms of the problem are ASE's failing to build when you run the
installer, or "Segmentation Fault" when trying to start an ASE
instance. The Seg Fault happens right after Engine ) is brought online
in the error log.
If you are running Fedora Core 5 or 6
You will need to set the environment variable LD_POINTER_GUARD to 0, in
your sybase .profile, as follows:
export LD_POINTER_GUARD=0
Alternatively, just export this from the shell. If you haven't built
any ASE's yet, you'll need to export this before running the installer,
otherwise ASE will fail to build. If you are trying to boot an already
installed ASE, then put it in your .profile / .bash_profile or export
it as an environment variable before starting ASE.
If you are running Ubuntu / Kubuntu "Edgy"
You will need to set the environment variable LD_POINTER_GUARD to 1 in
your sybase .profile, as follows:
export LD_POINTER_GUARD=1
I googled around a bit trying to find out what the LD_POINTER_GUARD
thingie did and ran across a posting / blog where it talked about
insome glibc versions it's backwards ... RedHat just made a change I
guess and that's why you have to set it to "0" for Fedora and "1" for
Ubuntu / Kubuntu / Debian (glibc 2.4). Same info applies if you are
building a new ASE.
If you are running Suse 10.1
You will need to set the environment variable LD_POINTER_GUARD to 1 in
your sybase .profile, as follows:
export LD_POINTER_GUARD=1
Same discussion as for Ubuntu.
I've tried all of the above they all work with the workaround listed.
Happy ASE-ing! I've tested all of the above distros (sorry it took me
so long, was on the road a lot over the last several weeks) and they
allow ASE to boot; the workaround should be valid for ASE 15.x and 12.x
(prolly even for 11.x if you wanted to try).
See also forums.sybase.com for more information.
• Some engines refuse to start
Patrick LeBoutillier supplied the following:
I stumbled onto a strange problem this week regarding ASE 12.5 on
Linux (FC3, 2.6.17) where some of the engines where refusing to start
with the following error message in the Sybase log:
00:00000:00010:2007/05/04 19:09:13.04 kernel upsetaffinity: can't
affinity to engine 1 for kpid 851981
00:00000:00010:2007/05/04 19:09:13.04 kernel upsetaffinity: can't
affinity to engine 1 for kpid 851981
After googling a bit, I found what appears to be the solution
(depending on the kernel version):
kernel.exec-shield=0
kernel.exec-shield-randomize=0
or
kernel.randomize_va_space=0
in /etc/sysctl.conf, followed by a
$ sysctl -p
• srvbuild keyboard issue
Guy Gallagher posted the following to sybase.public.ase.linux:
When starting srvbuild, you may get the following errors:
Warning: translation table syntax error: Unknown keysym name: osfActivate
Warning: ... found while parsing ':osfActivate: ManagerParentActivate()'
Solution:
cd to /usr/X11R6/lib/X11
create a symbolic link:
- ln -s /usr/share/X11/XKeysymDB XKeysymDB
cd to /usr/X11R6/lib/X11/locale
make symbolic links to
/usr/share/X11/locale/en_US.UTF-8
/usr/share/X11/locale/locale.alias
/usr/share/X11/locale/locale.dir
In my case, I had to create the directory /usr/X11R6/lib/X11/locale; YMMV.
• dsync performance with 2.6 kernels
ASE 15.0.2 (non-cluster edition) has very bad disk IO performance when using dsync on
file-system devices on 2.6 kernels.
Ben Slade reports the following:
Surprisingly, on Linux 2.6, ASE 15.0.2's (non-cluster edition)
performance on "dsync" devices (file or non-raw block based devices with
the dsync option set) is horrible (about 8 times slower).
The really insidious thing here is if the master device is file based,
you can't set the directio option. So you pretty much have to use raw
devices for master. But the master device using dsync doesn't normally
doesn't cause significant problems, except when you do stuff like
dropping large databases or running installmaster. Then the server
just takes forever to run the command.
Background:
As per "solved case" 11432104:
On a 2.6 linux kernel, with ASE 15.0.2 and higher you must use direct
i/o on file system devices for good performance. In Cluster Edition,
which is built on RHEL 4 (i.e. 2.6 kernel) we use direct i/o by
default. But regular ASE 15.0.2 is built on RHEL 3, so it still uses
dsync on by default.
Regular ASE 15.0 will not be built on RHEL 4 until we merge the products.
