important points

1.  Originally the UTLBSTAT/UTLESTAT scripts were used to monitor performance metrics. Oracle 8i introduced the Statspack functionality which Oracle 9i extended. In Oracle 10g statspack has evolved into the Automatic Workload Repository (AWR).
2. Oracle 10g took code instrumentation in the kernel to a whole new level with the introduction of the Automatic Workload Repository (AWR) and Active Session History (ASH) features. Oracle 11g takes that further with options such as the Automatic Diagnostic Repository (ADR) and the SQL Performance Analyzer (SPA).
3. In Oracle database 11g, a new facility, the ADR, was added. As part of this new facility, there’s a new V$ view—V$DIAG_INFO.
4. select * from v$diag_info;
5. Starting in Oracle database 11g, The ADRCI tool allows you to review “problems” (critical errors in the database) and incidents (occurrences of those critical errors) and to package them up for transmission to support
   adrci> show tracefile -I 6177
   This shows me the location of the trace file for incident number 6177. Further, I can see a lot of detail about the incident if I so choose:
   adrci> show incident -mode detail -p "incident_id=6177"
6. Automatic Storage Management (ASM): This is a new feature of Oracle 10g Release1 (for both Standard and Enterprise editions).
7. Oracle 11g Release 2, ASM provides not only this database file system but optionally a clustered file system as well, which is described next.
8. This feature of multiple block sizes was introduced for the purpose of making transportable tablespaces usable in more cases.
9. Tablespaces with multiple block sizes should be used to facilitate transporting tablespaces; they are not generally used for anything else.
10. The change-tracking file is a new, optional file for use with Oracle 10g Enterprise Edition and above
11. Flashback logs were introduced in Oracle 10g in support of the FLASHBACK DATABASE command
12. The Data Pump format is exclusive to Oracle 10g Release 1 and above—it did not exist in any Oracle9i release, nor can it be used with that release.
13. PGA_AGGREGATE_TARGET: This parameter controls how much memory the instance should allocate, in total, for all work areas used to sort or hash data.

14. select sum(bytes) from v$sgastat where pool = 'shared pool';

    The sharedpool holds many other structures that are outside the scope of the corresponding parameter. The SHARED_POOL_SIZE is typically the largest contributor to the shared pool as reported by the SUM(BYTES), but it is not the only contributor.

    In Oracle 10g, the SHARED_POOL_SIZE parameter controls the size of the shared pool, whereas in Oracle9i and before, it was just the largest contributor to the shared pool. You should review your 9i and before actual shared pool size (based on V$SGASTAT) and use that figure to set your SHARED_POOL_SIZE parameter in Oracle 10g and above.

15. When someone complains of deadlocks in the database, I have them run a script that finds unindexed foreign keys; 99 percent of the time we locate an offending table. By simply indexing that foreign key, the deadlocks—and lots of other contention issues—go away.

16. The number one cause of deadlocks in the Oracle database, in my experience, is unindexed foreign keys. (Thenumber two cause is bitmap indexes on tables subject to concurrent updates, which we’ll cover in Chapter 11).

17. The higher the transaction isolation level, the locking overhead can increase while user concurrency can decrease.

18. GRANT execute ON dbms_monitor TO scott;

19. What happens when you run an UPDATE
    statement, as follows, and while that statement is running, someone updates a row it has yet to read from Y=5 to Y=6
    and commits?
    Update t Set x = 2 Where y = 5;

20. So, why are constraints validated after the SQL statement executes? Why not during? This is because it is very natural for a single statement to make individual rows in a table momentarily inconsistent.
21. we also have the ability to defer constraint checking, which can be quite advantageous for

    various operations. The one that immediately jumps to mind is the requirement to cascade an UPDATE of a primary key to the child keys.
22. Page:290 : the bottom line is, only use deferrable constraints where you have an identified need to use them. They introduce subtle side effects that could cause differences in your physical implementation (non-unique vs. unique indexes) or in your query plans 
23. With the single UPDATE statement, we just reissue the

    UPDATE. We know that it will entirely succeed or entirely fail; there will not be partial work to worry about.
24. My final words on bad transaction habits concern the one that arises from using the popular programming APIs ODBC and JDBC. These APIs “autocommit” by default.
25. Every Oracle database has at least two online redo log groups with at least a single member (redo log file) in each group.
26. Those two things together—that the segment was actually created by the INSERT but not “uncreated” by the ROLLBACK, and that the new formatted blocks created by the INSERT were scanned the second time around—show that a rollback is a logical “put the database back the way it was” operation. The database will not be exactly the way it was, just logically the same.

RMAN Backup status

 

This script will report on all currently running RMAN backups like full, incremental & archivelog backups:

col STATUS format a9

col hrs format 999.99

select SESSION_KEY, INPUT_TYPE, STATUS,

to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,

to_char(END_TIME,'mm/dd/yy hh24:mi') end_time,

elapsed_seconds/3600 hrs from V$RMAN_BACKUP_JOB_DETAILS

order by session_key;

Below script will give you SID, Total Work, Sofar & % of completion.

SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK, 

ROUND (SOFAR/TOTALWORK*100, 2) "% COMPLETE"

FROM V$SESSION_LONGOPS

WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%'

AND TOTALWORK! = 0 AND SOFAR <> TOTALWORK;