Definition
The three different wait events of ‘control file sequential read’, ‘control file single write’, and ‘control file parallel write’ all contribute to the amount of time Oracle takes to keep the control file current.

Oracle maintains a record of the consistency of the database’s physical structures and operational state through a set of control files. The Oracle control file is essential to the database operation and ability to recover from an outage. In fact, if you lose the control file(s) associated with an instance you may not be able to recover completely. It is the Oracle control file(s) that records information about the consistency of a database’s physical structures and operational statuses. The database state changes through activities such as adding data files, altering the size or location of datafiles, redo being generated, archive logs being created, backups being taken, SCN numbers changing, or checkpoints being taken.

Through normal operation the control file is continuously hammered with reads and writes as it is being updated.

Why Control File Waits Occur
The performance around reads and writes against control files is often an indication of misplaced control files that share the same I/O access path or are on devices that are heavily used. It is interesting to note that Oracle has always defaulted the creation of control files in a single directory.

Query to check the control file wait event:

SELECT *
FROM v$system_event
WHERE event IN (SELECT name
FROM V$EVENT_NAME
WHERE name LIKE '%control%');

Likewise you could query the V$SESSION_WAIT view to see which sessions are experiencing control file waits in real time.
SELECT event, wait_time, p1, p2, p3
FROM v$session_wait
WHERE event LIKE ‘%control%’;

Making Improvements
So how can I reduce the time spent for control file reads and writes? There are two distinct answers to this problem.

First, you can ensure that you have placed your control files on disks that are not under excessive heavy loads. When trying to determine how many control files to have, it is best to keep in mind that the more control files you have, the more I/O and time will be needed to write to all those copies. If is often better to have the O/S mirror the control files and reduce Oracle overhead.

Second, since the number of reads and writes are dictated by the type of activity within the database, it is often a good idea to revisit application logic and processing steps to ensure that excessive activities are not causing excessive reads and writes to the control files. For instance, I have seen code that produces excessive commits and even log switches. Since DBA activity is typically concentrated on modifying structures in the database, we need to be careful when performing batch runs of administrative scripts that could conflict with normal application processing. So be on the lookout for high activity levels such as log switching, checkpointing, backups taking place, and structural changes.

DB file sequential read / Db file scattered read:

Because all Oracle databases retrieve and store data, the relative cost of physical disk access is an important topic. In Oracle, we see two types of data block access:

• db file sequential read—A single-block read (i.e., index fetch by ROWID)
   
• db file scattered read—A multiblock read (a full-table scan, OPQ, sorting)

Physical disk speed is an important factor in weighing these costs. Faster disk access speeds can reduce the costs of a full-table scan vs. single block reads to a negligible level.

For example, the new solid state disks provide up to 100,000 I/Os per second, six times faster than traditional disk devices. In a solid-state disk environment, disk I/O is much faster and multiblock reads become far cheaper than with traditional disks.

The standard STATSPACK report can be generated when the database is processing a peak load, and you can get a super-detailed report of all elapsed-time metrics. The most important of these metrics is the STATSPACK top-five timed events. This report is critical because it shows the database events that constitute the bottleneck for the system. We can also see the same phenomenon where a system is disk I/O bound. In the STATSPACK report in Listing A, we see that the system is clearly constrained by disk I/O.

Top 5 Timed Events

                                                           % Total

Event                        Waits         Time (s)       Ela Time

————————— ———— ———–      ——–

db file sequential read       2,598          7,146          48.54

db file scattered read       25,519          3,246          22.04

library cache load lock         673          1,363           9.26

CPU time                                     1,154           7.83

log file parallel write      19,157            837           5.68
Here we see that reads and a write constitute the majority of the total database time. In this case, we would want to increase the RAM size of the db_cache_size to reduce disk I/O, tune the SQL to reduce disk I/O, or invest in a faster disk I/O subsystem.

The ideal optimizer settings depend on your environment and are heavily influenced by your system’s costs for scattered disk reads vs. sequential disk reads.  Below is a great script you can use to measure these I/O costs on your database.

col c1 heading ‘Average Waits|forFull| Scan Read I/O’        format 9999.999

col c2 heading ‘Average Waits|for Index|Read I/O’            format 9999.999

col c3 heading ‘Percent of| I/O Waits|for Full Scans’        format 9.99

col c4 heading ‘Percent of| I/O Waits|for Index Scans’       format 9.99

col c5 heading ‘Starting|Value|for|optimizer|index|cost|adj’ format 999

select

   a.average_wait                                  c1,

   b.average_wait                                  c2,

   a.total_waits /(a.total_waits + b.total_waits)  c3,

   b.total_waits /(a.total_waits + b.total_waits)  c4,

   (b.average_wait / a.average_wait)*100           c5

from

  v$system_event  a,

  v$system_event  b

where

   a.event = ‘db file scattered read’

and

   b.event = ‘db file sequential read’;
Scattered reads and full-table scans

Contrary to some opinions, full-table scans are not necessarily a detriment to performance, and they are often the fastest way to access the table rows. The CBO (cost-based optimizer) choice of performing a full-table scan depends on the settings for Oracle Parallel Query, the db_block_size, the clustering_factor, the estimated percentage of rows returned by the query (according to the CBO statistics), and many other factors.

Once Oracle has chosen a full-table scan, the speed of performing a full-table scan (SOFTS) depends on internal and external factors:

• The number of CPUs on the system
• The setting for Oracle Parallel Query (parallel hints, alter table)
• Table partitioning
• The speed of the disk I/O subsystem (e.g., hardware-cached I/O, solid-state disk RAM 3)

With all of these factors, it may be impossible to determine the exact best setting for the weight in optimizer_index_cost_adj. In the real world, the decision to invoke a full-table scan is heavily influenced by run-time factors such as:

• The availability of free blocks in the data buffers
• The amount of TEMP tablespace (if the FTS has an order by clause)
• The current demands on the CPUs

Hence, it follows that the optimizer_index_cost_adj should change frequently, as the load changes on the server.

However, is it safe to assume that all of the SOFTS factors are reflected in the relative I/O speed of FTS vs. index access? If we make this assumption, we’ve measured the relative speed in v$system_event and have a foundation for creating a self-tuning parameter. To do this, we must accept the following assumptions:

• No systems are alike, and good DBAs must adjust optimizer_index_cost_adj according to their configuration and data access patterns.
   
• The SOFTS is measurable and is reflected in the wait times in v$system_event.
   
