026.笔记：10G DG-基础知识2

1.逻辑备用数据库的管理
SQL Apply引擎包括下列几个进程：
READER进程在重做日志到达备用数据库之后，负责读出日志并将其放入共享池中名为LCR缓存的内存结构里
PREPARER进程将LCR缓存中的重做日志转换成逻辑变更记录（LCR)并明确逻辑变更记录之间的关系。
BUILDER进程将每一条逻辑变更记录创建成为完整的事务
ANALYZER进程获取BUILDER进程创建的事务并分析事务之间的相关依赖性
COORDINATOR进程监测事务间的依赖性并通过应用子进程正确地排序这些事务的应用
APPLY进程接收来自COORDIANTOR进程的事务，并从物理上对数据库表应用具体的改变。

1.1停止和启动SQL Apply
--启动
alter database start logical standby apply;--读取归档
alter database start logical standby apply immediate;--变更从主数据库到达备用数据库时及时地加以应用（实时应用）。
--停止：在关闭备用数据库之前，或者在改变SQL Apply引擎属性之前
alter database stop logical standby apply;

1.2监测SQL Apply进程
select * from v$logstdby;--进程执行的动作
select * from v$logstdby_stats;--DBMS_LOGSTDBY.APPLY_SET的默认设置
select * from dba_logstdby_progress;--逻辑备用数据库中SQL应用操作的进展。

要查看备用数据库中不再需要的归档日志，需要首先执行下面的过程：
execute dbms_logstdby.purge_session;
这个过程通过一系列备用数据库中不再需要的归档日志来更新
DBA_LOGMNR_PURGED_LOG

1.3 禁止用户修改逻辑备用数据库
alter database guard all;--all/standby/none
all所有的系统用户都不能修改由SQL Apply维护的表，非系统用户不能在逻辑备用数据库中创建新的对象。
standby所有的系统用户都不能修改由SQL apply维护的表，但它们可以在逻辑备用数据库上创建新的对象。
none数据库防护被关闭，所有的更新都可以在逻辑备用数据库上执行。

--会话级的防护
alter session disable guard;
alter session enable guard;

1.4错误恢复
当SQL Apply引擎在执行SQL语句遇到了错误的时候，它将会停止下来。错误和出现错误的语句将会记录在DBA_LOGSTDBY_EVENTS视图中。
（1）DDL事务的恢复
注意：DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT参数在逻辑备用数据库中是不起作用的。如果备用数据库中的目录结构和主数据库的是一致的，创建
文件的DDL事务将不会出现错误。
【DDL事务失败后的恢复】
第1步：确定失败的SQL
selelct * from dba_logstdby_events order by event_time;
第2步：alter session disable guard;
第3步：在逻辑备用数据库上运行补偿事务。例如，运行失败的CREATE TABLESPACE命令，但是采用正确的文件定位。
第4步：alter session enable guard;
第5步：重新启动逻辑备用数据库，其中启动命令中包括自动跳过失败事务的子句。
alter database start logical standby apply skip failed transaction;
【DML事务的恢复】
解决办法是实例化表
第1步：alter database stop logical standby apply;
第2步：通过DBMS_LOGSTDBY.INSTANTIATE_TABLE过程重新获得与主数据库同步的表。
exec dbms_logstdby.instantiate_table('SCOTT','T1','DB_LINK');
第3步：alter database start logical standby apply;

1.5修改SQLAPPLY 引擎中的默认操作
exec dbms_logstdby.apply_set('MAX_SGA',70);
exec dbms_logstdby.apply_set('TRANSACTION_CONSISTENCY','READ_ONLY');
exec dbms_logstdby.apply_unset('MAX_SGA');--重新设为默认值
【常用参数】
MAX_SGA这是SQL Apply引擎中缓存的变更记录的兆字节数。这也被认为是LCR缓存。
MAX_SERVERS这是SQL apply引擎中用到的最大的并行查询数。默认为9，或者由参数PARALLEL_MAX_SERVERS参数来具体指定，以这两者中的较低者为准。
TRANSACTION_CONSISTENCY这是主数据库中的重做日志在应用中维持的事务一致性的级别。值为FULL/READ_ONLY/NONE

2.其他DBMS_LOGSTDBY过程
2.1 DBMS_LOGSTDBY.SKIP过程
跳过特定的对象或模式
（1）atler database stop logical standby apply;
（2）exec dbms_logstdby.skip('SCHEMA_DDL','SCOTT','T1',null)
exec dbms_logstdby.skip('DML','SCOTT','T1',null)
（3）使用通配符跳过模式中的所有表
　　　exec dbms_logstdby.skip('SCHEMA_DDL','SCOTT','%',null)
exec dbms_logstdby.skip('DML','SCOTT','%',null)

撤销：dbms_logstdby.unskip

