从<<提问的智慧>>引发出对数据库的一套解决方案
rollingpig 的＜＜提问的智慧＞＞已经在论坛发布２年多了，我觉得他的这个文章就是解决数据库的一套完整方法论．
１．遇到问题初期：
当遇到问题的时候，如果有报错代码，我首先到metalink: http://metalink.oracle.com ，查找报错的原因．metalink的内容其实写得很详细．
当遇到有些参数不太理解或者想不起来的时候，我首先会到 online document: http://tahiti.oracle.com 的refenerce里面查找该参数的含义，（我个人认为在安装配置的时候，这个用的多一些）．
有些时候，当遇到语言障碍或者是ＭＥＴＡＬＩＮＫ解释和实际情况不符的时候，我会一下．
备注：在alert log里发现了报错信息或者在运行时发现了报错信息，那么，最 简单的做法就是将错误信息或者错误号先在google/metalink/论坛里搜索 一下。
这里特别提一下Ora-7445/ora-600的错误，是不能单用错误号来搜索的，必须加上后面的相应信息才能找到合适的答案。
ORA-600时，加上后面的argument,Ora-7445时，还需要打开相应的TRACE文件，并截取其中有意义的部分进行搜索。
２．如果判断是Instance 方面的问题，首先查看alerlog.
alert log的位置，多数情况下是$ORACLE_BASE/admin/$ORACLE_SID/bdump底下，当然，确切的说应该是在 db parameter background_dump_dest定义的目录底下。如果没有定义background_dump_dest，或者$ORACLE_HOME/rdbms/log底下。
３．网络的问题：查看 listener.ora ，sqlnet.ora ，并运行lsnrctl status．然后查看client 端的的 tnsnames.ora , sqlnet.ora ,并运行tnsping
４．DB总体性能问题： 在peak time 做 statspack,并查看statspack report。同时检查CPU/MEM配置，以及使用命令查看CPU IDLE/free menory 的情况 ．
备注：１．关于statspack的如何使用,请参考eygle系列文章 (http://www.eygle.com/statspack/statspack_list.htm )
２．如何获得CPU Usage或者Free Mem的信息. unix 下通常可以通过vmstat来获得，以及根据不同的操作系统而定．
５．SQL性能问题，列出当前SQL,以及执行计划。同时应提供表结构，index情况，Table的record数。CBO/RBO,table是否analyze等信息。
备注： 执行计划的获取: 通过 EXPLAIN PLAN FOR
或者通过在sqlplus 里运行set autotrace 的方式来获得……；也可以通过第三方软件获得．
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/8334342/viewspace-408800/ ，如需转载，请注明出处，否则将追究法律责任。
