当然这里是从statspack搜集的stats$sqltext中去找的(你可以在statspack的文本报告中去找)，实际上，我们可以直接在当前数据库中的v$sqlarea或者v$sqltext里面去找到这些sql，然后来尝试优化。

    select sql_text
    from v$sqltext a,
    (select distinct a.owner,a.segment_name,a.segment_type from
    dba_extents a,
    (select dbarfil,dbablk
    from (select dbarfil,dbablk
    from x$bh order by tch desc) where rownum < 11) b
    where a.RELATIVE_FNO = b.dbarfil
    and a.BLOCK_ID <= b.dbablk and a.block_id + a.blocks > b.dbablk) b
    where a.sql_text like '%'||b.segment_name||'%' and b.segment_type = 'TABLE'
    order by a.hash_value,a.address,a.piece;
    SQL_TEXT
    ----------------------------------------------------------------
    SELECT NULL FROM DUAL FOR UPDATE NOWAIT
    SELECT SEQ_SMS_TRANSACTION.nextval FROM DUAL
    SELECT SEQ_BIZ_EXPRESS.nextval FROM DUAL
    SELECT SEQ_IM_GROUP.nextval FROM DUAL
    SELECT SEQ_SAMPLE.nextval FROM DUAL
    ='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='
    SELECT SEQ_BIZ_SEARCHER.nextval FROM DUAL
    SELECT SEQ_OFFER_DRAFT.nextval FROM DUAL
    SELECT SEQ_SAMPLE_GROUP.nextval FROM DUAL
    DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRENCY='$' NLS_COMP='BI
    SELECT SEQ_CMNTY_USER_MESSAGE.nextval FROM DUAL
    SELECT SYSDATE FROM DUAL
    SELECT SEQ_SMS_USER.nextval FROM DUAL
    IMESTAMP_TZ_FORMAT='DD-MON-RR HH.MI.SSXFF AM TZR' NLS_DUAL_CURRE
    SELECT SEQ_COMPANY_DRAFT.nextval FROM DUAL
    SELECT 1 FROM DUAL
    SELECT USER FROM DUAL
    SELECT DECODE('A','A','1','2') FROM DUAL

    18 rows selected.

    除了优化sql外，当然对于热点的表或者索引来说，如果小的话，我们可以考虑cache在内存中，这样可能降低物理读提高sql运行速度(这并不会减少cache buffer chains的访问次数)，对于序列，我们可以对序列多设置一些cache。如果是并行服务器环境中的索引对象，并且这个索引是系列递增类型，我们可以考虑反向索引(关于反向索引这里就不过多地做介绍了)。

    热点块的其他相关症状

    在数据库中还可能存在一些其他方面的热点块症状，通过v$waitstat的等待可以看出一些端倪,v$waitstat是根据数据缓冲区中各种block的类型(x$bh.class)而分类统计的等待状况。

    select">sys@OCN>select * from v$waitstat;

    CLASS COUNT TIME
    ------------------ ---------- ----------
    data block 1726977 452542
    sort block 0 0
    save undo block 0 0
    segment header 40 11
    save undo header 0 0
    free list 0 0
    extent map 0 0
    1st level bmb 611 112
    2nd level bmb 42 13
    3rd level bmb 0 0
    bitmap block 0 0
    bitmap index block 0 0
    file header block 13 92
    unused 0 0
    system undo header 111 28
    system undo block 7 0
    undo header 2765 187
    undo block 633 156

    比如在ASSM表空间出现之前，由于freelist的存在，如果表经常被并发的进程DML，则可能存在大量的data block的等待，或者有free list的等待。那么这个时候我们发现这样的segment之后需要考虑增加freelist数量。再比如经常发生长时间的DML的表被频繁地访问，这样将会造成过多的对回滚段中块的访问，这时可能undo block 的等待会比较多。那么我们可能需要控制DML的时间长度或者想办法从应用程序入手来解决问题。如果是undo header的等待比较多，没使用undo tablespace 之前，可能需要考虑增加回滚段的数量。

    总结

    本文从热点块的原理入手，详细地由oracle的内部结构特征开始介绍了热点块的产生和表现特征。进而阐述了诊断热点对象和找出造成热点对象的sql的方法。并从解决热点问题方面提供了解决方向。