Kbase 21552: How To Avoid Common Issues with Progress SQL-92 Server
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  10/15/2008 |
|
Status: Verified
GOAL:
How to debug and avoid the most frequently encountered problems on SQL-92 on UNIX?
GOAL:
How to debug common problems with SQL-92 server on UNIX?
FACT(s) (Environment):
UNIX
FIX:
The _sqlsrv2 process is started by the database broker (_mprosrv). When the process is executed, it needs to load shared libraries it is linked with. The path to find shared libraries exists in the environment settings. Following are some environment variables that will affect search for shared libraries on different platforms.
Solaris/LINUX/True64: LD_LIBRARY_PATH
HPUX: SHLIB_PATH
AIX: LIBPATH
Typically, SQL-92 shared libraries reside in $DLC/lib directory, please make sure the related shared library environment variable, at a minimum, includes this directory.
Do not start the database using the _mprosrv executable, use the proserve script in $DLC/bin directory. This script (proserve) calls $DLC/bin/java_env and $DLC/bin/slib_env.
$DLC/bin/java_env defines java environment for Progress and $DLC/bin/slib_env defines shared library paths for Progress.
If the location of the shared libraries or the JDK installation are changed, those scripts should be updated.
********
tip: Following techniques can be used to trouble shoot shared library pathing problem:
Execute following commands in sequence:
. $DLC/bin/java_env
. $DLC/bin/slib_env
ldd $DLC/bin/_sqlsrv2 (Solaris/LINUX/True64)
chatr $DLC/bin/_sqlsrv2 (HPUX)
dump -H $DLC/bin/_sqlsrv2 (AIX)
********
If root starts Progress, _sqlsrv2 might not be able to find shared libraries in $DLC/lib directory on some platforms even when environment variables are set correctly. This is because some OS have implemented security mechanism that only allows root to load shared libraries from /usr/lib directory. Add a soft link to this directory if this is the case. For example,
ln -s $DLC/lib/libpro* /usr/lib
ln -s $DLC/lib/librocket_r.* /usr/lib
Do not set the SUID bit for the _sqlsrv2 binary. The SUID bit basically spawns the executed process as it would be started by the owner of the binary file. This technique is, for example, used by the database broker (_mprosrv) but cannot be used for the _sqlsrv2 process (unless you make symbolic links in the /usr/lib directory).
The easiest way to test the SQL-92 connection is to try this sequence:
1) Set DLC and PATH variables
2) Make a copy of the sports database (prodb sports sports)
3) proserve sports -S 3000
4) sqlexp sports -S 3000 (uses JDBC)
If this test fails, check the database log file for any errors. If there is just one line with "SQL server process terminated. (8841)" or nothing at all, the process couldn't start. The error messages were not visible because the process was spawned by the database broker.
Manually execute the _sqlsrv2 process by using these commands:
1) Set DLC and PATH variables
2) Set LD_LIBRARY_PATH (or similar) to $DLC/lib:$LD_LIBRARY_PATH
3) ldd _sqlsrv2 --> all found?
4) SQLSRV2_DEBUG=y;export SQLSRV2_DEBUG --> generates sqlsrv.log
5) _sqlsrv2 -z -D juniper.serverid=1 -D "juniper.dbfile=sports"
Step number 4 (above) will probably give you some errors. If there are missing symbols then an OS patch is usually required. Check the release notes. Sometimes the JIT compiler causes the troubles and you can switch it off in the java_env file using the startup option '-nojit'. Progress Version 9.1B uses JDK 1.1.8, Version 9.1C uses JDK 1.1.3. However, the JDK is usually not a problem.
-- Summary
1) Do not start the database using the _mprosrv binary, use the
proserve command.
2) Do not set the SUID bit for the _sqlsrv2 binary
3) Make sure you have all the shared libraries required.
4) Manually execute the _sqlsrv2 process.