Dataguard一主多备配置报错处理

来源:互联网 发布:c 五子棋源码 编辑:程序博客网 时间:2024/05/22 12:58
tail -f /u01/app/oracle/diag/rdbms/hzjxc/hzjxc/trace/alert_hzjxc.log[oracle@hzjxc dbs]$ more /u01/app/oracle/diag/rdbms/hzjxc/hzjxc/trace/hzjxc_lgwr_17021.trcTrace file /u01/app/oracle/diag/rdbms/hzjxc/hzjxc/trace/hzjxc_lgwr_17021.trcOracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsORACLE_HOME = /u01/app/oracle/11204System name:    LinuxNode name:      hzjxcRelease:        2.6.32-431.el6.x86_64Version:        #1 SMP Sun Nov 10 22:19:54 EST 2013Machine:        x86_64Instance name: hzjxcRedo thread mounted by this instance: 1Oracle process number: 15Unix process pid: 17021, image: oracle@hzjxc (LGWR)*** 2017-02-23 14:37:14.486*** SESSION ID:(856.1) 2017-02-23 14:37:14.486*** CLIENT ID:() 2017-02-23 14:37:14.486*** SERVICE NAME:(SYS$BACKGROUND) 2017-02-23 14:37:14.486*** MODULE NAME:() 2017-02-23 14:37:14.486*** ACTION NAME:() 2017-02-23 14:37:14.486 *** 2017-02-23 14:37:14.486 7160 krsu.cNo LNS exists (ocis 0x7fc086f53d48) that requires a disconnect*** 2017-02-23 14:37:14.486 7977 krsu.cReusing NSS3 ...Subscribing to KSR Channel [id=33]          success!Indicating recv buffer for KSR Channel [id=21]  success*** 2017-02-23 14:37:14.486 8040 krsu.cNetserver NSS3 [pid 17066] for mode SYNC has been re-initializedPerforming a channel reset to ignore previous responsesConnecting as publisher to KSR Channel [id=21]Successfully reused NSS3 [pid 17066] for dest dg2 mode SYNC ocis=0x7fc086f53d48*** 2017-02-23 14:37:14.513 3784 krsu.c   upiahm connect done status is 0Incident 264121 created, dump file: /u01/app/oracle/diag/rdbms/hzjxc/hzjxc/incident/incdir_264121/hzjxc_lgwr_17021_i264121.trcORA-00600: internal error code, arguments: [krsu_upi_atc.7], [], [], [], [], [], [], [], [], [], [], []error 470 detected in background processORA-00600: internal error code, arguments: [krsu_upi_atc.7], [], [], [], [], [], [], [], [], [], [], []kjzduptcctx: Notifying DIAG for crash event----- Abridged Call Stack Trace -----ksedsts()+465<-kjzdssdmp()+267<-kjzduptcctx()+232<-kjzdicrshnfy()+63<-ksuitm()+5570<-ksbrdp()+3507<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201<-__libc_start_main()+253 ----- End of Abridged Call Stack Trace -----*** 2017-02-23 14:37:15.104LGWR (ospid: 17021): terminating the instance due to error 470ksuitm: waiting up to [5] seconds before killing DIAG(17003)



原因是:

原因找到了,两个备库db_unique_name设备一样了


alter system set log_archive_dest_3='service=SDCRM01 valid_for=(online_logfiles,primary_role) LGWR SYNC Affirm NET_TIMEOUT=100 REOPEN=10 COMPRESSION=ENABLE db_unique_name=CDCRM01';
是因为我的standby 是在两台机器上,  主被机的db_unique_name都设置成一样的.所以报上边的错.
所以发现.如果不使用LGWR来传输日志是不会有问题的.
得出的结论: 我们在做备用机的时候,很多时候想两边机器设置成一摸一样,这样可以更加放心一点.其实不然,db_unique_name一定要唯一.不然会产生很多莫名的问题.


主库db_unique_name是:hzjxc

备库1是:dg       --db_unique_name

备库2是:dg2     --db_unique_name


正确的参数配置如下:

主库:

---修改参数文件
alter system set db_unique_name=hzjxc scope=spfile;
alter system set log_archive_config='dg_config=(hzjxc,dg,dg2)' scope=spfile;
alter system set log_archive_dest_2='service=dg LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=dg' scope=spfile; 
alter system set log_archive_dest_3='service=dg2 LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=dg2' scope=spfile; 
alter system set fal_server=dg,dg2 scope=spfile;    --备库为服务端
alter system set fal_client=hzjxc scope=spfile;    --日志发起者为客户端


alter system set standby_file_management=auto scope=spfile;
alter system set log_archive_dest_state_1=enable scope=spfile;
alter system set log_archive_dest_state_2=enable scope=spfile;
alter system set log_archive_dest_state_3=enable scope=spfile;


备库1:

alter system set log_archive_config='dg_config=(hzjxc,dg,dg2)' scope=spfile;
alter system set db_unique_name=dg scope=spfile;
alter system set log_archive_dest_2='service=hzjxc LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=hzjxc' scope=spfile; 
alter system set log_archive_dest_3='service=dg2 LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=dg2' scope=spfile; 
alter system set fal_server=hzjxc,dg2 scope=spfile;    --备库为服务端
alter system set fal_client=dg scope=spfile;    --日志发起者为客户端
alter system set standby_file_management=auto scope=spfile;
alter system set log_archive_dest_state_1=enable scope=spfile;
alter system set log_archive_dest_state_2=enable scope=spfile;
alter system set log_archive_dest_state_3=enable scope=spfile;


备库2:

alter system set log_archive_config='dg_config=(hzjxc,dg,dg2)' scope=spfile;
alter system set db_unique_name=dg2 scope=spfile;
alter system set log_archive_dest_2='service=hzjxc LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=hzjxc' scope=spfile; 
alter system set log_archive_dest_3='service=dg2 LGWR SYNC affirm  valid_for=(online_logfiles,primary_role) db_unique_name=dg2' scope=spfile; 
alter system set fal_server=hzjxc,dg scope=spfile;    --备库为服务端
alter system set fal_client=dg2 scope=spfile;    --日志发起者为客户端


alter system set standby_file_management=auto scope=spfile;
alter system set log_archive_dest_state_1=enable scope=spfile;
alter system set log_archive_dest_state_2=enable scope=spfile;
alter system set log_archive_dest_state_3=enable scope=spfile;

0 0
原创粉丝点击