15. AWR/STATSPACK性能分析SQL语句检查：
SQL ORDER BY GETS列出消耗CPU较高的SQL语句。其中第一条语句在数据库操作中消耗的时间最多，这条语句可以用于检查和优化以得到更好的性能。
对于统计时段中消耗CPU较高的SQL语句，可以对上述语句进行执行计划的分析，看有无优化的可能。如有无用到高效的索引，是否使用了外部变量。
较高的buffer get并不会导致高I/O，因为资料都被存在数据库缓冲区中；但是较高的buffer get会导致高CPU和系统资源被使用以得到资料。因此，一条优化好的SQL语句应该取出较少的buffer，从而减少系统资源的使用
16. 数据库极端情况处理 hanganalyzeDump hanganalyze by ORADEBUG
SQL>select * from dual; /* 在某些情况下，任何SQL语句都无法正常完成，此时，终止语句，重新登录，并跳过此步骤 */
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug hanganalyze
(only for RAC)
SQL> oradebug setinst all
SQL> oradebug -g def hanganalyze
17. 数据库极端情况处理 hanganalyze(续)LEVEL
10 Dump all processes (IGN state)
5 Level 4 + Dump all processes involved in wait chains (NLEAF state)
4 Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state)
3 Level 2 + Dump only processes thought to be in a hang (IN_HANG state)
1-2 Only HANGANALYZE output, no process dump at all
18. 数据库极端情况处理 systemstateDump systemstate by ORADEBUG
SQL>select * from dual; /* 在某些情况下，任何SQL语句都无法正常完成，此时，终止语句，重新登录，并跳过此步骤 */
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug dump systemstate 10
Level 1 - Very basic process information only
Level 10 - Most common level - includes state object trees
Level + 256 - Adding 256 to the level will try to dump short stack info for each process
19. 数据库极端情况处理 紧急状况下的信息收集HANGANALYZE应进行多次，间隔90s，重新登录（/as sysdba），推荐level 3
SYSTEMSTATE DUMP应进行多次，间隔90s，重新登录（/as sysdba），推荐level 266(9.2.0.6以上）
FOR RAC
'immediate trace name locks level 10
'immediate trace name row_cache level 10'
35. 模型设计 同义词
对于只读用户，建议创建与对象名字的同义词。
DB Link
容易导致分布式事物的多种故障，不建议使用。
Sequence
需要针对变化较大的sequence设置cache
对于RAC系统，sequence 的nocache可能会带来较大的性能影响
根据业务特点设置sequence的最大值或循环使用
对于RAC系统，sys.audses$（审计会话用， sessionid from this sequence），sys.idgen1$（在存在大量的LOB对象时，需要将该值调大）两个sequence的cache值调整为10000或者更高，特别是短连接且logon频率高的系统更需要调整
