Remote DBA Plans
Remote DBA Service

The fork system call
Oracle Tips by Burleson Consulting

The fork system call

The fork() system call directs UNIX to spawn a sub-task to service the request. In this case, our Korn shell script will fork two sub processes (Figure 2-3).

Figure 3: Forking a UNIX process

These forked processes are visible by using the UNIX ps –ef command. In the example below, we grep for all processes owned by oracle, and then use the grep –v command to remove all Oracle background processes. As we may know, the Oracle background processes (pmon, smon, arch, etc.) are all identified by a UNIX process in the form ora_processname_ORACLE_SID, such that we see processes with names like ora_ smon_testsid, and ora_pmon_prod, and so on.

root> ps –ef|grep ora|grep –v ora_

oracle 12624 12622 0 12:07:17 pts/5 0:00 –ksh

oracle 12579 12624 0 12:06:54 ? 0:00 oracletestsid

Look closely at above ps –ef listing and note that the first columns are as follows:

Column 1 – Process_owner_name

Column 2 – Process_ID

Column 3 – Parent process_ID

As we see, whenever a fork occurs, we can track backwards to see the originating process. Here we see that our UNIX session (process 12622) has forked process 12624 when the Korn shell script was started. Process 12624, in turn, has forked process 12579 to manage the connection to SQL*Plus. Here is a pictorial description of this interaction.

Note: The interactions in UNIX are very complicated, and these examples have been made deliberately simple to illustrate the basic concepts.

1 - Here we see that the initial task waits in the run queue for service.

2 - Upon reaching the head of the runqueue, the ksh script is started and it issues the read() to inspect the /etc/oratab file and the context switch places into a sleep state until the I/O is complete.

3 - Upon receiving the desired data, the process re-enters the runqueue and waits until it can issue the fork() command to start SQL*Plus. At this point the context switch is set to sleep until the SQL*Plus process has completed.

4 – The SQL*Plus command instructs the Oracle to issue a read() command to fetch the desired view information from the RAM memory in the SGA (The V$ views are in RAM, not on disk). Upon completion of the read, a write() is issued to display the results to the standard out device. SQL*Plus then terminates and sends a signal back to the owner process.

5 – The owner process (ksh) then has a context switch and re-awakens. After reaching the head of the runqueue, it issues a write() to standard output to display the “All Done” message.