• The overall amount of time spent performing full-table scans is equal to the percentage of db file sequential read waits as a percentage of total I/O waits from v$system_event:

  (avg-wait-for-db-file-sequential-read /

    avg-wait-for-db-file-scattered-read)       * 100

Control disk I/O

Disk I/O-intensive systems are common to Oracle databases, and the time spent performing disk I/O often consumes the majority of the wait time. The job of the Oracle professional is to examine all SQL statements to ensure that they’re performing the minimum amount of disk I/O and to know their relative costs of index access vs. full-table scan access.

Direct path read/ Direct path read temp

Description – Direct Path Read Temp

When a session reads buffers from disk directly into the PGA, the wait is on direct path read temp.  This is closely related to the direct path read wait.  If the I/O subsystem doesn’t support asynchronous I/Os, then each wait corresponds to a physical read request.  If the I/O subsystem supports asynchronous I/O, then the process overlaps read requests with processing the blocks already in the PGA. When the process attempts to access a block in the PGA that has not yet been read from disk, it issues a wait call and updates the statistics for this event. So, the number of waits is not always the same as the number of read requests.

Similarly, the direct path write temp wait event and direct path write wait event can occur when a process is writing buffers directly from PGA.  The process will wait on this event for the write call to complete. Operations that could perform direct path writes include when a sort goes to disk, parallel DML operations, direct-path INSERTs, parallel create table as select, and some LOB operations.  Like direct path reads, the number of waits is not the same as number of write calls issued if the I/O subsystem supports asynchronous writes. The session will wait if it has processed the buffers in the PGA and can’t continue work until an I/O request completes.

Diagnosing the direct path read temp wait

When a session is waiting on this event, an entry will be seen in the v$session_wait system view giving more information on the blocks being waited for:

SELECT p1 “file#”, p2 “block#”, p3 “class#”
FROM v$session_wait
WHERE event = ‘direct path read temp’;

In this case p1 represents the file_ID for the read call; p2 represents the start block_ID for the read call; while p3 is the number of blocks in the read call.  Check the file_ID to see if it is for temp.

SELECT relative_fno, owner, segment_name, segment_type
FROM dba_extents
WHERE file_id = &file
AND &block BETWEEN block_id AND block_id + &blocks – 1;

Causes for the direct path read temp wait

To reduce the direct path read wait event and direct path read temp wait event:

• High disk sorts – If the sorts are too large to fit in memory and get sent to disk, this wait can occur.
• Parallel slaves – Parallel slaves are used for scanning data or parallel DML may be used to create and populate objects.  These may lead to direct path read wait and direct path write wait respectively.
• Direct path loads – The direct path API is used to pass data to the load engine in the server and can cause the related direct path write wait.
• Server process ahead of I/O – The server process is processing buffers faster than the I/O system can return the buffers. This can indicate an overloaded I/O system
• Data Warehouse – Sorts in a data warehouse environment may always go to disk leading to high waits on direct path read temp and/or direct path write temp.
• Hash area size – For query plans that call for a hash join, excessive I/O could result from having HASH_AREA_SIZE too small.

Tune away the direct path read temp

High disk sorts –  The disk sort distribution can be checked:

select a.instance_number,to_char(a.snap_time,’dd/mon/yyyy hh24:mi’) meas_date, b.value
from stats$snapshot a, stats$sysstat b, v$statname c
where c.name=’sorts (disk)’
and a.snap_time>sysdate-7
and c.statistic#=b.statistic#
and b.snap_id=a.snap_id
order by a.instance_number,a.snap_time

It is recommended to use pga_aggregate_target.  This area is used both for sorts and the hash join area.  If possible the PGA can be sized larger to fit more in-memory sorts reducing the disk sorts.  It is important to remember that there are limitations of pga_aggregate_target:  The total work area cannot exceed 200 megabytes of RAM because of the default setting for the hidden parameter_pga_max_size.  No RAM sort may use more than 5% of pga_aggregate_target or _pga_max_size, whichever is smaller. This means that no task may use more than 200 megabytes for sorting or hash joins.   Oracle does not recommend changing the hidden parameters, but for certain environments, the result can be beneficial.

To view the PGA and its distribution.

Select  * from v$pgastat;
NAME                                          VALUE
—————————————- ———-
aggregate PGA target parameter            419430400
aggregate PGA auto target                 343517184
global memory bound                        20971520
total PGA inuse                            37789696
total PGA allocated                        42677248
maximum PGA allocated                      53294080
total freeable PGA memory                         0
PGA memory freed back to OS                       0
total PGA used for auto workareas                 0
maximum PGA used for auto workareas           16384
total PGA used for manual workareas               0
maximum PGA used for manual workareas             0
over allocation count                             0
bytes processed                            26643456
extra bytes read/written                          0
cache hit percentage                            100

Tune the sorts – Find the session experiencing the waits and look at the SQL statement currently being run to see the cause of the sorts. Query V$TEMPSEG_USAGE to find the SQL statement generating the sort.  Also query the statistics from V$SESSTAT for the session to determine the size of the sort. Determine whether it is possible to reduce the sorting by tuning the SQL statement.
Full Table Scans – If tables are defined with a high degree of parallelism, the optimizer leans towards using full table scans with parallel slaves. For a direct path read, locate the object being loaded.  Consider using disk striping or Automatic Storage Management (ASM) which can stripe for you.
Parallel DML – Check the I/O distribution across the disks and make sure your I/O is configured for the parallelism being used.  Verify that the parameter DISK_ASYNCH_IO is set to true.

Direct path Write/Direct path Write temp:

direct path write

A direct path write I/O operation is just the opposite of the direct path read operation, and it writes buffers from a session’s PGA to the datafiles. The direct path write operation allows a session to issue multiple write requests and continue processing. At some point, the session will wait on the direct path write event, either to confirm that the OS has completed all outstanding I/Os, or wait for slots to become available so that more writes can be issued. The direct path write operation is normally applied when writing to the temporary tablespace (sort overflows) or when using the direct load method to create or populate objects (CTAS, insert with the APPEND hint). Oracle 8.1.7 has a separate direct write I/O wait event for LOB segments – direct path write (lob).

Like the direct path read event, the number of waits and time waited for the direct path write event can be misleading if asynchronous I/O is supported and used. V$SESSION_WAIT Parameters:

• P1=The absolute file#
• P2=The starting block#
• P3=Number of blocks read

