分类目录归档：Oracle

V$LOCK视图相关知识

发表于 2011 年 8 月 7 日 由 惜分飞

1、V$LOCK视图结构

列名 类型 字段说明
ADDR RAW（4 | 8） Address of lock state object
KADDR RAW（4|8） Address of lock
SID NUMBER 会话的sid，可以和v$session 关联
TYPE VARCHAR2(2) 区分该锁保护对象的类型（表4）
TM – DML enqueue
TX – Transaction enqueue
UL – User supplied
–我们主要关注TX和TM两种类型的锁
–UL锁用户自己定义的，一般很少会定义，基本不用关注
–其它均为系统锁，会很快自动释放，不用关注
ID1
ID2		 NUMBER ID1,ID2的取值含义根据type的取值而有所不同
对于TM 锁
ID1表示被锁定表的object_id 可以和dba_objects视图关联取得具体表信息，ID2 值为0
对于TX 锁
ID1以十进制数值表示该事务所占用的回滚段号和事务槽slot number号,其组形式:
0xRRRRSSSS,RRRR=RBS/UNDO NUMBER,SSSS=SLOT NUMBER
ID2 以十进制数值表示环绕wrap的次数，即事务槽被重用的次数
LMODE NUMBER
  • 0 – none
  • 1 – null (NULL)
  • 2 – row-S (SS)
  • 3 – row-X (SX)
  • 4 – share (S)
  • 5 – S/Row-X (SSX)
  • 6 – exclusive (X)
  • 具体见表3
REQUEST NUMBER 同LMODE
–大于0时，表示当前会话被阻塞，其它会话占有改锁的模式
CTIME NUMBER
  • 已持有或者等待锁的时间
BLOCK NUMBER
  • 是否阻塞其他会话锁申请 1:阻塞 0:不阻塞


2、其它相关视图说明

视图名 描述 主要字段说明
v$session 查询会话的信息和锁的信息。 sid,serial#：表示会话信息。
program：表示会话的应用程序信息。
row_wait_obj#：表示等待的对象,和dba_objects中的object_id相对应。
lockwait :该会话等待的锁的地址,与v$lock的kaddr对应.
v$session_wait 查询等待的会话信息。 sid：表示持有锁的会话信息。
Seconds_in_wait：表示等待持续的时间信息
Event：表示会话等待的事件，锁等于enqueue
dba_locks 对v$lock的格式化视图。 Session_id：和v$lock中的Sid对应。
Lock_type：和v$lock中的type对应。
Lock_ID1： 和v$lock中的ID1对应。
Mode_held,mode_requested：和v$lock中的lmode,request相对应。
v$locked_object 只包含DML的锁信息，包括回滚段和会话信息。 Xidusn,xidslot,xidsqn：表示回滚段信息。和v$transaction相关联。
Object_id：表示被锁对象标识。
Session_id：表示持有锁的会话信息。
Locked_mode：表示会话等待的锁模式的信息，和v$lock中的lmode一致。

表3

锁模式 锁描述 解释 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行级共享锁，其他对象只能查询这些数据行 Select for update
Lock for update
Lock row share
3 SX(Row-X) 行级排它锁,在提交前不允许做DML操作 Insert/update/Delete
Lock row share
4 S(Share) 共享锁 Create index
Lock share
5 SSX(S/Row-X) 共享行级排它锁 Lock share row exclusive
6 X(Exclusive) 排它锁 Alter table
Drop able
Drop index
Truncate table
Lock exclusive

表4

System Type Description System Type Description
BL Buffer hash table instance NA..NZ Library cache pin instance (A..Z = namespace)
CF Control file schema global enqueue PF Password File
CI Cross-instance function invocation instance PI, PS Parallel operation
CU Cursor bind PR Process startup
DF datafile instance QA..QZ Row cache instance (A..Z = cache)
DL Direct loader parallel index create RT Redo thread global enqueue
DM Mount/startup db primary/secondary instance SC System change number instance
DR Distributed recovery process SM SMON
DX Distributed transaction entry SN Sequence number instance
FS File set SQ Sequence number enqueue
HW Space management operations on a specific segment SS Sort segment
IN Instance number ST Space transaction enqueue
IR Instance recovery serialization global enqueue SV Sequence number value
IS Instance state TA Generic enqueue
IV Library cache invalidation instance TS Temporary segment enqueue (ID2=0)
JQ Job queue TS New block allocation enqueue (ID2=1)
KK Thread kick TT Temporary table enqueue
LA .. LP Library cache lock instance lock (A..P = namespace) UN User name
MM Mount definition global enqueue US Undo segment DDL
MR Media recovery WL Being-written redo log instance
发表在 Oracle性能优化 | 3 条评论

Total insert collisions (ogg)

发表于 2011 年 8 月 5 日 由 惜分飞

1、错误现象
Replicating from ECP.TAB_UUM_PACKAGE to RWGL.TAB_UUM_USER:
*** Total statistics since 2011-08-05 10:34:10 ***

Total inserts                               20.00
Total updates                                0.00
Total deletes                                0.00
Total discards                               0.00
Total operations                            20.00
Total insert collisions                     20.00

2、错误原因
RWGL.TAB_UUM_USER表上有insert触发器，导致失败。因为触发器使得插入操作为插入和触发器中的操作绑定为了一个整体，现在因为触发器失败，导致插入失败，而且还会丢失该条插入记录，需要查找出该条记录比较困难。

3、解决方案
采用自治事件结合异常捕获
自治事件使得触发器和插入操作相互分离，异常捕获记录触发器失败的原因，插入到日志表中，通过该表，可以查询查失败的记录，然后人工干预，触发器实例：

create or replace trigger ogg_t
  before insert on t_1
  for each row
declare
   tid NUMBER;
   err VARCHAR2(100);
   PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
  SELECT t.id2 INTO tid FROM t_2 t WHERE NAME=:new.Name;
  INSERT INTO t_3 VALUES(tid,:new.name);
  COMMIT;
EXCEPTION
       WHEN TOO_MANY_ROWS THEN
         INSERT INTO t_error VALUES(:new.id,'TOO_MANY_ROWS');
         COMMIT;
        WHEN NO_DATA_FOUND THEN
           INSERT INTO t_error VALUES(:new.id,'NO_DATA_FOUND');
           COMMIT;
         WHEN OTHERS THEN
           err:=SUBSTR(SQLERRM(SQLCODE),1,100);
           INSERT INTO t_error VALUES(:new.id,err);
           COMMIT;
end ogg_t;

1)PRAGMA AUTONOMOUS_TRANSACTION;
自治事务，就是说触发器不管是成功，还是失败，数据库同步程序都能够同步成功数据到目标端

2)COMMIT;
因为采用了自治事件，所以begin end中的操作是独立与数据库中数据，需要单独提交

3)EXCEPTION
添加异常处理

4)INSERT INTO t_error VALUES(:new.id,’TOO_MANY_ROWS’);（类此语句，注意commit）
建立一张错误日志表（根据具体情况决定），如果触发器失败，把错误记录到该表中，以后出现问题查找很方便（要求：通过该表能够查询到那条语句的触发器执行失败。失败原因，失败时间，额外列（用于确定对应记录））

发表在 GoldenGate | 评论关闭

ORA-01012: not logged on

发表于 2011 年 8 月 4 日 由 惜分飞

今天接到现场反馈，数据库出现ORA-01012: not logged on错误提示，这个问题上次也出现过一次，当时按照网上说的方法，直接重启数据库了，问题解决了，同时也导致因为数据库重启，现场破坏，而alert日志中无任何异常信息，所以不知从何处下手分析。这次我上数据库准备查看时，发现数据库已经正常，监控也显示正常，说明数据库已经恢复正常。从此我推理这个问题应该是外部因素导致，而不是数据库本身的bug，从而决定要找出该问题的原因来。有个重要的因素，该数据库是我几个月前因为undo损坏做过恢复的，查看相关参数，发现processes是默认值150，是不是该值导致的不敢肯定，因为一般process超了会报ORA-00020错误，而这次只有ORA-01012。但是心中还是没有底，总感觉这个的可能性最大，于是想通过试验来证实下自己的想法
1、数据库版本（10g结果相同）
SQL> select * from v$version where rownum=1;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production

2、创建pfile，修改processes，重启数据库，查看processes值
SQL> select name,value from v$parameter where name=’processes’;

NAME VALUE
——————– ——————–
processes 30

3、查看系统processes数量
SQL> select count(*) from v$process;

COUNT(*)
———-
13

4、添加数据库连接数（为了增加process数目）
[oracle@localhost ~]$ sqlplus chf/xifenfei

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:11:50 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 – Production

SQL> !

5、重复3和4，发现当process数量为29时出现激动人心一幕
5.1)继续访问数据库
[oracle@localhost ~]$ sqlplus system/xifenfei

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:12:06 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

ERROR:
ORA-00020: maximum number of processes (%s) exceeded

Enter user-name:

5.2)使用其他用户访问
[oracle@localhost ~]$ sqlplus /nolog

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:12:49 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> conn / as sysdba
Connected to an idle instance.
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-01012: not logged on

SQL> conn chf/xifenfei
ERROR:
ORA-00020: maximum number of processes (%s) exceeded

[oracle@localhost ~]$ sqlplus “/ as sysdba”

SQL*Plus: Release 9.2.0.4.0 – Production on Wed Jul 27 23:29:52 2011

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected.
SQL> select * from dual;
select * from dual
*
ERROR at line 1:
ORA-01012: not logged on
现象说明：
1)终于发现了ORA-01012错误，期待了很久。发现只有当sys登录系统，对数据库进行查询或者操作之时才会出现ORA-01012，其他用户只要一登录数据库就会提示ORA-00020错误。

2)当process达到数据库最大限时，sysdba登录系统是也显示不正常
2.1）当使用sqlplus “/ as sysdba”登录时，缺少：
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 – Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 – Production
2.2）当使用conn / as sysdba登录时，提示为：
Connected to an idle instance.

发表在 ORA-xxxxx | 标签为 | 2 条评论