dataguard中有关lgwr async的测试

oracle选择了折中的办法...[@more@]

有关dataguard的几个有意思的问题
1.standby db上RFS进程是用户进程,不是后台进程,需要从primary db上获取log或者
primary db上的LNS进程需要把log传递给RFS时RFS才启动
2.在配置standby时primary db上的log_archive_dest_2如下:
SQL> show parameter log_archive_dest_2

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=orcl_s LGWR ASYNC VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=orcls
standby db上的log_archive_dest_2如下:
SQL> show parameter log_archive_dest_2

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=orcl_p LGWR ASYNC VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=orclp
SQL>
--显示log_archive_dest_2的值是想告诉大家是采用LGWR ASYNC方式传递redo
尽管我们指定了redo是由LGWR发送的,但是别忘了我们还指定了ASYNC,因此redo最终
其实可能是由lgwr通过lns进程传给rfs的,当然这种方式其实就是sync方式传递,既然是
sync方式传递的,可为什么standby又不需要standby redo logfile呢?这里我在配置standby
时没有创建standby redo logfile:
SQL> select count(*) from v$standby_log;

COUNT(*)
----------
0

SQL>
没有standby redo logfile,那么sync方式rfs最终能直接写redo到archivelog吗?
很显然不能,这里其实存在一个临时的standby redo logfile在standby db的log_archive_dest_1参数下面:
SQL> show parameter log_archive_dest_1

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string LOCATION=E:archivelogorcls
VALID_FOR=(ALL_LOGFILES,ALL_RO
LES) DB_UNIQUE_NAME=orcls
--=======================
E:archivelogorcls>dir
驱动器 E 中的卷没有标签。
卷的序列号是 F6E5-4B31

E:archivelogorcls 的目录

2010-02-05 11:24

E:archivelogorcls>
primary db上显示的当前日志序列是44
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 E:archivelogorclp
最早的联机日志序列 42
下一个存档日志序列 44
当前日志序列 44
SQL>
standby db上显示43#日志已经被传递过来而且applied了:
SQL> select sequence#,creator,registrar,applied,fal from v$archived_log order by
recid , name;

SEQUENCE# CREATOR REGISTR APP FAL
---------- ------- ------- --- ---
18 ARCH RFS YES YES
19 ARCH RFS YES YES
20 ARCH RFS YES YES
21 ARCH RFS YES YES
22 ARCH RFS YES YES
23 ARCH RFS YES YES
24 ARCH RFS YES YES
25 ARCH RFS YES YES
26 ARCH RFS YES YES
27 ARCH RFS YES YES
28 ARCH RFS YES YES

SEQUENCE# CREATOR REGISTR APP FAL
---------- ------- ------- --- ---
29 ARCH RFS YES YES
30 ARCH RFS YES YES
31 ARCH RFS YES YES
32 LGWR RFS YES NO
33 ARCH RFS YES YES
34 ARCH RFS YES YES
35 ARCH RFS YES YES
36 LGWR RFS YES NO
37 LGWR RFS YES NO
38 LGWR RFS YES NO
39 LGWR RFS YES NO

SEQUENCE# CREATOR REGISTR APP FAL
---------- ------- ------- --- ---
40 LGWR RFS YES NO
41 ARCH RFS YES YES
42 ARCH RFS YES YES
43 LGWR RFS YES NO

已选择26行。

SQL>
而且43日值的creator是:lgwr,42的creator是arch
我们看一下standby db下的v$managed_standby:
SQL> select process,status,pid,client_process,client_pid,group#,sequence#,block#
from v$managed_standby;

PROCE STATUS PID CLIENT_P CLIEN GROUP SEQUENCE# BLOCK#
----- ------------ ----- -------- ----- ----- ---------- ----------
ARCH CONNECTED 1452 ARCH 1452 N/A 0 0
ARCH CONNECTED 2188 ARCH 2188 N/A 0 0
MRP0 WAIT_FOR_LOG 820 N/A N/A N/A 44 0
RFS IDLE 3120 UNKNOWN 1908 N/A 0 0
RFS IDLE 3016 LGWR 140 2 44 9657

SQL>
这里我们发现pid=3016对应的rfs进程它对应的client_process是lgwr,对应的client_pid是140,这里的client当然就是指
primary db了,我们在primary db上查询140进程:
SQL> select addr,pid,program,background from v$process where spid=140;

ADDR PID PROGRAM B
-------- ---------- -------------------- -
6D24D7CC 18 ORACLE.EXE (LNS1) 1

SQL>
清楚的发现lgwr对应的这个140进程其实就是primary db上的lns进程.同时在
v$managed_standby里面发现group=2,sequence#=44的日志其实正好是对应的
primary db上的当前联机日志:
primary db:
SQL> select group#,sequence#,status,archived from v$log;

GROUP# SEQUENCE# STATUS ARC
---------- ---------- ---------------- ---
1 43 INACTIVE YES
2 44 CURRENT NO
3 42 INACTIVE YES