If P1 is not in DBA_DATA_FILES or V$DATAFILE and it is greater than the DB_FILES INIT.ORA parameter, then it is a TEMPFILE. Common Causes and Actions

The direct path write wait event is also popular with direct load operations such as CTAS and INSERT /*+ APPEND */ … SELECT. First, make sure the query is properly tuned to minimize the number of sorts, then tune the I/O subsystem to remove hot spots, if any.

Applications that write to LOB segments that are stored as NOCACHE tend to bottleneck on this event. Make sure there is no I/O bound on the disks where the LOB segments live.

Diagnosis

In Oracle 8.1.6 and up, the DBA can identify live sessions that wrote the most number of blocks in direct mode using the query below.

select a.name, b.sid, b.value

from   v$statname a, v$sesstat b

where  a.statistic# = b.statistic#

and    b.value      > 0

and    a.name       = ‘physical writes direct’

order by b.value;

select a.name, b.sid, b.value, d.ktssoblks

from   v$statname a, v$sesstat b, v$session c, x$ktsso d

where  a.statistic# = b.statistic#

and    b.value      > 0

and    a.name       = ‘physical writes direct’

and    b.sid        = c.sid

and    c.saddr      = d.ktssoses

and    c.serial#    = d.ktssosno

order by b.sid;

The cure for the direct path write waits is to locate and tune the SQL statement to reduce the number of sorts and eliminate hot disks. When the statement is executing, examine the P1 values. If they mostly point to the TEMP tablespace, this means the statement is performing disk sort operations, and if there are a lot of them, then the statement must be tuned to reduce the number of sorts. The DBA can query the X$KTSSO table to see what kind of sorts are taking place to further guide the DBA in tuning the statement. If there is enough memory, consider increasing the SORT_AREA_SIZE parameter, which can help reduce the number of disk sorts. If P1s mostly point to a tablespace other than TEMP, then the statement is probably inserting into a table with the APPEND hint or creating a table with the CTAS operation. In this case, use the appropriate operating system tools or utilities such as sar –d or iostat –dxn to ensure that there are no hot disks. During Direct Path operations, the data is asynchronously written to the database files. At some stage the session needs to make sure that all outstanding asynchronous I/O have been completed to disk. This can also happen if, during a direct write, no more slots are available to store outstanding load requests (a load request could consist of multiple I/Os). Wait Time:

10 seconds. The session will be posted by the completing asynchronous I/O. It will never wait the entire 10 seconds. The session waits in a tight loop until all outstanding I/Os have completed.

Log file parallel write:

The ‘log file parallel write’ event is caused by the Log writer (LGWR) process. The LGWR writes the redo buffer to the online redo log files. It issues a series of write calls to the system IO. The LGWR waits for the writes to complete on log file parallel write. A slow LGWR process can introduce log file sync waits which makes the user to experience wait times during commit or rollback. The log file parallel write and log file sync wait events are interrelated and must be dealt simultaneously.

If the average_wait time is high (above 10 milliseconds) it indicates that the system IO throughput is slow. To improve the average_wait time follow the same techniques used in db file parallel write wait event.

Tuning options:

1. Avoid running hot backups during peak hours.
2. Check for high commit sessions and try to change the application logic to commit less frequently. Use the following queries to find high commit sessions,

SQL> select sid, value from v$sesstat
where statistic# = select statistic# from v$statname where name = ‘user commits’) order by 2 desc;

A high redo wastage also indicates high frequency commits

