05.11.2015 Views

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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 10 ■ DATABASE TABLES 403<br />

I do use nested tables heavily as a programming construct <strong>and</strong> in views. This is where I<br />

believe they are in their element. As a storage mechanism, I much prefer creating the parent/<br />

child tables myself. After creating the parent/child tables, we can, in fact, create a view that<br />

makes it appear as if we had a real nested table. That is, we can achieve all of the advantages<br />

of the nested table construct without incurring the overhead.<br />

If you do use a nested table as a storage mechanism, be sure to make it an IOT to avoid<br />

the overhead of an index on the NESTED_TABLE_ID <strong>and</strong> the nested table itself. See the previous<br />

section on IOTs for advice on setting them up with overflow segments <strong>and</strong> other options. If<br />

you do not use an IOT, make sure to create an index on the NESTED_TABLE_ID column in the<br />

nested table to avoid full scanning it to find the child rows.<br />

Temporary Tables<br />

Temporary tables are used to hold intermediate resultsets, for the duration of either a transaction<br />

or a session. The data held in a temporary table is only ever visible to the current<br />

session—no other session will see any other session’s data, even if the current session COMMITs<br />

the data. Multiuser concurrency is not an issue with regard to temporary tables either, as one<br />

session can never block another session by using a temporary table. Even if we “lock” the temporary<br />

table, it will not prevent other sessions using their temporary table. As we observed in<br />

Chapter 9, temporary tables generate significantly less redo than regular tables. However,<br />

since they must generate undo information for the data they contain, they will generate some<br />

amount of redo. UPDATEs <strong>and</strong> DELETEs will generate the largest amount; INSERTs <strong>and</strong> SELECTs<br />

the least amount.<br />

Temporary tables will allocate storage from the currently logged-in user’s temporary<br />

tablespace, or if they are accessed from a definer rights procedure, the temporary tablespace<br />

of the owner of that procedure will be used. A global temporary table is really just a template<br />

for the table itself. The act of creating a temporary table involves no storage allocation; no<br />

INITIAL extent is allocated, as it would be for a regular table. Rather, at runtime when a session<br />

first puts data into the temporary table, a temporary segment for that session will be created.<br />

Since each session gets its own temporary segment (not just an extent of an existing segment),<br />

every user might be allocating space for her temporary table in different tablespaces. USER1<br />

might have his temporary tablespace set to TEMP1, so his temporary tables will be allocated<br />

from this space. USER2 might have TEMP2 as her temporary tablespace, <strong>and</strong> her temporary<br />

tables will be allocated there.<br />

<strong>Oracle</strong>’s temporary tables are similar to temporary tables in other relational databases,<br />

with the main exception being that they are “statically” defined. You create them once per<br />

database, not once per stored procedure in the database. They always exist—they will be in<br />

the data dictionary as objects, but they will always appear empty until your session puts data<br />

into them. The fact that they are statically defined allows you to create views that reference<br />

temporary tables, to create stored procedures that use static SQL to reference them, <strong>and</strong> so on.<br />

Temporary tables may be session based (data survives in the table across commits but<br />

not a disconnect/reconnect). They may also be transaction based (data disappears after a<br />

commit). Here is an example showing the behavior of both. I used the SCOTT.EMP table as a<br />

template:

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

Saved successfully!

Ooh no, something went wrong!