SQL>
这里已经很清楚了,进一步验证了standby db下的目录e:archivelogorcls下的文件
1_44_708970768.ARC其实就是一个standby db下临时的当前联机日志,什么时候用到这个
临时的当前联机日志呢?就是primary db上的lgwr通过lns进程sync的向standby db上的rfs发送
redo时需要的;那么真真的lgwr async其实最终又变成了arch传输模式,就像42#归档日志就是arch
通过网络传递给rfs的,当然arch传输日志是不需要通过lns进程的.我们发现
凡是由lgwr传送的日志,FAL的状态是no,由arch传送的FAL的状态YES.
再来看pid=3120对应的rfs进程它对应的client_process是UNKNOWN,对应的client_pid是1908,这里的client当然就是指
primary db了,我们在primary db上查询1908进程:
SQL> select addr,pid,program,background from v$process where spid=1908;

ADDR PID PROGRAM B
-------- ---------- -------------------- -
6D24C5FC 15 ORACLE.EXE (ARC1) 1

SQL>
很显然是一个archive进程
--================================
SQL> alter database recover managed standby database cancel;

数据库已更改。

SQL> shutdown immediate
ORA-01109: 数据库未打开

已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE 例程已经启动。

Total System Global Area 167772160 bytes
Fixed Size 1247900 bytes
Variable Size 75498852 bytes
Database Buffers 88080384 bytes
Redo Buffers 2945024 bytes
数据库装载完毕。
SQL> select process,status,pid,client_process,client_pid,group#,sequence#,block#
from v$managed_standby;

PROCE STATUS PID CLIENT_P CLIEN GROUP SEQUENCE# BLOCK#
----- ------------ ----- -------- ----- ----- ---------- ----------
ARCH CONNECTED 3988 ARCH 3988 N/A 0 0
ARCH CONNECTED 984 ARCH 984 N/A 0 0

SQL> alter database recover managed standby database disconnect from session;

数据库已更改。

SQL> select process,status,pid,client_process,client_pid,group#,sequence#,block#
from v$managed_standby;

PROCE STATUS PID CLIENT_P CLIEN GROUP SEQUENCE# BLOCK#
----- ------------ ----- -------- ----- ----- ---------- ----------
ARCH CONNECTED 3988 ARCH 3988 N/A 0 0
ARCH CONNECTED 984 ARCH 984 N/A 0 0
MRP0 WAIT_FOR_LOG 1696 N/A N/A N/A 44 0

SQL>
--重启standby db之后发现那个临时的联机日志不见了:
E:archivelogorcls>dir
驱动器 E 中的卷没有标签。
卷的序列号是 F6E5-4B31

E:archivelogorcls 的目录

2010-02-05 12:23

E:archivelogorcls>
--============================
在primary db上:
SQL> insert into t values(8);

已创建 1 行。

SQL> commit;

提交完成。

SQL>
在standby上没有发现临时的联机日志,这是后rfs已经启动了:
SQL> select process,status,pid,client_process,client_pid,group#,sequence#,block#
from v$managed_standby;

PROCE STATUS PID CLIENT_P CLIEN GROUP SEQUENCE# BLOCK#
----- ------------ ----- -------- ----- ----- ---------- ----------
ARCH CONNECTED 3988 ARCH 3988 N/A 0 0
ARCH CONNECTED 984 ARCH 984 N/A 0 0
MRP0 WAIT_FOR_LOG 1696 N/A N/A N/A 44 0
RFS IDLE 1884 N/A 1908 N/A 0 0
在primary db上switch logfile:
SQL> alter system switch logfile;

系统已更改。

SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 E:archivelogorclp
最早的联机日志序列 43
下一个存档日志序列 45
当前日志序列 45
SQL>
在standby db上生成了临时的联机日志,同时44号文件也被传递到了standby上:
E:archivelogorcls>dir
驱动器 E 中的卷没有标签。
卷的序列号是 F6E5-4B31

E:archivelogorcls 的目录

2010-02-05 12:32

E:archivelogorcls>
同时又多了一个rfs进程:
SQL> select process,status,pid,client_process,client_pid,group#,sequence#,block#
from v$managed_standby;

PROCE STATUS PID CLIENT_P CLIEN GROUP SEQUENCE# BLOCK#
----- ------------ ----- -------- ----- ----- ---------- ----------
ARCH CONNECTED 3988 ARCH 3988 N/A 0 0
ARCH CONNECTED 984 ARCH 984 N/A 0 0
MRP0 WAIT_FOR_LOG 1696 N/A N/A N/A 45 0
RFS IDLE 1884 UNKNOWN 1908 N/A 0 0
RFS IDLE 3428 LGWR 140 3 45 124

SQL>
接下来我们看看44#归档日志是被arch还是lgwr传给rfs的:
standby db:
SQL> select sequence#,creator,registrar,applied,fal from v$archived_log where se
quence#=44 order by recid , name;

SEQUENCE# CREATOR REGISTR APP FAL
---------- ------- ------- --- ---
44 ARCH RFS YES YES

SQL>
显然是由arch进程传的
再次在primary db上切换日志,在从db上查看45#日志发现是由lgwr传送的:
SQL> select sequence#,creator,registrar,applied,fal from v$archived_log where se
quence#=45 order by recid , name;

SEQUENCE# CREATOR REGISTR APP FAL
---------- ------- ------- --- ---
45 LGWR RFS YES NO

SQL>
所以这里我认为只要是使用lgwr传输日志最好创建standby redo logfile

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/19602/viewspace-1031140/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/19602/viewspace-1031140/