SQL> select b.name, a.value, round(sysdate – c.startup_time) days_old
from v$sysstat a, v$statname b, v$instance c
where a.statistic# = b.statistic#
and b.name in (‘redo wastage’,'redo size’);

Log file switch completion:

Definition – The amount of time users and applications must wait for a log switch to complete.

As users make changes to data, Oracle keeps a running log of these changes within a set of structures that make up what Oracle calls “redo”. These Redo Logs within Oracle are the critical link in the recovery process as they record the changes to data and provide the input to produce sets of archived logs that are used for point in time recovery. As redo logs fill to capacity and are readied for archival a log switch occurs that relinquishes control from the current redo log to the next available. A single log switch entails stopping further acceptance of generated of redo, reading & writing to control files for redo log status and SCN, (System Change Number), information, flushing memory, and the closing & opening of individual redo log files. Since there are many other resources in use when log switching occurs it is imperative that we are not fooled by high resource usage on these erroneous resources.

There is no record in Oracle that pinpoints the amount of time it takes for a log file switch. It is only experienced by users or applications and is recorded as a wait event at a session or system level. Other than individual sessions generating more redo through improper SQL applications this wait event can only be reduced by attacking it from a full system perspective.

Often the performance impact of switching too many redo logs is the culprit. A good rule of thumb is to switch a redo log every 20 to 30 minutes. Listing 1 gives a SQL statement that will show how often log switching is occurring every hour. You need only increase your redo log sizes to hold more redo and this will reduce the amount of log switching.

Listing 1. Log switching history

Often times the placement of redo log groups on disk is not optimal for the subsystem. Optimally each group member should be assigned to its own disk. This is the only way to eliminate the contention of writing redo and reading redo for archival purposes. Use the SQL in Listing 2 to determine where on disk the redo log groups are. After you have pinpointed them, use a disk monitoring utility such as iostat during high redo activity to determine if you have any contention for reads and writes. Alternatively you could use a disk cache to speed I/O operations.

Listing 2 Redo Log placement

Before diving into disk monitors, you can gain benefit from the SQL in Listing 3. This SQL will display sizes and statuses of the current configuration and use of redo logs. Of importance is the FIRST_CHANGE#. This column shows the first SCN number that was used for a particular redo log group. Use it to verify two redo log groups are not on the same disk that are used next to each other in the redo log rotation.

Listing 3 Redo Log usage order

During the log switch operation, the control file is used quite extensively. It has always been recommended that practitioners multiplex control files through Oracle.

Done this way the log switch operation must keep in sync all the control files defined and thus overhead is increased by a factor of the number of control files multiplexed. Mirroring control files at the operating system level will eliminate the reads and writes for each control file. Use the SQL in Listing 4 to determine the extra amount of I/O you are incurring for each log switch (and many other operations). If you choose this route, please schedule a backup of your control file to trace often enough for recoverability. Alternatively you could use a disk cache to speed I/O operations.

Listing 4 Control File placement

Listing 5 ARCHIVE_LAG_TARGET setting

Log file sync:

Log File Sync

The “log file sync” wait event is triggered when a user session issues a commit (or a rollback). The user session will signal or post the LGWR to write the log buffer to the redo log file. When the LGWR has finished writing, it will post the user session. The wait is entirely dependent on LGWR to write out the necessary redo blocks and send confirmation of its completion back to the user session. The wait time includes the writing of the log buffer and the post, and is sometimes called “commit latency”.

The P1 parameter in <View:V$SESSION_WAIT> is defined as follows for this wait event:

Reducing Waits / Wait times:

If a SQL statement is encountering a significant amount of total time for this event, the average wait time should be examined. If the average wait time is low, but the number of waits is high, then the application might be committing after every row, rather than batching COMMITs. Applications can reduce this wait by committing after “n” rows so there are fewer distinct COMMIT operations. Each commit has to be confirmed to make sure the relevant REDO is on disk. Although commits can be “piggybacked” by Oracle, reducing the overall number of commits by batching transactions can be very beneficial.

If the SQL statement is a SELECT statement, review the Oracle Auditing settings. If Auditing is enabled for SELECT statements, Oracle could be spending time writing and commit data to the AUDIT$ table.

If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same

If the average time waited is high, then examine the other log related waits for the session, to see where the session is spending most of its time. If a session continues to wait on the same buffer# then the SEQ# column of V$SESSION_WAIT should increment every second. If not then the local session has a problem with wait event timeouts. If the SEQ# column is incrementing then the blocking process is the LGWR process. Check to see what LGWR is waiting on as it may be stuck. If the waits are because of slow I/O, then try the following:

• Reduce other I/O activity on the disks containing the redo logs, or use dedicated disks.
  • Try to reduce resource contention. Check the number of transactions (commits + rollbacks) each second, from V$SYSSTAT.
  • Alternate redo logs on different disks to minimize the effect of the archiver on the log writer.
  • Move the redo logs to faster disks or a faster I/O subsystem (for example, switch from RAID 5 to RAID 1).
  • Consider using raw devices (or simulated raw devices provided by disk vendors) to speed up the writes.
  • See if any activity can safely be done with NOLOGGING / UNRECOVERABLE options in order to reduce the amount of redo being written.
  • See if any of the processing can use the COMMIT NOWAIT option (be sure to understand the semantics of this before using it).
  • Check the size of the log buffer as it may be so large that LGWR is writing too many blocks at one time.

Other Considerations:

There may be a problem with LGWR”s ability to flush redo out quickly enough if “log file sync” waits are significant for the entire system. The overall wait time for “log file sync” can be broken down into several components. If the system still shows high “log file sync” wait times after completing the general tuning tips above, break down the total wait time into the individual components. Then, tune those components that take up the largest amount of time.

The “log file sync” wait may be broken down into the following components:

1. Wakeup LGWR if idle
2. LGWR gathers the redo to be written and issues the I/O
3. Wait time for the log write I/O to complete
4. LGWR I/O post processing
5. LGWR posting the foreground/user session that the write has completed
6. Foreground/user session wakeup

Tune the system based on the “log file sync” component with the most wait time. Steps 2 and 3 are accumulated in the “redo write time” statistic. (i.e. as found under STATISICS section of Statspack) Step 3 is the “log file parallel write” wait event. (See Metalink Note 34583.1:”log file parallel write”) Steps 5 and 6 may become very significant as the system load increases. This is because even after the foreground has been posted it may take some time for the OS to schedule it to run.

Data Guard Note:

If Data Guard with synchronous transport and commit WAIT defaults is used, the above tuning steps will still apply. However step 3 will also include the network write time and the redo write to the standby redo logs. This wait event and how it applies to Data Guard is explained in detail in the MAA OTN white paper – Note 387174.1:MAA – Data Guard Redo Transport and Network Best Practices.

Conclusion

When a user session waits on the “Log File Sync” event, it is actually waiting for the LGWR process to write the log buffer to the redo log file and return confirmation/control back to it. If the total wait time is significant, review the average wait time. If the average wait time is low but the number of waits is high, reduce the number of commits by batching (or committing after “n”) rows.

If slow I/O, investigate the following:

• Reduce contention on existing disks.
• Put log files on faster disks.
• Put alternate redo logs on different disks to minimize the effect archive processes (log files switches).
• Review application design, use NOLOGGING operations where appropriate, and avoid changing more data than required.

If wait times are still significant, review each component of the “log file sync” and tune separately.

Read by other session:

Read By Other Session

Definition: When information is requested from the database, Oracle will first read the data from disk into the database buffer cache. If two or more sessions request the same information, the first session will read the data into the buffer cache while other sessions wait. In previous versions this wait was classified under the “buffer busy waits” event. However, in Oracle 10.1 and higher this wait time is now broken out into the “read by other session” wait event. Excessive waits for this event are typically due to several processes repeatedly reading the same blocks, e.g. many sessions scanning the same index or performing full table scans on the same table. Tuning this issue is a matter of finding and eliminating this contention.

Finding the contention

When a session is waiting on this event, an entry will be seen in the v$session_wait system view giving more information on the blocks being waited for:

If information collected from the above query repeatedly shows that the same block, (or range of blocks), is experiencing waits, this indicates a “hot” block or object. The following query will give the name and type of the object:

Eliminating contention

Depending on the database environment and specific performance situation the following variety of methods can be used to eliminate contention:

1. Tune inefficient queries - This is one of those events you need to “catch in the act” through the v$session_wait view as prescribed above. Then, since this is a disk operating system issue, take the associated system process identifier (c.spid) and see what information we can obtain from the operating system.
2. Redistribute data from the hot blocks –deleting and reinserting the hot rows will often move them to a new data block. This will help decrease contention for the hot block and increase performance. More information about the data residing within the hot blocks can be retrieved with queries similar to the following:

1. Adjust PCTFREE and PCTUSED – adjusting the PCTFREE value downward for an object will reduce the number of rows physically stored in a block. Adjusting the PCTUSED value for an object keeps that object from getting prematurely put back on the freelist.

Depending on the type of contention, adjusting these values could help distribute data among more blocks and reduce the hot block problem. Be careful to optimize these parameters so blocks do move in and out of the freelist too frequently.

1. Reduce the Block Size – this is very similar to adjusting the PCTFREE and PCTUSED parameters in that the goal is to reduce the amount of data stored within one block. In Oracle 9i and higher this can be achieved by storing the hot object in a tablespace with a smaller block size. In databases prior to Oracle 9i the entire database must be rebuilt with a smaller block size.
2. Optimize indexes – a low cardinality index has a relatively small number of unique values, e.g. a column containing state data with only 50 values. Similar to inefficient queries, the use of a low cardinality index could cause excessive number of blocks to be read into the buffer cache and cause premature aging out of “good” blocks.

Conclusion

When a session waits on the “read by other session” event, it indicates a wait for another session to read the data from disk into the Oracle buffer cache. If this happens too often the performance of the query or the entire database can suffer. Typically this is caused by contention for “hot” blocks or objects so it is imperative to find out which data is being contended for. Once that is known this document lists several alternative methods for solving the issue.

Log file switch (checkpoint incomplete):

Log file switch (checkpoint incomplete)

The log file switch – checkpoint incomplete event tells you that Oracle wants to reuse a redo log file, but the current checkpoint position is still in that log file. This results in redo generation being stopped until the log switch is done. Obviously not good!

Recommendation:
To resolve these incomplete checkpoints you need to give the checkpoint process more time to cycle through the logs by doing one or both of the following:

* increase the size of the redo logs

* add more redo log groups

Additionally, consider turning off logging for the temporary tables with transient data using the the NOLOGGING attribute on the tables.

Per Oracle documentation “The NOLOGGING clause specifies that subsequent DML statements (UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING attribute of the table and generate redo.” Therefore the SQL Hint /*+ APPEND */ should be used in your application code (only for non-critical, temporary tables).

DB file parallel write:

db file parallel write

The db file parallel write wait event belongs to the Oracle Database Writer (DBWR) process since it is the only process that writes blocks from the SGA to datafiles. When it is time to write, the DBWR process compiles a set of dirty blocks, hands the batch over to the OS, and waits on the db file parallel write event for the I/O to complete.

Although user sessions never experience the db file parallel write wait event, this doesn’t mean that they are never impacted by it. If the write complete waits or free buffer waits event shows up in user sessions, then they may be suffering from the impact of the db file parallel write event.

If a user session needs to modify a block that happens to be in the DBWR write batch, it has to wait on the write complete waits event until that batch of blocks is completely written to disk. If the batch size is large, or the I/O subsystem is slow, the DBWR process will incur additional time waiting for the I/O to complete, and so will the user session that needs the block that is being written.

If user sessions are experiencing the free buffer waits wait event, and the number of waits increases steadily, this means there is a shortage of free blocks in the SGA. This can happen if the Buffer Cache is too small, or DBWR can’t keep up with the rate of blocks being dirtied. One of the reasons why the DBWR process can’t keep up with dirty blocks is that it spends too much time on the db file parallel write event. Parameters:

• P1=The number of files Oracle is writing to.
• P2=The number of blocks to be written.
• P3=Total number of I/O request same as P2 because multi-block I/O is not used.

Since P1 and P2 report the number of files and blocks instead of the absolute file and block number, a DBA cannot tell which objects are being written. However, the user session that waits on the write complete waits or free buffer waits event does indicate the absolute file and block number in its P1 and P2 values. Common Causes and Actions

The db file parallel write latency is normally a symptom of a slow I/O subsystem or poor I/O configurations. This includes poor layout of database files, bad mount point to I/O controller ratio, wrong stripe size and/or RAID level, and not enough disks (i.e. there are a few high capacity disks versus many lower capacity disks). The DBA needs to look at the average I/O time. A well-laid database and I/O subsystem should provide an average I/O wait that does not exceed 2 centiseconds. If this is an issue, the DBA should review the I/O configuration by mapping out the I/O routes from mount points to controllers, and controllers to physical disk groups, and ensure proper placement of database files. The command for this function is platform specific and unfortunately, often requires administrator privilege. For storage systems configured with the Veritas volume manager on Sun platform, the DBA may be able to use the vxprint –ht command. The DBA should also watch for usage (i.e. I/O throughput and bottlenecks) from the OS level using sar –d, iostat –dxn, or an equivalent tool. If some disks are hit hard for an extended period of time (i.e. almost 100% busy), and the average queue length is greater than 3, then the DBA needs to rearrange some of the database files.

Beyond ensuring the I/O subsystem is properly configured and database files are well placed, the DBA should make non-blocking I/O (DISK_ASYNC_IO = TRUE) available to the DBWR process if the platform supports asynchronous I/O.

A larger write batch increases the DBWR I/O wait time, especially in an environment where datafiles are poorly placed. A sure sign that the write batch is too big is when user sessions start to wait on the write complete waits event. Prior to Oracle 8i, the _DB_BLOCK_WRITE_BATCH parameter determined the DBWR write batch size and the value can be seen in X$KVII. It is listed as DB writer IO clump. In 8i and higher, this parameter was replaced by the _DB_WRITER_CHUNK_WRITES and is listed as DBWR write chunk. A new parameter _DB_WRITER_MAX_WRITES was introduced to limit the number of outstanding DBWR I/Os. The DBA should ensure the batch size is not so large that it causes write complete waits and longer db file parallel write, and also not so small that it causes long dirty queue and free buffer waits. Also, bear in mind the improvements that Oracle made since 8i should put the write batch issue to rest, and DBAs shouldn’t have to mess with it. The write complete waits event is prevalent in versions prior to 8i.

Prior to Oracle 8i

view source

print?

1.select * from x$kvii where kviitag = ‘kcbswc’;

Oracle 8i and higher

view source

print?

1.select * from x$kvii where kviitag in (‘kcbswc’,'kcbscw’);

When the DB_BLOCK_MAX_DIRTY_TARGET parameter is set too low, it can also cause excessive waits on the db file parallel write and write complete waits events. This parameter is used to influence the amount of time it takes to perform instance recovery. When the number of dirty buffers exceeds the parameter’s value, DBWR will write the dirty buffers to disk. This is known as incremental checkpoint. A smaller value provides shorter instance recovery time but it may cause the DBWR process to become hyperactive, especially in an active database where a large number of buffers are being modified. This in turn may cause excessive write complete waits and a longer db file parallel write time. This parameter is hidden in 9i and DBAs should not have to be concerned with it. Diagnosis

For system-level diagnosis, query the V$SYSTEM_EVENT view to determine if the AVERAGE_WAIT is an issue.

view source

print?

1.select * from v$system_event where event = ‘db file parallel write’;

While at the V$SYSTEM_EVENT, look also for the companion events.

view source

print?

1.select * from v$system_event

2.where  event in (‘write complete waits’, ‘free buffer waits’);

This event occurs in the DBWR. It indicates that the DBWR is performing a parallel write to files and blocks. When the last I/O has gone to disk, the wait ends. Wait Time:

Wait until all of the I/Os are completed.

Streams AQ: qmn coordinator waiting for slave to start:

When someone asks you to take a quick look into database performance and for whatever reason you can’t run your usual scripts or performance tools on there, ), then what query would you run first?
Yeah sometimes I’ve been not allowed to run custom scripts nor even touch the keyboard due security policies in effect.

Whenever you’re in such situation you want to be the command both short and effective for showing the database state.

The simplest query for determining database state performance wise would be this:

SQL> select event, state, count(*) from v$session_wait group by event, state order by 3 desc;

EVENT                                                            STATE                 COUNT(*)

—————————————————————- ——————- ———-

rdbms ipc message                                                WAITING                      9

SQL*Net message from client                                      WAITING                      8

log file sync                                                    WAITING                      6

gcs remote message                                               WAITING                      2

PL/SQL lock timer                                                WAITING                      2

PL/SQL lock timer                                                WAITED KNOWN TIME            2

Streams AQ: qmn coordinator idle wait                            WAITING                      1

smon timer                                                       WAITING                      1

log file parallel write                                          WAITING                      1

ges remote message                                               WAITING                      1

SQL*Net message to client                                        WAITED SHORT TIME            1

DIAG idle wait                                                   WAITING                      1

pmon timer                                                       WAITING                      1

db file sequential read                                          WAITING                      1

Streams AQ: waiting for messages in the queue                    WAITING                      1

rdbms ipc message                                                WAITED KNOWN TIME            1

jobq slave wait                                                  WAITING                      1

Streams AQ: qmn slave idle wait                                  WAITING                      1

Streams AQ: waiting for time management or cleanup tasks         WAITING                      1

19 rows selected.

It uses the Oracle wait interface to report what all database sessions are currently doing wait/CPU usage wise. Whenever there’s a systemic issue (like extremely slow log file writes) this query will give good hint towards the cause of problem. Of course just running couple of queries against wait interface doesn’t give you the full picture (as these kinds of database wide “healthchecks” can be misleading as we should be really measuring end user response time breakdown at session level and asking questions like what throughput/response time do you normally get) but nevertheless, if you want to see an instance sessions state overview, this is the simplest query I know.

Interpreting this query output should be combined with reading some OS performance tool output (like vmstat or perfmon), in order to determine whether the problem is induced by CPU overload. For example, if someone is running a parallel backup compression job on the server which is eating all CPU time, some of these waits may be just a side-effect of CPU overload).

Below is a cosmetically enhanced version of this command, as one thing I decode the “WAITED FOR xyz TIME” wait states to “WORKING” and “On CPU / runqueue” as event name as otherwise it’s easy to miss by accident that some sessions are not actually waiting on previous event anymore:

SQL> select

  2     count(*),

  3     CASE WHEN state != ‘WAITING’ THEN ‘WORKING’

  4          ELSE ‘WAITING’

  5     END AS state,

  6     CASE WHEN state != ‘WAITING’ THEN ‘On CPU / runqueue’

  7          ELSE event

  8     END AS sw_event

  9  FROM

 10     v$session_wait

 11  GROUP BY

 12     CASE WHEN state != ‘WAITING’ THEN ‘WORKING’

 13          ELSE ‘WAITING’

 14     END,

 15     CASE WHEN state != ‘WAITING’ THEN ‘On CPU / runqueue’

 16          ELSE event

 17     END

 18  ORDER BY

 19     1 DESC, 2 DESC

 20  /

  COUNT(*) STATE   EVENT

———- ——- —————————————-

        11 WAITING log file sync

         9 WAITING rdbms ipc message

         4 WAITING SQL*Net message from client

         3 WAITING PL/SQL lock timer

         2 WORKING On CPU / runqueue

         2 WAITING gcs remote message

         1 WAITING ges remote message

         1 WAITING pmon timer

         1 WAITING smon timer

         1 WAITING jobq slave wait

         1 WAITING Streams AQ: waiting for messages in the

         1 WAITING DIAG idle wait

         1 WAITING Streams AQ: qmn slave idle wait

         1 WAITING Streams AQ: waiting for time management

         1 WAITING db file sequential read

         1 WAITING log file parallel write

         1 WAITING Streams AQ: qmn coordinator idle wait

17 rows selected.

SQL>

Also, sometimes you might want to exclude the background processes and idle sessions from the picture:

SQL> select

  2     count(*),

  3     CASE WHEN state != ‘WAITING’ THEN ‘WORKING’

  4          ELSE ‘WAITING’

  5     END AS state,

  6     CASE WHEN state != ‘WAITING’ THEN ‘On CPU / runqueue’

  7          ELSE event

  8     END AS sw_event

  9  FROM

 10     v$session

 11  WHERE

 12      type = ‘USER’

 13  AND status = ‘ACTIVE’

 14  GROUP BY

 15     CASE WHEN state != ‘WAITING’ THEN ‘WORKING’

 16          ELSE ‘WAITING’

 17     END,

 18     CASE WHEN state != ‘WAITING’ THEN ‘On CPU / runqueue’

 19          ELSE event

 20     END

 21  ORDER BY

 22     1 DESC, 2 DESC

 23  /

  COUNT(*) STATE   EVENT

———- ——- —————————————-

         6 WAITING PL/SQL lock timer

         4 WORKING On CPU / runqueue

         3 WAITING db file sequential read

         1 WAITING read by other session

         1 WAITING Streams AQ: waiting for messages in the

         1 WAITING jobq slave wait

6 rows selected.

By the way, the above scripts report quite similar data what ASH is actually using (especially the instance performance graph which shows you the instance wait summary). ASH nicely puts the CPU count of server into the graph as well (that you would be able to put the number of “On CPU” sessions into perspective), so another useful command to run after this script is “show parameter cpu_count” or better yet, check at OS level to be sure

Note that you can use similar technique for easily viewing the instance activity from other perspectives/dimensions, like which SQL is being executed:

SQL> select sql_hash_value, count(*) from v$session

  2  where status = ‘ACTIVE’ group by sql_hash_value order by 2 desc;

SQL_HASH_VALUE   COUNT(*)

————– ———-

             0         20

     966758382          8

    2346103937          2

    3393152264          1

    3349907142          1

    2863564559          1

    4030344732          1

    1631089791          1

8 rows selected.

SQL> select sql_text,users_executing from v$sql where hash_value = 966758382;

SQL_TEXT                                                     USERS_EXECUTING

———————————————————— —————

BEGIN :1 := orderentry.neworder(:2,:3,:4); END;                           10

Resmgr:cpu quantum:

The session is waiting to be allocated a quantum of cpu. This event occurs when the resource manager is enabled and is throttling CPU consumption. To reduce the occurrence of this wait event, increase the CPU allocation for the sessions’s current consumer group.

Wait Time: The time the session waited to acquire a CPU quantum

With above diagram from enterprise manage we can check the high load period or problematic time and can check the Database in deep for the particular time and can work on identifying the problem.
But all above comforts you will get when you have enterprise manager available and number of databases you have is very less so that you can go to each and every database and monitor the performance to address this issue here I come with.
Oracle AWR report is mainly driven based on time statistics which is nothing but DB_time. DB_Time is based on all wait events in a DB. So if we can monitor the DB time for the period of time we can easily identify the peak and bottle neck time of the database.
To archive the this below are the query which is helpful to get the DB_TIME for certain period(in the query have filtered for monitoring time for last 1 week but it all depends on your AWR retention period)
set feedback off
set pagesize 2000
set linesize 200
set verify off echo off trimspool on

col snap_id format A8
col begin_interval_time_N format A30 trunc
col end_interval_time_N format A30 trunc
col HOST_NAME format A15 trunc
col INSTANCE_NUMBER format 9 heading “I”
col begin_interval_time_N noprint
col end_interval_time_N noprint
select
A.SNAP_ID
, A.INSTANCE_NUMBER
, C.HOST_NAME
, MIN(A.begin_interval_time) OVER (partition by A.dbid, A.snap_id) AS begin_interval_time_N
, MIN(A.end_interval_time) OVER (partition by A.dbid, A.snap_id) AS end_interval_time_N
, (B. VALUE – LAG(B.VALUE,1,0) OVER (ORDER BY A.SNAP_ID))/1000000/60 as DB_TIME
from dba_hist_snapshot A , DBA_HIST_SYS_TIME_MODEL B,dba_hist_database_instance C
where A.SNAP_ID=B.SNAP_ID
and A.DBID=B.DBID
And A.INSTANCE_NUMBER=B.INSTANCE_NUMBER
and B.STAT_NAME Like ‘DB time’
and A.DBID=C.DBID
and A.INSTANCE_NUMBER=C.INSTANCE_NUMBER
and A.startup_time = C.startup_time
and A.begin_interval_time >= trunc(sysdate) – 7 and A.begin_interval_time <= trunc(sysdate) + 20/(26*60)

In Mentioned query we are using dba_hist_snapshot , DBA_HIST_SYS_TIME_MODEL, dba_hist_database_instance views to get the DB_TIME along with LAG function to calculate DB time for that sanp interval.
Once we have this output with us we can use some linux based graph plotting tools to get the nice graph as below and this job can be automated by using cron job.

I have used Ploticaus tool to plot graph in linux, you can use your own way to plot the graph to get the best of it.

http://ploticus.sourceforge.net/doc/welcome.html

Apart from this we can also use excel to get the similar output by using ODBC drivers.

Another great feature of Oracle 10G that allow you to tune SQL. Now you don’t need to tune SQL statement manually. This new feature does it for you.

SQL Tuning Advisor using DBMS_SQLTUNE package and very simple to use.

The example below shows how to use SQL advisor.
1. Grant following access to the user that is going to run this new tool. In the example below SCOTT is the owner of the schema.

 GRANT ADVISOR TO SCOTT;
GRANT SELECT_CATALOG_ROLE TO SCOTT;
GRANT EXECUTE ON DBMS_SQLTUNE TO SCOTT;

2. Create the tuning task
 

DECLARE
task_name_var VARCHAR2(30);
sqltext_var CLOB;
BEGIN
sqltext_var := ‘SELECT * from EMP where empno = 1200′;
task_name_var := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text => sqltext_var,
user_name => ‘SCOTT’,
scope => ‘COMPREHENSIVE’,
time_limit => 60,
task_name => ‘sql_tuning_task_test1′,
description => ‘This is a test tuning task on EMP table’);
END;
/

