Dataguard小结--2

五、DG进程

1、主库进程

在主库上必须有LNSn进程

LNSn进程的作用：在主库配置完成后，需要将主库的日志传输到备库，此时，主库的lgwr进程触发LNSn进程来完成这个任务；

LNSn：LGWR触发以后真正负责传输的进程，包括初始化网络I/O等一些列功能。

lgwr==>LNSn==>RFS

SQL>  select process from v$managed_standby;

PROCESS

---------

ARCH

ARCH

ARCH

ARCH

LNS

2、备库进程

而在备库上则必须有RFS进程和MRP进程

MRP：managed recovery process，简单来说就是物理standby是通过这个进程来实现数据的同步的，直接通过standby redo log或者是归档日志（取决于模式不同）来进行的一个数据恢复。

MRP进程的作用：该进程只针对物理备库。该进程应用归档日志到备库。如果我们使用SQL语句启用该进程ALTER DATABASE RECOVER MANAGED STANDBY DATABASE，那么前台进程将会做恢复。如果加上disconnect语句，那么恢复过程将在后台进程，发出该语句的进程可以继续做其他的事情。

RFS进程的作用：remote file service

Rfs进程主要用来接受从主库传送过来的日志信息。对于物理备用数据库而言，RFS进程可以直接将日志写进备用重做日志，也可以直接将日志信息写到归档日志中。为了使用备库重做日志，我们必须创建他们，一般和主库的联机日志大小以及组一样。

SQL>  select process from v$managed_standby;

PROCESS

---------

ARCH

ARCH

ARCH

ARCH

MRP0

RFS

RFS

RFS

RFS

LSP:logical standby process：逻辑standby的方式，和上面的一样，只不过当中多了一步将redo信息转换成sql语句再恢复。也可以从这里看出逻辑standby和物理standby的不同。

mrp进程停止期间，只要RFS进程存在，那么不影响日志的接收

六、DG视图

v$managed_standby

主要用来检查在主备两端的进程以及状态；

SQL>  select  process,status  from  v$managed_standby;

v$archive_gap

主要用来查看备库丢失的日志，在配置了fal_server/fal_client的DG一般是不会发生的。

v$archive_dest

主要用来协助alert日志定位日志无法传送的错误信息

SQL.> select  dest_name,status,error  from v$archive_dest;

v$archive_dest_status

可以用来查询备库状态，保护模式和归档日志路径等

v$archive_log

主要用来查看应用到了第几个归档日志

SQL> selectfirst_time,applied,sequence#,status,next_time from v$archived_log;

v$database

主要查询主备两端的数据库状态和模式

七、DG运维

1、归档日志管理

在DG中一般默认是使用最大性能模式，因此归档日志的管理显得非常重要；

原则：现在备库上删除已经应用的日志，然后在主库上删除相同的日志。

检查备库上已经应用的日志：

SELECT name, SEQUENCE#,FIRST_TIME, REGISTRAR, APPLIED, NEXT_TIME, status

  FROM V$ARCHIVED_LOG

 where applied = 'YES'

   and REGISTRAR = 'RFS'

   and name is not null

 ORDER BY SEQUENCE#;

可以手动删除也可以脚本实现。

1、常见问题解决

1）、密码文件的一致性

密码文件是有格式的，排错用了很长时间，希望跟我犯同样错误的能尽快解决。

For example, for a database instance with the SID orcldw, the password file must be named orapworcldw  on Linux and PWDorcldw.ora on Windows.

2）、网络问题

需要进一步排错。

3）、归档中断

1、在备库检查是否有日志缺失

SQL> select * fromV$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE#HIGH_SEQUENCE#

------- ---------------------------

1           101            105

从上面的信息可以看出，备库中缺失了101到105的日志。

2、在主库中查询缺失的日志的所在路径和名称

SQL> SELECT NAME FROMV$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 101 AND 105;

3、把日志拷贝到备库上

