
平台论坛博客文库

› 论坛 › 数据库技术 › Sybase › ASE on Linux FAQ

ASE on Linux FAQ [复制链接]

hello~world

稍有积蓄

论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2004-04-18 20:34 |只看该作者 |倒序浏览

http://www.peppler.org/FAQ/linux.html

ASE on Linux FAQ
Index of Sections
Sources and General Information
Where do I get the software?
Connecting to the server
Configuring memory
Sybase rc scripts and IDENTITY values
Raw disk I/O
Raw disk I/O doesn't work (RH 6.x, RH 7.x, SuSE)
Building sybperl on linux
Building Sybtcl on linux
Connecting from Win NT/95/98
Date formats
Sybase Central on linux
Placing tempdb on a RAM disk
Maximum number of file descriptors
Can I run more engines than CPUs?
FreeBSD/other BSD derivatives
Client Library apps dump core on startup
Can't connect to server from different host
Running ASE 12.5.x on RH 9
Running ASE 12.5.x on Fedora
Using a tmpfs device for tempdb
Trace flag 1650 (Migrating passwords from Solaris to Linux)
ASE 12.5.0.x and Async IO
--------------------------------------------------------------------------------
" 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., sqlserver.general, sqlserver.administration, sqlserver.linux, sqlserver.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.
" 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 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 sybperl on linux
NOTE: Recent Linux distributions (RH 7.x and later) do not require any special handling - you can build sybperl directly using the perl binary that comes with those systems.
Well, now that we have all of OpenClient we want to build the full sybperl distribution, right?
Well it turns out there's a gotcha there too.
The main problem is that there is a conflict between Sybase's DB-Library and the -ldb and -lndbm libraries. Perl is linked with these libraries by default, so Sybperl's Sybase::DBlib module will not work out of the box.
So here's how I build Sybperl:
Get a fresh copy of perl, from www.perl.com
Unpack the source, and run
./Configure -ders -Dlibs="-lnsl -lgdbm -ldl -lm -lc -lposix -lcrypt"
note: if you are trying to rebuild from an existing source tree you must remove or rename config.sh and Policy.sh.
Run make, make test.
If make test did not produce any errors, then su to root and run make install
Now go to the Sybperl source directory, and edit the CONFIG file:
Set SYBASE=/opt/sybase
Set EXTRA_LIBS=-linsck
and leave everything else the way it was originally.
Run perl Makefile.PL, make
Edit the PWD file and enter the information needed to connect to your Sybase server
Run make test
If all went well, su to root, and run make install.
You should now have a functioning sybperl installation.
There's also another write-up on this problem in the Sybperl FAQ, as well as in the README.linux file.
" 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:
Note that these files are no longer available from ftp.redhat.com. They may be available elsewhere (use Google), or you could try the glibc packages from Fedora Core 1.
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
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.

复制代码

文库|博客

返回列表

Chinaunix › 论坛 › 数据库技术 › Sybase › ASE on Linux FAQ