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 13 ■ PARTITIONING 605<br />

Sure enough, we see a similar effect for the INDEX RANGE SCAN. Our indexes are used <strong>and</strong><br />

can provide high-speed OLTP access to the underlying data. If they were partitioned, they<br />

would have to be prefixed <strong>and</strong> enforce index partition elimination; hence, they are scalable as<br />

well, meaning we can partition them <strong>and</strong> observe the same behavior. In a moment, we’ll look<br />

at what would happen if we used LOCAL indexes only.<br />

Lastly, let’s look at the area of availability. The <strong>Oracle</strong> documentation claims that globally<br />

partitioned indexes make for “less available” data than locally partitioned indexes. I don’t fully<br />

agree with this blanket characterization. I believe that in an OLTP system they are as highly<br />

available as a locally partitioned index. Consider the following:<br />

ops$tkyte@ORA10G> alter tablespace p1 offline;<br />

Tablespace altered.<br />

ops$tkyte@ORA10G> alter tablespace p2 offline;<br />

Tablespace altered.<br />

ops$tkyte@ORA10G> alter tablespace p3 offline;<br />

Tablespace altered.<br />

ops$tkyte@ORA10G> select empno, job, loc from emp where empno = 7782;<br />

EMPNO JOB LOC<br />

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

7782 MANAGER NEW YORK<br />

Here, even though most of the underlying data is unavailable in the table, we can still gain<br />

access to any bit of data available via that index. As long as the EMPNO we want is in a tablespace<br />

that is available, <strong>and</strong> our GLOBAL index is available, our GLOBAL index works for us. On the<br />

other h<strong>and</strong>, if we had been using the “highly available” local index in the preceding case, we<br />

might have been prevented from accessing the data! This is a side effect of the fact that we<br />

partitioned on LOC but needed to query by EMPNO. We would have had to probe each local index<br />

partition <strong>and</strong> would have failed on the index partitions that were not available.<br />

Other types of queries, however, will not (<strong>and</strong> cannot) function at this point in time:<br />

ops$tkyte@ORA10G> select empno, job, loc from emp where job = 'CLERK';<br />

select empno, job, loc from emp where job = 'CLERK'<br />

*<br />

ERROR at line 1:<br />

ORA-00376: file 13 cannot be read at this time<br />

ORA-01110: data file 13: '/home/ora10g/oradata/.../o1_mf_p2_1dzn8jwp_.dbf'<br />

The CLERK data is in all of the partitions, <strong>and</strong> the fact that three of the tablespaces are<br />

offline does affect us. This is unavoidable unless we had partitioned on JOB, but then we would<br />

have had the same issues with queries that needed data by LOC. Anytime you need to access<br />

the data from many different “keys,” you will have this issue. <strong>Oracle</strong> will give you the data<br />

whenever it can.

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

Saved successfully!

Ooh no, something went wrong!