Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

1

好友

5

主题
1#
发表于 2013-9-25 16:40:11 | 查看: 4195| 回复: 10
本帖最后由 Alex 于 2013-9-25 16:40 编辑

ML,你好!
有一数据库频繁发生ORA-03113故障:
此时所有的相关应用无论使用sqlplus、JDBC、.net来连接均是此错误(本系统.net的架构应用居多而且均为短连接,即需要时才去连接数据库)。
此时在ORACLE服务器上使用sqlplus 去连接会报如下错误:
ERROR:
ORA-03113: end-of-file on communication channel
Process ID: 0
Session ID: 0 Serial number: 0

但在ORACLE服务端使用"/as sysdba"则可以连接,而且数据库正常可用。故障发生时,lsnrctl service也可以正常返回且监听状态正常。此故障现象持续几分钟后自动恢复正常!

稍后上传最近2次的故障时的采集日志。
第1个 故障时间: 2013-09-23 17:21-26分左右
第2个 故障时间:2013-09-24  09点42-44分左右

目前有2个方面的怀疑:
1、aud审计没有关闭,鉴于应用多为.net为短连接,且连接频繁,此表 目前有2千8百万行记录,不知是否会导致这种错误?
2、通过awr,ash等报告来看,‘row cache lock’等待事件排首位,不知是需要调整share_pool_size 还是 与'Bug 9720182 : DUE TO ROW CACHE LOCK WAIT EVENTS IN DATABASE APPLICATION GOT HUNG' 有无关系 ?

希望ML给点建议方向,谢谢 !

2013.9.23_17点21分.zip

13.6 KB, 下载次数: 799

23日17点21分 发生故障持续4分钟

20130924_09点43分.zip

393.59 KB, 下载次数: 761

24日09点43分 发生故障持续2分钟左右

2#
发表于 2013-9-25 16:42:49
奇怪,发布本贴后,怎么好象看不到

回复 只看该作者 道具 举报

3#
发表于 2013-9-25 17:35:28
补充一下,这个数据库应用特点,也是多个ORACLE数据库间 很多 DB-Link 频繁 访问

回复 只看该作者 道具 举报

4#
发表于 2013-9-25 20:10:03
***********************************************************************

Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
        Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
        Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
  Time: 23-9月 -2013 17:26:04
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
   
TNS-12535: TNS: 操作超时
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=44.4.6.17)(PORT=62991))
WARNING: inbound connection timed out (ORA-3136)
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
   
TNS-12535: TNS: 操作超时
    ns secondary err code: 12606
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=44.4.6.17)(PORT=63040))
WARNING: inbound connection timed out (ORA-3136)
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=44.4.6.17)(PORT=62937))
WARNING: inbound connection timed out (ORA-3136)
Mon Sep 23 17:26:25 2013


***********************************************************************

Fatal NI connect error 12170.

  VERSION INFORMATION:
        TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
        Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
        Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
  Time: 23-9月 -2013 17:26:25
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12535
   
TNS-12535: TNS: 操作超时
    ns secondary err code: 12560
    nt main err code: 505
   
TNS-00505: 操作超时
    nt secondary err code: 60
    nt OS err code: 0
  Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=44.4.1.55)(PORT=60726))


大量网络 TNS错误

强烈怀疑安装没有按照最佳实践来, 同时数据库资源可能各种不足 或者负载高



建议 安装11.2.0.3 并遵照最佳实践来安装

回复 只看该作者 道具 举报

5#
发表于 2013-9-25 20:12:24
PS:此类问题至少给出AWR

回复 只看该作者 道具 举报

6#
发表于 2013-9-25 22:55:33
ML,你好,在第个压缩包里有awr,ash,listener.log ,alert.log 等

回复 只看该作者 道具 举报

7#
发表于 2013-9-25 22:55:55
ML,你好,在第2个压缩包(即第2个故障)里有awr,ash,listener.log ,alert.log 等

回复 只看该作者 道具 举报

8#
发表于 2013-9-25 22:56:42
这个是客户的生产环境,一时半会 还真不能马上去给他升级到11.2.0.3 ,所以才想分析是不是 有其它原因

回复 只看该作者 道具 举报

9#
发表于 2013-9-25 23:09:18
Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
row cache lock        1,579        21,973        13916        66.12        Concurrency
DB CPU                 5,424                 16.32         
db file sequential read        502,684        3,203        6        9.64        User I/O
log file sync        376,955        1,647        4        4.96        Commit
cursor: mutex S        5,823,872        1,117        0        3.36        Concurrency


CPU不高 , 但top event是 row cache lock


Hard parses:         44.8         0.4  硬解析每秒44.8次

时间模型中耗时主要体现在 建立连接和解析上


Statistic Name        Time (s)        % of DB Time
connection management call elapsed time        14,232.51        42.83
parse time elapsed        12,234.81        36.81


shared pool        2,816.00        2,816.00        2,432.00        4,736.00        0        GRO/DEF

shared pool一直有波动



这个库需要做优化, 优化后你之前说的症状可能 减轻 或者消失

回复 只看该作者 道具 举报

10#
发表于 2013-9-25 23:16:30
ALLSTARS_ORACLE,你好,你所说的库需要优化,主要是指应用方面的代码和连接方式等方面么?

回复 只看该作者 道具 举报

11#
发表于 2013-9-26 10:27:03
各位大神,再发表些意见

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2025-1-6 08:29 , Processed in 0.054800 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569