2.2 DBMS_LOGSTDBY.SKIP_ERROR过程
值得注意的是，SQL Apply引擎在执行SQL语句的过程中只要接收到错误就会终止。
alter database stop logical standby apply;
exec dbms_logstdby.skip_error('NON_SCHEMA_DDL','SCOTT','%',null);-- 跳过非模式的DDL
alter database start logical standby apply immediate;

2.3 DBMS_LOGSTDBY.SKIP_TRANSACTION过程
Oracle Database 10g中有一个新的特性，它可以启动SQL APPLY引擎并跳过上一次失败的事务，假设我们已经运行了一个补偿事务。在以前的版本中，用户不得不通过使用
DBMS_LOGSTDBY.SKIP_TRANSACTION过程来跳过一个特定的失败状态。这个过程在10g中仍然有用。

步骤：
第1步：通过DBA_LOGSTDBY_EVENT视图获取失败事务的XIDUSN、XIDSLT和XIDSQN的值：
select event,xidusn,xidslt,xidsqn from dba_logstdby_events
where event_time =(select max(event_time) from dba_logstdby_events0;
第2步：暂时停用数据库防护，以便对逻辑备用数据库运行补偿事务
alter session disable guard;
第3步：执行补偿事务
第4步：打开数据库防护
alter session enable guard;
第5步：通过DBMS_LOGSTDBY.SKIP_TRANSACTION过程跳过失败的DDL语句
exec dbms_logstdby.skip_transaction(4,17,233);


3.通过switchover功能实现角色转换
当我们将主数据库或者备用数据库的角色改变为另一种角色，这就叫作角色转换。有两种用来改变角色的方法：switchover和故障切换。
switchover可以使数据库在主数据库和备用数据库角色之间转换而不产生数据丢失，并且不需要重建先前的主数据库。相比之下，故障切换可能会
导致数据丢失，并需要重建主数据库。
switchover实现角色转换之前应该考虑的一些问题：
a.查看主数据库和备用数据库的初始化参数文件，确认它们都支持双重的角色。
b.核实主数据库和备用数据库主机都有TNS别名指向另外的别名，并且这些别名工作正常。
c.为了快速和高效地实现角色转换，应该断开所有的用户连接。如果不能断开所有的用户连接，就尽可能地限制用户的活动。
d.核实主数据库和备用数据库中的临时表空间都是通过临时文件来填充的。
e.让所有的备用数据库，都应用所有来自主数据库的变更
f.如果主数据库是一个RAC数据库，必须只留一个实例，并关闭其他所有的实例。

【物理备用数据库的switchover角色转换】
第1步：在主数据库上
select switchover_status from v$database;
第2步：将主数据库转换成备用数据库
alter database commit to switchover to physical standby;
如果第1步中值是session active,则应该运行：
alter database commit to switchover to physical standby with session shutdown;
第3步：关闭主数据库并以物理备用数据库的角色启动主数据库
shutdown immediate;
startup mount;
第4步：当我们将主数据库转换成为备用数据库时，我们在重做日志流中产生了一个标记，并将这个标记传送给了备用数据库。
select switchover_status from v$database;--备用数据库
如果值为TO_PRIMARY,说明标记已经收到。如果状态为SESSION active，就应该执行带SESSION SHUTDOWN 的switchover。如果状态是NOT ALLOWED,说明
标记还没有收到，就不能运行SWITCHOVER。
第5步：将备用数据库转换成为主数据库
alter database commit to switchover to primary;
如果第4步值为SESSION ACTIVE:
alter database commit to switchover to primary with session shutdown;
第6步：关闭并重新启动新的主数据库
shutdown immediate;
startup;

【逻辑备用数据库的switchover角色转换】
第1步：select switchover_status from v$database;
第2步：10g中主数据库与备用数据库都有预备角色转换的能力，可以大大减少转换的时间。
主数据库
alter database prepare to switchover to logical standby;--在测试环境执行了一个小时，switchover_status仍然是 PREPARING SWITCHOVER
select switchover_status from v$database; --如果为TO LOGICAL STANDBY就可以转换了
alter database commit to switchover to logical standby;--这条命令会等到所有的当前事务完成之后才会执行，并会阻止新的事务的发生。可检查V$TRANSACTION
第3步：备用数据库
alter database prepare to switchover to primary;
select switchover_status from v$database;--如果为TO PRIMARY就可以转换了
alter database commit to switchover to primary;

4.通过故障切换实现角色转换
4.1故障切换首要的步骤
需要考虑：
a.尝试将那些未应用的数据从主数据库中卸下并安装到备用数据库主机中去。这里还包括没有传送的归档日志。
b.确保备用数据库中的临时表空间是存储在临时文件中的。
c.如果备用数据库即将转换成RAC主数据库，应该确保除了一个实例以外，其他的实例全都关闭了。
d.从主数据库中删除由于恢复重做日志而进行的任何延迟设置
e.将备用数据库的保护模式设置为最大性能保护模式

【物理备用数据库的故障切换】
第1步：处理备用数据库中的所有缺失。通过在备用数据库中查询V$ARCHIVE_GAP视图来定位备用数据库中的日志缺失。尝试通过从主数据库或其他的备用数据库复制缺失日志
来弥补缺失。
第2步：那些为处理备用数据库中缺失而复制来的归档日志，需要在备用数据库的控制文件中注册。
alter database register physical logfile '/u01/ora10g/arch/1_123.arc';
第3步：alter database recover managed standby database finish;
如果备用数据库没有重做日志，或者备用数据库中的重做日志没有被激活，则必须输入：
alter database recover managed standby database finish skip standby logfile;
第4步：alter database commit to switchover to primary;
第5步：重新启动新的主数据库
shutdown immediate;
startup;
第6步：对新的主数据库进行备份

【逻辑备用数据库的故障切换】
值得注意的是，当通过逻辑备用数据库来实现故障切换时，旧的主数据库和物理备用数据库就不再是Data Guard配置中的一部分了。但是，在大多数情况下，配置中其他的
逻辑备用数据库仍然是处于Data Guard的配置之中的。
第1步:通过DBA_LOGSTADBY_LOG视图来确认逻辑备用数据库中是否还有遗漏的归档日志。将遗漏的归档日志或序列号大于逻辑备用数据库中最后序列号的归档日志复制到逻辑
备用数据库所在的主机上。
第2步：alter database register logical logfile '/u01/ora10g/arch/1_127.arc';
第3步：通过查看DBA_LOGSTDBY_PROGRESS视图来确定什么时候完成所有可用的事务的应用。当NEWEST_SCN的值等于APPLIED_SCN的值时，说明所有的事务都已经应用。
select applied_scn,newest_scn from dba_logstdby_progress;
第4步：alter database stop logical standby apply;
alter database activate logical standby database;
第5步：备份新的主数据库

4.2在故障切换后使用闪回技术
通过闪回主数据库，可以将旧的主数据库恢复到故障发生之前，并将它重新放到Data Guard的配置中，形成一个新的备用数据库。然后，通过
switchover，我们可以实现角色转换，从而将主数据库放回到最初的主机上。
第1步：在新的主数据库上，确定备用数据库是在什么SCN上变成新的主数据库的：
select to_char(standby_became_primary_scn) from v$database;
第2步：在旧的主数据库上
flashback database to scn ;
第3步：在旧的主数据库上
alter database flashback on;
第4步：在旧的主数据库上
alter database create standby controlfile as '/u01/tmp/standby.ctl'
第5步：在旧的主数据库上配置控制文件
第6步：旧的主数据库
startup mount;
第7步：启用闪回数据库
alter database failover on;
第8步：在新的主数据库上，启用一个指向主数据库的归档目标
alter system set log_archive_dest_state_2=enable;
第9步：在新的备用数据库上
alter database recover managed standby database disconnect;


5.Data Guard的代理和客户端
Data Guard代理是一个集中的框架，它可以创建、自动操作和管理Data Guard配置的各个方面。Data Guard代理可以在本地和远程通过下面的两种客户端访问：命令行（CLI）
或者新嵌入式企业管理器（OEM）的Data Guard页。
Data Guard代理主要的三个部件是：两个接口或者说是客户端和Data Guard Monitor进程。
5.1 CLI接口
在使用CLI之前，物理备用数据库或逻辑备用数据库必须已经创建，因为CLI不具备创建备用数据库的能力（只有Data Guard GUI才可以）。另外，主数据库和备用数据库启动时的
参数DG_BROKER_START必须为TRUE（也就是产生DMON进程）并且使用了系统参数文件。
命令：
DGMGRL
DGMGRL>connect sys/oracle
第一步是定义数据库。在定义并保存好主数据库后创建备用数据库对象
DGMGRL>create configuration 'mydr' as primary database is 'ora10g1' connect identifier is ora10g1_db1;
添加备用数据库
DGMGRL>add database 'orastdb' as connect identifier is standby_dg1 maintained as physical;--物理备库
DGMGRL>add database 'orastdb' as connect identifier is standby_dg1 maintained as logical; --逻辑备库
DGMGRL>enable configuration;
DGMGRL>show configuration;

DGMGRL>edit database 'orastdb' set state='READ-ONLY';
DGMGRL>edit database 'orastdb' set state='ONLINE';

DGMGRL>switchover to 'orastdb';

5.2使用Data Guard GUI
用命令行创建代理配置
ADMINISTRATION-HIGH AVAILABILITY-DATA GUARD

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7901922/viewspace-1059971/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7901922/viewspace-1059971/