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.

144<br />

CHAPTER 4 ■ MEMORY STRUCTURES<br />

10 rows selected.<br />

294 7<br />

559 2<br />

This is due to clusters (discussed in the Chapter 10), which may contain multiple tables.<br />

Therefore, when joining from X$BH to DBA_OBJECTS to print out a segment name, we would<br />

technically have to list all of the names of all of the objects in the cluster, as a database block<br />

does not belong to a single table all of the time.<br />

We can even watch as <strong>Oracle</strong> increments the touch count on a block that we query<br />

repeatedly. We will use the magic table DUAL in this example—we know it is a one row, one<br />

column table. We need to find out the block information for that single row. The built-in<br />

DBMS_ROWID package is good for getting that. Additionally, since we query ROWID from DUAL,<br />

we are making <strong>Oracle</strong> actually read the real DUAL table from the buffer cache, not the “virtual”<br />

DUAL table enhancement of <strong>Oracle</strong> 10g.<br />

■Note Prior to <strong>Oracle</strong> 10g, querying DUAL would incur a full table scan of a real table named DUAL stored<br />

in the data dictionary. If you set autotrace on <strong>and</strong> query SELECT DUMMY FROM DUAL, you will observe some<br />

I/O in all releases of <strong>Oracle</strong> (consistent gets). In 9i <strong>and</strong> before, if you query SELECT SYSDATE FROM DUAL<br />

or variable := SYSDATE in PL/SQL, you will also see real I/O occur. However, in <strong>Oracle</strong> 10g, that<br />

SELECT SYSDATE is recognized as not needing to actually query the DUAL table (since you are not asking<br />

for the column or rowid from dual) <strong>and</strong> is done in a manner similar to calling a function. Therefore, DUAL<br />

does not undergo a full table scan—just SYSDATE is returned to the application. This small change can<br />

dramatically decrease the amount of consistent gets a system that uses DUAL heavily performs.<br />

So every time we run the following query, we should be hitting the real DUAL table:<br />

sys@ORA9IR2> select tch, file#, dbablk, DUMMY<br />

2 from x$bh, (select dummy from dual)<br />

3 where obj = (select data_object_id<br />

4 from dba_objects<br />

5 where object_name = 'DUAL'<br />

6 <strong>and</strong> data_object_id is not null)<br />

7 /<br />

TCH FILE# DBABLK D<br />

---------- ---------- ---------- -<br />

1 1 1617 X<br />

0 1 1618 X<br />

sys@ORA9IR2> exec dbms_lock.sleep(3.2);<br />

PL/SQL procedure successfully completed.

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

Saved successfully!

Ooh no, something went wrong!