HOW TO COMPILE INVALID OBJECT?

There are five ways to recompile invalid objects in schema.

1. DBMS_DDL (exec dbms_ddl.alter_compile ('PROCEDURE','SCOTT','TEST'); )
2. DBMS_UTILITY (exec dbms_utility.compile_schema('SCOTT'); )
3. UTL_RECOMP (Exec UTL_RECOMP.RECOMP_SERIAL ();)
4. UTLRP.SQL (SQL> @c:\oracle\product\10.1.0\db_1\rdbms\admin\UTLRP.SQL)
5. Manually Recompile

TUNING THE CACHE HIT RATIO:-( should be <15%, if not, increase  SHARED_POOL_SIZE )

SELECT SUM (getmisses) / SUM (gets) "Miss ratio" FROM v$rowcache;

TUNING THE LIBRARY CACHE:-(hit ratio should be at least 85%, reload percent should be < 2%, if not,
increase SHARED_POOL_SIZE and parameter OPEN_CURSORS (in init.ora))
SELECT SUM (pinhits) / SUM (pins) "Hit Ratio",
SUM (reloads) / SUM (pins) "Reload percent"
FROM v$librarycache
WHERE namespace IN ('SQL AREA', 'TABLE/PROCEDURE', 'BODY', 'TRIGGER');

TUNING THE LOG BUFFER:- (should be < 5000:1, increase LOG_BUFFER )

SELECT ROUND (e.VALUE / s.VALUE, 5) "Redo Log Ratio"
FROM v$sysstat s, v$sysstat e
WHERE s.NAME = 'redo log space requests' AND e.NAME = 'redo entries';

