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;
- Dataguard一主多备配置报错处理
- EhCache配置报错处理方法记录
- ASPxGridView报错处理
- mencoder 报错处理
- tomcat报错处理
- Unity 报错处理
- @override 报错处理
- javaee报错处理
- RSS报错处理
- SVN报错处理
- hadoop报错处理
- Unity 报错处理
- ZF报错处理
- override 报错处理
- adb报错处理
- MySQL报错处理
- MyBatis报错处理
- @override 报错处理
- 数据结构 最短路径之—迪杰斯特拉算法
- Ubuntu-unable to resolve host
- 002_第一个SpringBoot项目
- Linux信号(Signal)
- 蚂蚁的难题(八)
- Dataguard一主多备配置报错处理
- 3.揭秘angular2学习 ------- 模版
- 1052. 卖个萌 (20)
- 信号处理中的滤波器的阶数和谐波的理解
- 怎么看《就算老公一毛钱股份都没拿到,在我心里,他依然是最牛逼的创业者》文中创业公司 CEO 的行为?
- Opencv2系列学习笔记9(使用Canny算子检测轮廓)
- size_t、ssize_t类型
- java根据正则表达式查出对应字符,并在查到的字符基础上作修改
- MATLAB R2016b 安装教程