Installing Oracle 10g on SUSE Linux 9.1
Time flies when having fun with databases, and recently it came to my attention that my 8.1.7 developer system was more than dusty. So after a quick trip down to the local memory emporium (the amount of RAM specified by each new Oracle version is without fail twice the amount I currently have) I set out to install Oracle 10g on my PC du jour.
Previous versions of Oracle were always somewhat tricky to install, at least in Linux, requiring certain very specific Java and glibc versions, the sacrifice of small mammals and the like, so I was somewhat apprehensive as to whether 10g would deign to reside on my shiny new SUSE 9.1 Professional with its 2.6 kernel - especially as it's not listed anywhere on the support matrix:
A little research indicated successfull installs on a variety of distributions including various SUSE versions, albeit with a variety of minor problems, which gave me grounds for apprehensive optimism.
This document assumes you are familiar with the basics of Oracle installation and administration. It does not provide a step-by-step installation guide and only details the issues specific to Oracle 10g and SUSE Linux 9.1.
As with previous Oracle versions, 10g is available as a free download for development and / or evaluation purposes from Oracle (unless you are a resident of an Axis of Evil™ Member Nation and / or are planning to use the software to develop / evaluate weapons of mass destruction). The main download page is:
You will of course require a free OTN membership.
To install the server and associated software only the first file (ship.db.cpio.gz) is required. For some reason both Oracle and most third-party documentation imply this file should be burnt to CD. This is not necessary, unless you are extremely short on disk space, and shown below, one installation file may need to be modified.
Unpack it somewhere convenient with
gunzip ship.db.cpio.gz and
cpio -idmv < ship.db.cpio.
The Oracle install document contains the basic information needed to carry out the installation:
Previous SUSE versions came with appropriate users and groups for an Oracle installation already included. Presumably the move towards certifying Oracle only on the high-end SLES (SUSE Linux Enterprise Systems) accounts for their disappearance.
The kernel parameters, at least with the SUSE stock kernel, are pretty much as Oracle desires. Only semopm is a little low (32 as opposed to 100); set the correct values with:
echo "250 32000 100 128" > /proc/sys/kernel/sem
Also, ip_local_port_range is 32768 61000 , Oracle recommends 1024 65000;
echo "1024 65000" > /proc/sys/net/ipv4/ip_local_port_range
should do the trick.
There appears to be a subtle problem when Oracle tries to locate an unused port for "Oracle Enterprise Manager Agent HTTP" with SUSE - it gets confused if there is an entry for that port in /etc/services, which causes problems post-install when trying to start the Enterprise Manager.
To prevent this problem, simply remove the references to port 1830 (both TCP and UDP) in /etc/services before beginning the installation. For good measure you might want to delete 1831 to 1849 as well.
Start the installation with: ./runInstaller
The script will then inform you that your operating system must be redhat-2.1, UnitedLinux-1.0, redhat-3, which it presumably isn't. Fortunately a little bit of l33t h@x0r1ng will get round this problem: using the text editor of your choice or genetic predeliction, open the file Disk1/install/oraparam.ini and make sure the line following
[Certified Versions] looks like this:
(yes, the exact case is important). Disclaimer: the above modification is in no way meant to imply Oracle 10g is certified for a given SUSE version. Use at your own risk, and use only open source databases to work on nuclear weapons-related projects.
Start ./runInstaller again and you should see something like this:
The next steps follow the established installation procedure. If in at any point in doubt, click "OK". If the worst comes to the worst you can always do the install again - it's good practice.
At some point the DBCA (Database Configuration Assistant) will start and subsequently abort with the message:
ORA-27125: unable to create shared memory segment
Fortunately this is not a show-stopper; the remedy is to execute the following commands as user oracle:
cd $ORACLE_HOME/bin mv oracle oracle.bin cat >oracle <<"EOF" #!/bin/bash export DISABLE_HUGETLBFS=1 exec $ORACLE_HOME/bin/oracle.bin $@ EOF chmod +x oracle
Click "Abort" until the warnings stop, then retry - it should work.
The rest of the install should proceed smoothly.
Once the install is complete, Oracle should be slumbering somewhere on your system awaiting the first tender commands from SYS AS SYSDBA.
On a development system you should be aware that one of the tasks executed as root during the installation will probably have added entries to /etc/rc.d/ a line to /etc/inittab which keeps the ocssd daemon running. This is the Oracle Cluster Synchronization Service Daemon and is only necessary if you are planning on using cluster-related functions and can be reomved by issuing
insserv -r init.cssd and commenting out the entry in inittab.
Oracle Enterprise Manager
If you're used to the 8i/9i way of doing things, you might flounder around for a while looking for the Oracle Enterprise Manager. This has metamorphosed into a browser-based HTTP client/server system, as you may have gathered, and can be found at:
(the precise URL may vary depending to your local network configuration). You may need to change a line in sysman/config/emd.properties so that it looks something like this:
It can be started with
emctl start dbconsole.
Apparently SQL*Plus is no longer included by default in Windows installs, but nostalgic Linux users will be delighted to find it in its usual place, complete with early 80s style usability (I've always wondered how a multi-billion dollar corporation still hasn't managed to created a similar level of functionality to the GNU readline library, even the Windows command line is user-friendlier than SQL*Plus ).
But enough of this command line dinosaur. You'll be excited to know there is now a browser-based "replacement", offering a slightly more comfortable environment and another potential vulnerability, under the name of iSQL*Plus. This is a Java-based mini-server-app and it lives at
isqlplusctl start should get it moving if not already up.
For composing and issuing individual SQL statements it's quite handy and more comfortable than SQL*Plus. Nothing beats a powerful command line client such as that delivered whith PostgreSQL though.
Disclaimer: The information provided in this article is for informational purposes only. Despite careful checking it may contain errors. No guarantee of accuracy or fitness for a particular purpose is given by the author. Use at your own risk.