Version history

Version Date Author Change

0.0 17 December 2008 James Cone Initial version

1. Theory

So what does it mean to connect to a database? Oracle started out in accounting systems,
so they really care about who is connecting to a database, and whether they’re allowed to
make a change. So you need a few things to connect:
- a client that knows about Oracle, and does something for you
- a server that is running Oracle
- a path to transmit data both ways between the client and the server
- a plan for the client to convince the server about who it is, and what it’s allowed to
do

Note that you do not need a plan for the server to convince the client that it really is the
Oracle server they intended to connect to. Clients are assumed to be automatically
convinced, because they got to choose the path for the data transmission. These
assumptions are not necessarily convincing in the TCP/IP world, because there are
attacks against ARP and the DNS.

ESG’s clients are usually sqlplus, which installs with Oracle Server and provides generic
access to everything that does not involve difficult data-types, and Pro*C and OCI
computer programs which we have written.

Details of servers are out of scope for this discussion.

1.1. Data transmission

There are a few common kinds of transmission. Basically, one only works if you’re
local, and the other works either way, but is more complicated.

1.1.1. Local

If the database is local on your machine, and not clustered, then the application will
fork() (see unix man pages) a sub-process, and the sub-process will exec()
$ORACLE_HOME/bin/oracle, which looks like this:

oracle@usms:/home/oracle> (cd $ORACLE_HOME/bin; ls -l oracle)

-rwsr-s--x 1 oracle dba 112316088 Aug 1 11:12 oracle

Note the ‘s’s in the permission block on the left. They mean that regardless of who execs
the binary, it runs with the permissions of user oracle and group dba (from the ownership
in the middle).
The forked process has often been called a ‘shadow process’. What happens then is not
officially defined, but it is likely to be: there are pipes between the application and the
shadow process, so that the application can send DDL (table creates, etc) and DML
(select/insert/update/delete rows, etc) and receive responses; the shadow process is
directly connected to the other components of the local instance, and directly carries out
the DML and DDL.

Oracle calls this option “Bequeath”, which is the same word in English as giving
something to somebody in your will.

1.1.2. Remote

If the instance is not guaranteed to be local, then a shadow process could not connect
directly to it. What happens instead is that the application process does a tcp connect(),
or the moral equivalent, and communicates with something like a shadow process, at the
other end of the connection, where that process is close enough to the instance to do the
required work directly.

Being remote adds a variety of possibilities, for the thing which receives the connection
to make decisions. The common decisions are:

- load balancing: adding new connections to the least utilized copy of a resource
- fail-over (eg Transparent Application Failover), stalling an application which is
connected to a failed resource, and then silently re-routing it to a replacement
resource
- resource sharing, where the shadow process is only intermittently available to a
session which expects only intermittently to use it (Multi-Threaded Server)
- … (there may be more that I haven’t seen)

The thing which receives the connection is called an Oracle listener. It creates endpoints
for network connections, waits for someone to connect, and arranges for the connection
to go to processes close to the relevant instance.

1.2. Convincing

If the application is remote, then there are a few ways that it might convince the
database of its identity:

- ASCII user-name and reusable password

o This one is common in Oracle

- Public-key encryption
o I believe that this one is a chargeable option; we don’t use it
 - If the server trusted the machine the client came from, it could ask an ident (RFC
1413) server on that client machine, which could tell it the unix user who owns the
process that made the TCP connection
o Oracle has never done this, as far as I know

2. Local cases

In local cases, the shadow process is trusted by Oracle, and also has complete information
about the application process. It can decide about the connection by considering:

- all of the options above

- the unix user of the application process
- the unix group of the application process
o we do not use this one
- whether the application process is owned by a privileged user or group

3. Local cases

To find out what instances are available on the machine:

oracle@usms:/home/oracle> cat /var/opt/oracle/oratab

#
<snip>
SMF:/u01/app/oracle/product/10.2:Y
SCP:/u01/app/oracle/product/10.2:Y
oracle@usms:/home/oracle>

On some older machines, the corresponding file is /etc/oratab. These machines may all
have passed out of service.

So this machine (which is slightly made up) has two instances of Oracle. We can choose
which one we want to address, as follows:

oracle@usms:/home/oracle> . oraenv
ORACLE_SID = [oracle] ? SMF
oracle@usms:/home/oracle>

And we can check the choice that has been made for us as follows :

oracle@usms:/home/oracle> env | egrep 'ORA|TWO_TASK'

ORACLE_BASE=/u01/app/oracle
ORACLE_SID=SMF
ORACLE_HOME=/u01/app/oracle/product/10.2
oracle@usms:/home/oracle>

So the SID (instance identifier) that we typed in has been copied into ORACLE_SID, and
the bit in the middle, which is a path to the important files for the instance, has been
copied into ORACLE_HOME.
Note that TWO_TASK is not defined. This is important, but it will only be explained
later. PATH and LD_LIBRARY_PATH are also important to applications. Given that
eSG run Oracle 9 applications against an Oracle 10 instance, the way they are configured
is unobvious, and incompatible with oraenv; the two path variables point to Oracle 9
software, but the ORACLE_HOME points to the Oracle 10 instance. That should not
matter to you, using sqlplus, because the Oracle 9 and Oracle 10 versions of sqlplus are
substitutable, as far as I know, so you can use the version that is compatible with the
instance.

So, now that we have chosen our instance and path (we were local, so it was always
Bequeath), we can try the various ways of convincing Oracle that we’re house-trained.

3.1. Password

