Saturday, July 31, 2010

Partitioning in Oracle

Partitioning enables tables and indexes or index-organized tables to be subdivided into smaller manageable pieces and these each small piece is called a partition. From an Application Development perspective, there is no difference between a partitioned and a non-partitioned table. The application need not be modified to access a partitioned table if that application was initially written on a non partitioned tables.

Oracle introduced partitioning like Range Partitioning, Hash Partitioning, Composite Partitioning, List Partitioning,etc. Each method of partitioning has its own advantages and disadvantages and the decision which one to use will depend on the data and type of application. Also one can MODIFY, RENAME, MOVE, ADD, DROP, TRUNCATE, SPLIT partitions.

Advantages of using Partition’s in Table

1. Smaller and more manageable pieces of data (Partitions)
2. Reduced recovery time
3. Failure impact is less
4. Import / Export can be done at the Partition Level.
5. Faster access of data
6. Partitions work independent of the other partitions.
7. Very easy to use

What is SQL*Loader and why it is used for?

SQL*Loader is a bulk loader utility used for moving data from external files into the Oracle database. Its syntax is similar to that of the DB2 Load utility, but comes with more options. SQL*Loader supports various load formats, selective loading, and multi-table loads.

One can load data into an Oracle database by using the sqlldr utility. Invoke the utility without arguments to get a list of available parameters.

Faster SQL performance with dbms_stats

While executing a SQL Query, the execution plan determines the best way to retrieve the data most efficiently. For Oracle, there are many way to retrieve the data from a SQL Query, like which index need to be use, order of joins to be performed and which internal join methods to be use like, hash joins, star joins, and sort merge join, etc. These execution plans are computed by the Oracle’s Cost-Based Optimizer, widely known as CBO.

The choice of executions plans made by the Oracle SQL Optimizer is only as good as the Oracle statistics. Always choose the best execution plan for a SQL query, Oracle depends on information about the tables and indexes in the query.

Using dbms_stats package, Oracle provides a simple way for the Oracle developer to collect statistics for the CBO. The dbms_stats utility does a far better job in estimating statistics, especially for large partitioned tables, and the better stats results in faster SQL execution plans.

The old-fashioned method is Analyzing a table and using methods of dbms_utility to generating CBO statistics are obsolete and somewhat dangerous to SQL performance because they don't always capture high-quality information about tables and indexes. The CBO determines using the the object statistics to choose the best execution plan for all SQL Queries.

The dbms_stats utility does a far better job in estimating statistics, especially for large partitioned tables, and the better stats result in faster SQL execution plans.