Standard Oracle relational theory tells you that, when putting data into a table, it doesn't matter in which order you insert the data, as Oracle doesn't guarantee the order in which it's returned, unless you specifically use an ORDER BY clause. Therefore, you can't rely on data coming back out from a table in the same order it was entered in.
However, when working with data warehouse fact tables, there can be benefits in specifying how Oracle physically stores the row data within the database, so that rows that relate to a particular time span are found within the same database block, reducing disk I/O and speeding up queries.
The INSERT /*+ APPEND */ feature of Oracle allows you to use the direct path method of loading tables, storing new data after existing data in the table and optionally allowing you to specify NOLOGGING to bypass the writing of undo and redo entries. If you couple this with an ORDER BY statement in the accompanying SELECT clause, you can make Oracle store new table rows in blocks in the order in which you want to retrieve them. For example;
INSERT /*+ APPEND */
INTO sales_fact
SELECT *
FROM customer_sales_fact_staging
ORDER BY time_wh_id;
COMMIT;
would insert rows into the sales_fact table, using the direct path method, and the rows would be placed in blocks in the order of the time warehouse key. This would be particularly useful if common queries to the sales_fact table returned rows around the same date range, as Oracle would be able to return many fact table rows from each block retrieved, rather than one or two per block.
If you're looking to populate a table from fresh (either a new table, or one that's been truncated) inserting rows in a particular order could also benefit index creation, as you could specify NOSORT and save many hours of index creation on large tables.
Many thanks to John W Spencer, Justin Cave and Chris Slattery for contributing to the OTN Thread that pointed out this useful tip.
10:22:46 PM 
|
