1.Dataguard环境设计的三个重要概念
1.1 Primary数据库
在Data Guard的环境中与Standby数据库对应的数据库即是Primary数据库，也就是Primary数据库正在运行的生产数据库，大多数的应用要访问该数据库，因为它在Data Guard环境中处于Primary的角色，所以称为Primary数据库。
1.2 物理Standby数据库
物理Standby数据库是Standby数据库的一种，物理Standby数据库在本质上是通过Redo传输服务实施Redo应用，将Primary数据库的Redo数据拷贝到Standby数据库，实现Primary数据库与Standby数据库的同步。
Standby数据库其实就是Primary数据库的物理拷贝，二者的数据库结构相同。
1.3 逻辑Standby数据库
逻辑Standby数据库与Primary数据库在物理文件组织以及数据结构方面可以不同，这点是与物理Standby数据库的一个区别，并且逻辑Standby数据库是通过SQL应用实现与Primary数据库的数据同步，SQL应用的本质是将从Primary数据库获得的Redo数据转化成SQL语句，然后使用SQL语句实现Redo数据的操作。所以逻辑数据库中有自己的Standby本地日志文件。
逻辑Standby数据库可以向应用提供服务，如数据查询、报表服务等，同时不用停机就可以在逻辑Standby数据实现数据库软件升级以及补丁操作。
备注：在11g当中出现快照Standby数据库，此处以10g为例子。
2. Data Guard 服务本质
2.1 Apply服务
在Data Guard环境下，我们有一个提供主要服务的生产数据库----Primary数据库，同时在另一个物理主机(也可以同一台主机)创建了一个数据库拷贝，我们成为Standby数据库。通过网络将用户的数据操作结果传输到Standby数据库，此时传输的数据库就是保存在生产数据库的重做日志文件中的用户操作记录数据，其实与单实例数据库保持数据一致性相同，只不过Data Guard通过网络来传输Redo数据，将Redo数据归档或者直接将Redo数据写入Standby数据库。这要依赖于用户在配置数据库时选择的Redo传输服务参数。
传输Redo数据的服务成为"Apply服务"，该服务实现了Standby数据库与Primary数据库之间的数据同步，并在第一环境下允许对这两个数据库的同时访问，这依赖于Standby数据库的类型。
在Oracle Data Guard中，将Standby数据库分为物理Standby数据库和逻辑Standby数据库。根据Standby数据库的类型，Redo数据的”Apply”服务有两种实现方式，即Redo应用和SQL应用。
2.2 Redo应用
Apply服务根据创建的Standby数据库的不同而有差异，从本质上讲，就是实现Redo数据写操作的级别不同。Redo应用服务于物理Standby数据库，复制Redo中的二进制数据。
在物理Standby数据库中使用Redo应用保持与Primary数据库的数据同步，Redo应用的本质上使用介质恢复的方式来保持与Primary数据库的同步。即传输到Standby数据库的Redo数据块，会通过Redo应用直接保存在Standby数据库中，如果2-1所示。
图2-1 物理Standby的Redo应用
在图2-1中，Primary数据库的Redo数据使用Redo传输服务，通过网络传输到Standby数据库，在Standby数据库上相应的进程接受Redo数据，并使用Redo应用将数据块写入数据库。此时Standby数据库只能用于只读访问。
2.3 SQL应用
SQL应用服务于逻辑Standby数据库，它将Redo数据中的数据转化成SQL语句，再执行Redo操作。所以SQL应用是一个SQL语句传输和重建的过程。逻辑Standby数据库能够以读/写模式打开，但是它维护的数据表只能以只读模式打开，用于报表查询等服务，如图2-2所示。
图2-2 逻辑Standby的SQL应用
在创建逻辑Standby数据库时，系统会使用SQL应用来保存从Primary数据传输过来的Redo数据。SQL语句在应用过程中，此时的Standby数据库也可以提供报表服务。
2.4 角色转换服务
在Data Guard配置中与数据库功能对应的两种角色，即Primary角色和Standby角色。在一个Data Guard配置中可以有多个Primary数据库和多个Standby数据库，但是角色就两种，要么是Primary角色，要么是Standby角色。我们使用数据字典v$database来查询当前数据库的角色。
3. 基础知识准备
3.1 Oracle中数据库和实例
这是Oracle中最基本的2个概念。
先说数据库(database)。Oracle中的数据库，是存储数据的一种媒介。常用一般为2种形式，即文件和磁盘阵列。文件比较很好理解，就是在磁盘创建一批文件，然后在文件中存储数据信息。而磁盘阵列呢？所谓磁盘阵列，就是数据不是存放在某个文件中的，而是把一个或多个磁盘格式化为oracle的一种格式，等于整个磁盘只能存放oracle数据库，不能作为其它用途。以我们最常用的文件格式来说，数据库就是那些所有数据文件、控制文件、REDO文件等等一系列文件的集合。即：
数据库=重做文件+控制文件+数据文件+临时文件
实例(instance)是操作系统中一系列的进程以及为这些进程所分配的内存块。即：
ORACLE实例=进程+进程所使用的内存(SGA)
由上可见，对数据库的应用，实例和数据库缺一不可。仅有数据库，那么只表示数据存储在文件中，但是我们无法对它直接进行操作。仅有instance，表示我们可以进行操作，但是没有操作对象(不知道目标数据)，也是没有什么意义的。
Database是永久的，instance是临时性的。当我们结束oracle的实例进程，它所占内存释放，那么instance也就不存在了。但是，各种数据库相关文件还是存在的，所以database仍然存在的。
因此，也就不难理解了，oracle数据库服务器启动一般包含的3个步骤：1.创建并启动实例；2.装载数据库；3.打开数据库。每到一个阶段，都有相应的操作可以进行。例如，同一个SID，但是如果以不同的参数文件启动，那么我们可以装载和打开不同的数据库。同样的，一个数据库，也可以被不同的instance加载和打开。
一个实例在其生存期内只能装载(alter database mount)和打开(alter database open)一个数据库。
3.2 Oracle中的name,id
db_name：数据库名。物理数据库的名字标识。数据库创建完成后，参数db_name被写入参数文件，格式如下：
db_name=orcl
数据库名虽说可以修改，但是修改步骤比较麻烦。建议最好不要修改db_name。
在不同的服务器上创建数据库，可以使用同样的db_name。
在DG环境中，主备服务器中的数据库有同样的db_name。
可以利用下列sql查询db_name：
1 select name from v$database;
db_domain：数据库域名。这个域同网络的域没有什么联系。
global_name：全部数据库名。利用Database Configuration Assistant创建数据库时，要求输入就是全局数据库名。通常，它的名字是由db_name.db_domain构成。
SID：实例标识。利用Database Configuration Assistant创建数据库时，要求输入SID。
SID和instance_name的值是一致的。它是oracle的实例标识。
Instance_name用于对外部连接。在操作系统中要取得与数据库的联系，必须使用数据库实例名。
可以通过下列sql查询instance_name：
1 select instance_name from v$instance;
db_unique_name：在Data Guard里，主从服务器中的数据库，都有一个样的DB_NAME。然而它们和RAC环境下不一样，不代表同一个库(主备机中均有自己的数据库文件，不像RAC环境中通过多个实例通过磁盘阵列共享一个库)。但是它们的db_unique_name是不一样的，用以标识不同的数据库。
service_name：服务名。Service_name是连接数据库的时候使用的别名。
需要注意的是，service_name主要用于数据库网络连接时，可以有多个，可以随意命名，可以通过系统初始化参数service_name设置。
一般情况下，service_name的缺省值为db_name.db_domian，同global_name相同。
Net service name：网络服务名，即连接描述符。是客户端程序访问数据库时所需要，屏蔽了客户端如何连接到服务器端的细节，实现了数据库的位置透明特性。