When gathering data using your own scripts, remember to make the appropriate adjustments. The significant time-consuming background process wait events should be of no surprise: log file parallel write and db file parallel write. There are others, of course, but these are the most common. The other wait events are easily recognizable by their event name being associated with a background process. If you are unsure, refer to Oracle documentation or search Metalink. Even better, sample from v$session_wait or, for Oracle Database 10g and later, sample from v$active_session_history or v$session, to see which sessions are posting the wait event in question.

Back in Chapter 3, I stated that serialization is death. When working with batch processes, this is profoundly important. Suppose that a process takes 60 minutes to complete, and the system has ample available capacity. We know that if we can alter the process to run in two streams instead of one, the process may complete twice as fast-in 30 minutes. That is using parallelism to our advantage.

With online processes, Oracle has already taken significant steps to increase and take advantage of parallelism. The existence of multiple server and background processes is an example of this. However, having a batch Oracle client process related to a single Oracle server process can become a serialization limitation. So, our parallelism effort will focus on ways to split the process into multiple streams, each with its own Oracle client and server process.