数据库容灾方案(某证券公司)

某证券热备容灾方案技术建议书

深圳市沃信科技有限公司

目录

第1章引言 (1)

第2章PAC for Oracle产品介绍 (2)

2.1 概述 (2)

2.1.1 PAC for Oracle能满足用户什么需求 (2)

2.2 PAC for Oracle技术原理 (3)

2.2.1 PAC for Oracle与Oracle redo logs、archive logs (4)

2.2.2 PAC与OCI (4)

2.2.3 复制范围与日志断点定位 (4)

2.2.4 严格的交易级别同步控制 (5)

2.2.5 高效安全的内嵌缓存数据库 (5)

2.2.6 断点续传 (5)

2.2.7 跨平台支持、高兼容性和低影响性 (5)

2.2.8 PAC与数据库的DML、DDL、DCL操作 (6)

2.2.9 大对象支持 (6)

2.2.10 Truncate支持 (7)

2.2.11 交互式界面设计 (7)

第3章数据库容灾系统建设方案 (8)

3.1 需求分析 (8)

3.1.1 用户期望 (8)

3.1.2 用户软硬件环境 (9)

3.2 PAC热备容灾部署 (9)

3.2.1 本地热备容灾系统部署 (9)

3.2.2 本地查询系统部署 (10)

3.2.3 远程集中容灾部署 (12)

3.2.4 PAC安装环境需求与复制性能 (13)

3.2.5 备库的初始化和软件的安装配置 (14)

3.2.6 复制的实时性与有效性 (15)

3.2.7 PAC对资源的占用 (17)

3.3 用户期望的解答 (18)

i

3.4 PAC支持环境及数据库列表 (19)

ii

第1章引言

某证券股份有限公司是经国务院批准，由中国**资产管理公司主要发起设立的一家全国性证券公司，注册资本**亿元人民币，总部设在北京。作为在证券市场蓬勃发展形势下新组建的证券公司，某证券资本充实，大股东中国**资产管理公司为中央直属大型金融企业，实力雄厚。

由于目前业务系统的升级以及对证券业务系统数据保护的严格需求，目前考虑实施本地热备容灾和异地热备容灾项目，以达到双机、双库、双地的不间断实时热备容灾效果。我公司的PAC和DBE两个备份产品有幸参与到本次招标行列，下面将对整体方案进行详细阐述。

第2章PAC for Oracle产品介绍

2.1 概述

PAC for Oracle 是基于redo log 分析技术的Oracle 实时复制工具，具有简单灵活、

高性能低成本的特点，中文图形的软件界面使部署和使用非常简便，对系统资源

和运行环境的需求也较低。PAC 能够帮助用户在复杂的应用环境下完成Oracle

热备容灾、远程容灾、查询业务分担、容灾中心的建设等工作。

2.1.1 PAC for Oracle能满足用户什么需求

z提高业务系统的持续对外服务能力

PAC的热备模式为用户提供了一个高可用性的备用数据库，无论是计划停机

（数据库、系统升级或者备份）还是意外引起的宕机（例如硬件故障、灾难、

人为错误等）。PAC对源数据库的保护能最大限度的减少宕机时间，提高可

用性是减少数据丢失、经济损失和保持生产力水平、企业形象的关键。

z低需求带宽下提供高效复制

由于传统复制技术的限制，容灾必须拥有专用的硬件支持和专用的光纤传输

链路。容灾距离和系统平台还有诸多的限制，这就意味着对大部分公司而言，

容灾将是一项巨大的工程，要求投入巨大的人力物力。但是，由于传统容灾

系统的目的端数据库不能随时打开使用，不但风险不能评估，而且巨大的投

入也得不到回报。

PAC使用逻辑复制技术，传递的是交易指令，因此传输数据量很小，保证了

在低带宽环境下实现低延迟的数据准同步复制，是一种高效且低成本的数据

库容灾方式。

PAC使用标准网络进行通讯，备机的Oracle数据库可以部署在本地或远程容

灾中心（距离没有限制）。此外，容灾端数据库始终处于打开状态，因此，当

生产数据库遇到计划内或非计划停机时，可以快速的将业务切换至备机的数

据库上。与其它基于磁盘或文件系统的物理复制技术相比，不但省略了漫长

的数据库恢复（recovery）和启动（startup）时间，而且能够保证备库的高可

用性。

z分担源库的负载压力

PAC的逻辑复制技术决定了备库始终处于可用状态，对于实时交易处理之外

的只读应用，例如历史查询、报表处理、数据备份、统计分析等都可以交给

备库处理。多种应用也不必在同一个交易数据库上争夺资源。生产系统运行

和维护的压力得以释放，提高了稳定性；不同的应用在各自的数据库上也可

以得到分别的优化。

z跨操作平台、跨数据库版本支持

PAC支持跨平台的数据传输，只要能装上Oracle数据库的任意操作系统（如：

AIX、HP-UX、Solaris、Linux、Windows等），PAC都能实现同步，并且源

库和目标库的操作平台也可以异构。同时，PAC支持Oracle8i、Oracle9i、

Oracle10g和Oracle11g之间的跨版本同步，这意味着用户在软件和硬件上的

选择有了更大的灵活性，建设容灾系统的成本更加可控。

z灵活的多种按需复制方式

企业数据的物理热备、查询等需求，决定了用户需要不同的复制模式应用于

不同的数据库间复制，PAC提供了多种灵活的复制方式，如按表复制、按用

户复制，用户可根据自己的需求做相应的定制。

z同步数据校验

PAC提供静态数据校验工具Power Checker，通过使用Power Checker检查源

库与备库的数据，用户可以方便的查出字段级的差别，方便用户快速定位和

纠错。

z交互式中文界面易于操作管理

由于数据热备应用于不同领域，进行数据热备的操作人员的技术水平参次不

齐。因此，PAC提供了一个直观的、操作简单的图形化用户界面，可缩短操

作人员的学习时间，减轻其工作压力，使热备工作得以轻松地设置和完成。

同时热备软件要具有全局的管理功能，能够在控制中心对所有的作业进行统

一的控制。

z界面查看同步事务与同步日志

PAC在完成同步的同时，会在管理界面的“事务”窗口，按照Oracle数据库

内部的SCN（System Change Number）号，记录所做同步的所有SQL语句。

用户也可按照SCN号查询历史的某个操作（目前支持），这让数据库DBA人

员更清楚的了解数据同步进度。

同时，PAC管理界面还提供日志查看功能。可在“日志窗口”，查询到所有

异常记录，如源端或目标端网络连接中断，数据库异常无法连接等，大大提

高了数据库管理人员对问题的定位和处理速度。

z出错报警设置

当PAC在同步过程中发生异常情况时，PAC的“日志”界面会显示出错信息

提示。

2.2 PAC for Oracle技术原理

将在本节阐述PAC For Oracle 的实现原理。

2.2.1 PAC for Oracle与Oracle redo logs、archive logs

z日志读取

PAC通过读取Oracle数据库的Oracle redo logs来获取数据库数据。PAC在读

取过程中无需等待Oracle redo log 文件归档之后再进行处理，而是在线读取

其数据块内容。读取的间隔时间可以用参数设定，以“秒”为单位。PAC也

不会传输Oracle redo log的全部内容到目的端，除指定复制对象（数据表）

相关的DML/DDL操作外，对其他的信息不做处理。

z Oracle redo logs 与Oracle archive logs

Oracle 的日志有两种类型：在线日志Redo Logs和归档日志Archived Logs。

如果Oracle数据库是运行在归档模式下的话，在多个Redo Logs中（数据库

默认情况下为3个），每写满一个，数据库会自动做一次归档操作，把当前在

线日志信息存放在Archived Logs里。然后接着使用下一个redo log，这样实

现对多个在线日志循环使用。通常情况PAC读取在线日志的信息。因此不要

求Oracle 数据库必须打开归档。但在某些特殊情况下，Redo logs还没来得

及处理就被覆盖或清除，此时PAC将需要读取归档日志以获取需要的信息，

所以我们推荐用户打开Oracle归档。

2.2.2 PAC与OCI

OCI(Oracle Call Interface)是Oracle公司提供的基于Oracle数据库应用程序的底层

