Tag Archives: dataguard

RMAN-06820 During Backup at dataguard

0

Posted on by

在数据库版本 11.2.0.4 dataguard上备份有以下的错误:

	Starting backup at 2016-03-15 14:12:35

	RMAN-06820: WARNING: failed to archive current log at primary database

	ORACLE error from target database: 

	ORA-17629: Cannot connect to the remote database server

	ORA-17627: ORA-00942: table or view does not exist

 

需要把登入方式修改下

 

SOLUTION

Workaround

Do not use operating system authentication to login with RMAN. Use a username and password.

That is, do not use just the "/" (operating system authentication) connect to the standby database:

$ rman target /


Instead put in the username and password for the SYSDBA user:


$ rman sys/password

 

kcbgtcr_13 on active dataguard

0

Posted on by

今天在acitve dataguard上报出一个错误,在监控表空间时报出的,

经查为bug Bug 12848798 – OERI:kcbgtcr_13 on active dataguard [ID 12848798.8]

数据库版本为:11.2.0.3.5 

错误内容:

	ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [], [], [], [], [], [], [], [], [], []

在查询V$或者X$会报出的。

下载补丁:12848798可解决

Affects:

Product (Component)

Oracle Server (Rdbms)

Range of versions believed to be affected

Versions >= 10.2 but BELOW 12.1

Versions confirmed as being affected

Platforms affected

Generic (all / most platforms affected)

Fixed:

The fix for 12848798 is first included in

 

Use EXPDP FOR Physical Standby Database

0

Posted on by

  正常情况下在物理dataguard上是不能expdp,还好expdp有个NETWORK_LINK功能,可以巧妙的导出dump文件。

 

如果是10g,需要先open下

SQL> alter database recover managed standby database cancel;
SQL> alter database open read only;

 

–在一个临时数据库上新建一个到物理dataguard的dblink

SQL> create database link expdp_primary connect to system identified by password using 'standby_database';
SQL> select sysdate from dual@expdp_primary;
SQL> create directory datapump as '/u01';


–在临时数据库的服务器上执行
expdp system/password directory=datapump network_link=expdp_primary full=y dumpfile=standby_database.dmp logfile=standby_database.log

 

如果是exp就没有问题,直接可以导出。

参考:How To Use DataPump Export (EXPDP) To Export From Physical Standby Database (文档 ID 1356592.1)

ORACLE 11G SNAPSHOT STANDBY转换

0

Posted on by

PHYSICAL STANDBY Convert to SNAPSHOT STANDBY

 

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=50g scope=both;
 
SQL> alter system set db_recovery_file_dest='/u01/flasharch' scope=both;

SQL> alter database recover managed standby database cancel;

SQL> select database_role,db_unique_name,open_mode from v$database;

SQL> alter database convert to snapshot standby;

SQL> select database_role,db_unique_name,open_mode from v$database;

SQL> alter database open;

 

 

SNAPSHOT STANDBY Convert to PHYSICAL STANDBY

 

SQL> shutdown immedaite

SQL> startup mount

SQL> select database_role,db_unique_name,open_mode from v$database;

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

SQL> select database_role,db_unique_name,open_mode from v$database;

SQL> alter database recover managed standby database using current logfile disconnect from session;

 

 

大量update导致的逻辑dataguard延迟

1

Posted on by

处理过程:

 1.关闭apply

alter database stop logical standby apply;

停止不掉可以强制关闭

alter database abort logical standby apply;

 

2.排除表

EXEC DBMS_LOGSTDBY.SKIP('DML','ORADBCA','T_TRANSACTION_ORDER');

update system.logstdby$skip
set esc = '\'
where esc is NULL;
commit;

 

3.重新应用

alter database start logical standby apply immediate;

 

4.关闭应用

alter database stop logical standby apply;

 

5.把排除的表,重新恢复同步

EXEC DBMS_LOGSTDBY.UNSKIP('DML','ORADBCA','T_TRANSACTION_ORDER');

 

6.表初始化

exec dbms_logstdby.instantiate_table('ORADBCA','T_TRANSACTION_ORDER','Pridb');

 

7.起同步进程

alter database start logical standby apply immediate;

 

8.check check

 

 

–附检查sql

select * from V$LOGSTDBY_STATE;

select * from V$LOGSTDBY_STATS;

 

select * from V$LOGSTDBY_PROGRESS;

select * from V$LOGSTDBY_PROCESS;

 

 

select 'Logical standbydb delay '||(sysdate-lp.APPLIED_TIME)*24*3600||'s' delay from v$logstdby_progress lp,v$database d

where d.database_role= 'LOGICAL STANDBY';