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

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

158

积分

1

好友

8

主题
1#
发表于 2012-4-1 11:09:52 | 查看: 11142| 回复: 8
环境:rac节点1
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle/product/oracle10g/10.2.0/db
System name:    HP-UX
Node name:      ynods1
Release:        B.11.31
Version:        U
Machine:        ia64
Instance name: odsdb1
Redo thread mounted by this instance: 1
Oracle process number: 103

节点2类似;


描述:
现象一:
系统有的时候不能创建create table as select * from dual;
有记录的表不能建立,空表倒是能够建立。
现象2;
跑报表的时候,很慢,感觉hang住;


用下面语句查询
要了解哪些数据库用户的会话锁定了对象、锁定的模式是什么、对应的操作系统用户是在哪台计算机上进行操作的、被锁定的对象及其类型等信息
-------------------------------------------------------------------------------------------------------
select s.username,
       s.sid,
       s.serial#,
       decode(lo.locked_mode,
              0,
              'none',
              1,
              'null',
              2,
              'row-s(ss)',
              3,
              'row-x(sx)',
              4,
              'share',
              5,
              's/row-x(ssx)',
              6,
              'exclusive',
              to_char(lo.locked_mode)) mode_locked,
       lo.os_user_name,
       do.object_name,
       do.object_type
  from v$session s, v$locked_object lo, dba_objects do
where lo.object_id = do.object_id
   and s.sid = lo.session_id;


USERNAME                              SID    SERIAL# MODE_LOCKED                              OS_USER_NAME                   OBJECT_NAME                                                                                                                      OBJECT_TYPE
------------------------------ ---------- ---------- ---------------------------------------- ------------------------------ -------------------------------------------------------------------------------------------------------------------------------- ------------------
STATRPT                                36      28416 row-x(sx)                                statrpt                        OBJ$                                                                                                                             TABLE
STATRPT                                36      28416 share                                    statrpt                        BK_PAYMENT_03   




现在我只能看到单纯OBJ$是18号对象,被锁住了。type是table。
接下来请问该怎么进一步分析啊?
2#
发表于 2012-4-1 20:07:18
locked_mode=3 是 Sub-exclusive(SX)  

这只说明有进程可能在更新OBJ$表, SX锁一般不会阻塞其他session的递归SQL更新或查询OBJ$

问题在于为什么会有 进程长期持有 SX锁, 建议你上传当时的AWR来分析

回复 只看该作者 道具 举报

3#
发表于 2012-4-16 18:32:08

案例重现,帮忙看看,抓到awr了

描述:v$obj被锁住,今早我检查的时候发现,我就等着抓awr,没有杀session。
我发现的时候大概10点半左右,由于我们的库抓awr是一个小时抓一次,不是半个小时,所以我只有等。

我一直在此期间检查,发现v$obj一直锁到了11点过几分才解锁,我本来打算抓到awr如果还不释放就kill。
没想过11点几分就自己解锁了。
帮我看看awr,我看到的是浅层次的:

top 5

EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Class
CPU time 11,428 34.0
db file scattered read1,118,2687,349721.9User I/O
PX Deq Credit: send blkd193,9837,3473821.9Other
cursor: pin S wait on X178,1253,4681910.3Concurrency
db file sequential read460,2202,89668.6User I/O





水平有限,希望刘大帮忙看看,我该从哪些地方开始下手??

mrq_obj_awr-ods1.html (1.54 MB, 下载次数: 827) --节点1的awr
mrq_obj-awr-ods2.html (1.51 MB, 下载次数: 762) --节点2 的awr

回复 只看该作者 道具 举报

4#
发表于 2012-4-18 10:53:42

回复 2# 的帖子

帮我查看一下啊,我更新了,实在不解为什么会有进程长期锁住V$OBJ

回复 只看该作者 道具 举报

5#
发表于 2012-4-18 12:22:53
enq: TM - contention         21         0.00         0         8         0.00


Segments by Row Lock Waits

    % of Capture shows % of row lock waits for each top segment compared
    with total row lock waits for all segments captured by the Snapshot

Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Row Lock Waits        % of Capture
ODS         TBS_ODS_DATA         SERV         P_KM         TABLE PARTITION         6,356         88.65
ODS         TBS_ODS_DATA         SERV         P_WS         TABLE PARTITION         94         1.31
ODS         TBS_ODS_DATA         SERV         P_QJ         TABLE PARTITION         78         1.09
ODS         TBS_ODS_DATA         SERV         P_HH         TABLE PARTITION         74         1.03
ODS         TBS_ODS_IDX         IDX_SERV_ETL_TIME         P_KM         INDEX PARTITION         58         0.81


enq: TM - contention         4,994         0.00         2         0         0.06


Segments by Row Lock Waits

    % of Capture shows % of row lock waits for each top segment compared
    with total row lock waits for all segments captured by the Snapshot

Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Row Lock Waits        % of Capture
DSG         TBS_DSG_INDEX         IDX_C_BUSI_ORDER                   INDEX         126         6.66
DSG_CRM         TBS_DSG_INDEX         IDX_ATOM_ACTION_OLID                   INDEX         106         5.60
** UNAVAILABLE **         ** UNAVAILABLE **         ** UNAVAILABLE **         AILABLE **         UNDEFINED         103         5.44
** UNAVAILABLE **         ** UNAVAILABLE **         ** UNAVAILABLE **         AILABLE **         UNDEFINED         93         4.92
DSG         TBS_DSG_INDEX         IDX_I_IN_C_OO_ROLE_BO_ID                   INDEX         86         4.55





就AWR看  enq: TM - contention 表锁争用的等待时间很少,  主要的Row Lock Waits 行锁 也和 obj$没有关系,  不知道你为什么那么关注 obj$ 上的 Sub-exclusive(SX)   , SX 即不 block DML也不 block 查询 , 不是性能的瓶颈所在。

回复 只看该作者 道具 举报

6#
发表于 2012-4-19 15:02:51

哦,谢谢啦

哦,原来不是性能瓶颈啊,我就是以为之前发生的和这个v$obj有关,看来 我定位问题还是不行,那我在继续研究研究,努力学习,谢谢你啦。

回复 只看该作者 道具 举报

7#
发表于 2012-4-19 16:43:12
看来我们分析的时候 有时候抓小放大了 不断提高

回复 只看该作者 道具 举报

8#
发表于 2012-4-19 16:44:34
奇怪 下载个附件 就没金钱了  还收费?

回复 只看该作者 道具 举报

9#
发表于 2012-5-9 14:07:32
我也一样奇怪 下载个附件 就没金钱了  还收费?

回复 只看该作者 道具 举报

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

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

GMT+8, 2024-11-15 15:01 , Processed in 0.054937 second(s), 24 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

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