Database Reference
In-Depth Information
act as the coordinator, collect the results, bind up the finished report, and deliver it. It would not have been done in
one-tenth the time, but perhaps one-eighth or so. Again, I say this with the proviso that
you have sufficient free resources.
If you have a large staff that is currently not doing anything, then splitting the work up makes complete sense.
However, consider that as the manager, your staff is multitasking and they have a lot on their plates. In that case,
you have to be careful with that big project. You need to be sure not to overwhelm them; you don't want to work them
beyond the point of exhaustion. You can't delegate out more work than your resources (your people) can cope with,
otherwise they'll quit. If your staff is already fully utilized, adding more work will cause all schedules to slip and all
projects to be delayed.
Parallel execution in Oracle is very much the same. If you have a task that takes many minutes, hours, or days,
then the introduction of parallel execution may be the thing that makes it run eight times faster. But if you are already
seriously low on resources (the overworked team of people), then the introduction of parallel execution would be
something to avoid, as the system will become even more bogged down. While the Oracle server processes won't quit
in protest, they could start running out of RAM and failing, or just suffer from such long waits for I/O or CPU as to
make it appear as if they were doing no work whatsoever.
If you keep this in mind, remembering never to take an analogy to illogical extremes, you'll have the
commonsense guiding rule to see if parallelism can be of some use. If you have a job that takes seconds, it is doubtful
that parallel execution can be used to make it go faster—the converse would be more likely. If you are low on
resources already (i.e., your resources are fully utilized), adding parallel execution would likely make things worse, not
better. Parallel execution is excellent for when you have a really big job and plenty of excess capacity. In this chapter,
we'll take a look at some of the ways we can exploit those resources.
Oracle Exadata
Oracle Exadata Database Machine is a combined hardware/software offering by Oracle Corporation that takes parallel
operations to the next level. Oracle Exadata is a massively parallel solution to large database problems (on the order
of hundreds to thousands of terabytes, or more). It combines hardware—a specialized storage area network (SAN) for
the database, with software—Oracle Enterprise Linux or Oracle Solaris and parts of the Oracle Database software at
the physical disk level to offload what typically has been database server processing functions such as the following,
and performing them at the storage level itself.
•
Scanning blocks
•
Processing blocks
•
Decrypting/encrypting blocks
•
Filtering blocks (applying a
WHERE
clause)
Selecting columns from blocks
•
•
Processing regular expressions
This results in a tremendous resource usage decrease on the database server—as it receives and processes only
the rows and columns that are needed (the storage devices perform the
WHERE
clause processing and the
SELECT
column list already, among other things) instead of the full set of data. Not only is the scanning of the disk significantly
faster (many times in magnitude faster), but the processing of the data itself is sped up by being performed in a
massively parallel fashion.
So, at the core, Oracle Exadata is about parallel processing, but it will not be covered in detail in this topic. In the
future I do envision that changing, at which point, a chapter (or two) on the topic will be called for. For now, I'm going
to focus on the native parallel processing capabilities of the Oracle Database without Exadata itself.
