I found that installing Oracle on Linux and CentOS for that matter was not a straightforward process but for that matter there were also some issues in hooking VisualWorks up that made for a bumpy ride. Any senior Smalltalker / developer probably would eventually figure things out but in the hopes of saving others some of the pain I went through I’ll detail my little adventure below.
Oracle Installation
Once upon a time in a land not so far away I found myself in front of a Linux box with an Oracle 10 g client install CD. My objective was to install Oracle 10g Instant client i.e. that which simply installs the libraries required for the Oracle client call interface and nothing more, nothing less.
Problem: CentOS is not recognised as “supported” Linux distro.
and here is where I forget what I did. Have to write these blog entries closer to time zero. Essentially, the “runInstaller.sh” found at the top of the Oracle Client 10g CD can be run with a flag which means don’t check if the current OS is a valid distro etc. I’ll try to dig up that flag and amend this article but I do recall that in particular the CentOS forums where helpful.
Configuring VisualWorks
It is extremely important to provide visibility for the Oracle libs from the get go. This is accomplished by setting two environment vars to the location of the Oracle libs. This was done in the startup script for my VisualWorks image. The entries are:
ORACLE_HOME=/apps/oracle
export ORACLE_HOMEPATH=$PATH:$ORACLE_HOME/lib
export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib
export LD_LIBRARY_PATH
Note that the Oracle documentation states that env var “ORACLE_HOME” does not need to be setup for the call interface to work. Also the install of Instant client does not create a “lib” directory. I created one because the directory structure the installer creates is just too painful for me. So I simply took the libraries and put them in the lib directory which I created under ORACLE_HOME.
Configuring Oracle
Oracle call interface will require the following env vars to be set as follows:
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
export NLS_LANG
TNS_ADMIN=$ORACLE_HOME/lib
export TNS_ADMIN
NLS_LANG is I assume pretty self explanatory but TNS_ADMIN is not. As a matter of fact, nobody knew in this shop what that did. The reason being is that when one performs any of the “fatter” install options this var is set underneath the covers. TNS_ADMIN specifies the location where the tnsnames.ora file resides. Entries in this file follow the pattern illustrated below:
TBOPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = linux)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = tbOPROD)
)
)etc …
So let’s break this down:
- TBOPROD = this is simply the label assigned to the entry above.
- Host & Port = host and port where the oracle cluster is running.
- SERVICE_NAME = the name of the database instance.
Your dba usually sets this file up and usually generated by Oracle configuration tools.
Calling Oracle
The following workspace code illustrates how to retrieve a connection:
connection := OracleLinuxInterface new.
connection username: ‘Charles’
connection environment: ‘//MyLinuxBox/TBOPROD’.
connection connect: ‘smalltalkrocks’
Well this is as far as I go with this article. The VisualWorks docs do good job of showing how the database EXDI interface works. Furthermore , you really ought to be using an object relational mapping layer such as GLORP instead of using the EXDI layer which just provides for Direct SQL However, what is noteworthy is that I found that the pattern provided for the “environment” string is incorrectly documented in the docs. What I found to work is illustrated above and that is why I have included the workspace above.
Hope this is useful.
-Charles