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.

When a process is serialized, there may be plenty of available capacity, but it cannot be used. For example, if there are four CPU cores providing 240 seconds of CPU power over a 1-minute period (4 _ 1 _ 60), but a single stream process is serialized, it can only hope to consume at most 60 seconds of CPU. If we look at the operating system during the serial process, average CPU utilization will be 25%, while our CPU-intensive batch process crawls along. What is needed is increased parallelism to take advantage of the additional and available resources.