TECHNOLOGY: Ask Tom. As Published In. May/June 2011

Transcription

1 TECHNOLOGY: Ask Tom As Published In May/June 2011

2 On Deferring and Bulking Up By Tom Kyte Our technologist prefers not to defer and works to increase bulk. In your column On Constraints, Metadata, and Truth, you wrote about how constraints (or the lack thereof) can really have an impact on query plans. I have a question on constraints: given that you cannot alter an existing constraint to be deferrable you have to drop it and re-create it as deferrable would it be OK to create all constraints as deferrable, just in case you wanted to defer them someday? The short answer is no, you do not want to create all constraints as deferrable just in case. The longer answer is still no, but with an explanation. By default, constraints are implemented in an IMMEDIATE fashion integrity constraints are checked immediately after the entire SQL statement has been processed. Since Oracle8 Database, the database program has had the ability to defer constraint checking, which can be quite advantageous for various operations. One that immediately leaps to mind is the requirement to cascade an UPDATE of a primary key to the child keys. Many people claim that you should never need to do this that primary keys are immutable (I am one of those people) but many others persist in their desire to have a cascading UPDATE. Deferrable constraints make this possible. Before Oracle8 Database, it was actually possible to do a CASCADE UPDATE, but doing so involved a tremendous amount of work and had certain limitations. With deferrable constraints in Oracle8 Database and later releases, it becomes almost trivial. The code can look like this: SQL> create table parent 2 (pk int primary key ) 3 / Table created. SQL> create table child 2 (fk constraint child_fk_parent 3 references parent(pk) 4 deferrable 5 initially immediate 6 ) 7 / Table created. SQL> insert into parent values ( 1 ); 1 row created. SQL> insert into child values ( 1 ); 1 row created. The code creates a parent table, PARENT, and a child table, CHILD. The CHILD table references the PARENT table, and the constraint used to enforce that rule is called CHILD_FK_PARENT (child foreign key to parent). This constraint was created as DEFERRABLE, but it was set to INITIALLY IMMEDIATE. This means that the constraint can be deferred until the COMMIT or to some other time. By default, however, the constraint will be validated at the statement level. This is the most common use of deferrable constraints. As defined, the CHILD table behaves the same way tables always have, but the deferrable constraint makes it possible to explicitly change the table s behavior. Now let s try some data manipulation language and see what happens: SQL> update parent set pk = 2; update parent set pk = 2 * ERROR at line 1: ORA-02292: integrity constraint

3 Next Steps ASK Tom Tom Kyte answers your most difficult technology questions. Highlights from that forum appear in this column. READ more Tom Oracle Database Concepts 11g Release 2 (11.2) Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions, Second Edition) DOWNLOAD Oracle Database 11g Release 2

4 That ll fetch 1,000 rows, process the data, and then bulk-update 1,000 rows back into the table (by rowid and with no index access). That is your first step. (There was a ton of procedural code in the original statement far too much for me to sit down and rewrite in a couple of minutes as a single SQL statement.) This first step will accomplish a few things: The COMMIT after each row is removed. Your original code was not restartable. If it failed halfway through due to an ORA-1555 or any other error, your data would be left in a very inconsistent state from which you would not be able to recover. The data would be logically corrupt. Not only that, but committing after every row is also slow. The update is done by ROWID instead of via a primary key lookup. With your original code, you perform 27,000,000 INDEX UNIQUE SCANS on your primary key. That is at least three, if not four or five, I/Os performed for each lookup! This ROWID optimization alone will probably save you around 100,000,000 I/Os. The code fetches and updates 1,000 records at a time. It eliminates 999 out of every 1,000 round-trips to the server. (Even though we are in PL/SQL, we still have round-trips to the server. They do not go over the network, but they do draw on CPU and other processing resources.) To show the net effect of this last improvement, I ll present a bit of material I use in an Efficient PL/SQL presentation. Among other things, I discuss the reasons for bulking up and when to bulk up versus when not to. In short, if you are in PL/SQL, retrieving data from the database, and not sending it back to the database, you do not need to bulk-collect. The following bit of code is a perfect example: for x in (select * from t where ) dbms_output.put_line( t.x ); end ; In this example, I retrieve data from the database via the SELECT statement but I don t go back to the database to INSERT/UPDATE/DELETE some bit of data, row by row. The SELECT statement is already using bulk processing even if it doesn t look like it. Since Oracle Database 10g, the for x in (select ) construct has been optimized to silently array-fetch 100 rows at a time. So all the SQL in the preceding code snippet already employs bulk processing. This code snippet for x in ( select * from t where ) process(x); update t set where ; end ; needs some work, however. It is doing array fetching for the SELECT but not array processing for the UPDATE. I need to revise the code to do explicit array processing. As a more concrete example, let s look at the stored procedure in Listing 3. Code Listing 3: The slow_by_slow stored procedure create or replace procedure slow_by_slow as begin for x in (select rowid rid, object_name from t t_slow_by_slow) x.object_name := substr(x.object_name,2) substr(x.object_name,1,1); update t set object_name = x.object_name where rowid = x.rid; end ;

5 T o m K y t e H e a d s h o t Tom Kyte is a database evangelist in Oracle s Server Technologies division and has worked for Oracle since He is the author of Expert Oracle Database Architecture (Apress, 2005, 2010) and Effective Oracle by Design (Oracle Press, 2003), among other books. Send us your comments this page Printer View Hardware and Software, Engineered to Work Together