05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

628<br />

CHAPTER 14 ■ PARALLEL EXECUTION<br />

• ALTER TABLE MOVE: A table may be moved in parallel.<br />

• ALTER TABLE SPLIT|COALESCE PARTITION: The individual table partitions may be split or<br />

coalesced in parallel.<br />

• ALTER INDEX SPLIT PARTITION: An index partition may be split in parallel.<br />

The first four of these comm<strong>and</strong>s work for individual table/index partitions as well—that<br />

is, you may MOVE an individual partition of a table in parallel.<br />

To me, parallel DDL is where the parallel execution in <strong>Oracle</strong> is of greatest measurable<br />

benefit. Sure, it can be used with parallel query to speed up certain long-running operations,<br />

but from a maintenance st<strong>and</strong>point, <strong>and</strong> from an administration st<strong>and</strong>point, parallel DDL is<br />

where the parallel operations affect us, DBAs <strong>and</strong> developers, the most. If you think of parallel<br />

query as being designed for the end user for the most part, then parallel DDL is designed for<br />

the DBA/developer.<br />

Parallel DDL <strong>and</strong> Data Loading Using External Tables<br />

One of my favorite new features in <strong>Oracle</strong> 9i is external tables, which are especially useful in<br />

the area of data loading. We’ll cover data loading <strong>and</strong> external tables in some detail in the next<br />

chapter but, as a quick introduction, we’ll take a brief look at these topics here to study the<br />

effects of parallel DDL on extent sizing <strong>and</strong> extent trimming.<br />

External tables allow us to easily perform parallel direct path loads without thinking too<br />

hard about it. <strong>Oracle</strong> 7.1 gave us the ability to perform parallel direct path loads, whereby multiple<br />

sessions could write directly to the <strong>Oracle</strong> data files, bypassing the buffer cache entirely,<br />

bypassing undo for the table data, <strong>and</strong> perhaps even bypassing redo generation. This was<br />

accomplished via SQL*Loader. The DBA would have to script multiple SQL*Loader sessions,<br />

split the input data files to be loaded manually, determine the degree of parallelism, <strong>and</strong> coordinate<br />

all of the SQL*Loader processes. In short, it could be done, but it was hard.<br />

With parallel DDL plus external tables, we have a parallel direct path load that is implemented<br />

via a simple CREATE TABLE AS SELECT or INSERT /*+ APPEND */. No more scripting,<br />

no more splitting of files, <strong>and</strong> no more coordinating the N number of scripts that would be<br />

running. In short, this combination provides pure ease of use, without a loss of performance.<br />

Let’s take a look at a simple example of this in action. We’ll see shortly how to create an<br />

external table. We’ll look at data loading with external tables in much more detail in the next<br />

chapter. For now, we’ll use a “real” table to load another table from, much like many people<br />

do with staging tables in their data warehouse. The technique in short is as follows:<br />

1. Use some extract, transform, load (ETL) tool to create input files.<br />

2. Load these input files into staging tables.<br />

3. Load a new table using queries against these staging tables.<br />

We’ll use the same BIG_TABLE from earlier, which is parallel-enabled <strong>and</strong> contains 10 million<br />

records. We’re going to join this table to a second table, USER_INFO, which contains OWNERrelated<br />

information from the ALL_USERS dictionary view. The goal is to denormalize this<br />

information into a flat structure.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!