Thứ Năm, 29 tháng 3, 2012

Recompile Invalid Schema Objects

Recompiling Invalid Schema Objects

Operations such as upgrades, patches and DDL changes can invalidate schema objects. Provided these changes don't cause compilation failures the objects will be revalidated by on-demand automatic recompilation, but this can take an unacceptable time to complete, especially where complex dependencies are present. For this reason it makes sense to recompile invalid objects in advance of user calls. It also allows you to identify if any changes have broken your code base. This article presents several methods for recompiling invalid schema objects.

Identifying Invalid Objects

The DBA_OBJECTS view can be used to identify invalid objects using the following query.
COLUMN object_name FORMAT A30
SELECT owner,
       object_type,
       object_name,
       status
FROM   dba_objects
WHERE  status = 'INVALID'
ORDER BY owner, object_type, object_name;
With this information you can decide which of the following recompilation methods is suitable for you.

The Manual Approach

For small numbers of objects you may decide that a manual recompilation is sufficient. The following example shows the compile syntax for several object types.
ALTER PACKAGE my_package COMPILE;
ALTER PACKAGE my_package COMPILE BODY;
ALTER PROCEDURE my_procedure COMPILE;
ALTER FUNCTION my_function COMPILE;
ALTER TRIGGER my_trigger COMPILE;
ALTER VIEW my_view COMPILE;
Notice that the package body is compiled in the same way as the package specification, with the addition of the word "BODY" at the end of the command.
An alternative approach is to use the DBMS_DDL package to perform the recompilations.
EXEC DBMS_DDL.alter_compile('PACKAGE', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PACKAGE BODY', 'MY_SCHEMA', 'MY_PACKAGE');
EXEC DBMS_DDL.alter_compile('PROCEDURE', 'MY_SCHEMA', 'MY_PROCEDURE');
EXEC DBMS_DDL.alter_compile('FUNCTION', 'MY_SCHEMA', 'MY_FUNCTION');
EXEC DBMS_DDL.alter_compile('TRIGGER', 'MY_SCHEMA', 'MY_TRIGGER');
This method is limited to PL/SQL objects, so it is not applicable for views.

Custom Script

In some situations you may have to compile many invalid objects in one go. One approach is to write a custom script to identify and compile the invalid objects. The following example identifies and recompiles invalid packages and package bodies.
SET SERVEROUTPUT ON SIZE 1000000
BEGIN
  FOR cur_rec IN (SELECT owner,
                         object_name,
                         object_type,
                         DECODE(object_type, 'PACKAGE', 1,
                                             'PACKAGE BODY', 2, 2) AS recompile_order
                  FROM   dba_objects
                  WHERE  object_type IN ('PACKAGE', 'PACKAGE BODY')
                  AND    status != 'VALID'
                  ORDER BY 4)
  LOOP
    BEGIN
      IF cur_rec.object_type = 'PACKAGE' THEN
        EXECUTE IMMEDIATE 'ALTER ' || cur_rec.object_type || 
            ' "' || cur_rec.owner || '"."' || cur_rec.object_name || '" COMPILE';
      ElSE
        EXECUTE IMMEDIATE 'ALTER PACKAGE "' || cur_rec.owner || 
            '"."' || cur_rec.object_name || '" COMPILE BODY';
      END IF;
    EXCEPTION
      WHEN OTHERS THEN
        DBMS_OUTPUT.put_line(cur_rec.object_type || ' : ' || cur_rec.owner || 
                             ' : ' || cur_rec.object_name);
    END;
  END LOOP;
END;
/
This approach is fine if you have a specific task in mind, but be aware that you may end up compiling some objects multiple times depending on the order they are compiled in. It is probably a better idea to use one of the methods provided by Oracle since they take the code dependencies into account.

DBMS_UTILITY.compile_schema

The COMPILE_SCHEMA procedure in the DBMS_UTILITY package compiles all procedures, functions, packages, and triggers in the specified schema. The example below shows how it is called from SQL*Plus.
EXEC DBMS_UTILITY.compile_schema(schema => 'SCOTT');

UTL_RECOMP

The UTL_RECOMP package contains two procedures used to recompile invalid objects. As the names suggest, the RECOMP_SERIAL procedure recompiles all the invalid objects one at a time, while the RECOMP_PARALLEL procedure performs the same task in parallel using the specified number of threads. Their definitions are listed below.
PROCEDURE RECOMP_SERIAL(
   schema   IN   VARCHAR2    DEFAULT NULL,
   flags    IN   PLS_INTEGER DEFAULT 0);

PROCEDURE RECOMP_PARALLEL(
   threads  IN   PLS_INTEGER DEFAULT NULL,
   schema   IN   VARCHAR2    DEFAULT NULL,
   flags    IN   PLS_INTEGER DEFAULT 0);
The usage notes for the parameters are listed below.
  • schema - The schema whose invalid objects are to be recompiled. If NULL all invalid objects in the database are recompiled.
  • threads - The number of threads used in a parallel operation. If NULL the value of the "job_queue_processes" parameter is used. Matching the number of available CPUs is generally a good starting point for this value.
  • flags - Used for internal diagnostics and testing only.
The following examples show how these procedures are used.
-- Schema level.
EXEC UTL_RECOMP.recomp_serial('SCOTT');
EXEC UTL_RECOMP.recomp_parallel(4, 'SCOTT');

-- Database level.
EXEC UTL_RECOMP.recomp_serial();
EXEC UTL_RECOMP.recomp_parallel(4);

-- Using job_queue_processes value.
EXEC UTL_RECOMP.recomp_parallel();
EXEC UTL_RECOMP.recomp_parallel(NULL, 'SCOTT');
There are a number of restrictions associated with the use of this package including:
  • Parallel execution is perfomed using the job queue. All existing jobs are marked as disabled until the operation is complete.
  • The package must be run from SQL*Plus as the SYS user, or another user with SYSDBA.
  • The package expects the STANDARD, DBMS_STANDARD, DBMS_JOB and DBMS_RANDOM to be present and valid.
  • Runnig DDL operations at the same time as this package may result in deadlocks.

utlrp.sql and utlprp.sql

The utlrp.sql and utlprp.sql scripts are provided by Oracle to recompile all invalid objects in the database. They are typically run after major database changes such as upgrades or patches. They are located in the $ORACLE_HOME/rdbms/admin directory and provide a wrapper on the UTL_RECOMP package. The utlrp.sql script simply calls the utlprp.sql script with a command line parameter of "0". The utlprp.sql accepts a single integer parameter that indicates the level of parallelism as follows.
  • 0 - The level of parallelism is derived based on the CPU_COUNT parameter.
  • 1 - The recompilation is run serially, one object at a time.
  • N - The recompilation is run in parallel with "N" number of threads.
Both scripts must be run as the SYS user, or another user with SYSDBA, to work correctly.

Source: http://www.oracle-base.com/articles/misc/RecompilingInvalidSchemaObjects.php

Steps to configure Oracle 11g OEM DBConsole manually for an existing database

In most of the time DBAs used to go for manual configuration of the database after the database creation. Suppose your database is cloned from other database where you have grid already installed and configured. After the cloning, in the target database the same set of configuration will not work. You have to reconfigure the same. For that you have to drop the existing configuration first. If it is a new database you can directly configure the grid using emca.
Step 1. Drop the existing configuration if it is having sysman user already present.
Connect to sqlplus with sys as sysdba and check SYSMAN is exist or not
SQL> Select username from dba_users where username='SYSMAN';

USERNAME
------------------------------
SYSMAN
      
Command to drop the existing configuration
$ emca -deconfig dbcontrol db -repos drop

STARTED EMCA at Jun 23, 2011 5:27:34 AM
EM Configuration Assistant, Version 11.1.0.7.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database SID: prod9
Listener port number: 1522
Password for SYS user:
Password for SYSMAN user:
Password for SYSMAN user:
Do you wish to continue? [yes(Y)/no(N)]: Y
Jun 23, 2011 5:27:47 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /data/oracle/cfgtoollogs/emca/prod9/emca_2011_06_23_05_27_34.log.
Jun 23, 2011 5:27:49 AM oracle.sysman.emcp.EMDBPreConfig performDeconfiguration
WARNING: EM is not configured for this database. No EM-specific actions can be performed.
Jun 23, 2011 5:27:50 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Dropping the EM repository (this may take a while) ...
Jun 23, 2011 5:37:25 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Repository successfully dropped
Enterprise Manager configuration completed successfully
FINISHED EMCA at Jun 23, 2011 5:37:26 AM

Step 2. Create the OEM GRID repository
$ emca -repos create

STARTED EMCA at Jun 23, 2011 6:41:59 AM
EM Configuration Assistant, Version 11.1.0.7.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database SID: prod9
Listener port number: 1522
Password for SYS user:
Password for SYSMAN user:
Do you wish to continue? [yes(Y)/no(N)]: Y
Jun 23, 2011 6:42:17 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /data/oracle/cfgtoollogs/emca/prod9/emca_2011_06_23_06_41_59.log.
Jun 23, 2011 6:42:18 AM oracle.sysman.emcp.EMReposConfig createRepository
INFO: Creating the EM repository (this may take a while) ...
Jun 23, 2011 7:16:31 AM oracle.sysman.emcp.EMReposConfig invoke
INFO: Repository successfully created
Enterprise Manager configuration completed successfully
FINISHED EMCA at Jun 23, 2011 7:16:31 AM

Step 4. Confitgure EM Grid control

$ emca -config dbcontrol db

STARTED EMCA at Jun 23, 2011 8:58:47 PM
EM Configuration Assistant, Version 11.1.0.7.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Enter the following information:
Database SID: prod9
Database Control is already configured for the database prod9
You have chosen to configure Database Control for managing the database prod9
This will remove the existing configuration and the default settings and perform a fresh configuration
Do you wish to continue? [yes(Y)/no(N)]: Y
Listener port number: 1522
Password for SYS user:
Password for DBSNMP user:
Password for SYSMAN user:
Password for SYSMAN user: Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
-----------------------------------------------------------------

You have specified the following settings

Database ORACLE_HOME ................ /data/oracle/product/11.1.0

Local hostname ................ localhost
Listener port number ................ 1522
Database SID ................ prod9
Email address for notifications ...............
Outgoing Mail (SMTP) server for notifications ...............

-----------------------------------------------------------------
Do you wish to continue? [yes(Y)/no(N)]: y
Jun 23, 2011 8:59:36 PM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /data/oracle/cfgtoollogs/emca/prod9/emca_2011_06_23_20_58_47.log.
Jun 23, 2011 8:59:41 PM oracle.sysman.emcp.util.DBControlUtil stopOMS
INFO: Stopping Database Control (this may take a while) ...
Jun 23, 2011 8:59:49 PM oracle.sysman.emcp.EMReposConfig uploadConfigDataToRepository
INFO: Uploading configuration data to EM repository (this may take a while) ...
Jun 23, 2011 9:09:13 PM oracle.sysman.emcp.EMReposConfig invoke
INFO: Uploaded configuration data successfully
Jun 23, 2011 9:09:36 PM oracle.sysman.emcp.util.DBControlUtil configureSoftwareLib
INFO: Software library configured successfully.
Jun 23, 2011 9:09:36 PM oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Deploying Provisioning archives ...
Jun 23, 2011 9:10:15 PM oracle.sysman.emcp.EMDBPostConfig configureSoftwareLibrary
INFO: Provisioning archives deployed successfully.
Jun 23, 2011 9:10:16 PM oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Securing Database Control (this may take a while) ...
Jun 23, 2011 9:11:01 PM oracle.sysman.emcp.util.DBControlUtil secureDBConsole
INFO: Database Control secured successfully.
Jun 23, 2011 9:11:01 PM oracle.sysman.emcp.util.DBControlUtil startOMS
INFO: Starting Database Control (this may take a while) ...
Jun 23, 2011 9:13:04 PM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: Database Control started successfully
Jun 23, 2011 9:13:04 PM oracle.sysman.emcp.EMDBPostConfig performConfiguration
INFO: >>>>>>>>>>> The Database Control URL is https://localhost:1158/em <<<<<<<
Jun 23, 2011 9:13:20 PM oracle.sysman.emcp.EMDBPostConfig invoke
WARNING:
************************  WARNING  ************************

Management Repository has been placed in secure mode wherein Enterprise Manager data will be encrypte                                                    ile: /data/oracle/product/11.1.0/localhost_prod9/sysman/config/emkey.ora.   Pleas                                                         d data will become unusable if this file is lost.
***********************************************************
Enterprise Manager configuration completed successfully
FINISHED EMCA at Jun 23, 2011 9:13:20 PM

Step 5. Verify the configuration by typing the address (https://localhost:1158/em) in the explorer.

How to check the status of EM Grid control
To check the status of grid control you have issue emctl status dbcontrol
$ emctl status dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.1.0.7.0
Copyright (c) 1996, 2008 Oracle Corporation.  All rights reserved.
https://localhost:1158/em/console/aboutApplication
Oracle Enterprise Manager 11g is running.
------------------------------------------------------------------
Logs are generated in directory /data/oracle/product/11.1.0/localhost_prod9/sysman/log

How to start the EM Grid control
$ emctl start dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.1.0.7.0
Copyright (c) 1996, 2008 Oracle Corporation.  All rights reserved.
https://localhost:1158/em/console/aboutApplication
Starting Oracle Enterprise Manager 11g Database Control ................ started.
------------------------------------------------------------------
Logs are generated in directory /data/oracle/product/11.1.0/localhost_prod9/sysman/log

How to stop the EM Grid Control?

$ emctl stop dbconsole
Oracle Enterprise Manager 11g Database Control Release 11.1.0.7.0
Copyright (c) 1996, 2008 Oracle Corporation.  All rights reserved.
https://localhost:1158/em/console/aboutApplication
Stopping Oracle Enterprise Manager 11g Database Control ...
 ...  Stopped.

Try out!!!!

Source: http://shonythomas.blogspot.com/2011/06/steps-to-configure-oracle-11g-oem.html

Thứ Ba, 20 tháng 3, 2012

Oracle Shared Server and Oracle Dedicated Server Architecture

In order to communicate with oracle database, oracle users need a program such as SQL *Plus which can issue SQL statements and few processes which can execute these SQL statements. These processes are divided into User Process, Server Process and Background Processes. User process runs user application like SQL *Plus. Server process manages oracle user process’s requests. Server process executes SQL statements and returns result to user process. Background processes are the core of oracle database which handle over all database operations.
Each user process is associated to a single server process. The server process can be Dedicated or Shared. A dedicated process has one to one relationship with user process. A dedicated process occupies certain amount of memory. In oracle database 10g, a dedicated server process consumes about 5 MB of memory. In large scale application, memory requirements for dedicated server can be a serious issue. On the other hand, a shared server process is shared by multiple user processes. We do not need a dedicated server process for every user process, so less memory is required and performance increases. At a given time, Shared server process can serve only one user process. Multiple shared server processes are configured to handle multiple user processes.
Shared server architecture consists of Listener Process, Dispatcher Process, Request Queue, Shared server process and Response Queue. Network Listener process listens the user process request. If user process request requires a dedicated server process, listener process starts a dedicated server process. If the request can be assigned to a shared server process, then the request is forwarded to dispatcher process. Shared server configuration requires at least on dispatcher process. Dispatcher process places the request on request queue. Request Queue is created in SGA and shared by all dispatcher processes. On of free Shared server process picks up the request from request queue. After processing the request, shared server process places the result in response queue. Each dispatcher process has its own response queue in SGA. Dispatcher knows about the user process which placed the request, so the response is returned back to user process.

Thứ Ba, 13 tháng 3, 2012

ANY, SOME and ALL in Oracle

I recently stumbled upon a SQL query with ANY in the WHERE clause; it caught my attention because it reminded me of the rarely used SQL comparison operators ANY, SOME and ALL. Let’s play with these operators a little bit. But first, some definitions (from the Oracle Docs):
ANY or SOME: Compares a value to each value in a list or returned by a query. Must be preceded by =, !=, >, <, <=, >=. Evaluates to FALSE if the query returns no rows.
ALL: Compares a value to every value in a list or returned by a query. Must be preceded by =, !=, >, <, <=, >=. Evaluates to TRUE if the query returns no rows.
Now some examples:
Select all employees:
scott@eddev> select ename, job, sal
  2  from emp;

ENAME      JOB              SAL
---------- --------- ----------
SMITH      CLERK            800
ALLEN      SALESMAN        1600
WARD       SALESMAN        1250
JONES      MANAGER         2975
MARTIN     SALESMAN        1250
BLAKE      MANAGER         2850
CLARK      MANAGER         2450
SCOTT      ANALYST         3000
KING       PRESIDENT       5000
TURNER     SALESMAN        1500
ADAMS      CLERK           1100
JAMES      CLERK            950
FORD       ANALYST         3000
MILLER     CLERK           1300

14 rows selected.
Select all employees with a salary greater than 1600 or greater than 2999:
scott@eddev> select ename, sal
  2  from emp
  3  where sal > any (1600, 2999);

ENAME             SAL
---------- ----------
JONES            2975
BLAKE            2850
CLARK            2450
SCOTT            3000
KING             5000
FORD             3000

6 rows selected.
The optimizer expands a condition that uses the ANY or SOME comparison operator followed by a parenthesized list of values into an equivalent condition that uses equality comparison operators and OR logical operators. So, the following query returns the same result as the previous query with the ANY operator.
scott@eddev> select ename, sal
  2  from emp
  3  where sal > 1600 or sal > 2999;

ENAME             SAL
---------- ----------
JONES            2975
BLAKE            2850
CLARK            2450
SCOTT            3000
KING             5000
FORD             3000

6 rows selected.
ANY and SOME are interchangeable. You can use either one and get the same result. Here is an example:
Select employees whose name starts with either A, W or J:
scott@eddev> select ename from emp
  2  where substr(ename,1,1) = any ('A', 'W', 'J');

ENAME
----------
ALLEN
WARD
JONES
ADAMS
JAMES

scott@eddev> c /any/some
  2* where substr(ename,1,1) = some ('A', 'W', 'J')
scott@eddev> l
  1  select ename from emp
  2* where substr(ename,1,1) = some ('A', 'W', 'J')
scott@eddev> /

ENAME
----------
ALLEN
WARD
JONES
ADAMS
JAMES
You can use a subquery instead of a a parenthesized list of values after ANY or SOME:
Select employees whose salary is greater than any salesman’s salary:
scott@eddev> select ename
  2    from emp
  3    where sal > any (
  4      select sal
  5      from emp
  6      where job = 'SALESMAN');

ENAME
----------
ALLEN
JONES
BLAKE
CLARK
SCOTT
KING
TURNER
FORD
MILLER

9 rows selected.
The optimizer transforms a condition that uses the ANY or SOME operator followed by a subquery into a condition containing the EXISTS operator and a correlated subquery. So, The above query is equivalent to the following (added table aliases for clarification):
scott@eddev> select emp1.ename
  2    from emp emp1
  3    where exists (
  4      select emp2.sal
  5      from emp emp2
  6      where emp2.job = 'SALESMAN'
  7        and emp1.sal > emp2.sal);

ENAME
----------
ALLEN
JONES
BLAKE
CLARK
SCOTT
KING
TURNER
FORD
MILLER

9 rows selected.
Now on to the ALL:
Select all employees with a salary greater than 1600 and greater than 2999 (This is not a logical query but it does show the usage of ALL):
scott@eddev> select ename, sal
  2    from emp
  3    where sal > all (1600, 2999);

ENAME             SAL
---------- ----------
SCOTT            3000
KING             5000
FORD             3000
The optimizer expands a condition that uses the ALL comparison operator followed by a parenthesized list of values into an equivalent condition that uses equality comparison operators and AND logical operators. So, the following query is equivalent to the previous one:
scott@eddev> select ename, sal
  2    from emp
  3    where sal > 1600 and sal > 2999;

ENAME             SAL
---------- ----------
SCOTT            3000
KING             5000
FORD             3000
You can use a subquery instead of a a parenthesized list of values after ALL:
Select employees whose salary is greater than every salesman’s salary:
scott@eddev>  select ename
  2        from emp
  3        where sal > all (
  4          select sal
  5          from emp
  6          where job = 'SALESMAN');

ENAME
----------
JONES
BLAKE
CLARK
SCOTT
KING
FORD

6 rows selected.
The optimizer transforms a condition that uses the ALL comparison operator followed by a subquery into an equivalent condition that uses the ANY comparison operator and a complementary comparison operator. So, the optimizer transforms the first condition (using ALL) into this one (using ANY):
scott@eddev>  select emp1.ename
  2        from emp emp1
  3        where not (
  4          emp1.sal <= any (
  5          select emp2.sal
  6          from emp emp2
  7          where emp2.job = 'SALESMAN'));

ENAME
----------
JONES
BLAKE
CLARK
SCOTT
KING
FORD

6 rows selected.
The optimizer then further transforms the second query into the following query using the rule for transforming conditions with the ANY comparison operator, followed by a correlated subquery:
scott@eddev>  select emp1.ename
  2        from emp emp1
  3        where
  4          not exists (
  5          select emp2.sal
  6          from emp emp2
  7          where emp2.job = 'SALESMAN'
  8            and emp1.sal <= emp2.sal);

ENAME
----------
JONES
BLAKE
CLARK
SCOTT
KING
FORD

6 rows selected.
The comparison operators ANY, SOME and ALL can be used when writing queries that answer specific questions; Whether they are the best option to use as far as performance is concerned has to be analysed on a case by case basis.

Source: http://awads.net/wp/2005/08/09/any-some-and-all-in-oracle/

Thứ Hai, 12 tháng 3, 2012

Using alias in WHERE Clause in ORACLE

This is not possible directly, because chronologically, WHERE happens before SELECT, which always is the last step in the execution chain.
You can do a sub-select and filter on it

Thứ Hai, 5 tháng 3, 2012

SQL*Loader (sqlldr) Utility tips


For complete details on using SQL*Loader, see the book "Oracle Utilities".  This is a small excerpt.

Oracle SQL*Loader has dozens of options including direct-path loads, unrecoverable, etc and get super-fast loads. Here are tips for getting high-speed loads with SQL*Loader.
SQL*Loader
SQL*Loader () is the utility to use for high performance data loads.  The data can be loaded from any text file and inserted into the database.
SQL*Loader reads a data file and a description of the data which is defined in the control file.  Using this information and any additional specified parameters (either on the command line or in the PARFILE), SQL*Loader loads the data into the database. 
During processing, SQL*Loader writes messages to the log file, bad rows to the bad file, and discarded rows to the discard file.
The SQL*Loader control file contains information that describes how the data will be loaded.  The sqlldr file contains the table name, column datatypes, field delimiters, etc. and provides the guts for all SQL*Loader processing. 
Manually creating control files is an error-prone process.  The following SQL script () can be used to generate an accurate control file for a given table.  The script accepts a table name and a date format (to be used for date columns), and generates a valid control file to use with SQL*Loader for that table.   
Once executed and given a table name and date format, controlfile.sql will generate a control file with the following contents: 
The control file can also specify that records are in fixed format.  A file is in fixed record format when all records in a datafile are the same length.  The control file specifies the specific starting and ending byte location of each field.  This format is harder to create and less flexible but can yield performance benefits.  A control file specifying a fixed format for the same table could look like the following:
 LOAD DATA
INFILE 'table_with_one_million_rows.dat'
INTO TABLE TABLE_WITH_ONE_MILLION_ROWS
The SQL Loader Log File

The log file contains information about the SQL*loader execution. It should be viewed after each SQL*Loader job is complete. Especially interesting is the summary information at the bottom of the log, including CPU time and elapsed time. The data below is a sample of the contents of the log file.

Maximizing SQL*Loader Performance 
SQL*Loader is flexible and offers many options that should be considered to maximize the speed of data loads.  These include many permutations of the SQL*Loader control file parameters:
OPTIONS (DIRECT=TRUE, ERRORS=50, rows=500000)
UNRECOVERABLE LOAD DATA

 
- Use Direct Path Loads - The conventional path loader essentially loads the data by using standard insert statements.  The direct path loader (direct=true) loads directly into the Oracle data files and creates blocks in Oracle database block format.  To prepare the database for direct path loads, the script $ORACLE_HOME/rdbms/admin/catldr.sql.sql must be executed.
- Disable Indexes and Constraints.  For conventional data loads only, the disabling of indexes and constraints can greatly enhance the performance of SQL*Loader.  The skip_index_maintenance SQL*Loader parameter allows you to bypass index maintenance when performing parallel build data loads into Oracle, but only when using the sqlldr direct=y direct load options.

According to Dave More in his book “Oracle Utilities” using skip_index_maintenance=true means “don’t rebuild indexes”, and it will greatly speed-up sqlldr data loads when using parallel processes with sqlldr:

Also, according to Oracle expert Jonathan Gennick "The skip_index_maintenance SQL*Loader parameter: “Controls whether or not index maintenance is done for a direct path load. This parameter does not apply to conventional path loads. A value of TRUE causes index maintenance to be skipped.
- Use a Larger Bind Array.  For conventional data loads only, larger bind arrays limit the number of calls to the database and increase performance.  The size of the bind array is specified using the bindsize parameter.  The bind array's size is equivalent to the number of rows it contains (rows=) times the maximum length of each row.
- Increase the input data buffer - The sqlldr readsize parameter determines the input data buffer size used by SQL*Loader
- Use ROWS=n to Commit Less Frequently.  For conventional data loads only, rows specifies the number of rows per commit.  Issuing fewer commits will enhance performance. 
- Use Parallel Loads.  Available with direct path data loads only, this option allows multiple SQL*Loader jobs to execute concurrently. Note:  You must be on an SMP server (cpu_count > 2 at least) to successfully employ parallelism, and you must also employ the append option, else you may get this error:  "SQL*Loader-279: Only APPEND mode allowed when parallel load specified."
Note that you can also run SQL*Loader in parallel, and create parallel parallelism:
$ sqlldr control=first.ctl  parallel=true direct=true
$ sqlldr control=second.ctl parallel=true direct=true
6.   Use Fixed Width Data.  Fixed width data format saves Oracle some processing when parsing the data. 
7.   Disable Archiving During Load.  While this may not be feasible in certain environments, disabling database archiving can increase performance considerably.
8.   Use unrecoverableThe unrecoverable option (unrecoverable load data) disables the writing of the data to the redo logs.  This option is available for direct path loads only.

Source: http://www.dba-oracle.com/tips_sqlldr_loader.htm