接口。它具有速度快、与平台无关性（跨平台）支持第三代编程语言、对Oracle

数据库的控制功能强等优点。

通过调用OCI接口访问Orcle数据库，PAC可实现对任何操作平台下的Oracle数

据库进行访问和远程装载。同时，这也是实现PAC无需在生产环境安装任何插件

的技术之一。

2.2.3 复制范围与日志断点定位

z复制对象和方式

PAC复制以表级为单位，在对用户指定了需要同步的表后，PAC通过过滤日

志，只处理指定复制对象有关的交易，其它表的操作信息则不会传输到目标

端。

z数据变化定位技术

在PAC每次成功读取redo log信息后，内嵌数据库中会记录最后一个SCN

号。在下一个读取周期的时候，PAC会根据这个SCN号去查找日志中的下一

个SCN号，来定位数据库的变化操作信息。同时这也是PAC针对数据库异

常情况下，实现断点续传的关键之一。

2.2.4 严格的交易级别同步控制

基于PAC的日志读取模式（在源库读取日志信息是以“事务”为单位读取），PAC

在目标库装载时，会严格按照源库的“交易”顺序和源库事务的先后顺序执行，

确保“交易”的一致性和完整性。

2.2.5 高效安全的内嵌缓存数据库

PAC内嵌有自身专用的缓存数据库，用来临时存储从源端捕获过滤的事务的SQL

语句。当与目标库网络正常时，再严格按照交易的先后顺序把重做数据发送到目

标库装载，PAC的这一设计有助于其实现断点续传功能。

2.2.6 断点续传

PAC可以正确地处理将备用数据库与主数据库暂时断开的网络连接问题。当备用

数据库变为不可用时，PAC在主数据库本地继续捕获事务。当重新建立与备用数

据库的连接时，将自动传输累积的日志，并将其应用到备用数据库中，直到备用

数据库已经与主数据库重新同步。

实际验证表明，PAC在证券行业的处理速度可达到200笔/秒，以一个中等规模的

交易系统（100万笔交易/天，每个交易包含10条100bit的SQL语句）为例：在

断网1天后，PAC内嵌数据库的缓存记录有100万条交易。那么当网络连通后，

PAC在备库装载完所需要的时间为：1000000/200=5000秒=83分钟，也就是说一

天的累计量需要83分钟来完成复制。理论上，断点时间无限制，但是为了能尽快

的达到主备库的一致和防止万一因累积数据量过大而可能造成的部分数据丢失，

所以建议用户尽快修复。

2.2.7 跨平台支持、高兼容性和低影响性

由于PAC采用基于Oracle客户端OCI的连接远程装载技术，因而能够支持不同

版本Unix、Linux、Windows 系统下的Oracle 复制，对于具有复杂硬件环境的企

业来说，异构部署可以节省大量的资源，有效降低成本。同时，PAC还支持Oracle

数据库本身版本间的跨版本复制。大大提高了用户对软件的灵活规划性。跨版本

支持功能对用户的数据库升级也非常有价值，PAC可以协助把7*24 运行的

Oracle9i 数据库在线升级成Oracle10g。

基于采用Oracle客户端OCI连接远程装载技术，PAC无需在生产系统和备份系统

上安装任何插件，也无需改变生产环境的任何设置，因而PAC对容灾系统的环境

表现出近“0”影响；PAC只要求在装载数据库时，使用“SYS”用户来做同步数

据库的装载。

2.2.8 PAC与数据库的DML、DDL、DCL操作

数据操纵语言DML(Data Manipulation Language)用于查询和操纵模式对象中的数

据,主要包括UPDATE、INSERT、DELETE、EXPLAIN PLAN、SELECT、LOCK

六种语句。

数据定义语言DDL(Data Definition Language）用于定义数据的结构如定义或改变

数据库、表结构数据类型表之间的链接和约束,主要的包括CREATE、ALTER、

DROP三种语句。

数据控制语言DCL(Data Control Language）用于控制用户对数据库对象的访问权

限，主要包括GRANT、REVOKE、DENY三种语句。

目前PAC完全支持数据库的DML操作，但并不是所有DML操作都同步，PAC

会在缓存数据库内对所取得的SQL语句进行过滤转换等操作，只传输有效操作。

可支持数据库的DDL操作，PAC for Oracle目前8i支持CREATE TABLE、CREATE

VIEW；9i/10g支持TRUNCATE TABLE，但是沃信不建议用户利用PAC做此类

操作，例如当主备库之间存在操作平台异构时，主库的创建表空间操作是无法被

同步到备库的，这会导致PAC同步报错，影响同步作业运行。

因为DCL涉及到用户的权限问题，可能存在数据安全管理的隐患，目前PAC不

支持对DCL操作的同步。。

2.2.9 大对象支持

在PAC初始化的远程装载过程中，会读取数据库每个表的列信息。在同步过程中，

如果捕获的事务的含有大对象的操作，PAC会做如下处理：首先同步非大对象列

的值，当非大对象列在目标库装载完后，该事务暂不提交，PAC再利用LOB定

位符直接进行读取和装载操作，不在PAC缓存库中做缓存处理，当装载完成后提

交该事务。

说明：

LOB定位符是一个指向实际数据的指针,Oracle数据库中的大对象如CLOB，BLOB

等，存储时是以二进制形式存储在特定的存储区域，而数据区保存的是指向该特

定区域的LOB定位符）

在网络异常时，可能出现以下两种情况：

z大对象在同步过程中出现网络中断

该情况下，由于大对象并没做缓存处理，因而会导致该大对象数据无法复制

到目标库

z在网络中断的情况下，源库出现了对大对象的操作

由于PAC是以“事务”为单位进行同步，且处理方式是以该事务中非大对象

列为优先装载的机制，所以在网络重新连通的时候，会查找断点与记录的SCN

号对应的“事务”继续在目标库装载，当装载到该含有大对象的事务时，会

按照正常的流程装载，不会丢失数据。

综上所述，PAC只有在装载大对象的过程中出现异常的话，才会引起大对象数据

丢失

2.2.10 Truncate支持

当读取到redo语句后，PAC会先做判断，如果redo语句中含有truncate这个关键

字，则从truncate的语句中获取到这个操作的表名,重新组装成完整的事务SQL语

句，并在目标库装载。

2.2.11 交互式界面设计

PAC的界面设计遵循以下原则：

z符合用户的逻辑思维

z简洁，实用

z简化操作流程，并提示用户进行操作

z图形元素风格统一，美观协调

针对以上原则，PAC设计了简洁友好的交互式界面，该界面包含了“作业”“事

务”“日志”三大功能界面。

在“作业”界面中，PAC通过远程装载数据库信息，用户可详细的查看所有同步

表和被屏蔽表的记录信息，并且还能直观的查看每个作业的运行情况（每个作业

以“需同步”、“已同步”和“被屏蔽”条数显示）。

在“事务”界面，对每个同步作业，PAC从内嵌缓存数据库中抽取其最后执行的

100条SQL语句，显示在“事务”界面的显示区域上，用户可以选择不同的作业，

以SCN号查询每条操作所执行的SQL语句，大大提高了同步的透明性，有助与

DBA的跟踪管理。同时为了防止日志信息过多，可能对同步造成性能影响，PAC

还可以提供日志清除设置。

在“日志”界面，当PAC遇到意外情况时，该日志窗口会显示出错信息提示，如

数据库出现异常无法连接，网络中断等。

第3章数据库容灾系统建设方案

3.1 需求分析

虽然国内企业的数据灾备建设目前还处在起步阶段，但对于数据安全性要求的级

别却仍然需要遵循世界标准。从某种程度来说，国内企业目前的数据量已经超过

了同行业的欧美企业。

另外一方面，容灾是一个复杂的系统，基础技术的选择对整个灾备系统的应用效

果、易用性和可扩展性会产生非常大的影响。其中，底层数据库复制技术是整个

容灾系统的核心部分。传统的复制容灾技术仅限于硬件层和存储管理层，不但无

法解决系统异构的问题，而且成本高昂。特别是灾备设备和数据无法利用，造成

巨大的资源浪费。

对于某证券公司来说，目前需要在北京总部建立容灾中心，通过4M带宽的SDH

网络将上海主系统的数据库数据远程复制到北京容灾中心。并在上海本地分别建

立热备容灾系统和查询分析系统。由于证券行业交易日交易量大的行业特点以及

远程带宽的限制，传统的物理层容灾复制技术是无法满足需求的。因此需要更灵

活的逻辑层复制容灾技术来设计容灾系统。

3.1.1 用户期望

1.数据库备份机制对主数据库系统的性能影响低

CPU消耗平均低于3%，峰值低于5%

2.数据库备份系统带宽占用少，时间差小

本地实时备份系统数据库平均延迟低于5秒，峰值低于15秒；在4M通讯带

宽下，异地实时备份系统数据库平均延迟低于30秒，峰值延迟低于90秒

3.本地实时备份系统数据库和异地实时备份系统数据库处于可用状态

4.本地（上海）延时备份系统的延时时间可人工设置

5.数据库备份系统运行稳定，具备强大的自检能力

能提供准确的主备数据时间差异，对数据库传递过程中出现的错、漏、重能

主动进行纠错和报警

6.当数据库备份出现异常时，系统支持自动或经由人工干预对所有表单或特定

表单进行实时恢复

7.数据库备份系统运维管理方便，数据库表结构和索引变更时，无需复杂的配

置。运维管理易学习，无需复杂的培训

8.具备五家以上中国大中型企业大处理量实时业务系统一年以上针对

ORACLE数据库的成功经验

3.1.2 用户软硬件环境

表 3-1用户软件环境

序号 业务名称 操作系统 数据库版本 备注

1 集中交易系统 LINUX Oracle 10g 上海(RAC结构)

2 热备容灾系统 暂未确定 Oracle 10g 上海

3 查询分析系统 暂未确定 Oracle 10g 上海

4 远程容灾系统 LINUX Oracle 10g 北京

5 本地延时容灾系统 windows 上海

3.2 PAC热备容灾部署

我们提出基于Oracle redo logs日志分析的逻辑级复制容灾方案。使用PAC远程

复制软件，支持跨平台跨版本的远程Oracle数据实时容灾，能够预防自然灾害、

系统宕机等物理故障，实时保护公司数据的完整性，保障核心数据库的安全和

稳定。

3.2.1 本地热备容灾系统部署

考虑到公司日交易量大的特点，为了能够取得用户期望或更好的同步复制效果，

我们建议用户采用“第三台”的安装方式，即PAC单独安装在一台PC Server

上。并在这台Server上安装Oracle 10g客户端。

如图3-1，具体配置如下：

1.在热备容灾服务器上安装LINUX+Oracle10g数据库，并按由用户自定义建

立数据库实例

2.在PAC Server上安装LINUX+Oralce10g客户端，并在ORACLE客户端分

别添加上海核心数据库和热备容灾数据库网络服务名（默认是该数据库的

实例名，这是Oracle数据库之间通过网络互相访问的服务），并确认服务

连通。

图表 3-1本地热备容灾网路拓扑图

3.2.2 本地查询系统部署

z构建企业高实时数据中心

基于PAC的热备容灾方案，所有容灾数据库均为打开状态，因而查询平台方

案不需要安装额外的软件支持，即可直接对数据库进行应用。

z统一查询平台优势

?查询的实时性

目前很多查询方案都是定时地从生产数据库手工抽取数据进行应用，数

据的实时性得不到保证。而生产数据库的特点是突发性和随机性高，对

于数据分析来讲，数据的实时性得不到保证无疑是耽误了分析决策的最

佳时机。

PAC能够自动的实时将数据复制到查询数据库，将查询数据的延迟由以

“天”为单位降低到以“秒”为单位，根本性的提高了数据应用的有效

性和及时性。从而使企业得到最佳分析决策时机得到有效的保证。

?对生产系统的分流作用

证券行业突出的频繁交易操作和大量并发查询请求的出现，将对生产数

据库系统的资源争用非常严重，从而导致查询业务非常缓慢，同时也导

致生产业务性能大幅度下降，影响业务系统的对外服务能力，严重影响

企业形象。所以将查询数据库分离出来后，可以大大减轻生产系统的压

力和提高生产系统的服务能力。

?提高查询性能

通过将查询系统独立可以提高查询的性能。查询数据库与生产数据库完

全独立，可以按照OLAP（联机分析处理On-Line Analysis Processing）

系统的标准进行单独优化，如修改数据库存储及内存参数，增加索引等

工作能大幅提高查询性能。

?加强扩展业务支撑

因为传统应用部署都是以生产数据库中心为核心的，所有的外围系统数

据都直接来源于生产系统，但随着业务变化的逐步深入，外围系统越来

越复杂时，这种架构为企业应用部署带来了新的挑战：

可扩展性较差，生产系统性能无法满足大量的外部系统延伸；

生产系统功能单一，系统建设难度加大，系统建设失败率升高；

生产系统稳定性差，大量的新增外围系统的部署要求生产系统处于不断变化之中。生产系统的稳定性和连续性受到很大影响。

PAC支持应用系统部署的优化。将部署架构从传统的“以生产中心为基

础”的模式转向为“以灾备系统为基础”的架构。将外围系统如：报表

分析系统、归档系统、统计查询系统、决策支持系统等建立在灾备数据

库基础上，在与生产数据库隔离的情况下任意扩展外围系统，而不会对

生产系统产生任何影响。

通过PAC建立的灾备系统可提供业务连续性支持，更可以实现生产系统

信息的流通与共享，提升生产系统价值。实现灾备、数据共享一体化数

据管理架构。

z复制方式的灵活性

根据业务需求不同，所以对数据的内容需求，更新频率和周期也可以有所不同，针对查询和统计系统PAC提供了灵活的复制方式，完全可以按需要复制数据。PAC支持对指定表或用户的按需复制，同时达到减少存储和降低网络带宽压力的作用。

z查询应用系统的部署

图表 3-2查询应用系统拓扑

3.2.3 远程集中容灾部署

针对某证券公司规划在北京搭建远程容灾中心的计划，我们推荐做如下部署：

1.在北京远程容灾中心新增的硬件设备上，按照上海主系统构建硬件环境

2.在该环境下构建与上海主系统相同的数据库实例，相同的数据库信息（如User，

Tablespace等）

3.在上海本地容灾中心的 PAC Server上的Oracle客户端添加北京远程容灾中

心中容灾数据库的网络服务名，并确认能连通

部署如图3-3所示

图表 3-3远程集中容灾网络拓扑图

3.2.4 PAC安装环境需求与复制性能

数据保护观念越来越强的今天，用户选择数据复制产品时，产品的性能、数据的

一致性和系统的稳定性往往是关注的重点。PAC做为领先技术的产品，不但在功

能上能满足用户的各种业务需要，而且在用户所关注的方面也能很好的满足。

z安装PAC的环境需求

?软件需求

安装PAC的操作系统目前只支持LINUX系列，安装PAC的机器必须有

Oracle数据库（可以安装服务器或者客户端）。

?硬件需求

由于PAC采用高性能逻辑复制技术和Oracle客户端OCI远程装载技术，

决定了它具有很强的兼容性，因而无须采购特定型号的硬件，如磁盘阵

列等；PAC配合硬件，可有多种安装方式：如果使用第三台机作为安装

PAC软件来实现单库对单库任务的话，普通PC机（内存512MB以上，

CPU单核1.6GHz以上）只要能与主备库网络连通，就能很好的完成同

步任务；同时，PAC还可以装在生产机或热备机等满足PAC安装软件需

求的任一机器上。安装方式及硬件的选择可根据用户的不同需求做不同

的选择。

z日志分析处理速度

PAC速度有多快？其中一个主要的描述就是处理日志的速度。在实验室压力

测试下，PAC 利用一颗2GHz CPU 的资源每小时能够处理3GB 的Oracle 日

志。在实际应用中，PAC在广发**证券公司出现峰值交易的情况下，处理速

度为2000笔交易/秒，当然，由于硬件环境的不同我们很难有一个非常精确

的性能指标，但是这样的表现足以处理某证券股份有限公司的容灾需求。

z复制延迟原因

复制的延迟是指源端日志产生到目的端交易装载完毕的时间差。用户对数据

实时性的严格要求让复制延迟成为重要的关注指标。PAC 技术原理决定了延

迟必定存在，虽然它可能很小。以下几个方面的瓶颈会产生延迟问题：

?硬件速度

如果CPU 能力不足，那么数据的分析处理就会受到影响，特别是在目

的端系统，可能需要更多的CPU 执行并行数据装载以减少复制延迟。

?网络带宽和网络阻塞

PAC 传输的交易数据相对较小，因此对网络带宽要求很低。经验表明，

对于一个中等规模的交易系统（100 万笔交易/天），假设每笔交易包含

10条SQL语句，每条SQL语句100bit，那么每天需要传输的数据量为：

（（1000000*10*100/1024）/1024）=954MB，即每天的工作时间内的传

送速度为：954/（8*60*60）=33.5Kb/s，所以目前1MB带宽的VPN网络

理论上不会出现明显的网络延迟。当然一条专用稳定的线路是必要的，

其他网络应用引起的阻塞会影响到PAC的传输性能。

?目的端数据库的工作情况

偶尔我们会遇到复制的交易在目的端暂停装载的情况，而PAC 自身却

没有错误发生。这是由于目的端数据库繁忙造成的。数据库shutdown，

不可连接，某些资源紧张，大量的job 运行等都可能导致以上问题。目

的端装载延迟在所有可能引起延迟的因素中所占比例最高，影响也最大。

如果不存在以上瓶颈，那么PAC 的延迟表现还是非常优秀。在单实例数据库模

式下，平均的延迟为1~2 秒(不计用户设置的读取日志周期)，RAC 模式数据库下，

平均的延迟为7~10 秒(不计用户设置的读取日志周期)。与其他同类产品相比，

PAC 毫不逊色。

3.2.5 备库的初始化和软件的安装配置

z备库的初始化

复制容灾系统的建立，首先需要对备库数据进行初始化操作，具体如下：

1.在热备服务器上安装相应数据库实例

2.在对应实例中建立与源相同的用户和表空间

3.在业务量少的时间段停止外部使用数据库，然后使用System用户在源库

执行EXP命令，把源库数据导出

4.在备库使用System用户把刚才EXP出来的数据用IMP命令导入到相应

的实例

5.在备库SQLPLUS里面执行alter system switch logfile命令3次来确保激

活数据库的在线日志

至此备库初始化完毕。

z PAC的安装配置

在PAC Server上使用安装程序安装PAC（具体参考PAC安装说明书）。

安装完成后运行PAC同步复制工具，在“新建”界面输入我们之前添加好的源库

和备库的网络服务名，PAC会自动的读取源库和备库的信息，之后用户只需要选

择相应的源和备库来配置不同的同步复制作业，之后启动抽取、分析、装载进程

即可

到此PAC配置完成，具体详细配置请参考PAC使用说明书。

3.2.6 复制的实时性与有效性

z PAC软件的高健壮性

PAC方案具备足够的健壮性。源系统、目标系统和PAC Server的任何故障都

不会影响到复制环境。在以下故障发生时，PAC故障处理方法如下：

?源系统主机故障

源系统主机故障修复后，当Oracle数据库和操作系统重新启动后，PAC

自动重试连接数据库，并从断点继续进行复制工作。

?数据库故障

当源系统数据库故障修复后，当Oracle数据库重新启动后，可以从断点

继续进行复制工作。

?复制软件故障

当复制软件遇到任何非人为关闭时，可重新启动软件，所有任务会处于

暂停状态，只需继续运行任务，即可保证所有数据的继续复制。

?网络故障

当网络恢复后可以自动从断点进行复制工作。

?目标系统的主机故障

源库数据存储在PAC的内嵌数据库中，当目标系统主机故障修复后，从

断点继续进行复制工作。

?数据库故障

数据存储在PAC的内嵌数据库中，当目标系统数据库修复后，从断点继

续进行复制工作。

z数据丢失情况与弥补方案

PAC解决方案在一般性灾难发生时不存在数据丢失。这些一般灾难包括数据库宕机、操作系统宕机等等。对于一些极端的情况下，掉电、站点失败时，PAC也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。

?网络失败

PAC与源或目标之间的网络其一或同时中断，只要三者之间的网络恢复

时，PAC断点机制将自动从断点继续复制，没有数据损失。

?数据库关闭

无论是源库或目标库关闭，只要数据库恢复后，PAC断点机制将自动从

断点继续复制，没有数据损失。

?操作系统重起

在重起完系统，数据库起来后，PAC断点机制将自动从断点继续复制，

没有数据损失。

?掉电

大量测试表明不会出现数据丢失（但从理论上讲这些极端情况无法100%

避免数据丢失，因为这种情况可能造成了系统的严重破坏）。不过对于重

要的生产系统一般通过UPS预防断电情况，发生概率非常小.。

?PAC Server宕机

PAC的高健壮性保证了除人为终止外的所有意外关闭情况，PAC在软件

重起后，所有任务都会处于暂停状态，用户只需点“继续运行”，便可从

断点继续复制，没有数据损失。

?数据中心完全毁坏

由于目标系统在线可用，不存在任何切换风险。但对于还没来得及传输

到目标系统的数据可能出现少量丢失（最多为PAC扫描周期5秒内的数

据）。

z同步时间延迟

PAC是一种准实时数据库热备容灾软件，其数据延迟非常小。在生产系统中，数据延迟和源系统复制事物的多少、事物的处理方式有关、以及网络带宽有关；同时，还跟用户设置任务的同步周期有关。数据延迟一般是几秒钟。

z事务的完整性与可用性

PAC是一款准实时数据库热备容灾软件，其复制的基本单位是事务

(Transaction)。PAC在从redo logs中读取到交易数据后，存放在PAC的内嵌

数据库中，按照Oracle的SCN标记排序进行分析过滤，然后以一个基本单

位发送给目标端。目标端在执行时也严格按照SCN号进行，因此严格保证了

事务之间的先后秩序和交易的完整性。

3.2.7 PAC对资源的占用

与其它类型的复制产品比较，PAC要求的整体系统资源很少。无须采购指定型号

的硬件，如磁盘阵列；不需要特殊基础软件配合，如专用文件系统等。

z对源机的要求与影响

由于本方案PAC采用第三台机安装，无需在源机安装任何插件，因而安装调

试过程不会改动数据库，也不涉及文件系统、操作系统和数据卷。完全能够

在业务系统不停机甚至工作状态下实施安装、调试。而其他的解决方案可能

需要停机，甚至改动软硬件的配置。对生产系统将会产生较大的影响。

z对目标机器的要求与建议

由于本方案PAC采用第三台机安装，无需在源机安装任何插件，因而PAC

对目标机没有任何要求，但是，由与我们需要在目标机器安装数据库的多个

实例，所以建议该机配置至少与其中一源服务器相当或者更高，存储空间至

少是当前4个需要同步复制数据库空间总和的2倍。

z对网络资源的要求与建议

PAC方案所需网络带宽很少，能够在有限传输带宽上保证复制工作不延迟。

因为PAC复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而

不是采用中间件方式，传输只发生改变的数据也使网络负载降至最低。

通常情况下PAC传输的数据量只相当于日志的三分之一。在电信行业做过的

一些测试表明，基于数据库的复制技术的数据传输量仅仅是基于磁盘阵列或

卷管理复制技术的1/70。

以目前已经实施了PAC热备的南海西部石油油田服务（深圳）有限公司为例：

由于该公司需要同步海上作业油田的数据到大陆基地，在没有物理网络连接

的情况，该公司租用了卫星公司的128K链路进行通讯。经过过去对业务系

统的使用，发现海上平台的业务终端通过128K（实际上除掉网络电话等对带

宽的占用，业务系统可使用的带宽已经低于128K）链路访问基地的服务器，

访问速度很慢，可操作性非常低。但通过实施了基于逻辑复制技术的PAC的

热备方案后，基地可以快速的对备库进行查询，从根本上解决了基地查看油

田作业信息难的问题。