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 601<br />

OLTP <strong>and</strong> Global Indexes<br />

An OLTP system is characterized by the frequent occurrence of many small read <strong>and</strong> write<br />

transactions. In general, fast access to the row (or rows) you need is paramount. Data integrity<br />

is vital. Availability is also very important.<br />

Global indexes make sense in many cases in OLTP systems. Table data can be partitioned<br />

by only one key—one set of columns. However, you may need to access the data in many different<br />

ways. You might partition EMPLOYEE data by LOCATION in the table, but you still need fast<br />

access to EMPLOYEE data by<br />

• DEPARTMENT: Departments are geographically dispersed. There is no relationship<br />

between a department <strong>and</strong> a location.<br />

• EMPLOYEE_ID: While an employee ID will determine a location, you don’t want to have to<br />

search by EMPLOYEE_ID <strong>and</strong> LOCATION, hence partition elimination cannot take place on<br />

the index partitions. Also, EMPLOYEE_ID by itself must be unique.<br />

• JOB_TITLE: There is no relationship between JOB_TITLE <strong>and</strong> LOCATION. All JOB_TITLE<br />

values may appear in any LOCATION.<br />

There is a need to access the EMPLOYEE data by many different keys in different places in<br />

the application, <strong>and</strong> speed is paramount. In a data warehouse, we might just use locally partitioned<br />

indexes on these keys <strong>and</strong> use parallel index range scans to collect a large amount of<br />

data fast. In these cases, we don’t necessarily need to use index partition elimination. In an<br />

OLTP system, however, we do need to use it. Parallel query is not appropriate for these systems;<br />

we need to provide the indexes appropriately. Therefore, we will need to make use of<br />

global indexes on certain fields.<br />

The goals we need to meet are<br />

• Fast access<br />

• Data integrity<br />

• Availability<br />

Global indexes can accomplish these goals in an OLTP system. We will probably not be<br />

doing sliding windows, auditing aside for a moment. We will not be splitting partitions (unless<br />

we have a scheduled downtime), we will not be moving data, <strong>and</strong> so on. The operations we<br />

perform in a data warehouse are not done on a live OLTP system in general.<br />

Here is a small example that shows how we can achieve the three goals just listed with<br />

global indexes. I am going to use simple, “single partition” global indexes, but the results<br />

would not be different with global indexes in multiple partitions (except for the fact that availability<br />

<strong>and</strong> manageability would increase as we added index partitions). We start with a table<br />

that is range partitioned by location, LOC, according to our rules, which places all LOC values<br />

less than 'C' into partition P1, those less than 'D' into partition P2, <strong>and</strong> so on:<br />

ops$tkyte@ORA10G> create table emp<br />

2 (EMPNO NUMBER(4) NOT NULL,<br />

3 ENAME VARCHAR2(10),<br />

4 JOB VARCHAR2(9),<br />

5 MGR NUMBER(4),<br />

6 HIREDATE DATE,

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

Saved successfully!

Ooh no, something went wrong!