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

410
CHAPTER 10 ■ DATABASE TABLES
8 /
PL/SQL procedure successfully completed.
ops$tkyte@ORA10G> select table_name, num_rows, blocks, avg_row_len
2 from user_tables
3 where table_name = 'T';
TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN
------------------------------ ---------- ---------- -----------
T 500 7 100
Now, the optimizer won’t use its best guess—it will use our best guess for this information.
Temporary Tables Wrap-Up
Temporary tables can be useful in an application where you need to temporarily store a set of
rows to be processed against other tables, for either a session or a transaction. They are not
meant to be used as a means to take a single larger query and “break it up” into smaller result
sets that would be combined back together (which seems to be the most popular use of temporary
tables in other databases). In fact, you will find in almost all cases that a single query
broken up into smaller temporary table queries performs more slowly in Oracle than the single
query would have. I’ve seen this behavior time and time again, when given the opportunity
to rewrite the series of INSERTs into temporary tables as SELECTs in the form of one large query,
the resulting single query executes much faster than the original multistep process.
Temporary tables generate a minimum amount of redo, but they still generate some redo,
and there is no way to disable that. The redo is generated for the rollback data, and in most
typical uses it will be negligible. If you only INSERT and SELECT from temporary tables, the
amount of redo generated will not be noticeable. Only if you DELETE or UPDATE a temporary
table heavily will you see large amounts of redo generated.
Statistics used by the CBO can be generated on a temporary table with care; however, a
better guess set of statistics may be set on a temporary table using the DBMS_STATS package or
dynamically collected by the optimizer at hard parse time using dynamic sampling.
Object Tables
We have already seen a partial example of an object table with nested tables. An object table is
a table that is created based on a TYPE, not as a collection of columns. Normally, a CREATE TABLE
would look like this:
create table t ( x int, y date, z varchar2(25) );
An object table creation statement looks more like this:
create table t of Some_Type;
The attributes (columns) of T are derived from the definition of SOME_TYPE. Let’s quickly
look at an example involving a couple of types, and then we’ll review the resulting data
structures: