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.

96<br />

CHAPTER 3 ■ FILES<br />

Temp Files<br />

Temporary data files (temp files) in <strong>Oracle</strong> are a special type of data file. <strong>Oracle</strong> will use temporary<br />

files to store the intermediate results of a large sort operation <strong>and</strong> hash operations, as well<br />

as to store global temporary table data, or result set data, when there is insufficient memory to<br />

hold it all in RAM. Permanent data objects, such as a table or an index, will never be stored in<br />

a temp file, but the contents of a temporary table <strong>and</strong> its indexes would be. So, you’ll never<br />

create your application tables in a temp file, but you might store data there when you use a<br />

temporary table.<br />

Temp files are treated in a special way by <strong>Oracle</strong>. Normally, each <strong>and</strong> every change you<br />

make to an object will be recorded in the redo logs; these transaction logs can be replayed at a<br />

later date in order to “redo a transaction,” which you might do during recovery from failure, for<br />

example. Temp files are excluded from this process. Temp files never have redo generated for<br />

them, although they can have undo generated. Thus, there will be redo generated working<br />

with temporary tables since UNDO is always protected by redo, as you will see in detail in<br />

Chapter 9. The undo generated for global temporary tables is in order to support rolling back<br />

some work you have done in your session, either due to an error processing data or because<br />

of some general transaction failure. A DBA never needs to back up a temporary data file, <strong>and</strong><br />

in fact to attempt to do so would be a waste of time, as you can never restore a temporary<br />

data file.<br />

It is recommended that your database be configured with locally-managed temporary<br />

tablespaces. You’ll want to make sure that as a DBA, you use a CREATE TEMPORARY TABLESPACE<br />

comm<strong>and</strong>. You do not want to just alter a permanent tablespace to a temporary one, as you<br />

do not get the benefits of temp files that way.<br />

One of the nuances of true temp files is that if the OS permits it, the temporary files will<br />

be created sparse—that is, they will not actually consume disk storage until they need to. You<br />

can see that easily in this example (on Red Hat Linux in this case):<br />

ops$tkyte@ORA10G> !df<br />

Filesystem 1K-blocks Used Available Use% Mounted on<br />

/dev/hda2 74807888 41999488 29008368 60% /<br />

/dev/hda1 102454 14931 82233 16% /boot<br />

none 1030804 0 1030804 0% /dev/shm<br />

ops$tkyte@ORA10G> create temporary tablespace temp_huge<br />

2 tempfile '/d01/temp/temp_huge' size 2048m<br />

3 /<br />

Tablespace created.<br />

ops$tkyte@ORA10G> !df<br />

Filesystem 1K-blocks Used Available Use% Mounted on<br />

/dev/hda2 74807888 41999616 29008240 60% /<br />

/dev/hda1 102454 14931 82233 16% /boot<br />

none 1030804 0 1030804 0% /dev/shm

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

Saved successfully!

Ooh no, something went wrong!