here is a short extract from my book (to get all of the details, get the book)

SMON ¡V The System Monitor

SMON is the process that gets to do all of the jobs no one else wants. It is sort of the 'garbage collector' for the database. Some of the jobs it is responsible for include:

ƒá Temporary space clean up ¡V With the advent of 'true' temporary tablespaces, this job has lessened, but has not gone away. For example, when building an index, the extents allocated for the index during the creation are marked as TEMPORARY. If the CREATE INDEX session is aborted for some reason, SMON is responsible for cleaning them up. There are other operations that create temporary extents that SMON would be responsible for as well.

ƒá Crash recovery ¡V SMON is responsible for performing crash recovery of a failed instance, upon restart.

ƒá Coalescing free space ¡V If you are using dictionary-managed tablespaces SMON is responsible for taking extents that are free in a tablespace and contiguous with respect to each other, and coalescing them into one 'bigger' free extent. This occurs only on dictionary managed tablespace with a default storage clause that has pctincrease set to a non-zero value.

ƒá Recovering transactions active against unavailable files ¡V This is similar to its role during database startup. Here SMON recovers failed transactions that were skipped during instance/crash recovery due to a file(s) not being available to recover. For example, the file may have been on a disk that was unavailable or not mounted. When the file does become available, SMON will recover it.

ƒá Instance recovery of failed node in OPS ¡V In an Oracle Parallel Server configuration, when a node in the cluster goes down (the machine fails), some other node in the instance will open that failed node's redo log files, and perform a recovery of all data for that failed node.

ƒá Cleans up OBJ$ ¡V OBJ$ is a low-level data dictionary table that contains an entry for most every object (table, index, trigger, view, and so on) in the database. There are many times entries in here that represent deleted objects, or objects that represent 'not there' objects, used in Oracle's dependency mechanism. SMON is the process that removes these no longer needed rows.

ƒá Shrinks rollback segments ¡V SMON is the process that will perform the automatic shrinking of a rollback segment to its optimal size, if it is set.

ƒá 'Offlines' rollback segments ¡V It is possible for your DBA to 'offline' or make unavailable, a rollback segment that has active transactions. It may be possible that active transactions are using this offlined rollback segment. In this case, the rollback is not really offlined; it is marked as 'pending offline'. SMON will periodically try to 'really' offline it in the background until it can.

That should give you a flavor of what SMON does (there is more). As evidenced by the ps listing of processes I introduced above, SMON can accumulate quite a lot of CPU over time (the instance that ps was taken from was an active instance that had been up for well over a month). SMON periodically wakes up (or is woken up by the other backgrounds) to perform these housekeeping chores.

..................................


SMON is supposed to be busy, it is normal for it to have lots of CPU

As for why your system load is 4 -- cannot really help you unless you've been running statspack all along and have historical reports to compare with (if you have no history -- its very very hard to say "whats gone up")

A load of 4 is not necessarily bad -- my e450 with 4 cpus runs between 3 and 5 all day long but it still has plenty of idle CPU.

I suggest you start using statspack, generate a history of what you do in a typical day so you can compare this to what you are currently doing when you suspect something is changing.