TUNING BUFFER CACHE HIT RATIO:-(should n't be <90%,if not increase DB_CACHE_SIZE)
SELECT 100 * (1 - (v3.VALUE / (v1.VALUE + v2.VALUE))) "Cache Hit Ratio [%]"
FROM v$sysstat v1, v$sysstat v2, v$sysstat v3
WHERE v1.NAME = 'db block gets'
AND v2.NAME = 'consistent gets'
AND v3.NAME = 'physical reads'

TUNING SORTS:-(sorts(disk) should be <1% , increase SORT_AREA_SIZE )

SELECT NAME, VALUE FROM v$sysstat WHERE NAME IN ('sorts (memory)', 'sorts (disk)');

IDENTIFYING FREE LIST CONTENTION:-(<1%, if not To reduce contention for a table’s free list the
table must be recreated with a larger value in the FREELISTS storage parameter.)
select round( (sum(decode(w.class,'free list',count,0))
/ (sum(decode(name,'db block gets', value, 0))
+ sum(decode(name,'consistent gets', value, 0)))) * 100,2)
from v$waitstat w, v$sysstat;

IDENTIFYING MISSING INDEXES:-

To find the top SQL statements that have caused most block buffer reads:
SELECT buffer_gets, sql_text
FROM v$sqlarea
WHERE buffer_gets > 10000
ORDER BY buffer_gets DESC;
If this returns a large number of rows then increase the number of ‘buffer_gets’ required, if it returns no
rows then decrease this threshold.
To find the most frequently executed SQL:
SELECT executions, buffer_gets, sql_text
FROM v$sqlarea
WHERE executions > 10000
ORDER BY executions DESC;
If this returns a large number of rows then increase the number of ‘executions’ required. If it returns no
rows then decrease the number of executions required.

IDENTIFYING INDEX FRAGMENTATION:-

To obtain information about an index:
analyze index <index_name> validate structure;
This populates the table ‘index_stats’(SELECT * FROM index_stats )
An index should be considered for rebuilding under any of the following conditions:
· The percentage of deleted rows exceeds 30% of the total, i.e. if
· del_lf_rows / lf_rows > 0.3.
· If the ‘HEIGHT’ is greater than 4.
· If the number of rows in the index (‘LF_ROWS’) is significantly smaller than ‘LF_BLKS’ this can
indicate a large number of deletes, indicating that the index should be rebuilt.

IDENTIFY SIGNIFICANT REPARSING OF SQL:-

SELECT executions, t.sql_text
FROM v$sqlarea a, v$sqltext t
WHERE parse_calls > 1
AND parse_calls = executions
AND a.address = t.address
AND executions > 10000
ORDER BY executions DESC;

If this returns a large number of rows then increase the number of ‘executions’ required. If it returns no
rows then perhaps decrease the number of executions required.

If there is SQL that is being repeatedly reparsed then consider increasing the value of SHARED_POOL_SIZE.

REDUCING DATABASE FRAGMENTATION:-

Excessively fragmented tables or indexes can adversely affect performance. Use the following SQL to
identify those database objects that have over 10 extents allocated:
select * from dba_segments where extents > 10;
In general, if a table or index has more than 10 extents then rebuild it to fit into one extent.
A table can only be rebuilt by exporting and then importing it. The database will be unavailable for use by
applications during this time. The steps to accomplish this are:
1. Export the table with COMPRESS=Y
2. Drop the table
3. Import the table.
An index can be rebuilt without preventing others from still using it. Firstly change the storage parameters
to make the ‘next’ storage parameter larger (perhaps double it). The initial storage value cannot be
changed. Then rebuild the index.

REBUILDING INDEXES:-
Periodically, and typically after large deletes or inserts, it is worth rebuilding indexes. The SQL for this is:
Alter index <index_name> rebuild;

Alternatively, the following performs the same, but avoids writing to the redo logs and thus speeds up the
index rebuild:
Alter index <index_name> rebuild unrecoverable;

Note: If performing this under Oracle 7.3 then be sure to specify the destination tablespace, ie:
Alter index <index_name> rebuild tablespace <tablespace>;

Otherwise the index will be moved to the temporary tablespace.

TUNING ROLLBACK SEGMENTS:-

To identify contention for rollback segments first find out the number of times that processes had to wait for
the rollback segment header and blocks. The V$WAITSTAT view contains this information:

select class, count from v$waitstat

where class in ('system undo header', 'system undo block', 'undo header', 'undo block');
The number of waits for any class should be compared with the number of logical reads over the same
period of time. This information can be found in V$SYSSTAT:

select sum(value) from v$sysstat

where name in ('db block gets', 'consistent gets');

If the number of waits for any class of waits is greater than 1% of the total number of logical reads then
add more rollback segments.

The following query gives the percentage of times that a request for data resulted in a wait for a rollback
segment:

select round(sum(waits)/sum(gets),2) from v$rollstat;

If the percentage is greater than 1% then create more rollback segments.

Rollback segments should be isolated as much as possible by placing them in their own tablespace,
preferably on a separate disk from other active tablespaces. The OPTIMAL parameter is used to cause
rollback segments to shrink back to an optimal size after they have dynamically extended.
The V$ROLLSTAT table can help in determining proper sizing of rollback segments:

Select segment_name, shrinks, aveshrink, aveactive "Avg.Active"

from v$rollstat v, dba_rollback_segs d
where v.usn = d.segment_id;

The following table shows how to interpret these results:

Average
size of
Cumulative number of shrinks shrink Recommendation
If the value for “Avg.Active” is close to OPTIMAL, the settings are correct. If not, the
Low Low
(Note: Be aware that it is sometimes better to have a larger optimal value - dependi
reducing it towards “Avg.Active” may cause some applications to start experiencing O
Low High Excellent – few, large shrinks.
High Low Too many shrinks – OPTIMAL is too small.
High High Increase OPTIMAL until the number of shrinks is lower.

Other Oracle Services

If you do not need the Oracle HTTP Server (Apache) then ensure that the service
'OracleOraHome90HTTPServer' is not set to automatically start.

http://www.cryer.co.uk/brian/oracle/tuning.htm