Some time you may have queries that might take longer than the time that you have specified in the “time_limit” parameter. If this is the case then remove this parameter.

NOTE: You can not create more than one task with the same name. If this is the case then drop the existing task or use a different name.

2.1 To view the existing task for the user run the following statement.
 

select task_name from dba_advisor_log where owner = ‘SCOTT’;

3. Execute the tuning task
 

Execute dbms_sqltune.Execute_tuning_task (task_name => ‘sql_tuning_task_test1′);

3.1 You can check the status of the task using following query.

select status from dba_advisor_log where task_name=’sql_tuning_task_test1′;

4. Now view the Recommendation
 

set linesize 100
set long 1000
set longchunksize 1000

SQL> select dbms_sqltune.report_tuning_task(‘sql_tuning_task_test1′) from dual;

DBMS_SQLTUNE.REPORT_TUNING_TASK(‘SQL_TUNING_TASK_TEST1′)
—————————————————————————————————-
GENERAL INFORMATION SECTION
——————————————————————————-
Tuning Task Name : sql_tuning_task_test1
Scope : COMPREHENSIVE
Time Limit(seconds): 60
Completion Status : COMPLETED
Started at : 06/22/2006 15:33:13
Completed at : 06/22/2006 15:33:14

——————————————————————————-
SQL ID : ad1437c24nqpn
SQL Text: SELECT * from EMP where empno = 1200

——————————————————————————-
FINDINGS SECTION (1 finding)
——————————————————————————-

1- Statistics Finding
———————
Table “SCOTT”.”EMP” was not analyzed.

Recommendation
————–
Consider collecting optimizer statistics for this table.
execute dbms_stats.gather_table_stats(ownname => ‘SCOTT’, tabname =>
‘EMP’, estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
Based on this information, you can decide what actions are necessary to tune the SQL.

After lots of research on web to find the key definitions I found really difficult to find right place to get those. Finally one of my my guru could able to find these difinitions some where. Just uploading those definitions for those who looking like me.

Metadata is stored in first 256 files in ASM disk group

Space is initially allocated when disk group is created

Can be subsequently extended

Metadata allocation units are divided into blocks

Each block is 4096 bytes

Block size specifed using _asm_blksize

Metadata files include

      Allocation Table –  Each ASM has an Allocation Table to track free and allocated space within the disk. The allocation table begins immediately after the disk header. The table contains Allocation Table Entry (ATE) for every allocation unit in the disk.  ATE’s are grouped into allocation table blocks. (ATB)

      Free Space Table( FST)– The FST indicated which ATBs might contain free allocation units. ASM consults a disk’s FST when the disk is selected for allocation.

      Partnership Status Table ( PST)  . The PST tracks disk group membership and the disk partnerships. ASM consults the PST to determine whether a sufficient disks is online to mount the diskgroup.

      File Directory – It contains all of the metadata relevant to ASM files. This directory contains every ASM file and is indexed by file number.

      Disk Directory — It contains information about all the disks in the disk group. Disk Directory is more detailed than PST. Each disk in the diskgroup has an entry in the Disk Directory indexed by disk number.

      Active Change Directory — The ACD is the log that allows ASM to make atomic changes to multiple data structures. It is similar to the redo logs used by the oracle rdbms.

      Continuing Operations Directory (COD) – The COD tracks long running operations such as file creation and rebalance. COD entries allow ASM to recover from failures during long running operations.

      Template Directory — It contains information about all  of the file templates for the disk group.

      Alias Directory  - The alias directory contains all alias metadata as well as entreid for each system alias, system directory, user directory and user alias.

The High Watermark is the maximum fill-grade a table has ever reached. Above the high watermark are only empty blocks. These blocks can be formatted or unformatted.

First let’s have a look at the question when space is allocated

- when you create a table at least one extent (contiguous blocks) is allocated to the table
- if you have specified MINEXTENTS the number of MINEXTENTS extents will be allocated immediately to the table
- if you have not specified MINEXTENTS then exactly one extent will be allocated (we will look at extent sizes later in another post).

Immediately after creation of the segment (table) the high watermark will be at the first block of the first extent as long as there are no inserts made.

When you insert rows into the table the high watermark will be bumped up step by step.
This is done by the server process which makes the inserts.

Now let us take a look at when space is released again from a segment like a table or index:

Let’s assume that we have filled a table with 100’0000 rows. And let’s assume that we deleted 50’000 rows afterwards.  In this case the high watermark will have reached the level of 100’000 and will have stayed there. This means that we have empty blocks below the high watermark now.  Oracle has a good reason this: it might occur that you delete rows and immediately this you insert rows into the same table. In this case it is good that the space was not released with the deletes, because it had to be get reallocate again for the following inserts, which would mean permanent changes to the data dictionary (=> dba_free_space, dba_extents, dba_segements …) .
Furthermore the physical addresses of the deleted row get recycled by new rows.

These empty blocks below the high watermark can get annoying in a number of situations because they are not used by DIRECT LOADs and DIRECT PATH LOADs:

1. seriell direct load:
INSERT /*+ APPEND */
INTO hr.employees
NOLOGGING
SELECT *
FROM oe.emps;

2. parallel direct load:
ALTER SESSION ENABLE PARALLEL DML;
INSERT /*+PARALLLEL(hr.employees,2)
INTO hr.employees
NOLOGGING
SELECT *
FROM oe.emps;

3. direct path loads:
sqlldr hr/hr control=lcaselutz.ctl … direct=y (default is direct=n)

All the above actions case that the SGA is not used for the inserts but the PGA:
there wil be temporary segements filled and dumped into newly formatted blocks above the high watermark.

So we might want to get high watermark down before we load data into the table in order to use the free empty blocks for the loading.

So how can we release unused space from a table?

There are a number of possible options which are already available before Oracle 10g:
- What we always could do is export and import the segment. After an import the table will have only one extent. The rows will have new physical addresses and the high watermark will be adjusted.

With Oracle 9i another possibility was implemented:
ALTER TABLE emp MOVE TABLESPACE users;
This statement will also cause that
- the rows will have new physical addresses and the high watermark will be adjusted.
But for this:
- we need a full (exclusive) table lock – the indexes will be left with the status unusable (because they contain the old rowids) and must be rebuilt.

Starting with ORACLE 10gR1 we can use a new feature for adjusting the high watermark,
it is called segment shrinking and is only possible for segments which use ASSM, in other words, which are located in tablespaces which use Automatic Segment Space Management.
In such a tablespace a table does not really have a High watermark!
It uses two watermarks instead:
- the High High Watermark referred to as HHWM, above which alle blocks ar unformatted.
- the Low High Watermark referred to as LHWM below which all blocks are formatted.
We now can have unformatted blocks in the middle of a segment!

ASSM was introduced in Oracle 9iR2 and it was made the default for tablespaces in Oracle 10gR2.  With the table shrinking feature we can get Oracle to move rows which are located in the middle or at the end of a segment further more down to the beginning of the segment and by
this make the segment more compact.
For this we must first allow ORACLE to change the ROWIDs of these rows by issuing
ALTER TABLE emp ENABLE ROW MOVEMENT; (Even through oracle says row movement is online activity but all depending objects on this table will go invalid. It may cause your applications to behave abnormal.)

ROWIDs are normally assigned to a row for the life time of the row at insert time.

After we have given Oracle the permission to change the ROWIDs
we can now issue a shrink statement.
ALTER TABLE emp SHRINK SPACE;

This statement will proceed in two steps:
- The first step makes the segment compact by moving rows further down to free blocks at the beginning of the segment.
- The second step adjusts the high watermark. For this Oracle needs an exclusive table lock,
but for a very short moment only.

Advantages of Table shrinking
- will adjust the high watermark
- can be done online
- will cause only rowlocks during the operation and just a very short full table lock at the end of the operation
- indexes will be maintained and remain usable
- can be made in one go
- can be made in two steps

- ALTER TABLE emp SHRINK SPACE; – only for the emp table
- ALTER TABLE emp SHRINK SPACE CASCADE; – for all dependent objects as well

- ALTER TABLE emp SHRINK SPACE COMPACT; – only makes the first step (moves the rows)
)

The following restrictions apply to table shrinking:

1.) It is only possible in tablespaces with ASSM.
2.) You cannot shrink:
         – UNDO segments
         – temporary segments
         – clustered tables
         – tables with a column of data type LONG