Posts Tagged ‘64-bit’

You will probably have realised by now that a new version of Ubuntu (9.10, ‘Karmic Koala’) was released a couple of days ago. Whenever a new distro version hits the streets, I am compelled to work out whether or not my GOAL script has been broken: is it still a couple of mouse-clicks to install Oracle 10g or 11g on a 64-bit Linux distro, or has the change of distro version introduced problems for the Oracle installation process?

Well, it’s taken me a couple of days to work out the answers, but here they are…

GOAL and 11g Release 2 is fine. I had to make a minor adjustment to the bit where new repositories are added, because otherwise Karmic would have been updated with Jaunty packages. But that was trivial, and the end result is still that 11gR2 installs on 64-bit Karmic without linking errors of any kind. You still get the enormous list of ‘required packages not found’ displayed at one point, but a quick ‘Ignore All’ sorts all that 0ut.

But the bad news is that I cannot get 10gR2 to install on Karmic at all. I get the sort of linking errors that suggests the 32-bit compatible libc libraries haven’t been installed, but since they’re definitely in the list of packages to be installed, I’m assuming they are not yet in the Karmic repositories. Maybe it’ll all come good in a couple of weeks… and I’ll certainly be testing. But for now, 64-bit Karmic and 10g just don’t mix and GOAL doesn’t make them mix any better.

I’m extremely happy to report that 11g Release 2 installs onto 64-bit Ubuntu 9.04 without fuss or bother (or error!) if you simply follow the instructions I’ve posted previously:

Inevitably, the installer will freak out with (it thinks) barely any of the necessary prerequisite packages installed! But a quick ‘Ignore All’ will sort that out (always assuming you’ve actually followed those earlier instructions!), after which it’s completely plain sailing (not even one linking error, either).

Just note that in those previous instructions, I’d hard-coded a path to /u01/app/oracle/product/10.2.0/db_1. That will work well enough, but you will probably want to change that to be the all-new, all-shiny /u01/app/oracle/product/11.2.0/db_1!

Update: GOAL now handles all Oracle installations onto 64-bit Ubuntu

Thanks to a nasty bout of ‘flu-like symptoms, I have been able to experiment with Goal (my graphical oracle all-in-one loader script) and the new 11g Release 2 rather sooner than I was expecting to be able to. I am running a temperature and feeling pretty bloody awful, so apologies if this is not quite as polished and coherent as it should be!

Now, you will remember to start with that Goal seeks to do just one thing: install 64-bit Oracle onto 64-bit Red Hat 5 (or Centos 5 or Oracle Enterprise Linux 5 or any exactly-equivalent recompilation of Red Hat source code). Just so we set expectations suitably low!

The good news is that a new version of Goal is now available which allows for 10g Release 2, 11g Release 1 and 11g Release 2 installations and which works almost perfectly (I’ll come to explain that “almost” in just a moment!) The kernel parameters required for an 11g Release 2 installation have changed significantly since 11g Release 1 days (so when other sites simply re-badge their 11gR1 articles without changing the actual content, be warned!), so that’s why Goal has to allow for two different types of 11g installation: the settings for 11gR1 would be inadequate for 11gR2 and cause the installer to stall you on a page warning of this fact. Anyway, I’ve gone through the official documentation and made sure that Goal sets the recommended values for all the assorted kernel parameters, old and new.

I have, however, encountered what is perhaps 11gR2’s first bug! The documentation (at Section 4.3) clearly says that for Red Hat 5 (and hence Centos 5, which is what I was using), one of the required prerequisite packages is ksh-20060214. I don’t have a problem with that: Goal does actually download and install the package ksh, which is close enough. The bug, however, is that the installer will insist that you don’t have the package pdksh installed. Which is true enough: it isn’t installed because the package doesn’t actually exist in the RH5 repositories! Pdksh is a published requirement for Red Hat 4, however, not Red Hat 5… so it would seem that the installer has been written to deal with both RH4 and RH5 installations with the unfortunate consequence that it demands the installation on RH5 of a package which actually should be demanded of an installation on RH4.

The long and the short of this is that it seems impossible to go through Oracle’s 11gR2 installer wizard without being told at one point that you have failed to install a required package… even though it doesn’t exist for RH5 and even though the documentation itself makes it clear it is not a required package on RH5 at all! It would be nice to have a 100% flawless installation wizard, but this “issue” prevents that from happening -and there’s nothing Goal can do about it. I believe that if you are using “proper” distros (such a true Red Hat Enterprise Server 5 or Oracle Enterprise Linux 5), rather than cheap clones such as Centos, this problem goes away. I have to do some more testing to determine that, though.

Anyway, in the meantime, it’s possible to simply click the ‘Ignore All’ checkbox at this point, and the installation will proceed despite the “missing” package.

