Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

   

Oracle Business Intelligence, OLAP and BI training and consulting tips . . .

Click here for more
Oracle News Headlines

 


Tuning the Oracle OLAP TABLE Feature


June 16, 2004
Mark Rittman

If you need to write the contents of a variable, or a group of variables, to a relational table, you would normally use the SQL INSERT command. Normal practice is to loop round all of the variables' dimension values, inserting the variable values into the relational tables one by one, until the variable has been completely loaded into your database table.

Oracle 9i OLAP however introduces two new commands, SQL PREPARE and SQL EXECUTE, that allow us to prepare our INSERT statement in such a way that it uses bind variables to pass values to the Oracle tables. Bind variables are generally a 'good thing' and reduce the amount of time Oracle has to spend parsing your SQL insert statements. In addition, you can specify additional options with SQL PREPARE to specify 'direct path' insertions (quicker as they bypass the normal SQL engine and directly load data into Oracle blocks), nologging (to eliminate redo log generation), and to nominate individual partitions to load data in to. It's worth noting that there's an error in the current OLAP DML documentation that suggest that any OLAP DML insert operation into an Oracle table locks the entire table, preventing other AW processes from inserting into the table until you commit. This is actually untrue, and full-table locking only occurs if you use the DIRECT=YES option, which locks the table in the same way that SQL*Loader locks the table as they both use the Direct Path API.

However, an even better solution than using SQL EXECUTE and SQL PREPARE is to use the OLAP_TABLE feature in Oracle 9i to create a view against your AW variable, then use this view as the source for a "INSERT INTO table SELECT * FROM source" SQL statement, optionally using the /*+ INSERT APPEND */ option if you want to carry out direct path insertions. By using OLAP TABLE and having the SQL engine insert multiple variable values into our target table, rather than having an OLAP DML program loop through the variable and carry out multiple single-row insertions, we were able to increase our write performance by an order of magnitude compared to our earlier SQL INSERT command. One thing to bear in mind though is that, if you are running many copies of the program concurrently, using direct path insertions may well cause lock contention, as each process will obtain an exclusive table lock while the direct insertion takes place. In the case of concurrent processes, it may be better to use conventional path insertions (but still use SQL PREPARE and EXECUTE, or OLAP TABLE) as these only require row-level exclusive locks.
 


 

 

   
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational