oracle数据块如何定位到ASM中?在exadata定位block的思路是什么?

前几天有个朋友提出一个“老问题”,数据库上的block能否对应到EXADATA的block上,我答应做个demo,一直没时间,今天闲了,玩了一下:
对于EXADATA来说,这个需求设计两个问题:
1,数据库的block如何对应到asm中
2,exadata上的block如何对应到cell上的物理盘(griddisk,celldisk都是逻辑概念)

首先创建测试表:
create table lunartest as select * from dba_users;
–查找里面用户名为LUNAR的ROWID:

SQL> select username , rowid from lunartest where username='LUNAR';

USERNAME                       ROWID
------------------------------ ------------------
LUNAR                          AABCFqAABAAArF6AAW

记录一下这个表的username=’LUNAR’的数据的rowid,便于验证数据。

然后找到该表的第一个block,也就是segment header,方法至少有3种
1,通过dbms_rowid
2,通过dba_extents
3,通过dba_segments

这里我们随便选一种,找到了该block的位置:

select EXTENT_ID, BLOCK_ID, BLOCKS, FILE_ID from dba_extents where SEGMENT_NAME='LUNARTEST';

 EXTENT_ID   BLOCK_ID     BLOCKS    FILE_ID
---------- ---------- ---------- ----------
         0     176505          8          1

查看当前ASM的AU尺寸和BLOCK尺寸(通常是缺省的,不排除特殊客户自己设定的或者exadata的情况,因此还是找一下):

[grid@lunar ~]$ kfed read /dev/lunarlun02 ausz=1m aun=0 blkn=0|grep ausize   ----1M的AU(一般都是缺省是1M,exadata缺省是4M)
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
[grid@lunar ~]$ kfed read /dev/lunarlun02 ausz=1m aun=0 blkn=0|grep blksize   ----4k的ASM BLOCK(缺省值)
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
[grid@lunar ~]$ kfed read /dev/lunarlun02 ausz=1m aun=0 blkn=0|grep secsize  -----扇区512bytes(缺省值)
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
[grid@lunar ~]$ 

exadata上使用KEFED的例子可以参考《Exadata上验证ASM磁盘头备份的位置》
我的数据库为8k的数据块(db_block_size),那么计算一下对应到ASM是哪一个extent:

19:44:11 SQL> SELECT (176506*8192/1024)/1024 MB FROM DUAL;

        MB
----------
1378.95313

Elapsed: 00:00:00.00
19:44:23 SQL> 

lunartest表在DATA DG的asm file 1755上:

SQL> select file#,ts#,name from v$datafile WHERE FILE#=1 ;
     FILE#        TS#
---------- ----------
NAME
--------------------------------------------------------------------------------
         1          0
+DATA/lunar/datafile/lunar.1755.8764800657

SQL> 

如果是exadata,那么输出类似下面的,这里并没有本质区别(区别在通信方式上,后面会讲……):

TABLESPACE_NAME FILE_NAME
--------------- ------------------------------------------------------------------------------------------
SYSTEM          +DATA_DM01/lunar/datafile/system.264.764800657
SYSAUX          +DATA_DM01/lunar/datafile/sysaux.272.764800659
UNDOTBS1        +DATA_DM01/lunar/datafile/undotbs1.271.764800661
UNDOTBS2        +DATA_DM01/lunar/datafile/undotbs2.259.764800671
USERS           +DATA_DM01/lunar/datafile/users.267.764800667

根据上面的计算,查找这个表的第一个数据块在哪一个ASM的diskgroup,disk和AU的信息:

select x.GROUP_KFFXP ,x.XNUM_KFFXP ,x.DISK_KFFXP, 
   x.AU_KFFXP, d.path,a.name
from x$kffxp x, v$asm_alias a, v$asm_disk d
where x.number_kffxp=a.file_number
and x.DISK_KFFXP=d.disk_number
and x.GROUP_KFFXP=d.GROUP_NUMBER
and x.GROUP_KFFXP=a.GROUP_NUMBER
and a.name = 'lunar.1755.8764800657'   
AND x.xnum_kffxp=1378

    GROPU# XNUM_KFFXP DISK_KFFXP   AU_KFFXP
---------- ---------- ----------- ----------
PATH
------------------------------------------------------------------------------------------------------------------------------------------------------
NAME
------------------------------
         2       1378           4    1000601
/dev/lunarlun02
lunar.1755.8764800657

如果是exadata环境,那么查询到的信息,对应到这里的/dev/lunarlun02可能就是类似下面的:o/192.168.10.3/DATA_DM01_CD_00_dm01cel01:
这里也就对应到cell01(IP为:192.168.10.3)
具体例子可以参考:Exadata更换硬盘的操作过程和解释

NAME            PATH                                                    STATE    TYPE   FAILGROUP
--------------- ------------------------------------------------------- -------- ------ ---------------
DATA_DM01       o/192.168.10.3/DATA_DM01_CD_00_dm01cel01                NORMAL   NORMAL DM01CEL01
这里DATA_DM01_CD_00_dm01cel01就是cell01上的griddisk的名字(griddisk是逻辑的概念,经过了exadata划盘时的横切和纵切两种操作,具体介绍exadata磁盘的信息请参考《<a href="http://www.lunar2013.com/?p=897" title="Exadata的数据保护机制(冗余机制)- 1">Exadata的数据保护机制(冗余机制)- 1</a>》)。

file 1,block 176506在磁盘上的物理offset:
SQL> select (1000601.95313*1048576)/8192  from dual;

(1000601.95313*1048576)/8192
----------------------------
                   128077050

SQL> 

使用dd

[grid@lunar ~]$ dd if=/dev/lunarlun02 of=lunartest_1_176505_1.dmp bs=8k skip=128077050 count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.00459904 s, 1.8 MB/s
[grid@lunar ~]$ 

我们用dd验证一下数据,:

SQL> select username , rowid from lunartest where username='LUNAR';

USERNAME                       ROWID
------------------------------ ------------------
LUNAR                          AABCFqAABAAArF6AAW
SQL>

SQL> L
  1* select * from lunartest where username='LUNAR'
SQL> /

USERNAME                          USER_ID PASSWORD                       ACCOUNT_STATUS                   LOCK_DATE EXPIRY_DA DEFAULT_TABLESPACE             TEMPORARY_TABLESPACE          CREATED
------------------------------ ---------- ------------------------------ -------------------------------- --------- --------- ------------------------------ ------------------------------ ---------
PROFILE                        INITIAL_RSRC_CONSUMER_GROUP
------------------------------ ------------------------------
EXTERNAL_NAME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PASSWORD E AUTHENTI
-------- - --------
LUNAR                                 125                                OPEN                                                 USERS                          TEMP         11-SEP-14
DEFAULT                        DEFAULT_CONSUMER_GROUP

10G 11G  N PASSWORD


SQL> 


验证数据:这个LUNARTEST是根据DBA_USERS做的CTAS,因此上面我们有一行测试数据,这里可以找到:

[grid@lunar ~]$ strings lunartest_1_176505_1.dmp |grep LUNAR
LUNAR
[grid@lunar ~]$

因为是别人的生产库,不能使用bbed等工具瞎折腾,因此,我这里使用UltraEdit查看这个块来验证数据:

SQL> SELECT utl_raw.cast_to_raw('LUNAR') FROM dual;

UTL_RAW.CAST_TO_RAW('LUNAR')
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4C554E4152

SQL> 

1


可以看到数据是吻合的。至此,上面将oracle的block对应到ASM是没问题的。

另外,如果要想观察asm的具体操作,还可以使用strace,比如
read64(15, “#\242\0\0\33\0@\2\343\332\177\303s\5\1\4\211\330\0\0\0″…, 8192, 473128960) = 8192
表示每个读取操作以8k(oracle block)的进行读取的偏移量是473128960(451 MB + 27*8KB)
读取的文件FD是15
然后使用ls /proc/30094/fd 就可以找到具体的文件设备名称了,比如上面的/dev/lunarlun02(v$asm_disk.path)

但是要想定位EXADATA,就没那么简单了,因为exadata的cell的盘是做了横切的条带划的(还至少normal冗余,更增加难度……)

其通讯方式跟普通的ASM也不同,参考:在Exadata上,为什么 DUL 和 ODU不能读取ASM数据库的数据,但是Kfed却可以?Exadata读取数据和传统数据库环境中读取数据的方式有什么关键区别?

但是,如果真的想找到,猜测需要使用strace 定位,应该可以:

11771      0.013455 times({tms_utime=210862, tms_stime=79333, tms_cutime=0, tms_cstime=0}) = 2144885203
11771      0.000143 setsockopt(34, 0x114 /* SOL_?? */, 2, "\0\340f\3\10\0\0\0\0 \0\0\0\0\0\0008\22U\35\0\0\0\0\t\0\0\0\0\0\0\0", 32) = 0
11771      0.000067 sendmsg(32, {msg_name(16)={sa_family=AF_INET, sin_port=htons(50020), sin_addr=inet_addr("192.168.10.3")}, msg_iov(5)=[{"\4\3\2\1~\266\276\346\3\0\0\0MRON\4\3\0\0\0\0\0\0S\355\203>:p\353\n"..., 76}, {"\2+.j.j\0\0\30\1\0\0\230\0\0\0\0 \0\0\0\0\0\0\1\0\0\0", 28}, {"\4\3\2\1\2N\205\0\250\326ew\0\0\0\0S\355\203>\373-\0\0\0\0\1\0\261\32\244\367"..., 64}, {"\4\3\2\1\2\216\264\0\33\27\2\260\0\0\0\0S\355\203>\373-\0\0\0\0\1\0\262\32\244\367"..., 64}, {"\4\3\2\0013\5\230\234\35\0\0\0\0\0\1\0\0 \0\0\0\0\0\0\267\366\0\0\5\0\0\0"..., 152}], msg_controllen=0, msg_flags=0}, 0) = 384
11771      0.000107 setsockopt(34, 0x114 /* SOL_?? */, 2, "\0\340f\3\10\0\0\0\0 \0\0\0\0\0\0\300\203T\35\0\0\0\0\t\0\0\0\0\0\0\0", 32) = 0
11771      0.000039 sendmsg(32, {msg_name(16)={sa_family=AF_INET, sin_port=htons(24635), sin_addr=inet_addr("192.168.10.5")}, msg_iov(5)=[{"\4\3\2\1~\266\276\346\3\0\0\0MRON\4\3\0\0\0\0\0\0S\355\203>1p\353\n"..., 76}, {"\2+\200\370\200\370\0\0\30\1\0\0\230\0\0\0\0 \0\0\0\0\0\0\1\0\0\0", 28}, {"\4\3\2\1\2N%\0\346\"\200L\0\0\0\0S\355\203>\373-\0\0\0\0\1\0\263\32\243\367"..., 64}, {"\4\3\2\1\2\216\3\0007\245\0p\0\0\0\0S\355\203>\373-\0\0\0\0\1\0\264\32\243\367"..., 64}, {"\4\3\2\1\226()\234\34\0\0\0\0\0\1\0\0 \0\0\0\0\0\0\270\366\0\0\5\0\0\0"..., 152}], msg_controllen=0, msg_flags=0}, 0) = 384
11771      0.000119 poll([{fd=33, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=32, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}, {fd=34, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 3, 1000) = 1 ([{fd=34, revents=POLLIN|POLLRDNORM}])
11771      0.000067 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(9621), sin_addr=inet_addr("192.168.10.3")}, msg_iov(2)=[{"\4\3\2\1\30\215\302\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\220\360\224\23\0\0\0\0"..., 76}, {"\2 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0", 28}], msg_controllen=0, msg_flags=0}, MSG_PEEK) = 104
11771      0.000051 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(9621), sin_addr=inet_addr("192.168.10.3")}, msg_iov(2)=[{"\4\3\2\1\30\215\302\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\220\360\224\23\0\0\0\0"..., 76}, {"\2 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0", 28}], msg_controllen=0, msg_flags=0}, 0) = 104
11771      0.000050 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(45218), sin_addr=inet_addr("192.168.10.5")}, msg_iov(2)=[{"\4\3\2\1x\251\302\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\275\243\352f\0\0\0\0"..., 76}, {"\2 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0", 28}], msg_controllen=0, msg_flags=0}, MSG_PEEK) = 104
11771      0.000046 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(45218), sin_addr=inet_addr("192.168.10.5")}, msg_iov(2)=[{"\4\3\2\1x\251\302\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\275\243\352f\0\0\0\0"..., 76}, {"\2 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0", 28}], msg_controllen=0, msg_flags=0}, 0) = 104
11771      0.000045 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(56555), sin_addr=inet_addr("192.168.10.3")}, msg_iov(2)=[{"\4\3\2\1w\0\267\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\346=\213\26x:1\2"..., 76}, {"\2\4\335\24\335\24\0\0\230\0\0\0\0\0\0\0\0\0\0\0\230\0\0\0\1\0\0\0", 28}], msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK) = 104
11771      0.000063 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(56555), sin_addr=inet_addr("192.168.10.3")}, msg_iov(3)=[{"\4\3\2\1w\0\267\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\346=\213\26x:1\2"..., 76}, {"\2\4\335\24\335\24\0\0\230\0\0\0\0\0\0\0\0\0\0\0\230\0\0\0\1\0\0\0", 28}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\267\366\210\0\0\0"..., 152}], msg_controllen=0, msg_flags=0}, 0) = 256
11771      0.000055 setsockopt(34, 0x114 /* SOL_?? */, 3, "\33\27\2\260\0\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)
11771      0.000034 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(8045), sin_addr=inet_addr("192.168.10.5")}, msg_iov(2)=[{"\4\3\2\1}\0\267\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\324G\26\\\341\223\253-"..., 76}, {"\2\4\203\253\203\253\0\0\230\0\0\0\0\0\0\0\0\0\0\0\230\0\0\0\1\0\0\0", 28}], msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK) = 104
11771      0.000047 recvmsg(34, {msg_name(16)={sa_family=AF_INET, sin_port=htons(8045), sin_addr=inet_addr("192.168.10.5")}, msg_iov(3)=[{"\4\3\2\1}\0\267\376\3\0\0\0MRON\4\3\0\0\0\0\0\0\324G\26\\\341\223\253-"..., 76}, {"\2\4\203\253\203\253\0\0\230\0\0\0\0\0\0\0\0\0\0\0\230\0\0\0\1\0\0\0", 28}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\270\366\210\0\0\0"..., 152}], msg_controllen=0, msg_flags=0}, 0) = 256
11771      0.000053 setsockopt(34, 0x114 /* SOL_?? */, 3, "7\245\0p\0\0\0\0\0\0\0\0\0\0\0\0", 16) = -1 EINVAL (Invalid argument)
11771      0.000028 recvmsg(34, 0x7fff78c93bb0, MSG_PEEK) = -1 EAGAIN (Resource temporarily unavailable)
11771      0.000083 times({tms_utime=210862, tms_stime=79333, tms_cutime=0, tms_cstime=0}) = 2144885203
11771      0.000037 times({tms_utime=210862, tms_stime=79333, tms_cutime=0, tms_cstime=0}) = 2144885203

这个估计懂C语言,知道recvmsg,sendmsg,setsockopt等操作的程序猿可以解开这个迷,O(∩_∩)O哈哈~

下面从网上找到些recvmsg与sendmsg的介绍,诚然,recvmsg和sendmsg功能更为强大,当然用起来也更为复杂。
我已经看得快睡着了,晚安,杭州……

#include “sys/socket.h”

ssize_t recvmsg(int sockfd, struct msghdr * msg, int flags);
ssize_t sendmsg(int sockfd, struct msghdr * msg, int flags);
成功时候返回读写字节数,出错时候返回-1.

这2个函数只用于套接口,不能用于普通的I/O读写,参数sockfd则是指明要读写的套接口。
flags用于传入控制信息,一般包括以下几个
MSG_DONTROUTE send可用
MSG_DONWAIT send与recv都可用
MSG_PEEK recv可用
MSG_WAITALL recv可用
MSG_OOB send可用
MSG_EOR send recv可用

返回信息都记录在struct msghdr * msg中。
struct msghdr {
void * msg_name;//协议地址和套接口信息,在非连接的UDP中,发送者要指定对方地址端口,接受方用于的到数据来源,如果不需要的话可以设置为NULL(在TCP或者连接的UDP中,一般设置为NULL)。
socklen_t msg_namelen;//上面的长度
struct lovec * msg_lov;
ssize_t msg_lovlen;//和readv和writev一样
void * msg_control;
socklen_t msg_controllen;
int msg_flags; //用于返回之前flags的控制信息
}

样例1,在TCP中使用 sendmsg与recvmsg

服务器
……

#define MAXSIZE 100

int main(int argc, char ** argu) {
…….
struct msghdr msg;//初始化struct msghdr
msg.msg_name = NULL; //在tcp中,可以设置为NULL
struct iovec io;//初始化返回数据
io.iov_base = buf; //只用了一个缓冲区
io.iov_len = MAXSIZE; //定义返回数据长度
msg.msg_iov = &io;
msg.msg_iovlen = 1;//只用了一个缓冲区,所以长度为1

……………….
ssize_t recv_size = recvmsg(connfd, &msg, 0);
char * temp = msg.msg_iov[0].iov_base;//获取得到的数据
temp[recv_size] = ‘\0’;//为数据末尾添加结束符
printf(“get message:%s”, temp);
……………………..
}

客户端
………………
#define MAXSIZE 100

int main(int argc, char ** argv) {
……………..
struct msghdr msg;//初始化发送信息
msg.msg_name = NULL;
struct iovec io;
io.iov_base = send_buff;
io.iov_len = sizeof(send_buff);
msg.msg_iov = &io;
msg.msg_iovlen = 1;

if(argc != 2) {
printf(“please input port”);
exit(1);
}
…………
ssize_t size = sendmsg(sockfd, &msg, 0);
close(sockfd);
exit(0);
}

发表在 ASM, 内部机制 | 标签为 , , | 留下评论

insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作
insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况

####################################################################################
总结2 :
1,当存在pk时,无论有没有子表,对存在pk的表来说,无论有没有子表,update pk的操作会同时阻塞对该表做insert操作中那些pk跟update语句更改前、后两个值相关的会话。
2,当子表无事务时,我下面的简单的测试情况下(其他复杂情况没有测试)跟上述第一点结果相同
####################################################################################

测试6: 在测试5的基础上,测试一下子表无事务的情况下,对父表的update是如何影响父表的delete和insert的
首先,我们在Session 4(SID 116)对做commit,此时session 2(SID 220)会自动解锁,并报出来应有的违反约束的错误ORA-02292:
Session 4:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> INSERT INTO DEPT VALUES (2,'LUNAR');

1 row created.

SQL> commit;

Commit complete.

SQL> 

Session 2:
SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       220

SQL> delete from dept where deptno = 1;
delete from dept where deptno = 1
*
ERROR at line 1:
ORA-02292: integrity constraint (LUNAR.FK_DEPTNO) violated - child record found


SQL> 

现在,我们把所有的会话都做commit或者rollback,然后观察对父表的updae会不会对父表的其他DML操作有影响:
Session 2(SID 220):

SQL> select * from dept;

    DEPTNO DNAME
---------- ----------
         1 COSTCENTER
         5 baobao
         2 LUNAR

SQL> update dept set deptno =3 WHERE DEPTNO=2;

1 row updated.

SQL> 

Session 4(SID 116):
SQL> DELETE FROM DEPT WHERE DEPTNO=1;
DELETE FROM DEPT WHERE DEPTNO=1
*
ERROR at line 1:
ORA-02292: integrity constraint (LUNAR.FK_DEPTNO) violated - child record found


SQL> 

Session 5(SID 222):
SQL> INSERT INTO DEPT VALUES (3,'BAOBAO');
....HANG.....

Session 3观察:
       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       220 TM    1062788          0          3          0          0
       220 TX    1310742      42714          6          0          1
       222 TM    1062788          0          3          0          0
       222 TM    1062790          0          3          0          0
       222 TX    1310742      42714          0          4          0
       222 TX    1507340      34195          6          0          0


SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12766                           222      49879 ACTIVE
INSERT INTO DEPT VALUES (3,'BAOBAO')
9pmgcjs6qd7sa enq: TX - row lock contention                                    ACTIVE

这里看见session 4对父表的delete不受session 2在父表的update的影响,而session 5对父表的insert 会被session 2在父表的update阻塞
被阻塞的对父表的insert操作等待事件为:enq: TX – row lock contention

在测试一次:
把上面所有会话都commit或者rollback,然后:

Session 2(SID 220):

SQL> select * from dept;

    DEPTNO DNAME
---------- ----------
         1 COSTCENTER
         5 baobao
         2 LUNAR

SQL> update dept set deptno =3 WHERE DEPTNO=2;

1 row updated.

SQL> rollback;

Rollback complete.

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       220

SQL> 
SQL> update dept set deptno =3 WHERE DEPTNO=2;  ---------注意这里,deptno被更新为3

1 row updated.

SQL> 


Session 4(SID 116):
SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> INSERT INTO DEPT VALUES (6,'BAOBAO');

1 row created.

SQL> INSERT INTO DEPT VALUES (3,'BAOBAO');  -----------注意这里,只有插入deptno为3时才会被阻塞
..... HANG.....

这里我们看到,对父表的update阻塞了对其他会话对父表insert时pk的值=updae父表的pk的值的会话。
这个我们可以再做一个测试:
测试7,新建两个表,一个有pk,一个无pk,然后做同样的update和insert操作:
无pk的表:

CREATE TABLE LUNAR1
  (
    deptno NUMBER ,
    dname  VARCHAR2(10)
  );

insert into LUNAR1 values (1, 'LUNAR');
insert into LUNAR1 values (5, 'BAOBAO');
insert into LUNAR1 values (2, 'HAOBAOBAO');
commit;

sessin 1:
update LUNAR2 set deptno =3 WHERE DEPTNO=2;   ----注意这里,deptno被更新为3

session 2:
INSERT INTO LUNAR1 VALUES (7,'DABAOBAO');
INSERT INTO LUNAR1 VALUES (3,'DABAOBAO');     -----注意这里,插入了deptno为3的记录

这测试不会有任何问题。

现在我们改为带有pk的表:

CREATE TABLE LUNAR2
  (
    deptno NUMBER CONSTRAINT pk_LUNAR PRIMARY KEY,
    dname  VARCHAR2(10)
  );
  
insert into LUNAR2 values (1, 'LUNAR');
insert into LUNAR2 values (5, 'BAOBAO');
insert into LUNAR2 values (2, 'HAOBAOBAO');
commit;

SESSION 1:

SQL> update LUNAR2 set deptno =3 WHERE DEPTNO=2;    ----注意这里,deptno=2的记录被更新为deptno=3

1 row updated.

SQL> 

SESSION 2:
SQL> INSERT INTO LUNAR2 VALUES (7,'DABAOBAO');

1 row created.

Elapsed: 00:00:00.00
SQL> INSERT INTO LUNAR2 VALUES (3,'DABAOBAO');    -----注意这里,只有deptno为3的插入被阻塞
....HANG.....

取消掉,改为插入deptno=2的试试看:
SQL> INSERT INTO LUNAR2 VALUES (3,'DABAOBAO');
^Z^CINSERT INTO LUNAR2 VALUES (3,'DABAOBAO')
            *
ERROR at line 1:
ORA-01013: user requested cancel of current operation


Elapsed: 00:09:31.33
SQL> INSERT INTO LUNAR2 VALUES (2,'DABAOBAO');     -----注意这里,只有deptno为2的插入被阻塞
....HANG.....


也就是说,对存在pk的表来说,无论有没有子表,update pk的操作会同时阻塞对该表做insert操作中那些pk跟update语句更改前、后两个值相关的会话
比如update LUNAR2 set deptno =3 WHERE DEPTNO=2,就会阻塞所有insert deptno=2和deptno=3的会话

——未完,待续—

发表在 FAQ | 标签为 | 留下评论

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作

insert 的enq: TM – contention的情况-1 —–对有主外键关系的表的操作
insert 的enq: TM – contention的情况-2 —–只有主键约束无子表的情况

####################################################################################
总结1 :当外键无索引时
1,对子表的insert操作所在的事务没有完成前,对于父表的DML操作(INSERT/UPDATE/DELETE)都会因为不能获得对子表的TM锁而出现enq: TM – contention。
2,在总结1的基础上,如果又有了对子表的insert(我没有测试,但是我怀疑这里如果改成对子表的update和delete,也是相同道理……).
那么这个对子表的insert同样被阻塞,等待事件也是 enq: TM – contention。
3,对父表的insert会阻塞对父表的delete。同样的道理,此时对父表的insert也阻塞对父表的update pk操作。
####################################################################################

SQL> conn lunar/lunar
Connected.
SQL> CREATE TABLE DEPT
  2    (
  3      deptno NUMBER CONSTRAINT pk_dept PRIMARY KEY,
  4      dname  VARCHAR2(10)
  5    );

CREATE TABLE EMP
  (
    deptno NUMBER(2) CONSTRAINT fk_deptno REFERENCES dept(deptno),
    ename  VARCHAR2(20)
  );

Table created.

SQL> SQL>   2    3    4    5  
Table created.

SQL> 
SQL> select index_name from dba_indexes where OWNER='LUNAR';

INDEX_NAME
------------------------------
PK_DEPT

Elapsed: 00:00:00.21
SQL> 
SQL> insert into DEPT values (1, 'COSTCENTER');

1 row created.

SQL> insert into EMP values (1, 'SCOTT');

1 row created.

SQL>   
SQL> set linesize 200
SQL> set pages 999
SQL> set timing on
SQL> /

OWNER_NAME TABLE_NAME                KEY_NAME        REFERENCING_TAB FOREIGN_KEY_NAM
---------- ------------------------- --------------- --------------- ---------------
LUNAR      DEPT                      PK_DEPT         EMP             FK_DEPTNO

Elapsed: 00:00:01.07
SQL> 
  
SQL>   column table_name format a25
SQL> SELECT object_id,
  2    object_name
FROM dba_objects
  3    4  WHERE object_name IN ('EMP','DEPT')
  5  AND owner          = 'LUNAR';

 OBJECT_ID OBJECT_NAME
---------- --------------------------------------------------------------------------------------------------------------------------------
   1062788 DEPT
   1062790 EMP

Elapsed: 00:00:00.08
SQL> 

#########################################################
当没有索引的时候:
#########################################################
测试1, 在子表发生:Insert,然后在父表上有update操作

SQL> rollback;

Rollback complete.

Elapsed: 00:00:00.00
SQL> select * from dept;

no rows selected

Elapsed: 00:00:00.02
SQL> select * from emp;

no rows selected

Elapsed: 00:00:00.01
SQL>   

Session 1: 对子表进行insert,不commit时:

SQL> INSERT INTO DEPT VALUES (1, 'COSTCENTER');

1 row created.

Elapsed: 00:00:00.00
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00
SQL> INSERT INTO EMP VALUES (1, 'SCOTT'); 

1 row created.

Elapsed: 00:00:00.00
SQL> SELECT sid,  type,  id1,  id2,
  2    lmode,  request,  block
  3  FROM v$lock
  4  WHERE sid IN
  5    (SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID')  );  

       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       321 AE     884349          0          4          0          0
       321 TM    1062790          0          3          0          0   
       321 TM    1062788          0          3          0          0
       321 TX      65546      71036          6          0          0

Elapsed: 00:00:00.55
SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       321

Elapsed: 00:00:00.01
SQL> 

这是,我们看到,该回话在主表(1062788 DEPT)和子表(1062790 EMP)上都分别持有了 exclusive lock(LMODE=3)锁
同时,该回话还持有一个tx锁(在子表 emp上)

另开一个会话,观察锁:

SQL> select substr(type,1,2) type,substr(name,1,30) name ,substr(description,1,40) description  
  2  from v$lock_type
  3  where substr(type,1,2)='AE'
  4  ;

TYPE     NAME
-------- ------------------------------------------------------------------------------------------------------------------------
DESCRIPTION
----------------------------------------------------------------------------------------------------------------------------------------------------------------
AE       Edition Lock
Prevent Dropping an edition in use


Elapsed: 00:00:00.01
SQL>   

Session 2 : 然后,我们在父表做DML操作update:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       220

SQL> update dept set deptno = 1;
...hang...

Session 3: 检查锁的变化

SELECT sid,  type,  id1,  id2,  lmode,  request,  block
FROM v$lock
WHERE sid IN (220,321) 
ORDER BY SID; 

       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       220 TM    1062790          0          0          4          0
       220 TM    1062788          0          3          0          0
       220 AE     884349          0          4          0          0
       321 TX      65546      71036          6          0          0
       321 TM    1062790          0          3          0          1  --------blocker
       321 TM    1062788          0          3          0          0
       321 AE     884349          0          4          0          0

SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12456                           220      20401 ACTIVE
update dept set deptno = 1
4xjxb3twbayrj enq: TM - contention                                             ACTIVE

SQL> select * from v$lock where block=1;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
00007F6C85314EE0 00007F6C85314F40        321 TM    1062790          0          3          0        253          1

Elapsed: 00:00:00.07
SQL> 

这是我们看到,Session 2 在子表(1062790 EMP)上请求LMODE=4,并在主表(1062788 DEPT)上持有等待:enq: TM – contention

这是很清晰,有blocker了,也就是Session 1(SID 321),此时该回话正在对子表(1062790 EMP)进行插入操作
##################################
换句话说,当外键无索引时,对子表的insert操作,会造成对父表的更新操作的阻塞。
##################################

Session 4 更新父表:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> update dept set deptno = 1 where deptno = 2;
.....HANG.....

Session 3: 观察
SELECT sid,  type,  id1,  id2,  lmode,  request,  block
FROM v$lock
WHERE sid IN (220,321,116) AND TYPE!='AE'
ORDER BY SID,type,ID1; 

       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       116 TM    1062788          0          3          0          0
       116 TM    1062790          0          0          4          0
       220 TM    1062788          0          3          0          0
       220 TM    1062790          0          0          4          0
       321 TM    1062788          0          3          0          0
       321 TM    1062790          0          3          0          1
       321 TX      65546      71036          6          0          0

SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12602                           116      64289 ACTIVE
update dept set deptno = 1 where deptno = 2
2ha4z6qzxngj1 enq: TM - contention                                             ACTIVE

12456                           220      20401 ACTIVE
update dept set deptno = 1
4xjxb3twbayrj enq: TM - contention                                             ACTIVE

SQL> select * from v$lock where block=1;

ADDR             KADDR                   SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
00007F6C85314EE0 00007F6C85314F40        321 TM    1062790          0          3          0        386          1

这是我们看到,session 4(sid 116)遵循了跟session 220同样的所规律

这是我们在Session 1中执行commit,在Session 3中观察:

Session 1:
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00
SQL> 

可以看到Session 2和Session 4都完成了update:
Session 2:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       220

SQL> update dept set deptno = 1;

1 row updated.

SQL> 

Session 4:
SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> update dept set deptno = 1 where deptno = 2;

0 rows updated.

SQL> 

Session 3:
       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       116 TM    1062788          0          3          0          0    -------session 4获得了父表的update加LMODE=3的TM锁
       220 TM    1062788          0          3          0          0    -------session 2也获得了父表的update加LMODE=3的TM锁
       220 TX    1048603      29682          6          0          0

此时的等待事件:
SQL> select sid,event from v$session_wait where sid in (220,321,116);

       SID EVENT
---------- ----------------------------------------------------------------
       116 SQL*Net message from client
       220 SQL*Net message from client
       321 SQL*Net message from client

Elapsed: 00:00:00.00
SQL> 

这里我们看到,当外键无索引时,对子表的insert操作,会造成对父表的更新操作的阻塞,该阻塞直到子表的insert事务结束,才自动释放。

测试2, 在子表发生:Insert,然后在父表上有update操作,然后再有一个会话对子表做insert
重复上面的操作,不对session 1进行commit时,再开一个窗口(Session 5)对子表做insert

SQL> conn lunar/lunar
Connected.
SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       222

SQL> INSERT INTO EMP VALUES (2,'LUNAR');
。。。。。hang。。。。。。。

这是我们看到,对于子表的insert语句被阻塞了。

在Session 3中观察:


       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       116 TM    1062788          0          3          0          0
       116 TM    1062790          0          0          4          0
       220 TM    1062788          0          3          0          0
       220 TM    1062790          0          0          4          0
       222 TM    1062788          0          3          0          0
       222 TM    1062790          0          0          3          0   --------session 220请求以LMODE=3的模式对子表加TM锁
       321 TM    1062788          0          3          0          0
       321 TM    1062790          0          3          0          1
       321 TX    1310752      43053          6          0          0



SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12602                           116      64289 ACTIVE
update dept set deptno = 1 where deptno = 2
2ha4z6qzxngj1 enq: TM - contention                                             ACTIVE

12456                           220      20401 ACTIVE
update dept set deptno = 1
4xjxb3twbayrj enq: TM - contention                                             ACTIVE

12766                           222      49879 ACTIVE
INSERT INTO EMP VALUES (2,'LUNAR')
83wzmhc9kz5dp enq: TM - contention                                             ACTIVE

这里我们看到:
1,当外键无索引时,对子表的insert操作,会造成对父表的更新操作的阻塞,该阻塞直到子表的insert事务结束,才自动释放。
2,如果对子表有insert操作,在这个insert所在事务没有commit之前,有对父表的update,那么接下来的对子表的inser会被阻塞

测试3:
在测试2的场景上,将session 2和session 4中的对父表的update执行Ctrl+C,然后分别改为INSERT 和delete 父表(dept)的操作,观察一下
Session 4:

SQL> update dept set deptno = 1 where deptno = 2;
^Cupdate dept set deptno = 1 where deptno = 2
*
ERROR at line 1:
ORA-01013: user requested cancel of current operation

SQL> 

Session 2:
SQL> update dept set deptno = 1;
^Cupdate dept set deptno = 1
*
ERROR at line 1:
ORA-01013: user requested cancel of current operation

Session 5 随之自动解锁,并报了正常的违反约束的错误:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       222

SQL> INSERT INTO EMP VALUES (2,'LUNAR');
INSERT INTO EMP VALUES (2,'LUNAR')
*
ERROR at line 1:
ORA-02291: integrity constraint (LUNAR.FK_DEPTNO) violated - parent key not
found


SQL> 

在session 2中执行delete 父表的操作:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       220
SQL> delete from dept where deptno = 1;
..... HANG......

在session 3中观察:
       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       220 TM    1062788          0          3          0          0
       220 TM    1062790          0          0          4          0
       321 TM    1062788          0          3          0          0
       321 TM    1062790          0          3          0          1
       321 TX    1310752      43053          6          0          0

SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12456                           220      20401 ACTIVE
delete from dept where deptno = 1
56m0bvac2yfkm enq: TM - contention                                             ACTIVE

12766                           222      49879 INACTIVE
INSERT INTO EMP VALUES (2,'LUNAR')
83wzmhc9kz5dp SQL*Net message from client                                      INACTIVE

注意:
1,delete父表的操作被阻塞,依然是正在请求以LMODE=4的模式对子表(1062790 EMP)的TM锁
2,这里的sid 222中为非活动会话,当该回话执行了commit或者rollback后,这个Insert的“SQL*Net message from client”等待就会消失了。

测试4: 在测试3的场景上,继续session 4中的对父表做insert 的操作,观察一下
Session 4:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> INSERT INTO DEPT VALUES (2,'LUNAR');
。。。。。hang  。。。。。。。。。。

在Session 3观察:

       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       116 TM    1062788          0          3          0          0
       116 TM    1062790          0          0          3          0
       220 TM    1062788          0          3          0          0
       220 TM    1062790          0          0          4          0
       321 TM    1062788          0          3          0          0
       321 TM    1062790          0          3          0          1
       321 TX    1310752      43053          6          0          0


SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12602                           116      64289 ACTIVE
INSERT INTO DEPT VALUES (2,'LUNAR')
g2dc3zwjr19hf enq: TM - contention                                             ACTIVE

12456                           220      20401 ACTIVE
delete from dept where deptno = 1
56m0bvac2yfkm enq: TM - contention                                             ACTIVE

这里我们看到,虽然Session 4执行的是对父表的insert,session 2执行的是对父表的 delete,他们的表现跟update的表现都是相同的。
也就是说,对于子表的insert操作所在的事务没有完成前,对于父表的DML操作(INSERT/UPDATE/DELETE)都会因为不能获得对子表的TM锁而出现enq: TM – contention

测试5: 在测试4的基础上,我们在Session 1对做commit,完成对子表的insert操作,然后观察其他session:
Session 1:

SQL> INSERT INTO EMP VALUES (1, 'SCOTT'); 

1 row created.

Elapsed: 00:00:00.00
SQL> commit;

Commit complete.

Elapsed: 00:00:00.00
SQL> 

Session 4:对父表的insert插入操作随着session 1的commit 自动解锁:

SQL> SELECT sid FROM v$session WHERE audsid = userenv('SESSIONID');

       SID
----------
       116

SQL> INSERT INTO DEPT VALUES (2,'LUNAR');

1 row created.

SQL> 

Session 2(SID 220):对父表的delete操作依然是hang的状态:

SQL> delete from dept where deptno = 1;
...HANG ...

在session 3观察:
       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       116 TM    1062788          0          3          0          0
       116 TM    1062790          0          3          0          1  ----------session 4(sid 116)是阻塞者了
       116 TX    1310742      42713          6          0          0
       220 TM    1062788          0          3          0          0  ----------session 2依然是刚才的状态
       220 TM    1062790          0          0          4          0
       220 TX      65567      71014          6          0          0


SPID                            SID    SERIAL# STATUS
------------------------ ---------- ---------- --------
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID        EVENT                                                            STATUS
------------- ---------------------------------------------------------------- --------
12456                           220      20401 ACTIVE
delete from dept where deptno = 1
56m0bvac2yfkm enq: TM - contention                                             ACTIVE

也就是说,这里我们看到了,对父表的insert,阻塞了对父表的delete

——未完,待续—

发表在 Performence Tuning | 标签为 | 留下评论

一次体验N种报错的Oracle数据库恢复(ORA-704 ORA-604 ORA-600[25016] ORA-376)

朋友数据库报错:

Fri Nov 07 16:34:24 2014
ALTER DATABASE OPEN
Fri Nov 07 16:34:29 2014
Expanded controlfile section 9 from 18692 to 186920 records
Requested to grow by 168228 records; added 576 blocks of records
Thread 1 advanced to log sequence 36 (thread open)
Thread 1 opened at log sequence 36
  Current log# 6 seq# 36 mem# 0: /oradata/TESTAPP/redo06.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Nov 07 16:34:29 2014
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.9b359f77):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_8519700.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 14 with name "_SYSSMU14_2547694043$" too small
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_8519700.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 14 with name "_SYSSMU14_2547694043$" too small
Error 704 happened during db open, shutting down database
USER (ospid: 8519700): terminating the instance due to error 704
Instance terminated by USER, pid = 8519700
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (8519700) as a result of ORA-1092
Fri Nov 07 16:34:32 2014
ORA-1092 : opitsk aborting process

使用隐含参数拉库:

Fri Nov 07 21:29:00 2014
ALTER DATABASE RECOVER  database using backup controlfile until cancel  
Media Recovery Start
 started logmerger process
Fri Nov 07 21:29:00 2014
WARNING! Recovering data file 1 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 2 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 3 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 4 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 5 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 6 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 7 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 8 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 9 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 10 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 11 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 12 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 13 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 14 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 15 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 17 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 18 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 19 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 20 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 21 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 22 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 23 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 24 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 25 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 26 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 27 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 28 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 29 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 30 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 31 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 36 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 37 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 38 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 39 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 41 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 42 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 43 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 44 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 45 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 46 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 47 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 48 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 49 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 50 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
WARNING! Recovering data file 51 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
Parallel Media Recovery started with 16 slaves
ORA-279 signalled during: ALTER DATABASE RECOVER  database using backup controlfile until cancel  ...
ALTER DATABASE RECOVER    CANCEL  
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_pr00_9044064.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/TESTAPP/system01.dbf'
Slave exiting with ORA-1547 exception
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_pr00_9044064.trc:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/TESTAPP/system01.dbf'
ORA-1547 signalled during: ALTER DATABASE RECOVER    CANCEL  ...
ALTER DATABASE RECOVER CANCEL 
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Fri Nov 07 21:29:19 2014
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 2603982708
Clearing online redo logfile 1 /oradata/TESTAPP/redo01.log
Clearing online log 1 of thread 1 sequence number 0
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /oradata/TESTAPP/redo02.log
Clearing online log 2 of thread 1 sequence number 0
Clearing online redo logfile 2 complete
Clearing online redo logfile 3 /oradata/TESTAPP/redo03.log
Clearing online log 3 of thread 1 sequence number 0
Clearing online redo logfile 3 complete
Clearing online redo logfile 4 /oradata/TESTAPP/redo04.log
Clearing online log 4 of thread 1 sequence number 0
Clearing online redo logfile 4 complete
Clearing online redo logfile 5 /oradata/TESTAPP/redo05.log
Clearing online log 5 of thread 1 sequence number 0
Clearing online redo logfile 5 complete
Clearing online redo logfile 6 /oradata/TESTAPP/redo06.log
Clearing online log 6 of thread 1 sequence number 0
Clearing online redo logfile 6 complete
Online log /oradata/TESTAPP/redo01.log: Thread 1 Group 1 was previously cleared
Online log /oradata/TESTAPP/redo02.log: Thread 1 Group 2 was previously cleared
Online log /oradata/TESTAPP/redo03.log: Thread 1 Group 3 was previously cleared
Online log /oradata/TESTAPP/redo04.log: Thread 1 Group 4 was previously cleared
Online log /oradata/TESTAPP/redo05.log: Thread 1 Group 5 was previously cleared
Online log /oradata/TESTAPP/redo06.log: Thread 1 Group 6 was previously cleared
Fri Nov 07 21:29:25 2014
Setting recovery target incarnation to 2
Advancing SCN to 4294967296 according to _minimum_giga_scn
Fri Nov 07 21:29:25 2014
Assigning activation ID 264823552 (0xfc8e300)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /oradata/TESTAPP/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Nov 07 21:29:25 2014
SMON: enabling cache recovery
[9568454] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:18950108 end:18950872 diff:764 (7 seconds)
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'TB_DHREP_TEMP' #7 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'EAST_TEMP' #30 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'ZFMI_TEMP' #36 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'RPT1' #47 found in data dictionary,
but not in the controlfile. Adding to controlfile.
File #32 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00032' in the controlfile.
This file can no longer be recovered so it must be dropped.
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_9568454.trc  (incident=912216):
ORA-00600: 内部错误代码, 参数: [25016], [40], [43], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/diag/rdbms/testapp/TESTAPP/incident/incdir_912216/TESTAPP_ora_9568454_i912216.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_9568454.trc:
ORA-00600: 内部错误代码, 参数: [25016], [40], [43], [], [], [], [], [], [], [], [], []
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_9568454.trc:
ORA-00600: 内部错误代码, 参数: [25016], [40], [43], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 9568454): terminating the instance due to error 600
Fri Nov 07 21:29:29 2014
Instance terminated by USER, pid = 9568454
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (9568454) as a result of ORA-1092
Fri Nov 07 21:29:29 2014
ORA-1092 : opitsk aborting process

这里看到由于他之前在OS上删除了文件,又重建了控制文件,因此数据字典中的文件信息和重建的控制文件不匹配
因此,报了上面的错误。
这时候使用使用隐含参数屏蔽system表空间检查,并屏蔽只读打开状态的字典检查,并使用gdb跳过数据字典检查,再次resetlog数据库试试看:

(CDKF177:oracle)/home/oracle>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on 星期六 11月 8 18:24:56 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup nomount pfile=/tmp/spfile.bak
ORACLE 例程已经启动。

Total System Global Area 6413680640 bytes
Fixed Size                  2233480 bytes
Variable Size            3942648696 bytes
Database Buffers         2449473536 bytes
Redo Buffers               19324928 bytes
SQL> @controlfile

控制文件已创建。

SQL> recover database using backup controlfile until cancel;
ORA-00279: ?? 7516192769 (? 11/08/2014 17:58:22 ??) ???? 1 ????
ORA-00289: ??: /oradata/archivelog/1_1_863114302.dbf
ORA-00280: ?? 7516192769 (???? 1) ??? #1 ?


指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/TESTAPP/system01.dbf'


ORA-01112: ???????

这里是AIX系统:

(gdb) commands 
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>set *0x0700000000021C80=0x0 
>cont 
>end 
(gdb) cont 

这是看到,已经跳过了数据字典检查,并且报错是ORA-00604 ORA-00376 ORA-01110
这个跟我以前处理自己的一次测试很相似了,参见《艰难的修复数据库过程,却发现Oracle 11.2果然强大》
alert信息如下:

Sat Nov 08 18:30:30 2014
alter database open resetlogs
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 7516192769
Clearing online redo logfile 1 /oradata/TESTAPP/redo01.log
Clearing online log 1 of thread 1 sequence number 1
Clearing online redo logfile 1 complete
Resetting resetlogs activation ID 264909299 (0xfca31f3)
Online log /oradata/TESTAPP/redo01.log: Thread 1 Group 1 was previously cleared
Online log /oradata/TESTAPP/redo02.log: Thread 1 Group 2 was previously cleared
Online log /oradata/TESTAPP/redo03.log: Thread 1 Group 3 was previously cleared
Online log /oradata/TESTAPP/redo04.log: Thread 1 Group 4 was previously cleared
Online log /oradata/TESTAPP/redo05.log: Thread 1 Group 5 was previously cleared
Online log /oradata/TESTAPP/redo06.log: Thread 1 Group 6 was previously cleared
Sat Nov 08 18:30:30 2014
Setting recovery target incarnation to 2
Advancing SCN to 10737418240 according to _minimum_giga_scn
Sat Nov 08 18:30:30 2014
Assigning activation ID 264929176 (0xfca7f98)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /oradata/TESTAPP/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Nov 08 18:30:30 2014
SMON: enabling cache recovery
[10223722] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:94615629 end:94615676 diff:47 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_10223722.trc:
ORA-00604: ?? SQL ?? 1 ????
ORA-00376: ???????? 1
ORA-01110: ???? 1: '/oradata/TESTAPP/system01.dbf'
Errors in file /oracle/diag/rdbms/testapp/TESTAPP/trace/TESTAPP_ora_10223722.trc:
ORA-00604: ?? SQL ?? 1 ????
ORA-00376: ???????? 1
ORA-01110: ???? 1: '/oradata/TESTAPP/system01.dbf'
Error 604 happened during db open, shutting down database
USER (ospid: 10223722): terminating the instance due to error 604
Instance terminated by USER, pid = 10223722
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (10223722) as a result of ORA-1092
Sat Nov 08 18:30:32 2014
ORA-1092 : opitsk aborting process

再次尝试重建控制文件,使用gdb跳过字典检查,然后使用open upgrade尝试打开库(因为此时数据文件的scn都一致了):

(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>set *0x0700000000021C80=0x0 
>cont
>end
(gdb) cont
Continuing.

尝试open数据库,发现数据库又出现了ORA-00600 [25016]

SQL> alter database open upgrade;
alter database open upgrade
*
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: '/oradata/TESTAPP/system01.dbf'


SQL> recover database;
完成介质恢复。
SQL> alter database open upgrade;
alter database open upgrade
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [25016], [40], [43], [], [], [], [],
[], [], [], [], []
进程 ID: 10879136
会话 ID: 570 序列号: 3


SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断开

这至少说明一个问题,没有使用resetlogs的时候,控制文件并没有损坏,因此,不重建控制文件,直接恢复数据库,然后open upgrade:

(CDKF177:oracle)/home/oracle>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on 星期日 11月 9 00:15:24 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

已连接到空闲例程。

SQL> startup restrict mount pfile=/tmp/spfile.bak
ORACLE 例程已经启动。

Total System Global Area 6413680640 bytes
Fixed Size                  2233480 bytes
Variable Size            3942648696 bytes
Database Buffers         2449473536 bytes
Redo Buffers               19324928 bytes
数据库装载完毕。
SQL> alter database open upgrade;
alter database open upgrade
*
第 1 行出现错误:
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: '/oradata/TESTAPP/system01.dbf'


SQL> recover database;
完成介质恢复。
SQL> alter database open upgrade;

数据库已更改。

SQL> 

数据库已经open了。

发表在 backup&recovery | 标签为 , , , | 留下评论

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异

Oracle从10.1开始推出了自己真正意义的集群软件(9i和9i之前的版本,Oracle只有集群数据库,集群的存储和网络是由第三方厂商维护的,比如IBM的HACMP,HPUX的MC SERVICE GUARD /OA,SUN的suncluster,True64的Trucluster,linux就用ocfs和check-timer等等)。

因此,从10.1开始,oracle的集群有了自己的管理网络和存储的机制,ocr存放集群配置信息,voting disk用于磁盘心跳。
本文就简单的汇总一下各版本对于ocr和voting disk在一些维护操作和安装需求大致做个总结。

更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC

1,各个版本ocr和vot的空间需求:

For 10.1:
OCR device minimum size (each): 100M
Voting disk minimum size (each): 20M

For 10.2:
OCR device minimum size (each): 256M
Voting disk minimum size (each): 256M

For 11.1:
OCR device minimum size (each): 280M
Voting disk minimum size (each): 280M

For 11.2:
OCR device minimum size (each): 300M
Voting disk minimum size (each): 300M

2,各个版本ocr和vot的磁盘组权限:

For OCR device:
chown root:oinstall <OCR device>
chmod 640 <OCR device>

For Voting device:
chown <crs/grid>:oinstall <Voting device>
chmod 644 <Voting device>

For ASM disks used for OCR/Voting disk:
chown griduser:asmadmin <asm disks>
chmod 660 <asm disks>

3,voting disk个数的要求:
For Voting disks (never use even number of voting disks):
External redundancy requires minimum of 1 voting disk (or 1 failure group)
Normal redundancy requires minimum of 3 voting disks (or 3 failure group)
High redundancy requires minimum of 5 voting disks (or 5 failure group)

4,OCR个数的要求:
10.2 and 11.1, maximum 2 OCR devices: OCR and OCRMIRROR
11.2+, upto 5 OCR devices can be added.

更改ocr和voting disk的操作,参见《更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC

5,各版本操作命令的差异:
1,ocrconfig -replace也可以用来替换ocr(我上面给的例子是用冗余的方式来做的,replace是直接替换的)。
如果用这个命令,请注意11.2以后的 Bug 8604794 – FAIL TO CHANGE OCR LOCATION TO DG WITH ‘OCRCONFIG -REPAIR -REPLACE’
2,添加ocr的镜像,10.2和11.1只能用ocrconfig -replace ocrmirror来做,11.2用add
3,替换,10.2和11.1用ocrconfig -replace,11.2用ocrconfig -add,再ocrconfig -delete
4,对于vot,10.2的add和delete都需要force选项,例如; crsctl add css votedisk -force;
11.1以后(包括11.2),除了windows平台,Linux和unix平台都不需要force了

发表在 RAC | 标签为 , , | 留下评论

更改ocr(ocrconfig)和voting disk(crsctl replace votedisk)到其他的磁盘组—11.2 RAC

RAC上ocr和voting disk从10.1到11.2维护操作和需求的差异

检查当前的ocr所在磁盘:

[oracle@dm01db01 ~]$ ocrcheck
Status of Oracle Cluster Registry is as follows :
	 Version                  :          3
	 Total space (kbytes)     :     262120
	 Used space (kbytes)      :       2612
	 Available space (kbytes) :     259508
	 ID                       : 1194723922
	 Device/File Name         :   +DATA_DG
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

	 Cluster registry integrity check succeeded

	 Logical corruption check bypassed due to non-privileged user

添加+DBFS_DG作为新的存放ocr的磁盘组:

[oracle@dm01db01 ~]$ ocrconfig -add +DBFS_DG
PROT-20: Insufficient permission to proceed. Require privileged user
[oracle@dm01db01 ~]$ su 
Password: 
[root@dm01db01 oracle]# ocrconfig -add +DBFS_DG
[root@dm01db01 oracle]# exit
exit
[oracle@dm01db01 ~]$ ocrcheck
Status of Oracle Cluster Registry is as follows :
	 Version                  :          3
	 Total space (kbytes)     :     262120
	 Used space (kbytes)      :       2612
	 Available space (kbytes) :     259508
	 ID                       : 1194723922
	 Device/File Name         :   +DATA_DG
                                    Device/File integrity check succeeded
	 Device/File Name         :   +DBFS_DG
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

	 Cluster registry integrity check succeeded

	 Logical corruption check bypassed due to non-privileged user

[oracle@dm01db01 ~]$ su 
Password: 
[root@dm01db01 oracle]# ocrcheck
Status of Oracle Cluster Registry is as follows :
	 Version                  :          3
	 Total space (kbytes)     :     262120
	 Used space (kbytes)      :       2612
	 Available space (kbytes) :     259508
	 ID                       : 1194723922
	 Device/File Name         :   +DATA_DG
                                    Device/File integrity check succeeded
	 Device/File Name         :   +DBFS_DG
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

	 Cluster registry integrity check succeeded

	 Logical corruption check succeeded

删除+DATA_DG上的ocr:

[root@dm01db01 oracle]# ocrconfig -delete +DATA_DG
[root@dm01db01 oracle]# ocrcheck
Status of Oracle Cluster Registry is as follows :
	 Version                  :          3
	 Total space (kbytes)     :     262120
	 Used space (kbytes)      :       2612
	 Available space (kbytes) :     259508
	 ID                       : 1194723922
	 Device/File Name         :   +DBFS_DG
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

	 Cluster registry integrity check succeeded

	 Logical corruption check succeeded

[root@dm01db01 oracle]# 

查看voting disk当前存放在哪个磁盘组(N中方法,这里直接在ASM里面看的):
[oracle@dm01db01 ~]$ . ./env/grid.env
[oracle@dm01db01 ~]$ asmcmd
ASMCMD>
ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED NORMAL N 512 4096 4194304 16625664 16624360 1511424 7556468 0 Y DATA_DG/
MOUNTED NORMAL N 512 4096 4194304 894720 893568 81338 406115 0 N DBFS_DG/
MOUNTED NORMAL N 512 4096 4194304 2863872 2863224 260352 1301436 0 N RECO_DM01/
ASMCMD>
[/shell]
还可以使用crsctl query css votedisk来查看:

[oracle@dm01db01 ~]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   678abf64d3c34f9dbf923ab1420f40c0 (o/192.168.11.13/DATA_DM01_CD_00_dm01cel01) [DATA_DG]
 2. ONLINE   80581891d0414fb6bf397f8c0d14ff3d (o/192.168.11.14/DATA_DM01_CD_00_dm01cel02) [DATA_DG]
 3. ONLINE   663a4ca137f04fd2bf8719795542df30 (o/192.168.11.15/DATA_DM01_CD_00_dm01cel03) [DATA_DG]
Located 3 voting disk(s).
[oracle@dm01db01 ~]$ 

将voting disk替换到+DBFS_DG磁盘组:

[oracle@dm01db01 ~]$ crsctl replace votedisk +DBFS_DG
Successful addition of voting disk af022878bf3f4f2dbfa2c3f630ee15b9.
Successful addition of voting disk 83dd62df08da4f32bf71abefc6d8ee52.
Successful addition of voting disk 6712a4d602404f8ebfa4ed635659c42e.
Successful deletion of voting disk 678abf64d3c34f9dbf923ab1420f40c0.
Successful deletion of voting disk 80581891d0414fb6bf397f8c0d14ff3d.
Successful deletion of voting disk 663a4ca137f04fd2bf8719795542df30.
Successfully replaced voting disk group with +DBFS_DG.
CRS-4266: Voting file(s) successfully replaced
[oracle@dm01db01 ~]$ 
[oracle@dm01db01 ~]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   af022878bf3f4f2dbfa2c3f630ee15b9 (o/192.168.11.15/DBFS_DG_CD_02_dm01cel03) [DBFS_DG]
 2. ONLINE   83dd62df08da4f32bf71abefc6d8ee52 (o/192.168.11.13/DBFS_DG_CD_02_dm01cel01) [DBFS_DG]
 3. ONLINE   6712a4d602404f8ebfa4ed635659c42e (o/192.168.11.14/DBFS_DG_CD_02_dm01cel02) [DBFS_DG]
Located 3 voting disk(s).
[oracle@dm01db01 ~]$ 
[oracle@dm01db01 ~]$ asmcmd -p lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB   Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512   4096  4194304  16625664  16624456          1511424         7556516              0             N  DATA_DG/
MOUNTED  NORMAL  N         512   4096  4194304    894720    893472            81338          406067              0             Y  DBFS_DG/
MOUNTED  NORMAL  N         512   4096  4194304   2863872   2863224           260352         1301436              0             N  RECO_DM01/
[oracle@dm01db01 ~]$ 
发表在 RAC | 标签为 , | 留下评论

MYSQL小白的FAQ系列—-7—-如何配置mysql主从同步(Master-Slave)

======================================
主数据库master修改
======================================
# 是master的日志文件,存放地址和名称
log-bin=/u01/mysql/data/binlog/mysql-bin.index
log-bin=/u01/mysql/data/binlog/mysql-bin

# 日志格式,建议mixed
binlog_format = mixed

# 主数据库端ID号
server-id = 1

#不同步哪些数据库
binlog-ignore-db = mysql
binlog-ignore-db = test
binlog-ignore-db = information_schema

#只同步哪些数据库,除此之外,其他不同步
binlog-do-db = lunar

#日志保留时间
expire_logs_days = 10

#控制binlog文件的更新频率。每执行n次事务保存一次
#这个参数性能消耗很大,但可减小MySQL崩溃造成的损失
sync_binlog = 1

#查看log位置:
mysqlbinlog log-file | mysql -h server_name

#创建用于同步的账户:
#创建slave帐号slave,密码lunar
mysql>grant replication slave,select,reload,super on *.* to ‘slave’@’%’ identified by ‘lunar’;

#更新数据库权限
mysql>flush privileges;

重启mysql(使上面更改的参数生效)
[root@ebsdba2 u01]# service mysql stop
Shutting down MySQL..[ OK ]
[root@ebsdba2 u01]# service mysql start
Starting MySQL..[ OK ]
[root@ebsdba2 u01]#

启动后在主库执行:
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
记录下这个位置。

把主库的lunar数据库导出:
mysqldump -u root -p lunar > lunar.sql
然后在mysql解锁: UNLOCK TABLES;

把lunar.sql文件scp到从库上。

======================================
从数据库slave修改
======================================

mkdir -p /u01/mysql/data/binlog
mkdir -p /u01/mysql/data/relaylog
mkdir -p /u01/mysql/mysqldata
chown mysql:mysql /u01/mysql

grant all privileges on *.* to root@'%' identified by "lunar" with grant option;
grant replication slave,select,reload,super on *.* to 'slave'@'%' identified by 'lunar';
grant all privileges on *.* to lunar@'%' identified by "lunar";
flush privileges;


从库连接主库进行测试:
/opt/mysql/bin/mysql -u slave -p -h 10.45.10.141

停止从库,修改从库参数
[mysqld]
server-id=2
#basedir = /u01/mysql
datadir = /u01/mysql/mysqldata
port = 3306

replicate-do-db=lunar  

log-bin=/u01/mysql/data/binlog/mysql-bin.index
log-bin=/u01/mysql/data/binlog/mysql-bin

slave-skip-errors=1022,1032,1062
log_slave_updates=1
log_bin_trust_function_creators=1
auto_increment_increment=2
auto_increment_offset=1
#bind-address=10.0.2.31
#hostname=
relay-log=/u01/mysql/data/relaylog/mysql-relay-bin.index
relay-log=/u01/mysql/data/relaylog/mysql-relay-bin

[root@ebsdba1 u01]# service mysql stop
Shutting down MySQL..[ OK ]
[root@ebsdba1 u01]# service mysql start
Starting MySQL..[ OK ]
[root@ebsdba1 u01]#

在从库上导入lunar.sql:

[root@ebsdba1 mysql]# mysql -ulunar -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.6.21-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

mysql> create database lunar;
Query OK, 1 row affected (0.00 sec)

mysql> use lunar;
Database changed
mysql> source lunar.sql
Query OK, 0 rows affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

Query OK, 1 row affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

mysql> show tables;
+-----------------+
| Tables_in_lunar |
+-----------------+
| lunar           |
| new             |
+-----------------+
2 rows in set (0.00 sec)

mysql>

#执行同步命令,设置主数据库ip,同步帐号密码

change master to master_host='10.45.10.141' , master_user='slave', master_password='lunar' , master_log_file='mysql-bin.000003', master_log_pos=120;
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.45.10.141
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000004
          Read_Master_Log_Pos: 353
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 516
        Relay_Master_Log_File: mysql-bin.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: lunar
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 353
              Relay_Log_Space: 852
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1
                  Master_UUID: 9e56df6a-642f-11e4-957d-005056ad43d4
             Master_Info_File: /u01/mysql/mysqldata/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)

ERROR: 
No query specified

mysql> 

在主库插入数据:

[root@ebsdba2 ~]# mysql -ulunar -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.6.21-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use lunar;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> insert into lunar value('lunar','hao baobao');
Query OK, 1 row affected (0.01 sec)

mysql> select * from lunar;
+-------+------------+
| name  | phone      |
+-------+------------+
| lunar | 123456     |
| lunar | hao baobao |
+-------+------------+
2 rows in set (0.00 sec)

mysql> 

再从库检查数据:

[root@ebsdba1 mysqldata]# mysql -ulunar -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.6.21-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use lunar;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from lunar;
+-------+------------+
| name  | phone      |
+-------+------------+
| lunar | 123456     |
| lunar | hao baobao |
+-------+------------+
2 rows in set (0.00 sec)

mysql> 

上述表明数据已经自动同步了,且查看的slave status也正常。

检查主库进程:

mysql> show processlist;
+----+-------+---------------------------+-------+-------------+------+-----------------------------------------------------------------------+------------------+
| Id | User  | Host                      | db    | Command     | Time | State                                                                 | Info             |
+----+-------+---------------------------+-------+-------------+------+-----------------------------------------------------------------------+------------------+
|  2 | slave | ebsdba1.800best.com:31106 | NULL  | Binlog Dump | 1763 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
|  3 | lunar | localhost                 | lunar | Sleep       | 1595 |                                                                       | NULL             |
|  4 | root  | localhost                 | NULL  | Query       |    0 | init                                                                  | show processlist |
+----+-------+---------------------------+-------+-------------+------+-----------------------------------------------------------------------+------------------+
3 rows in set (0.00 sec)

mysql> 

检查备库的进程:

mysql> show processlist;
+----+-------------+-----------+-------+---------+------+-----------------------------------------------------------------------------+------------------+
| Id | User        | Host      | db    | Command | Time | State                                                                       | Info             |
+----+-------------+-----------+-------+---------+------+-----------------------------------------------------------------------------+------------------+
|  1 | slave       | localhost | NULL  | Sleep   |    9 |                                                                             | NULL             |
| 11 | system user |           | NULL  | Connect | 1753 | Waiting for master to send event                                            | NULL             |
| 12 | system user |           | NULL  | Connect | 1590 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |
| 13 | lunar       | localhost | lunar | Query   |    0 | init                                                                        | show processlist |
+----+-------------+-----------+-------+---------+------+-----------------------------------------------------------------------------+------------------+
4 rows in set (0.00 sec)

mysql> 

常见问题1:
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the –replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
解决:从库和主库的server_id是相同的值,需要修改为不同值:show variables like ‘server_id’;
修改从库的/usr/my.cnf中的server_id,不要和主库重复
然后重启从库。使用slave登陆后,执行:

			change master to master_log_file='mysql-bin.000003', master_log_pos=120;
			start slave;
			show slave status \G;
			
			如果在主库和从库的任何一个中,没有显示的指定server_id,那么也可能会报这类错误,通过指定set global server_id也不能排除问题:
			mysql> set global server_id=2;
			Query OK, 0 rows affected (0.00 sec)
			mysql> show variables like 'server%';
			+----------------+--------------------------------------+
			| Variable_name  | Value                                |
			+----------------+--------------------------------------+
			| server_id      | 2                                    |
			| server_id_bits | 32                                   |
			| server_uuid    | 8abc63a1-64cd-11e4-9983-005056ad27e5 |
			+----------------+--------------------------------------+
			3 rows in set (0.00 sec)
			
			mysql>			

这时候,检查主库和备库的参数,显示指定主库和备库的server_id为不同的值,然后重启服务器,问题就解决了。
查了一下,说是mysql的bug。

常见问题2: 有时候会遇到类似下面的错误:

2014-11-05 21:40:46 25430 [ERROR] Slave SQL: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
2014-11-05 21:40:59 25430 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='10.45.10.141', master_port= 3306, master_log_file='mysql-bin.000001', master_log_pos= 120, master_bind=''. New state master_host='10.45.10.141', master_port= 3306, master_log_file='mysql-bin.000003', master_log_pos= 120, master_bind=''.

可以使用mysqlbinlog来查看:

[root@ebsdba1 mysqldata]# mysqlbinlog --start-position=120 /u01/mysql/data/binlog/mysql-bin.000003
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#141105 22:12:09 server id 1  end_log_pos 120 CRC32 0xaf2e2d80  Start: binlog v 4, server v 5.6.21-enterprise-commercial-advanced-log created 141105 22:12:09 at startup
ROLLBACK/*!*/;
BINLOG '
OTBaVA8BAAAAdAAAAHgAAAAAAAQANS42LjIxLWVudGVycHJpc2UtY29tbWVyY2lhbC1hZHZhbmNl
ZC1sb2cAAAAAAAAAAAA5MFpUEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAYAt
Lq8=
'/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@ebsdba1 mysqldata]# 

然后根据错误提示,调整master_log_file和master_log_pos。
例如:
change master to master_log_file=’mysql-bin.000003′, master_log_pos=120;

发表在 FAQ, 复制 | 一条评论

升级到11.2.0.4的一些发现-3-catalog.sql的主要内容

升级到11.2.0.4的一些发现-1-catupgrd.sql大致解读
升级到11.2.0.4的一些发现-2-其他发现

升级脚本catupgrd.sql中,首先调用的catupstr.sql主要用于更新数据字典(里面还调用很多重要的创建基表的语句),例如:

[oracle@lunar admin]$ grep "create table obj" *
c1002000.sql:create table objerror$
dcore.bsq:create table obj$                                            /* object table */
dcore.bsq:create table objerror$
dcore.bsq:create table objauth$                           /* table authorization table */
dcore.bsq:create table objpriv$                       /* privileges granted to objects */
dmanage.bsq:create table object_usage                         /* object usage statistics */
utlmmig.sql:create table obj$mig                                         /* object table */
[oracle@lunar admin]$ 

之后,就是调用catalog.sql来创建各种数据字典,大概看了一下,记录如下:

--CATCTL -S    Initial scripts single process
@@cdstrt ---依次调用 :
						Rem Run CATALOG and CATPROC session initialization script
						@@catpses.sql
									--catpses.sql - CATalog and CATProc SESsion script
									--Rem Assure CHAR semantics are not used in the dictionary
									ALTER SESSION SET NLS_LENGTH_SEMANTICS=BYTE;								
						
						rem Load PL/SQL Package STANDARD first, so views can depend upon it
						@@standard
								[root@ebsdba1 admin]# cat standard.sql 
								@@stdspec.sql   ---里面是各种标准数据类型
								@@stdbody.sql   ---一些标准函数
								grant execute on STANDARD to public;
								[root@ebsdba1 admin]# 								

						@@dbmsstdx --调用stdext.sql - Kernel extensions to package standard
															--Rem    DESCRIPTION
															--Rem      Routines in this package do not need to be qualified by the owner or package name, 
															--Rem      similar to the behaviour of package 'standard'.  This package mostly contains utility routines for triggers.

						
						Rem Load registry so catalog component can be defined
						@@catcr --这个脚本本身是创建加载到数据库中的部件的registry信息相关的数据字典和存储过程等的(CATalog Component Registry)
										--This script creates the data dictionary elements and package for the registry of components that have been loaded into the database
										--例如CREATE TABLE registry$,CREATE TABLE registry$schemas,CREATE TABLE registry$log,PACKAGE dbms_registry等等
										--它调用catcrsc.sql(	Rem Server Components script)
										@@catcrsc : catcrsc.sql - CATalog Component Registry Server Components
																This script contains constants used to identify SERVER components and the associated upgrade/downgrade/patch/reload scripts
																--即,PACKAGE dbms_registry_server,其包含了已经注册的一些服务器部件的常量的定义,比如:
																-- Path names
																				JAVAVM_path   CONSTANT VARCHAR2(50) := '?/javavm/install/';
																				CATJAVA_path  CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				XML_path      CONSTANT VARCHAR2(50) := '?/xdk/admin/';
																				XDB_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				RAC_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				OLS_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				EXF_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				OWM_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				ORDIM_path    CONSTANT VARCHAR2(50) := '?/ord/im/admin/';
																				SDO_path      CONSTANT VARCHAR2(50) := '?/md/admin/';
																				CONTEXT_path  CONSTANT VARCHAR2(50) := '?/ctx/admin/';
																				ODM_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				WK_path       CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				MGW_path      CONSTANT VARCHAR2(50) := '?/mgw/admin/';
																				AMD_path      CONSTANT VARCHAR2(50) := '?/olap/admin/';
																				APS_path      CONSTANT VARCHAR2(50) := '?/olap/admin/';
																				XOQ_path      CONSTANT VARCHAR2(50) := '?/olap/admin/';
																				EM_path       CONSTANT VARCHAR2(50) := '?/sysman/admin/emdrep/sql/';
																				RUL_path      CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
																				APEX_path     CONSTANT VARCHAR2(50) := '?/apex/';
																				DV_path       CONSTANT VARCHAR2(50) := '?/rdbms/admin/';
								
								
@@cdfixed.sql   --Catalog FIXED views,Objects which reference fixed views
								--即,该脚本创建了大部分的gv_和v_的动态性能视图,例如:
													create or replace view v_$dataguard_status as select * from v$dataguard_status;
													create or replace public synonym v$dataguard_status for v_$dataguard_status;
													grant select on v_$dataguard_status to SELECT_CATALOG_ROLE;
													
													create or replace view v_$thread as select * from v$thread;
													create or replace public synonym v$thread for v_$thread;
													grant select on v_$thread to select_catalog_role;
													
													create or replace view v_$process as select * from v$process;
													create or replace public synonym v$process for v_$process;
													grant select on v_$process to select_catalog_role;
													
													create or replace view v_$bgprocess as select * from v$bgprocess;
													create or replace public synonym v$bgprocess for v_$bgprocess;
													grant select on v_$bgprocess to select_catalog_role;
													
													create or replace view v_$session as select * from v$session;
													create or replace public synonym v$session for v_$session;
													grant select on v_$session to select_catalog_role;
													。。。。。。。。。。。
													create or replace view gv_$sqltext as select * from gv$sqltext;
													create or replace public synonym gv$sqltext for gv_$sqltext;
													grant select on gv_$sqltext to select_catalog_role;
													
													create or replace view gv_$sqltext_with_newlines as
													      select * from gv$sqltext_with_newlines;
													create or replace public synonym gv$sqltext_with_newlines
													   for gv_$sqltext_with_newlines;
													grant select on gv_$sqltext_with_newlines to select_catalog_role;
													
													create or replace view gv_$sql as select * from gv$sql;
													create or replace public synonym gv$sql for gv_$sql;
													grant select on gv_$sql to select_catalog_role;

													。。。。。。。。。。。
													
													
@@cdcore.sql  --Catalog DCORE.bsq views,core objects。
							--This script contains catalog views for objects in dcore.bsq
							--即,基于dcore.bsq(在sql.bsq中调用)中的对象而创建的数据字典(DBA_, ALL_, USER_)
							--  _CURRENT_EDITION_OBJ  _ACTUAL_EDITION_OBJ   _BASE_USER   USER_CONS_COLUMNS   ALL_CONS_COLUMNS
							--- DBA_CONS_COLUMNS LOG_GROUP_COLUMNS  ALL_LOG_GROUP_COLUMNS  DBA_LOG_GROUP_COLUMNS
							---  syscatalog_    syscatalog   catalog   
							---  tab  col  syssegobj  sysfiles  synonyms  publicsyn
							--- TABLE_PRIVILEGES  COLUMN_PRIVILEGES  USER_LOBS, ALL_LOBS, and DBA_LOBS
							--- USER_CATALOG  ALL_CATALOG  DBA_CATALOG
							--- USER_INDEXES  ALL_INDEXES  DBA_INDEXES
							---  等等,大部分的 DBA_, ALL_, USER_

--CATCTL -M
@@cdplsql.sql   ---cdplsql.sql - Catalog DPLSQL.bsq views,libraries, procedure, etc。
								---This script contains catalog views for objects in dplsql.bsq.
								--即,基于DPLSQL.bsq(在sql.bsq中被调用。dplsql.bsq包含了procedure,function等的相关基表)中的对象而创建的数据字典
								--DPLSQL.bsq包含类似:create table procedure$ ,create table procedureinfo$ ,create table source$等等
								
@@cdsqlddl.sql  --- Catalog DSQLDDL.bsq views. database links, dictionary, recyclebin objects, etc.
								--- This script contains Catalog Views for objects in dsqlddl.bsq
								--- 即,基于dsqlddl.bsq(在sql.bsq中被调用)中的对象而创建的数据字典。例如,database links, dictionary, recyclebin等等。
								---例如 create or replace view DICTIONARY(Online documentation for data dictionary tables and views )
								------- create or replace view USER_RECYCLEBIN(List of objects in recycle bin)
												[oracrp3@ebscrp3 admin]$ cat dsqlddl.bsq|grep recycle
												create table recyclebin$
												create index recyclebin$_obj on recyclebin$(obj#)
												create index recyclebin$_ts on recyclebin$(ts#)
												create index recyclebin$_owner on recyclebin$(owner#)
												[oracrp3@ebscrp3 admin]$ 




@@cdmanage.sql  --Catalog DMANAGE.bsq views. SQL tuning, SQL text, SQL profile, etc. This script contains catalog views for objects in dmanage.bsq
								-- create or replace view V$OBJECT_USAGE

@@cdtxnspc.sql  --Catalog DTXNSPC.bsq views. two phase commit objects. This script contains catalog views for objects in dtxnspc.bsq
								-- create or replace view ps1$   create or replace view DBA_2PC_PENDING create or replace view DBA_2PC_NEIGHBORS

@@cdenv.sql  ----- Catalog DENV.bsq views. profiles, resources, etc. This script contains catalog views for objects in denv.bsq
						 ----- DBA_PROFILES USER_RESOURCE_LIMITS  USER_PASSWORD_LIMITS  
						 ----- USER_USERS  ALL_USERS  DBA_USERS
@@cdrac.sql  ------ DBA_SERVICES  ALL_SERVICES

@@cdsec.sql  ----- Catalog DSEC.bsq views .  Privilege objects
						------- SESSION_PRIVS   SESSION_ROLES  ROLE_SYS_PRIVS    ROLE_TAB_PRIVS  ROLE_ROLE_PRIVS
						------- DBA_ROLES  USER_SYS_PRIVS   USER_PROXIES   DBA_PROXIES   PROXY_USERS_AND_ROLES
						------- DBA_CONNECT_ROLE_GRANTEES
						
@@cdobj.sql  ------- Catalog DOBJ.bsq views. Nested tables, directories, operators, types, etc .This script contains catalog views for objects in dobj.bsq
						----- 调用 Rem Object views 
											@@catadt --- This SQL script creates data dictionary views for showing meta-data information for types and other object features in the RDBMS
															 ---This script must be run while connected as SYS or INTERNAL
															 ---  USER_TYPES, ALL_TYPES, and DBA_TYPES
															 --- USER_NESTED_TABLE_COLS  ALL_NESTED_TABLE_COLS     DBA_NESTED_TABLE_COLS   USER_NESTED_TABLES  ALL_NESTED_TABLES
															 --- ALL_DIRECTORIES
															 --- USER_REFS, ALL_REFS, and DBA_REFS
															 --- USER_VARRAYS   DBA_VARRAYS   ALL_VARRAYS
															 --- USER_OPERATORS  DBA_OPERATORS  ALL_OPERATORS
						

@@cdjava.sql
@@cdpart.sql
@@cdrep.sql
@@cdaw.sql
@@cdsummgt.sql
@@cdtools.sql


发表在 Installation and Deinstall | 标签为 , | 留下评论

MYSQL小白的FAQ系列—-6—-如何查看mysql中的“元数据”(类似于oracle的数据字典)

mysql中,INFORMATION_SCHEMA提供了访问数据库元数据的方式.
元数据是关于数据的数据,如数据库名或表名,列的数据类型,或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。
在mysql5.5的官方文档中有以下内容:
第23章:INFORMATION_SCHEMA信息数据库

目录
23.1. INFORMATION_SCHEMA表
23.1.1. INFORMATION_SCHEMA SCHEMATA表
23.1.2. INFORMATION_SCHEMA TABLES表
23.1.3. INFORMATION_SCHEMA COLUMNS表
23.1.4. INFORMATION_SCHEMA STATISTICS表
23.1.5. INFORMATION_SCHEMA USER_PRIVILEGES表
23.1.6. INFORMATION_SCHEMA SCHEMA_PRIVILEGES表
23.1.7. INFORMATION_SCHEMA TABLE_PRIVILEGES表
23.1.8. INFORMATION_SCHEMA COLUMN_PRIVILEGES表
23.1.9. INFORMATION_SCHEMA CHARACTER_SETS表
23.1.10. INFORMATION_SCHEMA COLLATIONS表
23.1.11. INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY表
23.1.12. INFORMATION_SCHEMA TABLE_CONSTRAINTS表
23.1.13. INFORMATION_SCHEMA KEY_COLUMN_USAGE表
23.1.14. INFORMATION_SCHEMA ROUTINES表
23.1.15. INFORMATION_SCHEMA VIEWS表
23.1.16. INFORMATION_SCHEMA TRIGGERS表
23.1.17. 其他INFORMATION_SCHEMA表

information_schema数据库是MySQL自带的(貌似mysql 5以后才有的),它提供了访问数据库元数据的方式。什么是元数据呢?元数据是关于数据的数据,如数据库名或表名,列的数据类型,或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。
在MySQL中,把 information_schema 看作是一个数据库,确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名,数据库的表,表栏的数据类型与访问权 限等。在INFORMATION_SCHEMA中,有数个只读表。它们实际上是视图,而不是基本表,因此,你将无法看到与之相关的任何文件。

mysql> use information_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> desc information_schema.tables;
+-----------------+---------------------+------+-----+---------+-------+
| Field           | Type                | Null | Key | Default | Extra |
+-----------------+---------------------+------+-----+---------+-------+
| TABLE_CATALOG   | varchar(512)        | NO   |     |         |       |
| TABLE_SCHEMA    | varchar(64)         | NO   |     |         |       |
| TABLE_NAME      | varchar(64)         | NO   |     |         |       |
| TABLE_TYPE      | varchar(64)         | NO   |     |         |       |
| ENGINE          | varchar(64)         | YES  |     | NULL    |       |
| VERSION         | bigint(21) unsigned | YES  |     | NULL    |       |
| ROW_FORMAT      | varchar(10)         | YES  |     | NULL    |       |
| TABLE_ROWS      | bigint(21) unsigned | YES  |     | NULL    |       |
| AVG_ROW_LENGTH  | bigint(21) unsigned | YES  |     | NULL    |       |
| DATA_LENGTH     | bigint(21) unsigned | YES  |     | NULL    |       |
| MAX_DATA_LENGTH | bigint(21) unsigned | YES  |     | NULL    |       |
| INDEX_LENGTH    | bigint(21) unsigned | YES  |     | NULL    |       |
| DATA_FREE       | bigint(21) unsigned | YES  |     | NULL    |       |
| AUTO_INCREMENT  | bigint(21) unsigned | YES  |     | NULL    |       |
| CREATE_TIME     | datetime            | YES  |     | NULL    |       |
| UPDATE_TIME     | datetime            | YES  |     | NULL    |       |
| CHECK_TIME      | datetime            | YES  |     | NULL    |       |
| TABLE_COLLATION | varchar(32)         | YES  |     | NULL    |       |
| CHECKSUM        | bigint(21) unsigned | YES  |     | NULL    |       |
| CREATE_OPTIONS  | varchar(255)        | YES  |     | NULL    |       |
| TABLE_COMMENT   | varchar(2048)       | NO   |     |         |       |
+-----------------+---------------------+------+-----+---------+-------+
21 rows in set (0.00 sec)

mysql> 

information_schema数据库表说明:
SCHEMATA表:提供了当前mysql实例中所有数据库的信息。是show databases的结果取之此表。
TABLES表:提供了关于数据库中的表的信息(包括视图)。详细表述了某个表属于哪个schema,表类型,表引擎,创建时间等信息。是show tables from schemaname的结果取之此表。
COLUMNS表:提供了表中的列信息。详细表述了某张表的所有列以及每个列的信息。是show columns from schemaname.tablename的结果取之此表。
STATISTICS表:提供了关于表索引的信息。是show index from schemaname.tablename的结果取之此表。
USER_PRIVILEGES(用户权限)表:给出了关于全程权限的信息。该信息源自mysql.user授权表。是非标准表。
SCHEMA_PRIVILEGES(方案权限)表:给出了关于方案(数据库)权限的信息。该信息来自mysql.db授权表。是非标准表。
TABLE_PRIVILEGES(表权限)表:给出了关于表权限的信息。该信息源自mysql.tables_priv授权表。是非标准表。
COLUMN_PRIVILEGES(列权限)表:给出了关于列权限的信息。该信息源自mysql.columns_priv授权表。是非标准表。
CHARACTER_SETS(字符集)表:提供了mysql实例可用字符集的信息。是SHOW CHARACTER SET结果集取之此表。
COLLATIONS表:提供了关于各字符集的对照信息。
COLLATION_CHARACTER_SET_APPLICABILITY表:指明了可用于校对的字符集。这些列等效于SHOW COLLATION的前两个显示字段。
TABLE_CONSTRAINTS表:描述了存在约束的表。以及表的约束类型。
KEY_COLUMN_USAGE表:描述了具有约束的键列。
ROUTINES表:提供了关于存储子程序(存储程序和函数)的信息。此时,ROUTINES表不包含自定义函数(UDF)。名为“mysql.proc name”的列指明了对应于INFORMATION_SCHEMA.ROUTINES表的mysql.proc表列。
VIEWS表:给出了关于数据库中的视图的信息。需要有show views权限,否则无法查看视图信息。
TRIGGERS表:提供了关于触发程序的信息。必须有super权限才能查看该表

mysql> SELECT table_name, table_schema,table_type, engine
    -> FROM information_schema.tables;
+---------------------------------------+--------------------+-------------+--------+
| table_name                            | table_schema       | table_type  | engine |
+---------------------------------------+--------------------+-------------+--------+
| CHARACTER_SETS                        | information_schema | SYSTEM VIEW | MEMORY |
| COLLATIONS                            | information_schema | SYSTEM VIEW | MEMORY |
| COLLATION_CHARACTER_SET_APPLICABILITY | information_schema | SYSTEM VIEW | MEMORY |
| COLUMNS                               | information_schema | SYSTEM VIEW | MyISAM |
| COLUMN_PRIVILEGES                     | information_schema | SYSTEM VIEW | MEMORY |
| ENGINES                               | information_schema | SYSTEM VIEW | MEMORY |
| EVENTS                                | information_schema | SYSTEM VIEW | MyISAM |
| FILES                                 | information_schema | SYSTEM VIEW | MEMORY |
| GLOBAL_STATUS                         | information_schema | SYSTEM VIEW | MEMORY |
| GLOBAL_VARIABLES                      | information_schema | SYSTEM VIEW | MEMORY |
| KEY_COLUMN_USAGE                      | information_schema | SYSTEM VIEW | MEMORY |
| OPTIMIZER_TRACE                       | information_schema | SYSTEM VIEW | MyISAM |
| PARAMETERS                            | information_schema | SYSTEM VIEW | MyISAM |
| PARTITIONS                            | information_schema | SYSTEM VIEW | MyISAM |
| PLUGINS                               | information_schema | SYSTEM VIEW | MyISAM |
| PROCESSLIST                           | information_schema | SYSTEM VIEW | MyISAM |
| PROFILING                             | information_schema | SYSTEM VIEW | MEMORY |
| REFERENTIAL_CONSTRAINTS               | information_schema | SYSTEM VIEW | MEMORY |
| ROUTINES                              | information_schema | SYSTEM VIEW | MyISAM |
| SCHEMATA                              | information_schema | SYSTEM VIEW | MEMORY |
| SCHEMA_PRIVILEGES                     | information_schema | SYSTEM VIEW | MEMORY |
| SESSION_STATUS                        | information_schema | SYSTEM VIEW | MEMORY |
| SESSION_VARIABLES                     | information_schema | SYSTEM VIEW | MEMORY |
| STATISTICS                            | information_schema | SYSTEM VIEW | MEMORY |
| TABLES                                | information_schema | SYSTEM VIEW | MEMORY |
| TABLESPACES                           | information_schema | SYSTEM VIEW | MEMORY |
| TABLE_CONSTRAINTS                     | information_schema | SYSTEM VIEW | MEMORY |
| TABLE_PRIVILEGES                      | information_schema | SYSTEM VIEW | MEMORY |
| TRIGGERS                              | information_schema | SYSTEM VIEW | MyISAM |
| USER_PRIVILEGES                       | information_schema | SYSTEM VIEW | MEMORY |
| VIEWS                                 | information_schema | SYSTEM VIEW | MyISAM |
| INNODB_LOCKS                          | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_TRX                            | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_DATAFILES                  | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_LOCK_WAITS                     | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_TABLESTATS                 | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMP                            | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_METRICS                        | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMP_RESET                      | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMP_PER_INDEX                  | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMPMEM_RESET                   | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_DELETED                     | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_BUFFER_PAGE_LRU                | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_FOREIGN                    | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_COLUMNS                    | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_INDEXES                    | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_DEFAULT_STOPWORD            | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_FIELDS                     | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMP_PER_INDEX_RESET            | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_BUFFER_PAGE                    | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_CMPMEM                         | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_INDEX_TABLE                 | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_BEING_DELETED               | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_TABLESPACES                | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_INDEX_CACHE                 | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_FOREIGN_COLS               | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_SYS_TABLES                     | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_BUFFER_POOL_STATS              | information_schema | SYSTEM VIEW | MEMORY |
| INNODB_FT_CONFIG                      | information_schema | SYSTEM VIEW | MEMORY |
| columns_priv                          | mysql              | BASE TABLE  | MyISAM |
| db                                    | mysql              | BASE TABLE  | MyISAM |
| event                                 | mysql              | BASE TABLE  | MyISAM |
| func                                  | mysql              | BASE TABLE  | MyISAM |
| general_log                           | mysql              | BASE TABLE  | CSV    |
| help_category                         | mysql              | BASE TABLE  | MyISAM |
| help_keyword                          | mysql              | BASE TABLE  | MyISAM |
| help_relation                         | mysql              | BASE TABLE  | MyISAM |
| help_topic                            | mysql              | BASE TABLE  | MyISAM |
| innodb_index_stats                    | mysql              | BASE TABLE  | InnoDB |
| innodb_table_stats                    | mysql              | BASE TABLE  | InnoDB |
| ndb_binlog_index                      | mysql              | BASE TABLE  | MyISAM |
| plugin                                | mysql              | BASE TABLE  | MyISAM |
| proc                                  | mysql              | BASE TABLE  | MyISAM |
| procs_priv                            | mysql              | BASE TABLE  | MyISAM |
| proxies_priv                          | mysql              | BASE TABLE  | MyISAM |
| servers                               | mysql              | BASE TABLE  | MyISAM |
| slave_master_info                     | mysql              | BASE TABLE  | InnoDB |
| slave_relay_log_info                  | mysql              | BASE TABLE  | InnoDB |
| slave_worker_info                     | mysql              | BASE TABLE  | InnoDB |
| slow_log                              | mysql              | BASE TABLE  | CSV    |
| tables_priv                           | mysql              | BASE TABLE  | MyISAM |
| time_zone                             | mysql              | BASE TABLE  | MyISAM |
| time_zone_leap_second                 | mysql              | BASE TABLE  | MyISAM |
| time_zone_name                        | mysql              | BASE TABLE  | MyISAM |
| time_zone_transition                  | mysql              | BASE TABLE  | MyISAM |
| time_zone_transition_type             | mysql              | BASE TABLE  | MyISAM |
| user                                  | mysql              | BASE TABLE  | MyISAM |
+---------------------------------------+--------------------+-------------+--------+
87 rows in set (0.01 sec)

mysql> 

SELECT table_name, table_schema,table_type, engine
FROM information_schema.tables
WHERE table_schema = 'mysql'
ORDER BY table_name DESC;

INFORMATION_SCHEMA是信息数据库,其中保存着关于MySQL服务器所维护的所有其他数据库的信息。在INFORMATION_SCHEMA中,有数个只读表。
它们实际上是视图,而不是基本表,因此,你将无法看到与之相关的任何文件。
每位MySQL用户均有权访问这些表,但仅限于表中的特定行,在这类行中含有用户具有恰当访问权限的对象。

发表在 FAQ | 标签为 , , | 留下评论

MYSQL小白的FAQ系列—-5—-如何查看mysql中的历史命令

如何查看mysql中的历史命令:
[root@lunar ~]# cat ~/.mysql_history
_HiStOrY_V2_
show\040databases;
FLUSH\040PRIVILEGES;
show\040databases;
create\040database\040lunardb;
show\040databases;
show\040user;
show\040users;
show\040tables;
use\040lunardb
show\040tables;
use\040mysql
show\040databases;
show\040databases
;
desc\040user;
use\040lunardb
desc\040user;
use\040mysql
help
status
connect?
;
connect
go
go\040mysql
;
select\040*\040from\040user;
select\040*\040from\040users;
show\040user;
desc\040user;
show\040databases;
show\040columns\040from\040user;
use\040test
show\040user;
desc\040user;
select\040*\040from\040’USER’;
show\040user;
SELECT\040*\040FROM\040`user`;
flush\040privileges;
show\040user;
show\040user
;
select\040user();
use\040lunardb;
select\040user();
show\040user();
select\040user();
[root@lunar ~]#

发表在 FAQ | 标签为 , | 留下评论