一步一步学DataGuard(3)物理standby之创建步骤(1)

一、 准备工作

不管物理standby还是逻辑standby，其初始创建都是要依赖primary数据库，因为这个准备工作中最重要的一部分，就是对primary数据库的配置。

1、 打开Forced Logging模式

将primary数据库置为FORCE LOGGING模式。通过下列语句：

SQL> alter database force logging;

提示：关于FORCE LOGGING

想必大家知道有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging时有nologging之类的语句在执行，则force logging会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过alter database no force logging语句关闭强制记录。

2、 创建密码文件(如果不存在的话)

需要注意的是，同一个Data Guard配置中所有数据库必须都拥有独立的密码文件，并且必须保证同一个Data Guard配置中所有数据库服务器的SYS用户拥有相同密码以保证redo数据的顺利传输，因为redo传输服务通过认证的网络会话来传输redo数据，而会话使用包含在密码文件中的SYS用户密码来认证。

3、 配置Standby Redo Log

对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC模式传输，当然你现在可能还不知道LGWR ASYNC是什么问题，没关系，你很快就会知道了。

Oracle建议你在创建standby时就考虑standby redolog配置的问题。standby redologs与online redologs非常类似，应该说两者只是服务对象不同，其它参数属性甚至操作的命令格式几乎都一样，你在设计standby redologs的时候完全可以借鉴创建online redologs的思路，比如多个文件组啦，每组多个文件冗余之类的。除些之外呢，oracle提供了一些标准的建议如下：

l  确保standby redo log的文件大小与primary数据库online redo log文件大小相同。

这个很好理解的吧，就是为了接收和应用方便嘛。

l  创建适当的日志组

一般而言，standby redo日志文件组数要比primary数据库的online redo日志文件组数至少多一个。推荐standby redo日志组数量基于primary数据库的线程数(这里的线程数可以理解为rac结构中的rac节点数)。

有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数

例如primary数据库有两个线程，每个线程分配两组日志，则standby日志组数建议为6组，使用这个公式可以降低primary数据库实例LGWR进程锁住的可能性。

提示：逻辑standby数据库有可能需要视工作量增加更多的standby redo log文件(或增加归档进程)，因为逻辑standby需要同时写online redo log文件。

Standby redo log的操作方式与online redo log几乎一模一样，只不过在创建或删除时需要多指定一个standby关键字，例如添加：

SQL> alter database add standby logfile group  4  ('e:\ora10g\oradata\jsspdg\STANDBYRD0 1 .LOG') size 20 M;

删除也同样简单：

SQL> alter database drop standby logfile group 4;

另外，从可靠性方面考虑，建议在primary数据库也创建standby redologs，这样一旦发生切换，不会影响primary做为standby的正常运行。

验证standby redo log文件组是否成功创建

例如：

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

4、 设置初始化参数

对于primary数据库，需要定义几个primary角色的初始化参数控制redo传输服务，还有几个附加的standby角色的参数需要添加以控制接收redo数据库并应用(switchover/failover后primary/standby角色可能互换，所以建议对于两类角色 相关的 初始化参数都进行配置)。

下列参数为primary角色相关的初始化参数：
DB_NAME	注意保持同一个Data Guard中所有数据库DB_NAME相同。 例如：DB_NAME=jssweb
DB_UNIQUE_NAME	为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非你主动修改它。 例如：DB_UNIQUE_NAME=jssweb
LOG_ARCHIVE_CONFIG	该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗号分隔 例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(jssweb,jsspdg)'
CONTROL_FILES	没啥说的，控制文件所在路径。
LOG_ARCHIVE_DEST_n	归档文件的生成路径 。该参数非常重要，并且属性和子参数也特别多(这里不一一列举，后面用到时单独讲解如果你黑好奇，建议直接查询oracle官方文档。Data guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。 例如： LOG_ARCHIVE_DEST_1= 'LOCATION=E:\ora10g\oradata\jssweb   VALID_FOR=(ALL_LOGFILES,ALL_ROLES)   DB_UNIQUE_NAME=jssweb'
LOG_ARCHIVE_DEST_STATE_n	指定参数值为ENABLE，允许redo传输服务传输redo数据到指定的路径。 该参数共拥有4个属性值，功能各不相同。
REMOTE_LOGIN_PASSWORDFILE	推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。
LOG_ARCHIVE_FORMAT	指定归档文件格式。
LOG_ARCHIVE_MAX_PRODUCESSES	指定归档进程的数量(1-30)，默认值通常是4 。
以下参数为standby角色相关的参数，建议在Primary数据库 的初始化参数中也进行 设置，这样在role transition后(Primary转为Standby)也能正常运行：
FAL_SERVER	指定一个数据库SID，通常该库为primary角色。 例如：FAL_SERVER=jssweb
FAL_CLIENT	指定一个数据库SID，通常该库为standby角色。 例如：FAL_CLIENT=jsspdg 提示：FAL是Fetch Archived Log的缩写
DB_FILE_NAME_CONVERT	在做duplicate复制和传输表空间的时候这类参数讲过很多遍，该参数及上述内容中同名参数功能，格式等完全相同。
LOG_FILE_NAME_CONVERT	同上
STANDBY_FILE_MANAGEMENT	如果primary数据库数据文件发生修改（如新建，重命名等）则按照本参数的设置在standby中做相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理。 例如：STANDBY_FILE_MANAGEMENT=AUTO

注意：上面列举的这些参数仅只是对于primary/standby两角色可能会相关的参数，还有一些基础性参数比如*_dest,*_size等数据库相关的参数在具体配置时也需要根据实际情况做出适当修改。

5、 确保数据库处于归档模式

SQL> archive log list;

数据库日志模式            存档模式

自动存档             启用

.......

如果当前primary数据库并未处于归档模式，可通过下列命令将数据库置为归档模式：

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

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

转载于:http://blog.itpub.net/7607759/viewspace-206132/