一分钟查一个案例带你看看
Oracle
数据库到底有多牛逼
性能难题
问题来了
电话响了,是一位证券客户 DBA 的来电,看来,问题没过两天,又出现了。
接起电话,果不其然。
“小 y,前天那个问题又重现了。重启后恢复正常,这次抓到了
hangAnalyze,不过领导在身后一直催,
所以没来得及抓取 systemstate dump 就重启了。你尽快帮忙分析下吧,hanganalyze 的 trace 文件
”已经转到你邮箱了。
就在 2 天前,该客户找到小
y,
他们有一套比较重要的系统出现了数据库无法登陆的情况,导致业务
中断,重启后业务恢复,但原因未明,搞的他们压力很大。
…可惜的是,他们是事后找过来,由于客户现场保护意识不足,最后也只能是巧妇难为无米之炊了
总的来说,小 y 还算是比较熟悉证券行业的。
毕竟,小
y
多年来一直在银行、证券、航空等客户提供数据库专家支持服务,这其中就包括了北京
排名前 6 的所有证券公司。
简而言之,证券行业的要求就是快速恢复,快速恢复业务大于一切。
原因很简单,股价瞬息万变,作为股民,如果当时无法出售或者购买股票,甚至可能引发官司。所
以,证券核心交易系统如果中断时间超过 5 分钟,则可以算得上是严重故障了,一旦被投诉,则可能会
被证监会通报,届时业务可能被降级,影响到证券公司的经营和收益。
结合这个特点,小 y 为客户制定了应急预案,看来收集 systemstate dump 是来不及了,只能
先 收集 hangAnalyze, 时间来得及的话则可以继续收集 systemstate dump 。收集 hangAnalyze
的命令很简单,照敲就是了,没什么技术含量。
$sqlplus –prelim “/as
sysdba” SQL>oradebug
setmypid SQL>oradebug
hanganalyze 3
.. 此处等上一会 ..
SQL>oradebug hanganalyze 3
SQL>oradebug trace*le_name