Oracle10gR2 Logical Standby(七)日常管理与优化

有一段时间没怎么写技术性的文章了，继续前面的逻辑备库系列，这是第七篇。

对于逻辑备库来说，日常管理主要需要关注SQL Apply。切换是很少发生的动作，而logminer的速度相对于sql apply来说是很快的，恢复的进度主要还是取决于SQL Apply的进度。

一、SQL Apply进程

SQL Apply实际上是一组后台并行进程，包括reader,preparer,builder,analyzer,coordinator,applier 六种不同作用的进程：

reader：读取redo记录传递给preparer进程
preparer: 根据redo记录和数据字典信息生成LCR
builder: 将同一个事务的LCR打包。对于大事务(eager transaction)，可能被打成多个事务包(transaction chunk)，那么可能有些包里是不包含commit的，每一个事务包都可能交给不同的applier进程。
analyzer:分析事务包之间的依赖关系
coordinator:将分析好的事务包交给applier进程
applier:将事务包应用，如果事务包依赖其他事务包，则需要等待相应的事务包完成。事务能否commit，可能还需要根据不同的情况从coordinator获得相应的信息。

[继续阅读全文]

Posted by NinGoo at 2008-11-20 16:27 | 『数据库』 | No Comments »

Oracle10gR2 Logical Standby(六)逻辑备库的Failover

当主库由于某种原因不可用时，需要考虑将备库直接拉起来，这就是failover。基本原理和操作步骤和switchover差不多只是不管主库，直接将备库切换成新的主库。

一.切换前的检查

确保所有能应用的归档都已经应用。确保监听设置正确。确保切换后应用能连接到新的主库等。

二.停止SQL Apply

如果原来是停止的，那么可能还有部分最新的日志没有应用，则最好先应用一下日志，减少最终切换需要的时间：

alter database start logical standby apply finish;

alter database stop logical standby apply;

三.激活备库

以下命令会终止RFS，然后应用还未应用的日志，最后将数据库转换成primary角色。

alter database activate logical standby database finish apply;

至此，逻辑备库已经转换成主库，非常的简单。由于数据库本身是open的，转换后无须再作任何操作

select database_role from v$database;

DATABASE_ROLE
----------------
PRIMARY

四.处理其他备库

如果原来的DataGuard中还有不止一个逻辑备库，则其中一个逻辑备库failover成主库以后，其他的备库需要重新指向新的主库。首先在其他备库创建一个到新主库的database link

alter session disable guard;
create database link newprimary connect to user identified by password using 'newprimary';
alter session enable guard;

然后重新指向新的备库

alter database start logical standby apply new primary newprimary;

如果执行时出现ORA-16109: failed to apply log data from previous primary，则备库只有重做了。

Posted by NinGoo at 2008-06-12 14:37 | 『数据库』 | 1 Comment »

Oracle10gR2 Logical Standby(五)逻辑备库的Switchover

相对物理备库的切换，逻辑备库的切换稍微复杂点，但只要按照步骤，整个操作过程也可以在很短的时间内完成。这里记录下主库正常时的switchover操作过程：

1.切换前的检查
包括主备库参数设置，主备库的TNS设置，以及应用连接数据库的TNS等，确保主备库角色转换后整个系统运行不受影响。

2.主库准备切换

alter database prepare to switchover to logical standby;

命令执行成功后，主库的状态

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER

3.备库准备切换

alter database prepare to switchover to primary;

命令执行成功后，备库的状态

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
PREPARING SWITCHOVER

4.主库开始切换
执行完第3步后，现在的备库需要生成logminer所需要的数据字典信息，然后传送到现在的主库，所以要执行逻辑备库切换，必须在备库也设置到主库的归档路径，并且主备库监听都需要保持开启。否则，切换的状态就会一直停留在PREPARING SWITCHOVER。

备库数据字典信息传递到主库后，主库的状态变成TO LOGICAL STANDBY，这时才能执行实际的切换。

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO LOGICAL STANDBY