And it will proceed smoothly, without errors or alerts about ‘error in invoking target install of makefile such-and-such’. The whole thing succeeds completely, in other words, and without fuss or bother.

I haven’t found any particularly good instructions on the Internet explaining how to do a 10g or 11g installation onto 64-bit Ubuntu (32-bit installations are a piece of cake… and even my own doris script has done those without trouble for a long time). Indeed, for a long time, I considered any such installation practically impossible -and used virtual Centos machines instead (where the 64-bit Oracle installation works flawlessly).

But times change: I use 64-bit Ubuntu as my OS at work and at home, and there are times when I don’t want to have to fire up a virtual machine just so I can do some Oracle experimentation. I’ve therefore been forced to work out how the Oracle installation can be made to succeed on that platform. I should say upfront that it’s still not a perfect installation: no matter what I do, I can’t get rid of an error in invoking target ‘collector’ of makefile ‘ins_emdb.mk’ message during the linking phase of the installation -but it is, at least, the only such error and it doesn’t seem to make any difference to the overall ability of the Oracle software to create, run and manage databases.

Here’s how I did it (and these instructions work for both 10g and 11g, with minor differences noted in the appropriate places).

Step 1: Perform a completely default Ubuntu 9.04 64-bit Desktop installation.

Step 2: Change the PC to use a static IP address rather than a DHCP-assigned one. That’s done by selecting System -> Preferences -> Network Connections. Select your network connection (for example, mine was under the “Wired” tab, called ‘Auto eth0′) and click Edit. Select the IPv4 Settings tab. Change the Method to Manual (from the default “Automatic DHCP”). Click Add and then specify an appropriate value for your Address (e.g., 192.168.0.100), Netmask (e.g., 255.255.255.0) and Gateway (e.g., 192.168.0.1). The Gateway’s especially important because if your Ubuntu machine cannot connect to the Internet, you won’t be able to download the necessary software prerequisites. If your Ubuntu machine is connected directly to the Internet, then of course you leave the Gateway blank. Otherwise, it’s the IP address of your router (or its equivalent, depending on your physical network setup). Also set up a suitable value for your DNS Server and Search Domains. Your DNS Server will either be an internal one if you’ve got one, or the one your ISP provides you with. The Search Domains entry should be the name of your internal network (such as ‘dizwell.home’) if you’re using an internal DNS Server: it’s basically the domain name for which the DNS Server you’ve just specified is authorative. If you don’t have an internal DNS Server, your Search Domains entry can be set to the domain name of your ISP (siuch as ‘telstra.com’).

Once that’s done, make your /etc/hosts file reference your static IP address by machine name. That is, issue the command

sudo gedit /etc/hosts

…and change the top part of the file from this:

127.0.0.1    localhost
127.0.1.1    heracles

…to this…

127.0.0.1    localhost
127.0.1.1    heracles
192.168.0.100 heracles

That is, my Ubuntu machine was created with a hostname of ‘heracles’. By default, that name is only mapped to a loopback address of 127.0.1.1. I’ve just set my IP address to be a static one of 192.168.0.100, so now I’m saying that the new IP address should also map back to my hostname. You obviously change the specific numbers and names used in the file to suit your own situation.

Step 3: Install the necessary software prerequisites:

sudo aptitude update
sudo aptitude install gcc libaio1 lesstif2 lesstif2-dev
     make libc6 libc6-i386 libc6-dev-i386 libstdc++5
     lib32stdc++6 lib32z1 ia32-libs sysstat rlwrap
     unixodbc unixodbc-dev elfutils rpm

(That should all be on one line, of course).

Step 4: Append appropriate entries to the following configuration files…

/etc/sysctl.conf

kernel.shmall = 2097152
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 65536
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144
vm.swappiness=5

/etc/security/limits.conf

*       soft    nproc    2047
*       hard    nproc   16384
*       soft    nofile   1024
*       hard    nofile  65536