scp /oradata/*.arc  10.1.25.2:/u01/oradata/archivelog/

4、在备库上手工注册上一步中从主库拷贝来的日志

SQL> ALTER DATABASEREGISTER LOGFILE '/u01/oradata/archivelog/*.arc';

Database altered.

......

5、检查备库的alert日志信息，确定是否应用

Media Recovery Log/u01/oradata/archivelog/*****.arc

......

6、再次确定备库有无gap

SQL> select * fromV$ARCHIVE_GAP;

no rows selected

4）、归档丢失的异常恢复

来自mos的解决方法

You can create an incremental backup of the target database containingchanges to the database since the creation of the duplicate or the previoussyncrhonization. You can apply the incremental backup to the standby database.

 

Note:

This technique cannot be used to update a duplicate database.

RMAN enables you to synchronize a standby database with a primary databaseby creating an incremental backup at the source database that contains allchanged blocks since the duplicate was created or last refreshed. You thenapply the incremental backup to the standby database, which updates it with allchanges.

This capability facilitates the temporary conversion of a physical standbydatabase into a reporting database, as described in Oracle Data GuardConcepts and Administration. In particular, this capabilitymakes it possible to reverse the effects of converting the standby into areporting database. After the standby database has been used for reporting ortesting, Flashback Database can reverse any changes resulting from that work,returning the database to its contents when it was still a standby. Anincremental backup created with BACKUP INCREMENTAL... FROM SCN can be used torefresh the standby with changes at the primary since the conversion and thenmanaged recovery can resume. The effect is to return the reporting database toits role as standby.

For more details on this scenario, see Oracle Data GuardConcepts and Administration.

Using BACKUP INCREMENTAL... FROM SCN

The incremental backup is created at the source database by means of theBACKUP INCREMENTAL FROM SCN=n form of the BACKUP command. Forexample:

BACKUP DEVICE TYPE SBT INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP INCREMENTAL FROM SCN 750923 DATABASE;
BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
FORMAT '/tmp/incr_standby_%U';

RMAN uses the selected SCN as the basis for this incremental backup. Forall files being backed up, RMAN includes all data blocks that were changed atSCNs greater than or equal to the FROM SCN in the incremental backup.

Note:

·        RMANdoes not consider the incremental backup as part of a backup strategy at thesource database. The backup is not suitable for use in a normal RECOVERDATABASE operation at the source database.

·        Thebackup sets produced by this command are written to ?/dbs by default, even ifthe flash recovery area or some other backup destination is defined as thedefault for disk backups.

·        Youmust create this incremental backup on disk for it to be useful. When you movethe incremental backup to the standby, you must catalog it at the standby asdescribed in "Step 3: Catalog the Incremental Backup Files at theStandby Database". Backups on tape cannot be cataloged.

See Also:

《Oracle Database Backup and Recovery Reference 》 for more details on BACKUP command syntax

Refreshing a Standby Database With INCREMENTAL FROM SCN Backups: Example

This example shows the steps required to update a standby database usingincremental backups. The assumption is that you have already activated thestandby, performed your tests or other operations at the standby, and then usedFlashback Database to undo the effects of those changes. The task here is torefresh the standby with the latest changes to the primary, so that it canresume its role as a standby database.

Step 1: Create the Incremental Backup

Create the needed incremental backup at the source database, using BACKUPwith the INCREMENTAL FROM SCN clause.

Assume that the incremental backup to be used in updating the duplicatedatabase is to be created on disk, with the filenames for backup piecesdetermined by the format /tmp/incr_for_standby/bkup_%U.

RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE
FORMAT '/tmp/incr_for_standby/bkup_%U';

Step 2: Make the Incremental Backup Accessible at the Standby Database

Make the backup pieces containing the incremental backup available in somedirectory accessible on the system containing the standby database. For thisexample, assume that the destination directory is called/standbydisk1/incrback/ and ensure that it contains nothing besides theincremental backups from Step 1.

Step 3: Catalog the Incremental Backup Files at the Standby Database

Use the RMAN CATALOG command to register the backup sets in the RMANrepository at the duplicate. With an RMAN client connected to the standbydatabase and the recovery catalog (if you use one at the standby), mount thestandby and run the following command:

RMAN> CATALOG START WITH '/standbydisk1/incrback/';

The backups are now available for use in recovery of the standby.

Step 4: Apply the Incremental Backup to the Standby Database

Use the RMAN RECOVER command with the NOREDO option to apply theincremental backup to the standby database. All changed blocks captured in theincremental backup are updated at the standby database, bringing it up to datewith the primary database. With an RMAN client connected to the standbydatabase, run the following command:

RMAN> RECOVER DATABASE NOREDO;

You can now resume managed recovery at the standby. Any redo logs requiredat the standby with changes since those contained in the incremental areautomatically requested from the primary and applied

5）、监听问题

Check whether thelistener is up and running.

PING[ARC1]:Heartbeat failed to connect to standby 'etradep_dg'. Error is 12541.

检查监听和tnsname的状态

6）、在standby端启动后，primary端并没有启动，查询视图v$archive_dest可以显示报错：

 

Error 1034received logging on to the standby

FAL[client, MRP0]:Error 1034 connecting to etradep_db for fetching gap sequence

7）、切换失败：

首先在切换的时候要首先切换primary端，再切换standby端；

standby

PING[ARC1]:Heartbeat failed to connect to standby 'etradep_db'. Error is 16009.

primary

RFS[2]: Assignedto RFS process 3832

RFS[2]: Databasemount ID mismatch [0x49f713f8:0x49f5e25e] (1240929272:1240851038)

RFS[2]: Client instanceis standby database instead of primary

RFS[2]: Not usingreal application clusters

建议：log_archive_dest_2在切换的时候再设置

在将主库切换为备库后执行：

altersystem set log_archive_dest_2=’ ’;