Oracle Parallel Query Tips

Oracle Tips by Burleson Consulting

The Oracle Parallel Query Option

Introduced in later versions of Oracle7, the parallel query option (PQO) allows multiple processes to simultaneously fetch records and perform sorting operations. This parallelization of operations can lead to impressive speed improvements in a properly set up parallel environment.

Also see here for a list of Oracle parallel query parameters.

The most important item to specify in a parallel environment is the number of parallel query slaves. Too few and you don't get the full benefits, too many and they end up competing with each other for resources. Of course parallel operations are of little or no benefit if your system doesn't have parallel processors and your tables aren't spread across multiple disks in a stripe set or partitioned. Along with the number of parallel query slaves the degree of parallel (DOP) for the tables and indexes needs to be set properly.

The maximum number of parallel query slaves should generally be set to at least twice the number of CPUs or to twice the number of disks that he object was spread across. The DOP can be determined by forcing a full table scan for tables (use a where 1=2 in a select count(*) from the table) and then timing the response for different DOP settings. These numbers are then adjusted up or down depending on performance.

Also see these notes on Oracle parallel features.

Oracle parallel query is very important as Oracle database move onto SMP servers with 8, 16, 32 and 64 CPU processors. On these servers, the speed of full-table scans and index fast-full scans can be greatly improved:

Invoking Oracle Parallel query

There are several ways to invoke Oracle parallel query, and some of them are very dangerous because they influence the costs assigned to full-table scans.

System-level parallelism - Up to 11g release 1, setting the parallel automatic tuning parameter (In 11g release 2 and beyond, the parallel_degree_policy parameter) may cause the cost-based optimizer to perceive full-table scans as cheaper. System-level parallelism is best for data warehouse and DSS systems and should be avoided for OLTP systems.
Session-level parallelism - Using the alter session force parallel query syntax.
Object level parallelism - You can say "alter table customer parallel degree 15", but beware, this influences the SQL optimizer into thinking that full-scans are "cheaper" then index access. I recommend invoking OPQ with hints, on a statement-by-statement basis.
SQL-level parallel query - This parallel hint is the preferred method for invoking parallel query, selectively, based on the operation:

select /*+ parallel (c, 31) (e, 31) */ . . . .

Invoking Oracle parallel query

When invoking Oracle parallel query, there are many perils and pitfalls:

Setting parallelism on at the table or system level influences the optimizer, and sometimes makes full-scan operations appear cheaper than they really are.
Determining the optimal degree of parallelism is tricky. The real optimal degree of parallelism depends on the physical placement of the data blocks on disk as well as the number of processors on the server (cpu_count).

Oracle Training from Don Burleson

The best on site "Oracle training classes" are just a phone call away! You can get personalized Oracle training by Donald Burleson, right at your shop!

��