(Make sure to add those lines before the “# End of file” one).

/etc/pam.d/login

session    required     pam_limits.so

Step 5: Create the Oracle User and all appropriate installation directories

sudo sysctl -p
sudo groupadd nobody
sudo groupadd oinstall
sudo groupadd dba
sudo useradd -s /bin/bash -g oinstall -G dba oracle -m
sudo passwd oracle

(…and supply a password for the oracle user when prompted)

sudo mkdir -p /u01/app/oracle/product/10.2.0/db_1
sudo chown -R oracle:oinstall /u01/app
sudo chmod -R 775 /u01/app

Step 6: Create necessary symbolic links

sudo ln -s /usr/bin/awk /bin/awk
sudo ln -s /usr/bin/rpm /bin/rpm
sudo ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so
sudo ln -s /usr/bin/basename /bin/basename

Step 7: Set appropriate environment variables for the oracle user

sudo gedit /home/oracle/.bashrc

…and then past these lines onto the end of that file:

ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
ORACLE_SID=ubu102
export ORACLE_BASE ORACLE_HOME ORACLE_SID
PATH=$ORACLE_HOME/bin:$PATH:.
export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib
export LD_LIBRARY_PATH CLASSPATH
alias sqlplus='rlwrap sqlplus'

Note that the above lines assume that you will call your starter database ‘ubu102′. If you want to call it something else, set the ORACLE_SID environment variable appropriately now. Also note that the above content assumes you are installing 10g (it has a ‘10.2.0′ bit in the ORACLE_HOME setting). If you’re installing 11g, that should be replaced with ‘11.1.0′.

Step 8: Become the Oracle User and commence the installation

sudo xhost +
su - oracle
export DISPLAY=":0.0"
/media/cdrom/runInstaller -ignoreSysPrereqs

Note that last command assumes you have created a proper installation CD from the 10gR2 cpio/zip file download. I describe how to do that here.

For the most part, you then just keep clicking [Next] through the Oracle Universal Installer’s screens. You’ll need to change the proposed database name to match what you typed for the ORACLE_SID in Step 7 (in my case, therefore, I changed the proposed ‘orcl’ to ‘ubu102′). You will, of course, fail all of the system tests that the OUI might try to do, but you can click through those regardless and confirm that you know what you’re doing: the thing will work correctly anyway.

As I mentioned at the beginning, you will see an error during the linking phase (relating to ims_emdb.mk) -at least, you are very likely to! I’ve had a couple of installations where no errors at all were raised, but others (following the same instructions, mind!) did. Go figure! If you happen to be unlucky enough to get a linking error, simply click ‘Continue’ when it appears, and the installation should proceed to completion without further incident, correctly creating appropriate networking configurations and a starter database. I wouldn’t call that a particularly robust installation -and there’s no way I’d want to run anything even vaguely of ‘production quality’ on the result! But it does at least work -to the point where I’m running a useful test database on my Ubuntu installation at work, including a very large and demanding Oracle Text index, without any apparent problems.

I’ve been quite proud of Doris, the ‘Dizwell-Oracle Installation Script’: she was my first attempt at a complex Bash script that would do something useful (namely, help automate the process of preparing a Linux box to be able to run Oracle database software). She worked quite well, too (which is probably the main thing!): downloading the correct software dependencies, creating database auto-start scripts, setting kernel parameters properly and setting all the right environment variables for an appropriate user, too.

Some people carped, of course, that Doris ‘hid’ all the complexities of installing Oracle, which meant you weren’t learning anything. Such people have obviously never quite mastered the ability to read, since merely reading the script would teach you everything you ever needed to know about how to install Oracle on Linux! Additionally, some might argue (I would, anyway) that you tend to install Oracle just a few times but use it hundreds of thousands of times… so maybe learning how to use it is a tad more important than learning how to install it? Just a thought.

Anyway, I know that Doris has helped hundreds of people, so I’d say on balance, she’s been a good thing to have written. Trouble is, she’s a bugger to maintain!

For a start, she was over-ambitious: she attempted to automate 10g and 11g installations on Redhat 4, Redhat 5, Suse10, Suse 11, Mandriva 2008, Ubuntu 7, Ubuntu 8, Fedora 8, Fedora 9 and Fedora 10, Debian 4.0… and even PCLinuxOS. In addition, she coped with both the 32-bit and 64-bit versions of at least three of those distros. Naturally, and inevitably, all of those options made coding her in the first place a complex proposition -but keeping her up-to-date as new distros arrived was a nightmare. By now, she’s getting a bit long in the tooth: no explicit support for Ubuntu 9 or Debian 5, for example (though I happen to know she works on those distros if you simply pretend they’re Ubuntu 8.10 or Debian 4.0 respectively, since my own installations on to both those platforms relied on me doing just that).

Well, all of the above is a long-winded way of saying that Doris is retiring: I’m not going to maintain her or bug-fix her any more.

Instead, I’m going to unveil her replacement: Goal -the Graphical Oracle All-in-one Loader. Goal is different from Doris in two main respects. First, it uses a graphical interface, because a lot of Linux first-timers seem to be a bit nervous around the command line! Second, it focuses on just one distro and one architecture. Out goes PCLinuxOS, for example, and Mandriva, Suse, Fedora, Ubuntu and the rest. Only support for Redhat remains (and its cousins, such as Oracle Enterprise Linux and Centos), largely because that’s the only distro (in my experience) that provides a completely solid, 100% reliable platform on which to run Oracle.

Also gone is the support for 32-bit architectures. I use 64-bit Linux myself and nearly all CPUs produced in the past 4 years are capable of running a 64-bit OS. Meanwhile, anyone thinking of doing any serious database work needs to switch to a 64-bit platform pronto, because running an instance in less than 4GB of RAM is, these days, a mug’s game (and don’t even think of talking to me about PAE!).

In short, Goal will do 64-bit 10g and 11g installations on Redhat 5 (or Centos 5 or OEL 5) only, and I have zero plans to add any other capabilities to her, ever. (Note that I will modify Goal whenever necessary to accommodate new Oracle versions. So, she’s already been amended to allow 10g, 11g Release 1 and 11g Release 2 installations, for example).

Doris will remain downloadable for the foreseeable future, since she clearly does things which Goal isn’t going to do. But she’ll just get quietly older and increasingly irrelevant! Meanwhile, if you want to run 64-bit Oracle on a ‘proper’ server-oriented distro that Oracle has been especially tailored to run on (i.e., basically, Redhat), then you should switch to Goal.

Goal is available for download from here.

You simply download the file onto (say) your desktop. You then right-click the file, select Properties -> Permissions and then set the Allow executing file as program checkbox to ‘on’. Click Close to shut the properties page down -and then simply double-click the file to launch it. When prompted, you select the ‘run in a terminal’ option. You don’t have to become root (though you’ll be prompted for the root password) and you don’t need to run anything manually from the terminal. Follow the prompts and Goal will configure your server appropriately. Once that’s done, you will need to perform the Oracle installation itself -and that will require you to open a terminal and become the oracle user… but there’s nothing I can do to work around that particular requirement, of course!

Goal does everything required for a successful Oracle installation: creating the right user and groups; setting the kernel parameters to appropriate values; downloading all software prerequisites; creating scripts required to automate the startup of databases at a bounce. All you have to do is sit back and let Goal do its thing! A directory called /osource is also created for you, if you require it: it’s where you’d download or copy the Oracle software to if you were going to perform the Oracle installation’off disk’ (that is, you’d invoke the Oracle Installer with the command /osource/database/runInstaller or something similar, depending on the precise directory structure). If you prefer to install straight off a DVD/CD (or a DVD/CD ISO mounted as a loop device so that it looks like a real DVD or CD), then the /osource directory is redundant and you can simply delete it (as root).

Once the Oracle software installation itself is complete, you will need to edit the /etc/oratab file (as root) to get a database to actually re-start each time the server boots up. The edit involves changing the final ‘N’ of the script into a ‘Y’. You also have to edit (as the oracle user) the $ORACLE_HOME/bin/dbstart script so that the ORACLE_HOME_LISTNER variable is set to the full path of the $ORACLE_HOME, instead of the $1 it’s set to in 11g and the bizarre /ade/vikrkuma_new/oracle it’s set to in 10g. Both edits take place around lines 78 to 80, regardless of the version of Oracle involved.

Apart from those edits of two configuration files, however, Goal will have done everything else for you.

If you try to install the VirtualBox additions in a virgin Centos 5.3 x86_64 guest virtual machine, you’ll get these errors:

Please install the build and header files for your current Linux kernel.
The current kernel version is 2.6.18-53.el5
Problems were found which would prevent the Guest Additions from installing.
Please correct these problems and try again.

The cure for these is to install the gcc (GNU C Compiler) and the Kernel Headers. I generally get gcc installed as a result of running my Doris script as preparation for doing an Oracle installation, but it doesn’t hurt to install it beforehand on its own (Doris will simply skip stuff she sees already installed by the time she runs). If that’s the case, the following command (run as root, of course) will do the trick:

yum -y install gcc kernel-devel-`uname -r`

Once that’s done, it’s just a question of clicking Devices -> Install Guest Additions if you haven’t already done so. That should cause a new ‘DVD’ to be automounted at /media. You can then invoke the Guest Additions installer (again, as root) by issuing the command:

sh /media/VBOXADDITIONS_2.2.4_47978/VBoxLinuxAdditions-amd64.run

The specific numbers in that command will, of course, depend on the specific version of VirtualBox you happen to be running. Generally, things will be plain sailing from this point on, though you will still get an error about the Centos kernel version not supporting OpenGL rendering. Ignore it, because it doesn’t really  affect the important stuff, such as proper mouse integration. However, you will still have rather peculiar graphics-related issues (such as the display size never being quite right enough to display both the top and bottom panels simultaneously), but they will be irritating but not fatal. (Here’s hoping the new VirtualBox 3.0 works better with Centos… but I haven’t managed to try it out just yet).

Update: I have now tried Centos 5.3 x86_64 in VirtualBox 3.0, and I am delighted to report that whilst the installation of the Guest Additions is as described above (that is, you still need to install gcc and the kernel headers beforehand), they now appear to work properly. You still get the error about OpenGL rendering, because that’s a kernel version issue (and RedHat/Centos 5 is not exactly on the bleeding edge of kernel versions!), but mouse integration works flawlessly and the display itself is correctly configured, properly able to display the whole screen without ’scrolling’ effects.