Oracle Data Guard, 分逻辑Standby和物理Standby。 下面讲的是物理Standby 环境的搭建步骤。 有关Data Guard的一些概念性的理论知识，请参考我的blog， 这里不做过多的说明。
Oracle Data Gurad 理论知识
将Primary数据库置为Force Logging模式。通过下列语句：
SQL> SELECT DATABASE_ROLE,FORCE_LOGGING FROM V$DATABASE;
DATABASE_ROLE FORCE_LOGGING
---------------- ---------------
PRIMARY NO
SQL> alter database force logging;
Database altered.
SQL> alter database no force logging;
Database altered.
有一些DDL语句可以通过指定NOLOGGING子句的方式避免写REDO（目的是提高速度，某些时候确实有效）。指定数据库为Force Logging模式后，，而忽略类似NOLOGGING之类的指定参数。如果在执行Force Logging时有NOLOGGING之类的语句在执行，那么Force Logging会等待，直到这类语句全部执行。
，因此其不受重启之类操作的影响（只执行一次即可），如果想取消，可以通过语句关闭强制记录。
同一个Data Guard配置中所有数据库必须都拥有独立的密钥文件，并且必须保证同一个Data Guard配置中，所有数据库服务器的SYS用户拥有相同密码，以保证REDO数据的顺利传输，因为REDO传输服务是通过认证的网络会话来传输REDO数据，而会话使用包含在密钥文件中的SYS用户密码来认证。
如果使用DBCA建库则Oracle会自动创建密钥文件，该文件默认路径在%ORACLE_HOME%/database目录下，如果在该目录没能找到对应的密钥文件也没关系，Oracle提供了一个创建密钥文件的命令：orapwd，位于%ORACLE_HOME%/bin目录下，该命令有两种调用方式：带参调用和不带参调用。
不带参调用时，会返回该命令的调用方式和参数形式，例如：
[oracle@localhost ~]$ orapwd
Usage: orapwd file= password= entries= force=
where
file - name of password file (mand),
password - password for SYS (mand),
entries - maximum number of distinct DBA and force - whether to overwrite existing file (opt),
OPERs (opt),
There are no spaces around the equal-to (=) character.
file：指定密钥文件名称和路径。
password：SYS用户密码。
entries：指定该数据库能够拥有SYSDBA权限的用户最大数。
force：如果文件存在是否覆盖。
orapwd命令使用非常简单，file和password为必填参数。
Windows平台命名规则：PWD[sid].ora
Linux/UNIX平台命令规则：orapw[sid] -- 注意：没有文件名，
示例如下：
[oracle@localhost dbs]$ orapwd file=/u01/app/oracle/product/10.2.0/db_1/dbs/orapworcl password=admin entries=30
Oracle OS认证 口令文件 密码丢失处理
对于最大保护和最高可用性模式，建议为Standby数据库配置Standby Redologs（不配置也可以，Oracle将在Standby数据库端自动创建归档文件，并虚拟为一组Standby Redologs），并使用LGWR SYNC模式传输REDO数据。
1．关于Standby Redologs
Oracle建议DBA在创建Standby数据库时，就考虑Standby Redologs配置的问题。Standby Redologs与Online Redologs非常类似，应该说两者只是服务对象不同，其他参数属性，甚至操作的命令格式几乎都一样，DBA在设计Standby Redologs的时候完全可以借鉴创建Online Redologs的思路，如创建几个文件组，每组多个文件冗余之类的。除些之外呢，Oracle提供了一些标准的建议，如下所示：
（1）确保Standby Redologs的文件大小与Primary数据库Online Redologs文件大小相同。这个很好理解，就是为了接收和应用方便嘛。
（2）创建适当数目的日志组。一般而言，Standby Redologs日志组要比Primary数据库的Online Redologs日志文件组数至少多一个。建议Standby Redologs日志组数量基于Primary数据库的线程数来确定（这里的线程数可以理解为RAC环境中的节点数）。
有一个推荐的公式可供参考：（每线程的日志组数+1）×最大线程数。
例如Primary数据库有两个线程，每个线程分配两组日志，则Standby日志组数建议为6组，使用这个公式可以降低Primary数据库实例LGWR进程锁住的可能性。
提 示： 逻辑Standby数据库有可能需要视工作量，增加更多的Standby Redologs组（或增加归档进程），因为逻辑Standby数据库有可能需要同时写Online Redologs文件。
2．管理Standby Redologs
Standby Redologs的操作方式与Online Redologs几乎一模一样，只不过在创建或删除时需要多指定一个Standby关键字。
查看redo log：
SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------
3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log
2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log
1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log
添加一个新的Standby Redologs组（注意组号不要与当前存在的Online Redologs组重复），并为该组指定一个成员：
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('/u01/app/oracle/oradata/orcl/redo04.log') size 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ('/u01/app/oracle/oradata/orcl/redo05.log') size 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ('/u01/app/oracle/oradata/orcl/redo06.log') size 50M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ('/u01/app/oracle/oradata/orcl/redo07.log') size 50M;
删除Standby Redologs组也同样简单：
SQL> ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;
可以通过动态性能视图V$LOGFILE查看当前数据库中创建的Standby Redologs，例如：
SQL> SELECT GROUP#,TYPE,MEMBER FROM V$LOGFILE;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------
3 ONLINE /u01/app/oracle/oradata/orcl/redo03.log
2 ONLINE /u01/app/oracle/oradata/orcl/redo02.log
1 ONLINE /u01/app/oracle/oradata/orcl/redo01.log
4 STANDBY /u01/app/oracle/oradata/orcl/redo04.log
5 STANDBY /u01/app/oracle/oradata/orcl/redo05.log
6 STANDBY /u01/app/oracle/oradata/orcl/redo06.log
7 STANDBY /u01/app/oracle/oradata/orcl/redo07.log
提示：通过该视图中的TYPE列区分该条记录是Online Redologs或是Standby Redologs。
通过查看Standby Redologs的专用视图V$STANDBY_LOG来查看当前数据库中创建的Standby Redologs，如：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
6 0 0 YES UNASSIGNED
7 0 0 YES UNASSIGNED
从可靠性方面考虑，DG的设计初衷就是当发生故障时快速切换Primary和Standby的角色，以达到快速恢复应用访问的目的。一旦发生切换，原Primary数据库就变成了Standby数据库，就得需要Standby Redologs，为了减少真正切换时应做的工作，建议在Primary数据库也创建Standby Redologs，这样即使发生切换，也不会影响Primary作为Standby身份的正常运行。
对于Primary数据库，有几个与角色相关的初始化参数需要进行设置，这些参数初始时有些用来控制REDO传输服务（即Primary数据库生成的REDO数据传给谁以及怎么传），有些用来指定角色，还有几个与Standby角色相关的初始化参数，也建议进行配置，以便switchover/failover操作后，Primary/Standby数据库仍能正常工作，建议不管是Primary数据库，还是Standby数据库，对于角色相关的初始化参数都进行配置。