Oracle 8.0.5 on Linux

Gone are the days when Linux users, on the lookout for databases suitable for large projects, had to make do without the products of the established software firms. Following Software AG, Inprise, Informix, Sybase, Empress and IBM, now Oracle is offering its RDBMS, as of version 8.0.5, for Linux, and goes on to praise the advantages (http://www.oracle.com/linux/embrclinux.html)of this operating system compared with Windows NT: greater stability, performance, and security. To the ‘professed’ Linuxer arguing against the Microsoft platform, these are all familiar arguments.

Towards the end of July, Oracle had already announced the port of the database and the application server. Since the beginning of October, anyone interested can download the ‘production release’ of the RDBMS over the Web, as well as the installation instructions and white papers: either as a single 140 MByte archive, or in seven chunks of 20 MBytes each. To obtain an evaluation license, a registration is required first. This article does not focus on the database server as such; instead, it concentrates more on installation and configuration of the system under Linux, and the efforts required in adopting and adapting data, data models, and applications from an Oracle7 implementation to the new RDBMS.

For smooth operation, the technical FAQ recommends a glibc-based (>= 2.0.7) Linux system with a kernel revision of 2.0.34 or higher. At least 48 MByte RAM and 275 MByte harddisk space should be available. In addition, the database to be created requires sufficient disk space; on the test system (Dual-Pentium-II 266 with 256 MByte RAM, 4 GByte HDD, RedHat 5.1 as base system) another 200 MByte were reserved to this end.

Work for the administrator

Prior to the installation of the database software, the administrator has to adjust various system parameters. First of all, he should reconfigure the Linux kernel and change the values for the maximum size of the shared memory segment and of the semaphore arrays as per installation instructions, then recompile the kernel and reboot the computer. Anyone wishing to recreate our installation can find the kernel parameters, shell-login scripts and examples here.

Furthermore a Unix user account and user group is required, whose members then become owners of the software. It is recommended to use ‘oracle’ as the user name and ‘dba’ for the group.

After unpacking the archive, it first becomes necessary to run the script orainst/oratab.sh as root. This creates the file etc/oratab, which determines the databases to be run when the system is started. The next step is to log in as user ‘oracle’ and to set the required environment variables in the shell-login scripts.

The following steps are recommended for the installation:

• start the installer ./orainst/orainst,
• select ‘Custom Installation’,
• select ‘Install New Product - Do Not Create DB Objects’
• accept defaults for ORACLE_BASE and ORACLE_HOME
• accept the default values for the paths to the logfiles
• set the installation directory
• NLS-support -> All languages

When prompted for a Unix group during installation, one should choose ‘dba’ for the OSDBA (group with DB rights) and ‘oracle’ as OSOPER. Configuring the RDBMS with the supplied installation program did fail on several occasions. For instance, selection of the menu item ‘Create/Update Database Object’ caused the installer to crash. After a number of attempts we nonetheless did succeed in installing the software in the necessary directories, although some of them, whose absence had been flagged by the installer, had to created manually.

Not everything worked smoothly

Following completion of the installation, it was not possible to start the server manager svrmgrl. This fault can probably be traced back to the relinking of the software during installation. The following workaround solves this problem: copy the entire bin directory (where the original files are located) from the installation tree to the target directory and set the owner (‘oracle’) and group (‘dba’) attributes.

After running the installer, the directory $ORACLE_HOME/orainst contains a file root.sh. This shell script must be executed with root permissions, the question about the local bin directory has to be answered with /usr/local/bin. This script also modifies the /etc/oratab and /etc/services files. Next the shell environment variable ORACLE_SID must be set. It determines the SID (system identifier) of the database to be installed. According to Oracle, it should be a string of four characters in length (preset by the installer as ‘ORCL’).

These fundamentals being settled, the individual parts of the database software need to be configured, beginning with network-dependent components. The latter include SQL*Net and the TNS subsystem. SQL*Net provides a consistent API for all Oracle applications, handles connection and disconnection to/from the database, and offers error message functions. The TNS subsystem (transparent network substrate) forms the core of the Oracle network components. It implements a series of network and protocol independent functions with forward requests from the SQL-Net layer to the protocol adapter. The latter handles network access via the protocols provided to this end, e.g. TCP/IP.

The file $ORACLE_HOME/network/admin/tnsnames.ora is responsible for the configuration of the TNS. It contains information about all nodes, the databases installed on them, as well as the unique TNS alias, for the TNS network. This alias addresses one computer on the network, and exactly one database instance on that computer. The second part of the configuration refers to the listener process and the actual Oracle instance, which is configured in the file $ORACLE_HOME/dbs/initSID.ora. The listener process control the connection requests to the database and is configured via the files $ORACLE_HOME/network/admin/listener_ora.

Once these points have been dealt with, the listener is switched into commandline mode with lsnrctl. The command start starts the actual process. With status the status of the listener can be queried.

A deciding factor in implementing Oracle on Linux is probably the ability to migrate data and data models. Good news: there were hardly any problems. Scripts developed for the Oracle SQL loader could be reused without modification, likewise with database models from an Oracle7 database. The latter effectively amounts to creating the necessary tables and transferring PL/SQL scripts. It only took one day to transfer a database with 350,000 records to the Linux RDBMS.

The Oracle administration software for Windows-NT clients (not contained in this distribution) could be used immediately, based on an existing SQL*Net7 client installation. Even third-party software, such as Quest’s SQL-Navigator, worked right away. Thus there is no pressing need to install Net8 on the clients.

In-house developed perl-scripts and C-programs could also be transferred without any problems. All that was needed was to install OraPerl - available from CPAN (Comprehensive Perl Archive Network) - on the client systems. Subsequently the scripts were ready to run. C-programs had to be recompiled - as well as various tools, such as the Apache extension PHP3 and the TCL extension oratcl (here changes to the Makefile were required).

Conclusion

Apart from difficulties with the patchy installer, the Linux RDBMS could be installed and configured in a relatively short amount of time. However, the administrator should have a thorough knowledge of the running of an Oracle database. The complexity of the software is not to be underestimated; all components have to be carefully tuned. The unproblematic migration of existing Oracle applications and data to the new system renders Linux a cost-effective alternative database platform.

Oliver Fischer and Sebastian Woelk

are freelance software developers.

iX-EVALUATION

[+] Transfer of existing database models, data, and applications [-] immature installation tool