05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

CHAPTER 14 ■ PARALLEL EXECUTION 627<br />

• There are certain declarative referential-integrity constraints that are not supported<br />

during the PDML, since each slice of the table is modified as a separate transaction in<br />

the separate session. Self-referential integrity is not supported, for example. Consider<br />

the deadlocks <strong>and</strong> other locking issues that would occur if it were supported.<br />

• You cannot access the table you’ve modified with PDML until you commit or roll back.<br />

• Advanced replication is not supported with PDML (because the implementation of<br />

advanced replication is trigger based).<br />

• Deferred constraints (i.e., constraints that are in the deferred mode) are not supported.<br />

• PDML may only be performed on tables that have bitmap indexes or LOB columns if<br />

the table is partitioned, <strong>and</strong> then the degree of parallelism would be capped at the<br />

number of partitions. You cannot parallelize an operation within partitions in this case,<br />

as each partition would get a single parallel execution server to operate on it.<br />

• Distributed transactions are not supported when performing PDML.<br />

• Clustered tables are not supported with PDML.<br />

If you violate any of those restrictions, one of two things will happen: either the statement<br />

will be performed serially (no parallelism will be involved) or an error will be raised. For example,<br />

if you already performed the PDML against table T <strong>and</strong> then attempted to query table T<br />

before ending your transaction, then you will receive an error.<br />

Parallel DDL<br />

I believe that parallel DDL is the real “sweet spot” of <strong>Oracle</strong>’s parallel technology. As we’ve discussed,<br />

parallel execution is generally not appropriate for OLTP systems. In fact, for many data<br />

warehouses, parallel query is becoming less <strong>and</strong> less of an option. It used to be that a data<br />

warehouse was built for a very small, focused user community—sometimes consisting of just<br />

one or two analysts. However, over the last decade I’ve watched them grow from small user<br />

communities to user communities of hundreds or thous<strong>and</strong>s. Consider a data warehouse<br />

front-ended by a web-based application: it could be accessible to literally thous<strong>and</strong>s or more<br />

users instantly.<br />

But a DBA performing the large batch operations, perhaps during a maintenance window,<br />

is a different story. The DBA is still a single individual <strong>and</strong> he might have a huge machine with<br />

tons of computing resources available. The DBA has only “one thing to do”: load this data,<br />

reorganize that table, rebuild that index. Without parallel execution, the DBA would be hardpressed<br />

to really use the full capabilities of the hardware. With parallel execution, he can. The<br />

following SQL DDL comm<strong>and</strong>s permit “parallelization”:<br />

• CREATE INDEX: Multiple parallel execution servers can scan the table, sort the data, <strong>and</strong><br />

write the sorted segments out to the index structure.<br />

• CREATE TABLE AS SELECT: The query that executes the SELECT may be executed using<br />

parallel query, <strong>and</strong> the table load itself may be done in parallel.<br />

• ALTER INDEX REBUILD: The index structure may be rebuilt in parallel.

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

Saved successfully!

Ooh no, something went wrong!