| Previous | Table of Contents | Next |
The Process Monitor (PMON) devotes its time to cleaning up after processes. It wakes up routinely (determined by operating system) and can also be called by other processes when they detect the need for its services. The following are some examples of tasks that PMON may have to perform when a user process dies:
Note:
You might wonder whether this number is then made available again? This is operating system dependent. On UNIX, the ID is not reused, on others it is. Process ID is not an internal Oracle consideration, it is a table in the kernel of the operating system that controls processing functions.
In the Net/8 multithreaded server environment, PMON is responsible for restarting any dispatcher or server processes that have died. The multithreaded server has a minimum and a maximum number of processes that can be active (see Chapter 24, “Oracle8 Database Tuning,” for information about tuning parameters). Here PMON intervenes only if the number of multithreaded server processes is less than the minimum level for this instance.
Cleaning up unnecessary processes is a very important function on systems where you have a large number of connections. Each connection on a typical UNIX system consumes several megabytes of memory and a fair amount of processor time. This may not seem significant on large, multiprocessor systems with several hundred megabytes of memory. However, if you accumulate several dozen or hundred unnecessary or open-ended processes (a data warehouse user who turns off his PC in the middle of a poorly formed query that takes many hours to complete, for example), you could easily consume a large number of processors and hundreds of megabytes of RAM if PMON were not there to detect the condition and kill those processes.
The Database Writer (DBWR) process is responsible for transferring data that has been modified in the buffer cache memory area to the appropriate disk data files. It ensures that there are always free buffers waiting in memory when a user process wants to write a modified record to the database buffer cache. To review our buffer cache theory from a few chapters back, whenever a user adds or modifies a record from a table, the modified record is written to the buffer cache. Oracle uses the term “dirty” to specify that the buffer in memory needs to be transferred to disk before it can be overwritten. You have only a fixed number of buffers in memory (determined by the size of the database buffer cache you establish in your initialization file). Every time you dirty a buffer it reduces the number of free buffers (available for writing). If the total number of free buffers becomes too low, there will be none available for user processes to place the data obtained on queries (remember, you read multiple records one-at-a-time and store the ones you do not immediately need in the buffer cache). This is where DBWR gets called into action.
The Database Writer writes records to database files that have not been used for the longest period of time. The user interface processes (dedicated server processes) also comply with this procedure in that they write to non-dirty buffers that have not been used recently. Many records can be used and updated frequently. The database writer avoids writing records to disk that are likely to be needed soon (as determined by their frequent usage in the past). A classic example of relatively inactive records is order data on an order-entry system. Typically, an order is entered and not accessed again until someone is ready to ship that product. These types of records are quickly removed from the buffer cache to make room for other orders. A type of record that typically stays longer in the buffer cache is a frequently used lookup table of legal values. For example, these values may be scanned every time an order is entered into the system to validate that it is correct.
Tip:
Does the lookup table stay in the buffer cache permanently just because it is used frequently? For example, if you have a frequently used lookup table containing the list of 50 state codes, it will be one of the last things that Oracle clears from the buffers. Oracle will clear it though, if it needs the space. The DBA has the option to manually “pin” a table in memory, in which case it stays there no matter what.
| Previous | Table of Contents | Next |