Specifies the preferred optimizer strategy for statements that
    specify a select expression. The following options are available:

    o  FAST FIRST

       A query optimized for FAST FIRST returns data to the user as
       quickly as possible, even at the expense of total throughput.

       If a query can be cancelled prematurely, you should specify
       FAST FIRST optimization. A good candidate for FAST FIRST
       optimization is an interactive application that displays
       groups of records to the user, where the user has the option
       of aborting the query after the first few screens. For
       example, singleton SELECT statements default to FAST FIRST
       optimization.

       If the optimization level is not explicitly set, FAST FIRST is
       the default.

    o  TOTAL TIME

       If your application runs in batch, accesses all the records in
       the query, and performs updates or writes a report, you should
       specify TOTAL TIME optimization. Most queries benefit from
       TOTAL TIME optimization.

       The following examples illustrate the DECLARE CURSOR syntax
       for setting a preferred optimization mode:

       SQL> DECLARE TEMP1 TABLE CURSOR
       cont>  FOR
       cont>    SELECT *
       cont>      FROM EMPLOYEES
       cont>      WHERE EMPLOYEE_ID > '00400'
       cont>  OPTIMIZE FOR FAST FIRST;
       SQL> --
       SQL> DECLARE TEMP2 TABLE CURSOR
       cont>  FOR
       cont>    SELECT LAST_NAME, FIRST_NAME
       cont>      FROM EMPLOYEES
       cont>        ORDER BY LAST_NAME
       cont>  OPTIMIZE FOR TOTAL TIME;

    o  SEQUENTIAL ACCESS

       Forces the use of sequential access. This is particularly
       valuable for tables that use the strict partitioning
       functionality.

       When the storage map of a table has the attribute PARTITIONING
       IS NOT UPDATABLE, the mapping of data to a storage area is
       strictly enforced. This is known as strict partitioning.
       When queries on such tables use sequential access, the
       optimizer can eliminate partitions which do not match the
       WHERE restriction rather than scan every partition.

       The following example shows a query that deletes selected rows
       from a specific partition. This table also includes several
       indexes, which may be chosen by the optimizer. Therefore, the
       OPTIMIZE clause forces sequential access.

       SQL> delete from PARTS_LOG
       cont> where parts_id between 10000 and 20000
       cont>   and expire_date < :purge_date
       cont> optimize for sequential access;

       Note that all access performed by such queries will be
       sequential. Care should be taken that the I/O being used is
       acceptable by comparing similar queries using index access.