alter database commit to switchover to logical standby;

注：在PREPARING SWITCHOVER状态时，可以通过执行以下命令取消切换操作：

alter database prepare to switchover cancel;

5.从库切换
上一步成功后，备库的状态应该变成了TO PRIMARY，则可以执行切换

select switchover_status from v$database;

SWITCHOVER_STATUS
--------------------
TO PRIMARY

alter database commit to switchover to primary;

6.在新的备库启动日志应用进程

alter database start logical standby apply;

如果是实时应用，则

alter database start logical standby apply immediate;

Posted by NinGoo at 2008-06-10 17:48 | 『数据库』 | No Comments »

Oracle10gR2 Logical Standby(四)转换逻辑备库的过程

关于Oracle10gR2逻辑备库，之前写过几篇：
Oracle10gR2 Logical Standby(一)概念与原理
 Oracle10gR2 Logical Standby(二)配置前需要考虑的问题
 Oracle10gR2 Logical Standby(三)配置逻辑备库

这里记录一下Oracle10gR2物理备库转换为逻辑备库的过程中，Oracle都做了哪些操作。从alert中可以获得很多有用的信息：当执行alter database recover to logical standby xxxx的命令后，首先启动基于SCN的不完全恢复(Oracle10g会自动开启并行恢复，这个例子中启动了15个并行恢复进程)。然后clear online redo logfile，但是Oracle10g在将备库置于manged standby状态的时候就提前将这个clear的动作做了，所以这里记录的是previously cleared，然后将备库激活，调用nid修改数据库的DBID。

alter database recover to logical standby shtest
Thu Jun 5 14:02:55 2008
Media Recovery Start: Managed Standby Recovery (shtest)
Thu Jun 5 14:02:55 2008
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 15 processes
Media Recovery Log /oradata/archive/shtest/1_2274_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2275_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2276_655399684.arc
Media Recovery Log /oradata/archive/shtest/1_2277_655399684.arc
Thu Jun 5 14:02:56 2008
Incomplete Recovery applied until change 20447678
Thu Jun 5 14:02:56 2008
Media Recovery Complete (shtest)
RESETLOGS after incomplete recovery UNTIL CHANGE 20447678
Resetting resetlogs activation ID 54725959 (0×3430d47)
Online log /oradata/shtest/redo01_01.dbf: Thread 1 Group 1 was previously cleared
Online log /oradata/shtest/redo01_02.dbf: Thread 1 Group 1 was previously cleared
Online log /oradata/shtest/redo02_01.dbf: Thread 1 Group 2 was previously cleared
Online log /oradata/shtest/redo02_02.dbf: Thread 1 Group 2 was previously cleared
Online log /oradata/shtest/redo03_01.dbf: Thread 1 Group 3 was previously cleared
Online log /oradata/shtest/redo03_02.dbf: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 20447676
Thu Jun 5 14:03:01 2008
Setting recovery target incarnation to 2
Thu Jun 5 14:03:01 2008
Converting standby mount to primary mount.
Thu Jun 5 14:03:01 2008
ACTIVATE STANDBY: Complete - Database mounted as primary (shtest)
*** DBNEWID utility started ***
DBID will be changed from 54167428 to new DBID of 55371925 for database SHTEST
DBNAME will be changed from SHTEST to new DBNAME of SHTEST
Starting datafile conversion
Setting recovery target incarnation to 1
Datafile conversion complete
Database name changed to SHTEST.
Modify parameter file and generate a new password file before restarting.
Database ID for database SHTEST changed to 55371925.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open with RESETLOGS option.
Succesfully changed database name and ID.
*** DBNEWID utility finished succesfully ***
Thu Jun 5 14:03:03 2008
ARC1: Archival disabled due to instance shutdown
Shutting down archive processes
Archiving is disabled
Thu Jun 5 14:03:03 2008
Completed: alter database recover to logical standby shtest