nobody@usms# id
uid=60001(nobody) gid=60001(nobody)
nobody@usms# unset ORACLE_SID

I’m nobody important, and I’ve forgotten which instance I want.

nobody@usms# . oraenv
ORACLE_SID = [nobody] ? SMF
nobody@usms#

Now I know which instance I’m addressing. On this made-up machine, I could have
chosen SCP instead.

nobody@usms# sqlplus smf/smf

<snip>
SQL> select user from dual;

USER
------------------------------
SMF

SQL> quit
<snip>

So I have connected as the user I asked for. How I knew to ask for that user is a story for
another time. Let’s try it again, with a different user, so we know it’s not a fluke.

nobody@usms# sqlplus su/ssob

<snip>
SQL> select user from dual;

USER
------------------------------
SU
SQL> quit

So, if we know a SID, username and password, we can connect as that user, and prove
that we’ve done it.

3.2. Password later, for scripts

What if we’re not sure about the password, and we need to test automatically, whether we
have connected or not?

nobody@usms# sqlplus /nolog

<snip>
SQL> whenever oserror exit 3
SQL> whenever sqlerror exit 2
SQL> connect smf/smf
Connected.
SQL> whenever sqlerror exit 1
SQL> select WRONG from dual;
select WRONG from dual
*
ERROR at line 1:
ORA-00904: "WRONG": invalid identifier
<snip>
nobody@usms# echo $?
1
nobody@usms#

Try this for yourselves, with a wrong username or password, and see how the exit status
($?) changes.

3.3. Operator account

root@usms# su - smf_oper
<snip>
smf_oper@usms:/IN/service_packages/SMS> id
uid=102(smf_oper) gid=101(esg)
smf_oper@usms:/IN/service_packages/SMS> sqlplus /
<snip>
SQL> select user from dual;

USER
------------------------------
OPS$SMF_OPER

SQL> quit
<snip>
smf_oper@usms:/IN/service_packages/SMS>
So now I’m somebody in particular, and I’m special because the application made me so.
Because the shadow process can see who I am, and because the operating system and
Oracle agree about me, I can connect without a password. Our daemon processes, which
run in the background, often use this, because otherwise we have to put copies of the
password into the file-system, to enable the daemons to start, and those copies all have to
be updated when the password is changed.

I’m not asking you to do this, because it makes permanent changes in the database, but
the command in Oracle that made this possible from the Oracle side is in
/IN/service_packages/SMS/db/install/create/smf_daemons.sql. It is the second of these
two commands:

@@smf_user.sql ops$smf_oper external "SMS Operator Account" "Runs

all Unix proce
sses" NULL

alter user ops$smf_oper identified externally;

and all users who connect this way are called ‘externally identified’, because the
operating system is external to Oracle, or ‘operator accounts’ because, as Oracle’s
designers see it, the permission is attached to a function (operating the machine) rather
than to a person.

For future reference, operator accounts and clustering interact badly, because clustering
takes away the certainty of who the application is, by making it remote (sqlNet) even on
the SMP. I do not know how eSG now solves this problem.

3.4. Sysdba/Sysoper

root@usms# su - oracle
<snip>
oracle@usms:/home/oracle> id
uid=101(oracle) gid=100(dba)
oracle@usms:/home/oracle> sqlplus "/ as sysdba"
<snip>
SQL> select user from dual;

USER
------------------------------
SYS

SQL> connect / as sysdba # so the quotes go away

Connected.
SQL> select user from dual;

USER
------------------------------
SYS
SQL> connect / as sysoper
Connected.
SQL> select user from dual;

USER
------------------------------
PUBLIC

SQL> quit
<snip>
oracle@usms:/home/oracle>

Now I’m a different kind of special, chosen by the designers of the database, rather than
by the designers of the application.

Oracle is a relational database, so it stores data, and lets you define the kinds of data it
stores. Oracle stores the definitions (about what kind to store) in Oracle. SYS and
SYSTEM are the accounts (~= users) in which the definitions are stored. There are some
things you can do to the instance and database only if you connect as these accounts.
Those are details for another time.

3.5. Sys with password

This explanation is going to be bad. Oracle stores the passwords for normal accounts in
the data dictionary (explanation later) in the system tablespace (explanation later), but
until the database is open (explanation later), the system tablespace is not available.
Oracle has to decide whether to connect a session (explanation later) as user SYS before
the instance (explanation later) is started (explanation later).

There is a utility called orapwd, that I have never used, that I think we don’t use, that
creates a file that I don’t know what it’s called, but it probably lives in
$ORACLE_HOME, and possibly in $ORACLE_HOME/dbs. That file stores a fixed
number of different passwords for SYS, for use instead of the data dictionary.

I don’t know what the syntax looks like, for connecting using one of these passwords.
When the manuals are available online, I may poke around in them, and put some
references here.

4. Remote cases

There is a clustered model in New Zealand, but it seems that its processes connect
directly to their instances. In other words, if the local instance fails, the applications on
that machine will fail with it.

I think I’m defining this bit as a work in progress.

5. Where to play
There are two model machines in Belgium:
>>>> usms: 192.168.47.152 (root/root)
>>>> uas: 192.168.47.158 (root/root)

These are available until COB 19/12/2008, and possibly longer by negotiation, for
logging into and logging into Oracle.

They don’t look exactly like the examples above, because I have cleaned up the
examples, to show the points I want to make, but it should be clear enough what’s going
on.

Please find me, to sit with you, and try all of the varieties of local login above.