Installing Oracle11 on Debian Squeeze (and Lenny)
Posted by kroshka on Thu 15 Jul 2010 at 11:55
The main goal is to get the Oracle installer to run so you can install Oracle successfully. This application has to run within X windows. We will use vnc for that, this is not necessary, but you may (often) find you have to install Oracle remotely. And using something like vnc sure beats spending time in a noisy server room.
This guide uses an existing guide as template with some adjustments so it will work with Oracle11 on Debian Lenny.
Debian Lenny was used to write the initial guide. I have since migrated a few Oracle11 servers from Lenny to Squeeze and did quite a number of fresh Oracle11 installs on squeeze. There is a tiny problem with regards to the name of a package and a problem regarding vm/hugetlb_shm_group (see below note Tuning kernel parameters). This guide should work on Squeeze and Lenny without much difficulty.
Getting Oracle11 from the Oracle website
http://www.oracle.com/technology/software/products/database/oracle11g/112010_linuxsoft.html
Normally you should find two zip files. Download and unzip them, in /opt for example. You should end up with a directory called database.
Making Debian a bit more compatible
We should install a few packages so that the Oracle installer will be able to do its thing:
Note: on Lenny use libmotif3apt-get install gcc make binutils libmotif4 lesstif2 rpm libaio1 libdb4.6
The following 2 steps will make the Debian environment look a bit like Red Hat so the installer will not complain. I am not sure if this is still necessary for Oracle11, but it's not affecting anything.
Create symlinks so the installer can find a few utilities it needs:
ln -s /usr/bin/awk /bin/awk ln -s /usr/bin/rpm /bin/rpm ln -s /usr/bin/basename /bin/basename
Create an rc.d symlink:
ln -s /etc /etc/rc.d
Oracle account and volumes
Create an account and group:
groupadd oinstall groupadd dba useradd -m -g oinstall -G dba -p passwd -s /bin/bash -d /home/oracle oracle passwd oracle <-- change password!
It's useful to have a few default volumes and/or directories in place, such as /u01 and /u02. /u01 is used to install Oracle and in my case I am not using it to store databases. In this case it's symlinked from /home, and I use /u02 to store databases and ideally should be a separate RAID volume, the same goes for /u03, etc. Anyways, you could choose whatever you prefer of course.
mkdir /home/u01 ln -s /home/u01 / mkdir /u02/oradata <-- assuming it's already mounted chown -R oracle.oinstall /home/u01 /u02 chmod -R 775 /home/u01 /u02
Change ownership of the directory from where we will run the Oracle installer:
chown -R oracle.oinstall /opt/database
Tuning kernel parameters
Oracle11 expects a few kernel parameters to be changed from its default. Some are different, i.e. higher, than for Oracle10. The below is what I used on a system with 4 CPU cores and 32 GB RAM, your mileage may vary and I am not sure if this is very optimal, but it worked.
Edit /etc/sysctl.conf and add the following at the bottom:
kernel.sem = 250 32000 100 128 kernel.shmmax = 2147483648 net.ipv4.ip_local_port_range = 9000 65000 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 fs.aio-max-nr = 1048576 fs.file-max = 6815744
Please note: after migrating from Lenny to Squeeze I had to add the following to sysctl.conf in order to be able use HugePages. This is enabled by default in the Debian kernel and increases performance, but the oracle/dba group may not be allowed to use it. See this for a discussion about it, dba_group_gid is the GID number of the dba group.
vm/hugetlb_shm_group = dba_group_gid
Now you can make those changes live:
sysctl -p
Configure the Oracle account environment
* Change a few settings in the /etc/security/limits.conf file:* soft nproc 2047 * hard nproc 16384 * soft nofile 1024 * hard nofile 65536
Make sure session required pam_limits.so module for PAM is being used. i.e. Ensure that pam_limits.so is included in the following files and is NOT commented out:
/etc/pam.d/su /etc/pam.d/login /etc/pam.d/sshd
Edit /etc/profile and add the following:
umask 022
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Edit /home/oracle/.profile and add (this will change slightly after install):
ORACLE_BASE=/u01/app/oracle ORACLE_SID=instancename export ORACLE_BASE ORACLE_SID unset ORACLE_HOME unset TNS_ADMIN
Setting up X and vnc to run the Oracle installer
Now we need to set up a minimal X environment (if it's not installed, which is not unusual for a server) in order to run the Oracle installer. I prefer to have no X environment on a server unless necessary and then I would like to keep it as minimal as possible.
Install the following packages, which include a dummy X server, xterm and a minimal window manager:
apt-get install xserver-xorg-video-dummy vnc4server x11-xserver-utils xterm wm2
As user oracle run vnc4server, then kill it and edit /home/oracle/.vnc/xstartup and add the following 2 lines to the bottom. This makes sure a window manager and terminal will be started without much problems:
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & wm2 &
Running the Oracle installer
Now run vnc4server again as user oracle. Connect to this server from your own machine and run the Oracle installer within the terminal, which should be named runInstaller and can be found wherever you unzipped the Oracle11 zipfiles. The installation should be fairly self explanatory. The installer WILL complain about a few things not being the way it expects it to be. It will list them as fail. It is safe to ignore it and continue. Near the end the installer once again will complain about some compilation error, which you too can safely ignore.
Note: [1] If you get more than one or two compilation errors it's possible tools such as dbca will not be installed. Please see the note at the bottom of this article on how to solve such compilation errors.
After the installer finished do some cleanup
Edit /home/oracle/.profile and edit the change you previously applied to become:
ORACLE_BASE=/u01/app/oracle ORACLE_SID=instancename ORATAB=/etc/oratab export PATH=$PATH:/u01/app/oracle/product/11.2.0/dbhome_1/bin/ export ORACLE_BASE ORACLE_SID ORATAB export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 unset TNS_ADMIN
Init script
In order to automatically start and stop Oracle at (re)boot create /etc/init.d/oracle and add:
#!/bin/bash
#
# Run-level Startup script for the Oracle Instance and Listener
#
# chkconfig: 345 91 19
# description: Startup/Shutdown Oracle listener and instance
### BEGIN INIT INFO
# Provides: oracle
# Required-Start: $remote_fs $syslog $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Oracle database server
# Description: Oracle database server
### END INIT INFO
ORA_HOME="/u01/app/oracle/product/11.2.0/dbhome_1"
ORA_OWNR="oracle"
# if the executables do not exist -- display error
if [ ! -f $ORA_HOME/bin/dbstart -o ! -d $ORA_HOME ]
then
echo "Oracle startup: cannot start"
exit 1
fi
# depending on parameter -- startup, shutdown, restart
# of the instance and listener or usage display
case "$1" in
start)
# Oracle listener and instance startup
echo -n "Starting Oracle: "
su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl start"
su - $ORA_OWNR -c $ORA_HOME/bin/dbstart
touch /var/lock/oracle
echo "OK"
;;
stop)
# Oracle listener and instance shutdown
echo -n "Shutdown Oracle: "
su - $ORA_OWNR -c "$ORA_HOME/bin/lsnrctl stop"
su - $ORA_OWNR -c $ORA_HOME/bin/dbshut
rm -f /var/lock/oracle
echo "OK"
;;
reload|restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 start|stop|restart|reload"
exit 1
esac
exit 0
Now make that live by running:
update-rc.d oracle defaults
You should now have a fresh Oracle11 installation. This was the easy part...
[1]Note: While installing Oracle you sometimes may stumble upon compilation errors. Even though those are not fatal it may mean tools such as dbca are not available. To fix these you will need to do a little detective work. It looks like this is especially the case on Debian releases newer than squeeze. Check the make log file, it will tell you exactly what it is trying to find:
/u01/app/oracle/product/11.2.0/dbhome_1/install/make.logFor example:
/usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.aAssuming you have the right packages installed this normally means such files are in a slightly different location. Try to find it:
find /usr/lib -name libpthread_nonshared.aIn case of a 64 bits system it could be in /usr/lib/x86_64-linux-gnu/, create a symlink this way:
ln -s /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a /usr/lib/libpthread_nonshared.aOr in case of a 32 bits system:
ln -s /usr/lib/i386-linux-gnu/libpthread_nonshared.a /usr/lib/libpthread_nonshared.aThen hit retry in the installer and repeat this for the other compilation errors. Common symlinks I had to create (replace x86_64 with i386 if using 32 bits system):
ln -s /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a /usr/lib/ ln -s /usr/lib/x86_64-linux-gnu/libc_nonshared.a /usr/lib/ ln -s /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/ ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/
You might also try, instead of installing a dummy X server, using SSH to tunnel the X11 clients' connections to an X server on your workstation.
I find on a Linux workstation, in an X11 session, that using the -Y option to ssh command works flawlessly, since X11Forwarding is enabled by default on Debian OpenSSH server. On on Windows workstation, you can install and run Xming (or any of the commercial X11 servers for Windows like Exceed), then enable X11 tunneling in the PuTTY profile ( Connection -> SSH -> X11, and tick the Enable X11 forwarding box). Other SSH clients may have this capability as well.
After doing this, any X11 windows that are created by programs you run in that SSH session on the server will appear on your workstation's desktop as if they were being run locally.
[ Parent | Reply to this comment ]
http://www.debian-administration.org/articles/430
Sorry if they want to switch my from Postgres or MySQL (why would they) they had better make life simpler not harder.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Lets just start with the simple fact that at an oracle installation something WILL fail. Then you have to restart the long time consuming process after you fixed it. What uses most of the default passwords? Oracle like 11 default one and most of them you dont even know what it's for or what middlewhare bull* where you can to login with it.
If you are DBA or Developer and you have postgres or mysql running on your system for gods sake don't recommend it to migrate to Oracle... Just don't!
I post my old howto in hope that maybe it will be help for someone:
----------------------------------------------------------------- ----------
Don't forget I wrote this back in 2006. Since then oracle may got worst.
-better if you start with a clean and new operating system ( at this time Fedora team almost done with the 6. version), but after FC5 you shouldn't worry about the version of the dependent packages, except libaoi(*)
-until the installation goes, separate that computer from the network if it's possible and turn off any firewall, especially if you planning to setup a cluster, get a cheap switch or crosslink and work on that segment
-don't try to install oracle for an old (slower than 1,2 Ghz) machine without 1Gb ram, it doesn't matter you run or not anything else on the oracle machine, you need that 1 Gb ram and this is the minimum
-xorg-x11-deprecated-libs
-libstdc++ linking if needed
-G++ for the compile of libaoi
Ok so after you added the accounts and did the specific kernel parameter setup:
cat >> /etc/security/limits.conf <<EOF oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 EOF
cat >> /etc/profile.local <<EOF if [ \$USER = "oracle" ]; then
if [ \$SHELL = "/bin/ksh" ]; then
ulimit -p 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
umask 022
fi EOF
Well I got trouble with this profil settings. And many people install oracle from the oracle account. I mean they login via GDM or KDM for the setup.
$ ./runInstaller -ignoreRequirements
If you planning to use oracle in cluster, you gonna need this. And libaio required for asm (you need to get the older one from external source and remove the original from the system), you can get dependency problems here :(
[ Parent | Reply to this comment ]
Yes it is unfortunate because Redhat just isn't as powerful when it comes to (remote) administration. Not to mention that Debian stable is in fact very stable.
> Lets just start with the simple fact that at an oracle installation something WILL fail. Then you have to restart the long time consuming process after you fixed it.
I disagree. All the Oracle10 and Oracle11 installations I did on Debian had a few failures, all of which I could safely ignore. The worst failure (on a laptop) was a failure to compile the enterprise manager, dbconsole, dbca et al. Things would still work fine even in that case. Of course it'll be more of a pain to create a database without the dbca, but it works.
> What uses most of the default passwords?
As far as I can see the installer will prompt you for passwords so you're able to set your own before the installation has completed.
I do agree there is no point in most cases to change to oracle, mssql or whatever when you're using a setup with mysql or postgresql with satisfaction. Again the "enterprise" label that comes with things like oracle and mssql is a selling factor.
[ Parent | Reply to this comment ]
1) Remeber to change /etc/oratab, "N" must be "Y" if you want your default database instance to start automatically;
2) Add 'su - $ORA_OWNR -c "$ORA_HOME/bin/emctl start dbconsole"' to /etc/init.d/oracle in the start section (and the equivalent in the stop section), to automatically start the web Enterprise Manager.
Thanks for the howto! :)
apprezzatamente,
Francesco P.
[ Parent | Reply to this comment ]
You're welcome :-)
Those are helpful tips.
With regards to the dbconsole. With Oracle10 I got into the habit to have the dbconsole only running when needed. There is a bug that causes the dbconsole to start consuming 100% CPU if it's left to run for more than a few hours (or even right away). It's not such an issue on a 4 CPU machine, but still annoying. The non free patch of Oracle10 is supposed to solve that though (along with an annoying day light saving bug).
[ Parent | Reply to this comment ]
"ulimit: 25: bad number"
In order to get rid of that, simply edit the file '$ORACLE_HOME/bin/emctl'
and change the first line from '#!/bin/sh -f' to '#!/bin/bash -f'
[ Parent | Reply to this comment ]
http://download.oracle.com/docs/cd/B10500_01/em.920/a96697/rsp.ht m
Br. Admir Trakic, Copenhague, Denmark
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
> of maintaining a server farm because of its stability, high
> quality and ease of maintenance
It's unsupported: you have to have a single problem once for less than a minute and any money saved gets wiped out. If you want to save money, use postgres!
Spending $$$$ on Oracle and then saving a hundred bucks on a RHEL license is, well, weird!
[ Parent | Reply to this comment ]
For one the article was not meant to avoid paying a Redhat license (Redhat by the way can be had for free). Neither does Oracle cost any money for many purposes. The article was meant to describe how to install Oracle on Debian. Nothing more and nothing less.
A problem with Oracle on Redhat is the same problem with Oracle on Debian. The type of distribution you're using doesn't matter at all with regards to how Oracle works and the problems it may have. Oracle doesn't have any magical code that senses your distro and then automagically decides to suck (more).
If you want to use Oracle on Redhat by all means go for it, power to the people. If you want to use postgress, or mysql, then again by all means feel free. It would be my preferred choice too. You don't always have this choice either historically, technically or politically.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
"Unsupported" in the above comment does not mean that Oracle doesn't run on Debian or that it runs worse on Debian than on Redhat. It means that the combination of Oracle Datase ABC + Redhat XYZ has been certified, that you get support for it, from the vendor, from other suppliers or from consultant companies. If something breaks you're backed up with your support contract with guaranteed response times. I don't know Oracle that well, but I doubt that they offer support for any Debian version.
If you don't need all that and don't care about support contracts, ok. But then I have to wonder even more why you would pick Oracle over any other database (except DB2 that is).
[ Parent | Reply to this comment ]
If the application for paid for support requires you to click the Redhat option on the webform, then so be it.
I can see though there may be a niche market to fill for a company doing Oracle consultancy/support on Debian. :-)
There can be many reasons why one picks one system in favour of another and many of them are not technical neither sensible, but historical or political. In a world where there are "enterprise" solutions such as exchange or lotus notes I find Oracle on Debian a rather sensible choice.
[ Parent | Reply to this comment ]
I'm sure you will find independent consultants willing to help, but the vendor may get touchy with you.
[ Parent | Reply to this comment ]
Running the GUI however is the easiest way by far to generate the response file - you'll need to do this at least once to get around the chicken and egg bootstrapping issue.. Subsequent installations can be made a tad easier.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View Weblogs ]
[ Parent | Reply to this comment ]