第9 部分: Informix 复制技术
关于本教程
本教程讨论 IDS 11.50 提供的各种复制和高可用性技术。它解释了如何配置High Availability Data Replication (HDR)、Enterprise Replication (ER)、Remote Standalone secondary (RSS) 服务器、Shared Disk secondary (SDS) 服务器和持续日志恢复。
目标
本教程主要帮助您熟悉：
?IDS 提供的各种复制技术
?各种复制技术之间的区别
?不同的复制术语
?如何设置 HDR、ER、RSS、SDS 和持续日志恢复
?容量释放：您可以将 OLTP 数据传播到备份站点，可以在报告时将用户引导到备份站点。这样，就可以在主站点上为与 OLTP 相关的用户提供更多的容量。
?高可用性：在主站点更新数据，然后再复制到备份站点。当主站点出现故障时，备份站点将成为主站点。
?数据合并：您可以将远程数据合并到中央服务器中。例如，您可以合并分支机构的数据。
?分布式可用性：您可以从中央服务器将数据分布到不同位置。例如，您可以从总部将数据分发到分支机构。
?就地更新：以点对点的方式在任意站点上更新数据，从而保持数据的一致性。
?主服务器和备份服务器的操作系统和硬件相同。不能在不同的操作系统之间设置 HDR。
?添加到每个服务器的块的磁盘布局必须相同。必须在备份服务器上创建可用的驻留数据库块的设备，并且其 PATH 值必须与主服务器一样。这可以通过符号链接来实现。
?HDR 主服务器和备份服务器上的 IDS 的版本必须一样。
?必须记录数据库日志。
?如果使用 blob 数据库类型，那么它们必须储存在 dbspace 中。将不复制存储在 dbspace 中的 blob 数据类型。
?如果根块（chunk）被映射到主服务器，那么也必须将它映射到备份服务器。
?HDR 使用 TCP/IP 连接。数据库服务器的名称（DBSERVERANME 配置参数的值）必须设置为 sqlhosts 文件中的 TCP/IP 连接。
?主服务器和备份服务器都必须是可信的。为用户 informix 修改 .rhosts 或 /etc/hosts.equiv 以建立可信通信。
?DRAUTO：DRAUTO 配置参数决定在主服务器失败时备份服务器采取什么操作。该参数的设置在主服务器和备份服务器中必须相同。需要谨慎地使用该参数。如果出现临时的网络失败，每个服务器都能感知对方宕机。对于这种情况，如果 DRAUTO 设置为 1，备份服务器将转变为标准服务器，而主服务器停止复制。客户端将分别尝试在这两个服务器上更新数据。这可能导致服务器不能保持同步。根据 DRAUTO 的设置不同，备份服务器可能执行以下操作之一：
o如果 DRAUTO 设置为 0，备份服务器将保持只读状态，直至手动地将其切换为主服务器或切换到标准模式。
o如果 DRAUTO 设置为 1（RETAIN_TYPE），备份服务器在主服务器失败时自动切换为标准服务器。当 HDR 对重新启动时，该服务器
将重新切换回到备份服务器。
o如果 DRAUTO 设置为 2（REVERSE_TYPE），备份服务器在主服务器失败时自动切换成主服务器。当 HDR 对重新启动之后，该服务器
将切换为主服务器（而原先的主服务器切换为备份服务器）。
?DRINTERVAL：DRINTERVAL 指定 HDR 数据缓冲区刷新之间的最大秒数。该参数在主服务器和备份服务器上的设置必须相同。
HDR 有两个主要操作模式：同步和异步。让我们看看更新如何从主服务器传播到备份服务器。
当主服务器开始将共享内存中的逻辑日志缓冲区的内容转储到磁盘的逻辑日志时，它同样将逻辑日志缓冲区的内容复制到一个数据复制缓冲区。
数据复制缓冲区是主服务器管理的虚拟共享内存的一部分。数据复制缓冲区的大小与逻辑日志缓冲区的大小一样。然后，主服务器以同步或异步的方式将数据复制缓冲区的内容发送到 HDR 备份服务器。配置参数
DRINTERVAL 的值决定服务器使用同步还是异步的方式进行更新。
o如果 DRINTERVAL 设置为 -1，更新就是同步的。
o如果 DRINTERVAL 设置为 -1 以外的其他值，那么更新就是异步的。
HDR 同步更新：当 DRINTERVAL 设置为 -1 时，到 HDR 备份服务器的数据复制就是同步的。当主服务器向 HDR 缓冲区写入逻辑日志缓冲内容时，它就将这些记录从缓冲区发送到 HDR 备份服务器。仅当主服务器收到来自 HDR 备份服务器关于记录已经接收的确认消息之后，主服务器上的逻辑日志缓冲转移才完成。
HDR 异步更新：当 DRINTERVAL 设置为 -1 以外的其他值时，到 HDR 备份服务器的数据复制就是异步的。主服务器在将逻辑日志缓冲区内容复制到 HDR 缓冲区之后才刷新逻辑日志缓冲区。当发生以下情况之一，主服务器将通过网络发送 HDR 缓冲区的内容，并且不受以上操作的影响：HDR 缓冲区变满，或者从最后一次刷新 HDR 复制缓冲区开始，在主服务器上由 DRINTERVAL 指定的时间间隔被错过。
?DRTIMEOUT：DRTIMEOUT 指定 HDR 对等待彼此的传输确认消息的时间间隔（单位为秒）。如果检查点没有在配置参数 DRTIMEOUT 指定的时间内完成，主服务器就认为发生了故障。该参数在主服务器和备份服务器上的值必须相同。
?DRLOSTFOUND：DRLOSTFOUND 配置参数指定 dr.lostfound.timestamp 文件的路径名。如果主服务器没有在 DRTIMEOUT 配置参数指定的时间内收到备份服务器的确认，它将向一个由 DRLOSTFOUND 配置参数命名的文件添加事务信息。
?ENCRYPT_HDR：ENCRYPT_HDR 指定是否启用 HDR 加密。
o 1 表示启用；为服务器之间的数据传输提供安全的办法
o0 表示禁用
增加安全性会带来额外的开销。加密和解密 HDR 数据要占用额外的 CPU 周期。
?DRIDXAUTO：DRIDXAUTO 指定当备份服务器检测到索引损坏时，HDR 服务器是否自动开始索引复制。
o 1 = on；自动复制索引
o0 = off；需要手动复制索引
?LOG_INDEX_BUILDS：LOG_INDEX_BUILDS 指定是否启用索引页日志。
o1：启用索引页日志。索引页被复制到逻辑日志。主服务器通过日志将索引发送到备份服务器。
o0：禁用索引页日志。当在主服务器上创建了索引时，将逐页把它传输到备份服务器。
如何设置和管理 HDR
首次设置 HDR
在进入设置 HDR 的步骤之前，首先要为 informix 用户启用主服务器和备份服务器之间的可信通信。为网络连接更新 $INFORMIXSQLHOSTS 和 /etc/services 文件。确保 onconfig 文件在主服务器和备份服务器上都正确设置。以下配置参数在主服务器和备份服务器上的值必须相同。
?ROOTNAME
?>ROOTOFFSET
?ROOTPATH
?ROOTSIZE
?MIRROROFFSET - 如果使用映像
?MIRRORPATH - 如果使用映像
?PHYSDBS
?PHYSFILE
?LOGFILES
?LOGSIZE DYNAMIC_LOGS
?DRAUTO
?DRINTERVAL
?DRTIMEOUT
?DRLOSTFOUND
?LOG_INDEX_BUILDS：可选
表 1. 首次设置 HDR 的步骤
步
骤
主服务器备份服务器
1安装和注册 UDR、UDT 和
DataBlade 模块。
安装 UDR、UDT 和 DataBlade 模块。
2ontape -s -L 0、onbar -b -L 0，或执行外部备份
-
3 onmode -d primary sec_name -
4 - ontape -p、ontape -r -p -e、onbar -r 或 onbar -r -p -e
5 - onmode -d secondary prim_name
6 - ontape -l or onbar -r -l
下面详细描述表 1 中的步骤：
1.在两个服务器上安装用户定义的类型、用户定义的例程和 DataBlade
模块。仅在主服务器上注册它们。
2.对主服务器执行 0 级别的部分。
3.运行以下命令将服务器设置为主服务器：
onmode -d primary sec_name
4.
5.在以上命令中，将sec_name替换为备份服务器的数据库服务器名
（DBSERVERNAME 配置参数的值）。在执行该命令之后，以下消息将打印到 online.log：
DR: new type = primary server name = sec_name
DR: Trying to connect to secondary server
DR: Cannot connect to secondary server
6.
7.在备份服务器上，使用备份时采用的实用工具从在步骤 2 中创建的 0
级别备份执行物理恢复。不要执行逻辑恢复。
o ON-Bar：使用 onbar -r -p 命令执行物理恢复。
o ON-Bar 并执行外部恢复：使用 onbar -r -p -e 命令执行物理恢复。
o ontape：使用 ontape -p 选项。您不能使用 ontape -r 选项，因为它同时执行物理和逻辑恢复。
o ontape 和执行外部恢复：使用 ontape -p -e 命令执行物理恢复。
8.在备份服务器上，运行以下命令将服务器设置为备份服务器：
onmode -d secondary prim_name
9.
10.在以上命令中，将prim_name替换为主服务器的数据库服务器名
（DBSERVERNAME 配置参数的值）。如果磁盘上的所有逻辑日志仍然可用的话，备份服务器上的恢复就能够完成；否则需要执行步骤 6。在执行该命令之后，将在备份服务器的 online.log 中打印以下消息：
DR: new type = secondary server name = prim_name
11.
12.如果写到主服务器的逻辑日志记录不再存在主服务器磁盘上，那么备份
服务器将提示您从磁带备份恢复这些文件。从磁带恢复了所有逻辑日志文件之后，逻辑恢复就完成了，从而可以在主服务器磁盘上使用逻辑日志文件。
当 HDR 设置成功完成之后，将在主服务器的 online.log 打印以下消息：
DR: Primary server connected DR: Primary server operational
将在备份服务器的 online.log 中打印以下消息：
Secondary server operational
?备份服务器在消息日志中打印一条消息：
DR: Receive error. HDR is turned off.
?
?备份服务器受到的影响取决于 DRAUTO 配置参数的设置：
o如果 DRAUTO 设置为 0，备份服务器将保持只读模式。
o如果 DRAUTO 设置为 1，备份服务器将切换到标准模式，并且可以接受更新。
o如果 DRAUTO 设置为 2，备份服务器将在旧主服务器连接丢失时切换到主服务器模式。
在备份服务器上，运行 onmode -k 命令将导致主服务器在消息日志中打印：DR: Turned off on primary server
Enterprise Replication：简介
Enterprise Replication (ER) 是一种基于异步日志的复制方法。当复制事务被提交并发送到目标实例（在此处用作常规日志事务）之后，将从源实例的逻辑日志捕捉它们。这种类型的复制对源实例的影响很小。由于信息是从逻辑日志读取
的，所以它不影响事务处理。因为复制是异步的，所以源实例将继续进行处理，而不是等待事务被应用到目标实例。
Enterprise Replication 的灵活架构支持多种复制方法和网络拓扑：?复制方法：
o主服务器-备份服务器（Primary-target）- 数据库更改发生在主服务器并被复制到目标实例，但目标实例上的更改不会复制到主服
务器实例
o处处更新（Update-anywhere）- 数据库更改应用到所有参与复制的实例，不管它们位于哪个服务器
?网络拓扑：
o完全连接（Fully connected）- 所有参与数据库服务器之间持续保持连接
o层次结构树（Hierarchical tree）- 一种支持持续连接和间断连接的父-子配置
o森林树（Forest of trees）- 通过根数据库服务器连接起来的多个层次结构树
Enterprise Replication 可以与 HDR、SDS 和 RSS 复制方法结合使用，这进一步增加了它的灵活性。此外，它还可以跨平台、跨 IBM Informix Dynamic Server 的各个版本使用。Enterprise Replication 不需要在实例之间定义相同的储存，甚至不需要使用相同的表模式和名称。
Enterprise Replication 的工作原理
下面列出了 Enterprise Replication 的 3 个阶段，并通过一个例子详细描述这 3 个阶段：
?数据捕捉
?数据传输
?应用复制数据
让我们通过一个简单的例子了解如何将一个事务从源实例复制到目标实例：
1.客户端应用程序在定义了复制的数据库中执行事务。
2.该事务被写入逻辑日志。
3.日志捕捉组件读取逻辑日志并将逻辑记录传递到分组组件。
4.分组组件计算需要复制的逻辑日志，并将它们分组到描述原始事务的操作
的消息中。
5.分组组件将消息添加到发送队列。在特定情况下，发送队列将消息临时储
存到磁盘上。
6.发送队列通过 Enterprise Replication 网络将复制消息传输到目标服
务器。
7.复制消息被添加到目标服务器的接收队列中。
8.数据同步组件将该事务应用到目标数据库。如果有必要的话，数据同步组
件还会执行冲突解决。
9.在确认队列中放置一条表示消息已成功应用的消息。
10.将确认消息发送回到源服务器。
?CDR_EVALTHREADS - 每个 CPU VP 的计算器线程数和额外的线程数，用逗号分隔（必要）
?CDR_DSLOCKWAIT - 数据同步组件等待数据库锁的秒数（必要）
?CDR_QUEUEMEM - 发送和接收队列的最大内存量，单位为 KB（必要）?CDR_NIFCOMPRESS - 控制网络界面压缩级别（必要）
?CDR_SERIAL - 指定增量大小和复制连续列的开始值（必要）
?CDR_DBSPACE - syscdr 数据库的 dbspace 名称（可选）
?CDR_QHDR_DBSPACE - 事务记录 dbspace 的名称；默认值为根 dbspace （可选）
?CDR_QDATA_SBSPACE - 临时储存到磁盘的事务数据的 sbdpace 名称，用逗号分隔（必要）
?CDR_MAX_DYNAMIC_LOGS - ER 在一个数据库会话中能够发出的动态日志请求的最大数量（必要）
?CDR_SUPPRESS_ATSRISWARN - 数据同步错误，警告在 STS 和 RIS 文件中隐藏的编码号（可选）
现在，我们通过一个例子了解如何在两个带有以下特征的实例中定义复制。这个例子展示处处更新复制。在处处更新复制中，任何服务器上的更改都被复制到其他所有参与服务器中。
?在 cook 文件 /u/data/qdatasbspace 中有一个名为 qdatasbspace 的CDR_QDATA_SBSPACE，它的偏移量为 0，大小为 200MB ?源组名 grp_er1，目标组名 grp_er2
?源 DBSERVERNAME er1，目标 DBSERVERNAME er2
?源数据库名 primary_db，目标数据库名 target_db
?源表名 primary_table，目标表名 target_table
?源 ATS 目录名 /u/data/atsdir，目标 ATS 目录名 /u/data/atsdir ?源 RIS 目录名 /u/data/risdir，目标 RIS 目录名 /u/data/risdir ?复制名 repl1
这个例子使用“timestamp”冲突解决方法。可用的冲突解决方法包括：
?always - Enterprise Replication 不解决冲突，但是将应用复制更改，即使操作在源和目标服务器上不一样。仅能用于从源服务器到目标服务器的复制。
?ignore - Enterprise Replication 不解决冲突。
?timestamp - 出现冲突时，时间戳最新的行或事务具有优先权。
?deletewins - 出现冲突时，带有 DELETE 操作或带有最新时间戳的行或事务具有优先权。deletewins 冲突解决规则阻止 upsert。
表 2. 首次设置 ER 的步骤
步
骤
源服务器目标服务器
1 使用 onspaces 为临时储存到磁盘的事务数据
创建 sbspace，由 CDR_QDATA_SBSPACE 指定：
?onspaces -c -S qdatasbspace -p
/u/data/qdatasbspace -o 0 -s 200000
使用 onspaces 为
CDR_QDATA_SBSPACE 定义
sbspace：
?onspaces -c -S
qdatasbspace -p
/u/data/qdatasbspace
-o 0 -s 200000
2 修改 onconfig 文件以设置
CDR_QDATA_SBSPACE：
?CDR_QDATA_SBSPACE qdatasbspace
修改名为 CDR_QDATA_SBSPACE
的 onconfig 配置文件：
?CDR_QDATA_SBSPACE
qdatasbspace
3 配置 sqlhosts 文件，以包含源服务器和目标
服务器的连接：
?grp_er1 group - - i=12
?er1 onsoctcp primary 9211 g=grp_er1
?grp_er2 group - - i=13
?er2 onsoctcp stewie 9212 g=grp_er2
配置 sqlhosts 文件，以包含
源服务器和目标服务器的连
接：
?grp_er1 group - - i=12
?er1 onsoctcp primary
9211 g=grp_er1
?grp_er2 group - - i=13
?er2 onsoctcp stewie
9212 g=grp_er2
4 为进行复制定义源服务器和目标服务器：?cdr define server -c grp_er1 -A
/u/data/atsdir -R /u/data/risdir -I
grp_er1
?cdr define server -c grp_er2 -A /u/data/risdir -R /u/data/risdir -I
-
-S grp_er1 grp_er2
5
定义复制：
? cdr define replicate -C timestamp -S
tran -A -R repl1 \
? "primary_db@er1.primary_table"
"select * from primary_table" \
? "target_db@er2.target_table" "select * from target_table"
? 注意：这将把 primary_table 的所有行
复制到 target_table 。可以在这里使用
任何有效的 select 语句，以定义需要
复制的数据。 -
6 开始复制：
? cdr start replicate repl1 - 这是设置复制的简单例子。阅读文档更详细地了解命令行语法和选项。 Shared Disk secondary ：简介
在 Shared Disk (SD) secondary 复制中，主服务器和 SD 备份服务器通过一个高度可用的集群配置共享磁盘空间。在该配置中，不在 SD 备份服务器中储存数据库的物理副本。如果主服务器和 SD 备份服务器驻留在相同的机器上，它们都可以访问本地磁盘。如果它们驻留在不同的物理机器上，那么配置它们以使用共享磁盘设备。不要将主服务器和 SD 备份服务器配置为使用操作系统缓冲区，比如 NFS 装载。主服务器和 SD 备份服务器共享磁盘空间，因此 SD 备份服务器的启动非常快，但它不能在复制环境之外提升为标准服务器，也不能提升为 RS
备份服务器。SD 备份服务器可以和 Enterprise Replication 、HDR 和 RS 备份服务器并存。
什么时候使用 SD 备份服务器？
?
增加容量：使用多个 SD 备份服务器能够减少报告容量，同时不影响主服务器实例。
? 主服务器失败备份：当主服务器失败时，SD 备份服务器能够快速提升为主服务器。
?SDS_ENABLE - 启用或禁用 SDS 服务器（必要）
?SDS_TEMPDBS - SDS 服务器使用的临时 dbspace
?SDS_PAGING - 两个缓冲页文件的路径
?SDS_TIMEOUT - 在将 SDS 服务器标记为宕机之前执行页刷新时，主服务器等待来自 SDS 服务器的确认的时间（秒）
?UPDATABLE_SECONDARY - 控制备份服务器是否能够接受更新、插入和删除操作
?TEMPTAB_NOLOG - 控制临时表的日志模式（在 SDS 服务器上要设置为 1）
表 3. 首次设置 SDS 服务器的步骤
步
骤
主服务器备份服务器
1 在 onconfig 文件中设置
SDS_TIMEOUT 配置参数。
-
2 设置 SD 主服务器的别名：
?onmode -d set SDS
primary alias
-
3 - 设置配置参数：
?SDS_ENABLE
?SDS_PAGING
?SDS_TEMPDBS
4 - 设置以下配置参数，使它们与主服务器上的参数匹配：
?ROOTNAME
?ROOTPATH
?ROOTOFFSET ?ROOTSIZE ?PHYSFILE ?LOGFILES ?LOGSIZE
5 - 在 sqlhosts 文件中添加一个主服务器条目：
?dbservername nettype
hostname servicename
6 - 开始使用 SD secondary 服务器：?oninit
查看文档详细了解命令行语法和选项。
将 SDS 服务器提升为主服务器
当主服务器失败时，通过发出以下命令之一将 SDS 服务器提升为主服务器：
onmode -d set SDS primary alias
onmode -d make primary
Remote Standalone 备份服务器：简介
RS (Remote Standalone) 备份服务器非常类似于 HDR 备份服务器。它可以在高度可用的集群中用于灾难恢复。它包含数据库的完整副本，以类似于 HDR 的方式接收日志，并且要求主服务器和备份服务器使用相同的硬件和数据布局。使用RS 备份服务器解决了只能使用一个备份服务器的限制，从而增强了可用性。
尽管 HDR 环境和 RS secondary 环境是相似的，但它们也有两个主要区别：?HDR 支持同步和异步模式，而 RS secondary 仅支持异步复制。
?HDR 使用同步检查点，而 RS secondary 没有使用。
什么时候使用 RS 备份服务器？
?增强服务器可用性：使用多个 RS 备份服务器能够提供更大的可用性。
?远程地理位置备份支持：通过将复制节点分布到多个地理位置，单点灾难导致停机的机会减少。
?改善报告性能：多个 RS 备份服务器可以将一部分报告转移到备份服务器，从而减轻报告对主服务器的影响。
?在不稳定的网络中增强可用性：在不稳定或速度很慢的网络环境中，RS 备份服务器通过利用异步复制消除在主服务器上出现的延迟。主服务器和
RS 备份服务器之间不同步任何事务提交和检查点。
?HA_ALIAS - 高可用性集群的服务器别名
?LOG_INDEX_BUILDS - 启用或禁用索引页日志（必要）
?UPDATABLE_SECONDARY - 控制备份服务器是否可以接受更新、插入和删除操作
?FAILOVER_CALLBACK - 当备份服务器切换为标准或主服务器时，指定需要调用的路径和程序名
?TEMPTAB_NOLOG - 控制临时表的默认日志模式（在 RS 备份服务器上需要设置为 1）
表 4. 首次设置 RS 的步骤
步
骤
主服务器备份服务器
1 安装和注册 UDR、UDT 和
DataBlade 模块。
安装 UDR、UDT 和 DataBlade 模块。
2 onmode 命令：
?onmode -wf
LOG_INDEX_BUILDS=1
-
3 onmode 命令：
?onmode -d add RSS
rss_servername
-
password
4 ontape 或 ON-Bar 命令：
?ontape -s -L 0
?onbar -b -L 0
-
5 - ontape 或 ON-Bar 命令：
?ontape -p or ontape -p -e
?onbar -r -p or onbar -r -p -e
6 - ontape 或 onbar 命令（当所有逻辑日志写在主服务器实例上时使用，因为步骤 1 的逻辑日志不再在主服务器磁盘上）：
?ontape -l
?onbar -r -l
onmode -d make primary alias
持续日志恢复：简介
可以使用持续日志恢复创建第二个系统（热备份），用于在源系统失败时取代源/主系统。该特性支持使用 ontape 和 ON-Bar 实用工具执行持续的逻辑日志备份恢复。只要源系统上的逻辑日志备份可用，就可以在目标系统上恢复它们。
常规的日志恢复将恢复所有可用的日志文件备份并应用日志记录。仍然打开的事务将在事务清除阶段回滚，然后使服务器进入静态模式。当服务器处于静态模式时，就不能再恢复其他逻辑日志。
通过使用持续逻辑日志恢复功能，当最后可用的日志被恢复之后，服务器将进入日志恢复暂停状态。恢复客户端（ontape 或 ON-Bar）退出，并恢复您的控制权。
当服务器处于该状态时，如果其他逻辑日志可用还可以开始另一个逻辑日志恢复。这种循环可以无限持续。
如果源系统失败，可以在目标系统上恢复其余的可用逻辑日志。然后，可以让目标系统上线并充当新的源系统。源系统和目标系统上的 IDS 的版本必须相同。
持续日志恢复的目的是帮助进行灾难恢复，它不是一个高可用性解决方案。不过，持续日志恢复服务器可以提升为 HDR 备份服务器。
设置持续日志恢复的步骤
表 5. 使用 ontape 设置持续日志恢复
步骤源服务器目标/备份服务器
1ontape -s -L 0 -
2- ontape -p
3ontape -a -
4- ontape -l -C
5- ontape -l -X
下面详细描述表 5 中的步骤：
1.对源服务器执行 0 级别的备份。
2.在目标服务器上，使用执行备份时所用的实用工具从步骤 1 创建的 0
级别备份执行物理恢复。不要自行逻辑恢复。
3.在源服务器上，使用以下命令备份逻辑日志：
ontape -a
4.
5.从源服务器将逻辑日志备份文件复制或挂载到目标服务器，并根据需要
重命名这些文件（或使用环境变量 IFX_ONTAPE_FILE_PREFIX 设置文件
名）。
在目标服务器上，使用以下命令执行逻辑日志恢复。目标服务器保持在恢复模式。
ontape -l -C
6.当所有必要的逻辑日志都被恢复之后，运行以下命令完成逻辑日志恢复
过程，并使服务器进入静态模式：
ontape -l -X
7.
8.注意：当目标服务器切换到静态或在线模式之后，持续日志恢复将停止。
您必须开始新的备份并重新启用持续日志恢复功能。
结束语
阅读完本教程之后，您应该对下列知识点有更深刻的理解：
?IDS 11.50 中可用的各种复制特性
?复制术语
?配置复制环境
数据镜像复制技术 大型的业务系统中，数据库中的各类数据，如市场数据，客户数据，交易历史数据，财务管理数据、社会综合数据、生产研发数据等，都是公司至关重要的资产，它不仅关系着整个业务系统的稳定和正常运行，还可能关系着巨大的经济利益。数据系统中，存储设备的安全和高可用性与数据库软件系统一样，都至关重要的一旦数据丢失，就有可能面临着百万、千万元的经济损失。 正因为如此，一个大型数据库系统要具有高安全、高可用性，就必须具有以下几个方面的特点： 高可用性HA（High Availability） l有遭受失败的能力 l有单独的服务和资源管理的能力 l通过一种类型的Cluster进行操作 l关键概念是失败转移(takeover) l与容错不同(容错失败是不可见的) 持续可用性CA( Continuous Availability) l一对或Cluster系统，支持100%联机运行 l高度分布式系统 l设计有多层冗余 l设计有客户端自动失败转移 l为非单点失败而设计 l为非计划停机事件而设计 在数据库系统设计中，常用到的系统结构图如： （图2） 如图所示中，数据库软件、主机、HBA卡和网络交换机一般都采用双机方式，通过多台设备间的Active-Active工作方式来保障系统中的高可用性。不过从上图我们也可以看到，整个系统中，只有存储是单台设备。虽然存储设备内部可通过双控制器、双电源和RAID组来实现内部的冗余，但从存储设备整体而言，仍然存在许多单点故障，比如控制器的背板，
磁盘扩展柜等；这与主机和网络层的高可用工作方式是不匹配的。一旦存储设备发生整体故障，将会直接引起整个系统瘫痪，甚至造成数据丢失，给使用者带来具大的损失。 1.1 卷镜像复制和RAID镜像卷 为了提供存储设备的高可用性，保障数据的安全性，常用的一种解决方案是再增加一台备用存储设备，由两台存储设备负责数据库系统的数据存储服务，保障数据库的安全和数据存储服务器稳定。根据两个存储设备之间工作方式的不同，数据同步和复制机制的不同，可分为两种方式，第一种是卷镜像复制方式，第二种是RAID镜像卷方式。 卷镜像复制工作方式的系统结构图如下： （图3） 左侧存储为主存储设备设备，右侧为备用存储设备，再通过卷镜像复制软件、数据备份软件、网络层的存储虚拟化设备、存储设备自带的卷镜像复制功能等多种方式来实现主、备两个存储之间的卷镜像复制，以此来保障数据的安全性，同时备份存储设备也可以作为数据库系统中的数据存储服务功能的一种后备方式，一旦主存储设备发生故障，就需要自动或手动的切换到备份存储设备上，这种切换实际上是主存储设备生产卷到备份存储设备的镜像卷的切换，经常会导致数据库不一致，数据库重起，切换时间过长等问题。。 RAID镜像卷工作方式的系统结构图下：
基于Oracle数据库的数据同步技术大体上可分为两类：Oracle自己提供的数据同步技术和第三方厂商提供的数据同步技术。Oracle自己的同步技术有DataGuard，Streams，Advanced Replication和今年 刚收购的一款叫做GoldenGate的数据同步软件。第三方厂商的数据同步技术有Quest公司的SharePlex 和DSG的RealSync。下面对这些技术逐一进行介绍。 一、DataGuard数据同步技术 DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。DataGuard 提供了三种日志传输（Redo Transport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（Maximum Performance Mode）、最大保护（Maximum Protection Mode）和最大可用（Maximum Availability Mode），其中最大保护模式 和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。 最大性能模式：这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的 数据保护等级。在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日 志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。 最大保护模式：在这种模式下，日志数据必须同时写到源数据库的联机日志文件和至少一个目标库 的备用日志文件（standby redo log），事务才能提交。这种模式可确保数据零丢失，但代价是源数据库的可用性，一旦日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库将会被关闭。这也是目前市场上唯一的一种可确保数据零丢失的数据同步解决方案。 最大可用模式：这种模式在不牺牲源数据库可用性的条件下提供了尽可能高的数据保护等级。与最 大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交，与最大保护模式不同的是，如果日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库不会被关闭，而是运行在最大性能模式下，待故障解决并将延迟的日志成功应用在目标库上以后，源数据库将会自动回到最大可用模式下。 根据在目标库上日志应用（Log Apply）方式的不同，DataGuard可分为Physical Standby（Redo Apply）和Logical Standby（SQL Apply）两种。 Physical Standby数据库，在这种方式下，目标库通过介质恢复的方式保持与源数据库同步，这种方 式支持任何类型的数据对象和数据类型，一些对数据库物理结构的操作如数据文件的添加，删除等也可支持。如果需要，Physical Standby数据库可以只读方式打开，用于报表查询、数据校验等操作，待这些操 作完成后再将数据库置于日志应用模式下。 Logical Standby数据库，在这种方式下，目标库处于打开状态，通过LogMiner挖掘从源数据库传 输过来的日志，构造成SQL语句，然后在目标库上执行这些SQL，使之与源数据库保持同步。由于数据 库处于打开状态，因此可以在SQL Apply更新数据库的同时将原来在源数据库上执行的一些查询、报表等操作放到目标库上来执行，以减轻源数据库的压力，提高其性能。 DataGuard数据同步技术有以下优势： 1）Oracle数据库自身内置的功能，与每个Oracle新版本的新特性（如ASM）都完全兼容，且不 需要另外付费； 2）配置管理较简单，不需要熟悉其他第三方的软件产品； 3）Physical Standby数据库支持任何类型的数据对象和数据类型；
SQL SERVER 的数据库复制数据库的复制是分布式数据库应用程序中常用的一种数据拷贝技术，它将一个数据库中的数据拷贝到通过局域网（LAN）、广域网（WAN）或Internet网络连接的不同站点或同一个服务器中的不同数据库中，并能够自动保持这些数据的同步，使各个拷贝具有相同的数据。 一、SQL SERVER复制技术 （一）、复制结构 SQL SERVR 数据复制基于“出版—订阅”模型，它由出版者、分发者和订阅者三种服务器构成。出版服务器标识其数据库中的哪些数据用于复制，并检测这些数据的变化和维护该站点中的所有出版信息。 分发服务器中建立一个或多个分发数据库，用来保存出版服务器的出版物，并向订阅者传递它们所订阅的复制数据。 订阅服务器用于存储复制数据和接收对复制数据的更改，SQL SERVE 7.0还允许修改订阅服务器所接收到的出版物。 出版服务器所出版数据的最小单位为条目，出版条目可以是数据库中的表或存储过程。SQL SERVER允许对所出版表添加纵向或横向过滤器，从而使出版条目中只包含表中的某些列或其中的某些数据行，一组出版条目的集合构成一个出版物。 订阅服务器对出版物的订阅方式有推式订阅和拉式订阅两种，SQL SERVER中的每个出版物均支持推式订阅和拉式订阅这两种订阅方式。所谓推式订阅是指当出版物内容被修改时，由出版服务器通知订阅服务器，而不需要订阅服务器进行查询。推式订阅的优点是订阅服务器能够及时了解出版数据的改变情况，但它相应加重了出版服务器的负载。所以，推式订阅适合于需要近乎实时要求的数据复制。 拉式订阅是指由订阅服务器定期轮询出版服务器中出版物的内容是否改变，之后决定是否需要再次进行复制。拉式订阅能够减轻出版服务器的负担，所以常用于拥有大量订阅者的数据复制领域。此外，拉订阅也适合于移动用户，因为移动用户与出版服务器间没有永久固定的通信连接，他们采用订阅方式，只是在需要时才查询出版物内容的变化情况。 （二）复制代理 SQL Server 复制部件采用模块化设计，各种复制操作通过不同的复制代理实现。SQL Server 中的复制代理包括： 快照代理：快照代理运行在SQL Server 代理服务环境下。其功能是：为复制准备表结构、初始化出版表和存储过程的数据文件、将出版物快照存储到分发服务器的分发数据库中、并记录分发数据库的同步状态信息。每个出版物在分发服务器上均运行着自己的快照代理，并通过快照代理与出版服务器连接。 日志阅读代理：将用于复制的事务从出版服务器的事务日志中拷贝到分发数据库。每一个使用事务复制出版的数据库在分发服务器上均运行着自己的日志阅读代理，并通过该代理与出版服务器连接： 分发代理：将保存在分发数据库中的事务或出版物快照传递到订阅者。分发代理运行在SQL Server 代理服务环境下，可以直接使用SQL 企业管理进行管理。对于快照复制和事务复制，如果在配置推订阅时采用立即同步（所谓同步是指维护出版服务器上
数据库同步更新 一、两类方法实现数据库实时更新 1、简单表更新可通过创建触发器实现时时更新，如果数据量大的话，不建议此类。x 2、数据量大的话，可通过数据库复制技术实现。 二，方法概述： 复制是将数据或数据库对象从一个数据库复制和分发到另外一个数据库，并进行数据同步，从而使源数据库和目标数据库保持一致。使用复制，可以在局域网和广域网、拨号连接、无线连接和 Internet 上将数据分发到不同位置以及分发给远程或移动用户。 一组SQL SERVER2005复制有发布服务器、分发服务器、订阅服务器（图1 复制服务器之间的关系图）组成，他们之间的关系类似于书报行业的报社或出版社、邮局或书店、读者之间的关系。以报纸发行为例说明，发布服务器类似于报社，报社提供报刊的内容并印刷，是数据源；分发服务器相当于邮局，他将各报社的报刊送（分发）到订户手中;订阅服务器相当于订户，从邮局那里收到报刊。在实际的复制中，发布服务器是一种数据库实例，它通过复制向其他位置提供数据，分发服务器也是一种数据库实例，它起着存储区的作用，用于复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库（称作分发数据库）相关联。分发数据库存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在很多情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。这称为“本地分发服务器”。订阅服务器是接收复制数据的数据库实例。一个订阅服务器可以从多个发布服务器和发布接收 数据。 (图1) 复制有三种类：事务复制、快照复制、合并复制。
事务复制是将复制启用后的所有发布服务器上发布的内容在修改时传给订阅服务器，数据更改将按照其在发布服务器上发生的顺序和事务边界，应用于订阅服务器，在发布内部可以保证事务的一致性。快照复制将数据以特定时刻的瞬时状态分发，而不监视对数据的更新。发生同步时，将生成完整的快照并将其发送到订阅服务器。合并复制通常是从发布数据库对象和数据的快照开始，并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。订阅服务器在连接到网络时将与发布服务器进行同步，并交换自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。 1、复制实例 这里以配置一个事务复制来说明复制配置过程。 试验在同一台机器的二个实例间进行，实例名分别是SERVER01、SERVER02 。将SERVER01配置发布服务器和分发服务器(也就是前面提到的“本地分发服务器”),SERVER02配置为 订阅服务器。在本例中将SERVER01中一个DBCoper库中person表作为发布的数据，在发布前请确保person表有主键、SQL SERVER 代理自动启动、发布数据库是日志是完整模式。第一步：完全备份SERVER01 DBCopy数据库，在SERVER02上恢复DBCopy数据库(复制前的同步，使用发布的源和目标数据一致) 第二步：在SERVER01上设置发布和分发A 在SERVER01的复制节点—>本地发布右键选择新建订阅(图2) ()(图2) B B 在新建发布向导中首先要求选择分发服务器，本例选择本机作为分发服务器，选择默认值。(图3)
一、概述 近几年来，容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来，对用户来说也有很广阔的选择余地。但由于容灾方案的技术复杂性和多样性，一般用户很难搞清其中的优劣以确定如何选择最适合自己状况的容灾解决方案。本文我们就容灾建设中的备份及复制技术做一个初步探讨，希望能对客户的数据中心容灾建设提供一些参考。 目前有很多种容灾技术，分类也比较复杂。但总体上可以区分为离线式容灾（冷容灾）和在线容灾（热容灾）两种类型。 二、离线式容灾 所谓的离线式容灾主要依靠备份技术来实现。其重要步骤是将数据通过备份系统备份到磁带上面，而后将磁带运送到异地保存管理。离线式容灾具有实时性低、可备份多个副本、备份范围广、长期保存、投资较少等特点，由于是备份一般是压缩后存放到磁带的方式所以数据恢复较慢，而且备份窗口内的数据都会丢失，因此一般用于数据恢复的RTO（目标恢复时间）和RPO（目标恢复点）要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。 目前主流的备份软件主要有： l Symantec Veritas NetBackup l EMC Legato NetWorker l IBM Tivoli Storage Manager l Quest BakBone NetVault 三、在线容灾 在线容灾要求生产中心和灾备中心同时工作，生产中心和灾备中心之间有传输链路连接。数据自生产中心实时复制传送到灾备中心。在此基础上，可以在应用层进行集群管理，当生产中心遭受灾难出现故障时可由灾备中心接管并继续提供服务。因此实现在线容灾的关键是数据的复制。 和数据备份相比，数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。根据数据复制的层次，数据复制技术的实现可以分为三种：存储系统层数据复制、操作系统数据复制和数据库数据复制。
数据库实时同步技术解决方案 一、前言 随着企业的不断发展，企业信息化的不断深入，企业内部存在着各种各样的异构软、硬件平台，形成了分布式异构数据源。当企业各应用系统间需要进行数据交流时，其效率及准确性、及时性必然受到影响。为了便于信息资源的统一管理及综合利用，保障各业务部门的业务需求及协调工作，常常涉及到相关数据库数据实时同步处理。基于数据库的各类应用系统层出不穷，可能涉及到包括ACCESS、SQLSERVER、ORACLE、DB2、MYSQL等数据库。目前国内外几家大型的数据库厂商提出的异构数据库复制方案主要有：Oracle的透明网关技术，IBM的CCD表（一致变化数据表）方案，微软公司的出版者/订阅等方案。但由于上述系统致力于解决异构数据库间复杂的交互操作，过于大而全而且费用较高，并不符合一些中小企业的实际需求。 本文结合企业的实际应用实践经验，根据不同的应用类型，给出了相应的数据库实时同步应用的具体解决方案，主要包括： (1) SQLSERVER 到SQLSERVER 同步方案 (2) ORACLE 到SQLSERVER 同步方案 (3) ACCESS 到SQLSERVER/ORACLE 同步方案
二、异构数据库 异构数据库系统是相关的多个数据库系统的集合，可以实现数据的共享和透明访问，每个数据库系统在加入异构数据库系统之前本身就已经存在，拥有自己的DMBS。异构数据库的各个组成部分具有自身的自治性，实现数据共享的同时，每个数据库系统仍保有自己的应用特性、完整性控制和安全性控制。异构数据库的异构性主要体现在以下几个方面： 1、计算机体系结构的异构 各数据库可以分别运行在大型机、小型机、工作站、PC嵌入式系统中。 2、基础操作系统的异构 各个数据库系统的基础操作系统可以是Unix、Windows NT、Linux等。 3、DMBS本身的异构 可以是同为关系型数据库系统的Oracle、SQL Server等，也可以是不同数据模型的数据库，如关系、模式、层次、网络、面向对象，函数型数据库共同组成一个异构数据库系统。 三、数据库同步技术
数据库容灾、复制解决方案全分析（绝对精品） 目前，针对oracle数据库的远程复制、容灾主要有以下几种技术或解决方案： （1）基于存储层的容灾复制方案 这种技术的复制机制是通过基于SAN的存储局域网进行复制，复制针对每个IO进行，复制的数据量比较大;系统可以实现数据的同步或异步两种方式的复制.对大数据量的系统来说有很大的优势（每天日志量在60G以上）,但是对主机、操作系统、数据库版本等要求一致，且对络环境的要求比较高。 目标系统不需要有主机，只要有存储设备就可以，如果需要目标系统可读，需要额外的配置和设备，比较麻烦。 （2）基于逻辑卷的容灾复制方案 这种技术的机制是通过基于TCP/IP的网络环境进行复制，由操作系统进程捕捉逻辑卷的变化进行复制。其特点与基于存储设备的复制方案比较类似，也可以选择同步或异步两种方式，对主机的软、硬件环境的一致性要求也比较高，对大数据量的应用比较有优势。其目标系统如果要实现可读，需要创建第三方镜像。个人认为这种技术和上面提到的基于存储的复制技术比较适合于超大数据量的系统，或者是应用系统的容灾复制。 我一直有一个困惑，存储级的复制，假如是同步的，能保证数据库所有文件一致吗？或者说是保证在异常发生的那一刻有足够的缓冲来保障？ 也就是说，复制的时候起文件写入顺序和oracle的顺序一致吗？如果不一致就可能有问题，那么是通过什么机制来实现的呢？ 上次一个存储厂商来讲产品，我问技术工程师这个问题，没有能给出答案 我对存储级的复制没有深入的研究过，主要是我自己的一些理解，你们帮我看一下吧…… 我觉得基于存储的复制应该是捕捉原系统存储上的每一个变化，而不是每隔一段时间去复制一下原系统存储上文件内容的改变结果，所以在任意时刻，如果原系统的文件是一致的，那么目标端也应该是一致的，如果原系统没有一致，那目标端也会一样的。形象一点说它的原理可能有点像raid 0，就是说它的写入顺序应该和原系统是一样的。不知道我的理解对不对。另外，在发生故障的那一刻，如果是类似断电的情况，那么肯定会有缓存中数据的损失，也不能100%保证数据文件的一致。一般来说是用这种方式做oracle的容灾备份，在发生灾难以后目标系统的数据库一般是只有2/3的机会是可以正常启动的（这是我接触过的很多这方面的技术人员的一种说法，我没有实际测试过）。我在一个移动运营商那里看到过实际的情况，他们的数据库没有归档，虽然使用了存储级的备份，但是白天却是不做同步的，只有在晚上再将存储同步，到第二天早上，再把存储的同步断掉，然后由另外一台主机来启动目标端存储上的数据库，而且基本上是有1/3的机会目标端数据库是起不来的，需要重新同步。 所以我觉得如果不是数据量大的惊人，其他方式没办法做到同步，或者要同时对数据库和应用进行容灾，存储级的方案是没有什么优势的，尤其是它对网络的环境要求是非常高的，在异地环境中几乎不可能实现。
TCMD -数据容灾解决方案 TrueCopy Modular Distributed (“TCMD”)是HUS专有软件扩大TC能力允许在HUS各存储之间远程copy模式：8:1 (fan-in) or 8:1 (fan-out). TCMD数据容灾解决方案是HDS公司在全面分析各种操作系统、各种容灾技术、仔细研究客户对容灾的需求和理念之后，结合HDS Freedom 智能存储系统的特点推出的数据远程容灾解决方案；彻底解决长期困绕用户的、难于进行容灾方案的真实演练、真实数据测试的问题，最大限度的减少数据丢失问题；TCMD是基于磁盘存储系统运行的软件包，不依赖任何的主机操作系统和其他第三方厂商软件，为用户提供了最安全、最开放、最经济、最实用的远程容灾解决方案。 HDS公司作为全球最大的独立的磁盘存储生产厂商，专注于单一化产品生产的优势，拥有熟悉IBM、HP、SUN、Compaq、SGI、Dell、Window NT/2000以及Linux等平台和远程灾备实施的经验丰富的服务工程师，向用户提供全方位的灾备方案设计、技术咨询和实施服务。 TCMD是对TrueCopy软件的一个扩展功能 目前，HDS的TrueCopy软件其独有的时间戳（Timestamp）和一致性组（Consistency Group）技术，是目前存储业界唯一可行且安全的存储系统之间的异步数据备份方案，保证异步处理方式下的数据一致性和完整性，最大程度的减少数据的丢失，并被广大用户采用。 1.主要功能 - TrueCopy Async异步数据拷贝软件，是HDS公司独有的创新技术，是世界第一也是唯一的在开放环境中基于存储硬件系统的、无需主机系统的、异步处理方式的、能够保证数据一致性的远程拷贝软件，它可以在重复发生的灾难中保护数据，在任何远的距离保持数据库记录被修改顺序的完整性； - TrueCopy可以在在任何距离下，提供完整的、可靠的异地或同城灾难数据恢复和应用系统快速重新启动的解决方案，先进的处理技术能够最大程度的减少灾难时的数据丢失，提升企业对事故和灾难的应变能力和快速反应能力； - 通过与HDS ShadowImage（本地数据镜像拷贝软件）配合，可以用PIT拷贝获得真实的生产环境数据，不必中止生产系统的运行，能够频繁的启动
随着全球IT产业的飞速发展，金融行业的IT建设逐步成为主导金融企业业务发展的核心驱动力，基于金融行业IT系统容灾建设的各种行业标准以及监管标准也相应提高。而决定容灾架构健壮与否的最关键因素就是数据复制技术，它是实现高标准RTO和RPO的前提条件。本文基于业界主流数据复制技术的原理、复杂度、关键因素以及复制效果等多个维度进行分析及论述，旨在为同业在此类项目规划和建设过程中提供一些启示和帮助。 1.背景及综述 在金融行业内，众所周知其对业务连续性的要求以及对各种IT风险的应对能力的要求都是非常高，尤其是对容灾能力的要求，这是由它的业务特殊性以及集中式架构所决定的。 在金融企业容灾架构中，所谓的数据复制技术主要是指能够将结构化数据进行复制，从而保证数据具备双副本或者多副本的技术。 目前业界发展来看，可以实现数据复制的技术多种多样，有基于数据库层面的数据复制技术，例如Oracle公司的Active Data Gurad、IBM公司的db2 HADR等；有基于系统层面的数据复制技术，例如赛门铁克的vxvm、传统的逻辑卷管理（LVM）、Oracle公司的自动存储管理（ASM）冗余技术、IBM公司的GPFS等；有基于存储虚拟化实现的数据复制技术，例如EMC公司Vplex Stretch Cluster、IBM公司SVC Split Cluster、NetAPP公司Metro Cluster等；也有基于存储底层实现的数据复制技术，例如IBM公司的DS8000 PPRC技术、EMC公司的SRDF技术、HP公司的CA技术等等。 每一种技术都有其实现的前提条件，也有各自的技术特点和实现的不同效果。本文将从复制技术的原理、特点、复杂程度以及复制效果等多方面展开分析及论述，并从多个维度进行对比分析，将业界主流数据复制技术的发展现状以及技术优劣给予一个清晰的展示，并就数据复制技术发展的未来以及趋势予以展望。 2.数据复制技术价值分析 2.1 数据复制在容灾中的必要性 一、RPO保障
数据库同步技术解决方案 ----数据库发布订阅SqlServer数据库同步是项目中常用到的环节，若一个项目中的数据同时存在于不同的数据库服务器中，而这些数据库需要被多个不同的网域调用时，配置SqlServer数据库同步是个比较好的解决方案。SqlServer数据库同步的配置比较烦锁，下面对其配置详细步骤进行介绍： 一、数据复制前提条件 1. 数据库故障还原模型必需为完全还原模型。 2. 所有被同步的数据表都必须要用主键。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。 4. SQLSERVER必需启动代理服务，且代理服务必需以本地计算机的帐号运行。 二、解决前提条件实施步骤 1. 将数据库故障还原模型调整为完全还原模型。具体步骤如下: 打开SQLSERVER企业管理器>选择对应的数据库>单击右键选择属性.>选择”选项”>恢复模式选‘完整’。 2. 所有被同步的数据表都必须要有主键。（主要指事务复制）如果没有主键的数据表，增加一个字段名称为id,类型为int 型，标识为自增1的字段。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。 在企业管理器里面注册的服务器，如果需要用作发布服务器、分发服务器和订阅服务器，都必需以服务器名称进行注册。不得使用IP地址以及别名进行注册，比如LOCAL, “.”以及LOCALHOST等。
4.如果非同一网段或者远程服务器，需要将其对应关系加到本地系统网络配置文件中。文件的具体位置在%systemroot%\system32\drivers\etc\hosts 配置方式: 用记事本打开hosts文件，在文件的最下方添加IP地址和主机名的对应关系。如图：
第13章数据库的导入导出与复制 本章内容 13.1 数据库的导入导出 13.2 数据库复制技术 13.1 数据库的导入导出 13.1.1 导入导出概述 13.1.2 导入数据 13.1.3 导出数据 13.1.1 导入导出概述 ?数据导入导出操作（为SQL的数据转换服务）主要解决异构数据源之间相互转换。 ?目的是提高数据库管理系统的适应性，是数据库管理系统的一个核心技术和组件。 数据导入导出实现不同格式的数据在应用程序之间交换 dBase Microsoft Access Microsoft Data Link Microsoft Excel Microsoft Visual FoxPro 其他ODBC数据源 其他OLE DB数据源 Paradox 文本文件 表13-1 数据导入导出方法和工具 13.1.2 导入数据 导入数据的操作步骤: 步骤1： ?在企业管理器中，从“工具”菜单中选择“向导…” ?在“向导”对话框中选择数据转换服务中的DTS导入向导 步骤2 ?打开“数据转换服务导入/导出向导”界面，单击“下一步”按钮 步骤3 ?选择导入数据源。选择文本文件为数据源，在“文件名”编辑框中输入C:\SUPPLIER.TXT 文本文件，将其导入Sales数据库的Supplier表 步骤4 ?单击“下一步”按钮，显示“选择文件格式”对话框 步骤5 ?单击“下一步”按钮，显示“指定列分隔符”对话框。“预览”列表框显示数据文件的数据。 步骤6 ?单击“下一步”按钮，显示“选择目的”对话框。 步骤7 ?单击“下一步”按钮，显示选择源表和视图对话框。选择导入数据的supplier表 步骤8 ?单击“下一步”按钮，显示“保存、调度和复制包”对话框。 步骤9 ?单击“下一步”按钮，在“正在完成DTS导入/导出向导”界面中单击“完成”按钮，运行数据导入工作。最后显示用户操作成功。 13.1.3 导出数据 导出数据的操作步骤:
SQL2000数据库数据同步复制技术详解 SqlServer数据库数据同步是项目中常用到的环节，若一个项目中的数据同时存在于不同的数据库服务器中，而这些数据库需要被多个不同的网域调用时，配置SqlServer数据库数据同步是个比较好的解决方案。SqlServer数据库数据同步的配置比较烦锁，下面对其配置详细步骤进行介绍： 一、数据复制前提条件 1. 数据库故障还原模型必需为完全还原模型。 2. 所有被同步的数据表都必须要用主键。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。 4. SQLSERVER必需启动代理服务，且代理服务必需以本地计算机的帐号运行。 二、解决前提条件实施步骤 1. 将数据库故障还原模型调整为完全还原模型。具体步骤如下: 打开SQLSERVER企业管理器à选择对应的数据库à单击右键选择属性à选择”选项”à 故障还原模型选择完全还原模型。 2. 所有被同步的数据表都必须要用主键。（主要指事务复制）如果没有主键的数据表，增加一个字段名称为id,类型为int 型，标识为自增1的字段。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。 在企业管理器里面注册的服务器，如果需要用作发布服务器、分发服务器和订阅服务器，都必需以服务器名称进行注册。不得使用IP地址以及别名进行注册，比如LOCAL, “.”以及LOCALHOST等。 如果非同一网段或者远程服务器，需要将其对应关系加到本地系统网络配置文件中。文件的具体位置 在%systemroot%\system32\drivers\etc\hosts 配置方式: 用记事本打开hosts文件，在文件的最下方添加IP地址和主机名的对应关系。如图:
数据同步传输方法，涉及数据传输技术，用于发送数据的第一智能设备所传送出的数据中，还包括该数据(虚拟物品)的当前执行信息，在完成数据传输后，用于接收数据的第二智能设备执行该数据到发送时的状态。如果传输的是第一智能设备上已经打开的图片文件，则在传输部分完成或完全完成后在第二智能设备上也打开该图片文件；如果传输的是第一智能设备已经打开的音频文件，则在传输部分完成或完全完成后在第二智能设备上也打开该音频文件。如果传输的是打开的视频文件、文档文件等类型的文件，也可以同上。 权利要求书 1.数据同步传输方法，其特征在于，用于发送数据的第一智能设备所传送出的数据中，还包括虚拟物品的当前执行信息，在完成数据传输后，用于接收数据的第二智能设备执行该数据到发送时的状态； 如果传输的是第一智能设备上已经打开的图片文件，则在传输部分完成或完全完成后在第二智能设备上也打开该图片文件；如果传输的是第一智能设备已经打开的音频文件，则在传输部分完成或完全完成后在第二智能设备上也打开该音频文件；如果传输的是打开的视频文件，则在传输部分完成或完全完成后在第二智能设备上也打开该视频文件；如果传输的是打开的文档文件类型的文件，则在传输部分完成或完全完成后在第二智能设备上也打开该文档文件类型的文件；当传输文件是播放中的音频文件或者影音文件时，在传输过程中在第二智能设备上进行同步播放；
优先传输正在播放的文件数据，以及将要播放的数据； 第一智能设备包括一微型处理器系统、一显示屏，所述微型处理器系统连接一设置在所述显示屏上的触摸屏，所述微型处理器系统用于处理所述触摸屏上的触摸动作信息，并将触摸动作信息与所述显示屏上的显示内容相关联； 所述触摸屏上具有至少两个触摸点的触摸点组，所述触摸点组中的至少两个触摸点分别压住所述虚拟物品时视为所述虚拟物品被拿住； 在所述虚拟物品被拿住时，所述虚拟物品跟随所述触摸点组的挪动而挪动； 所述触摸点组在所述第一智能设备上拿住一虚拟物品，然后将所述触摸点组移除，视为所述虚拟物品在第一智能设备上被拿起； 在第二智能设备的触摸屏上呈现一触摸点组，并且所述触摸点组中的至少两个触摸点距离变大，视为所述虚拟物品被放下在所述两个触摸点之间的位置； 所述第一智能设备通过数据通信将与所述虚拟物品关联的数据信息传送给第二智能设备； 在具有除第一智能设备之外的其他两个以上的智能设备时，允许将同一虚拟物品从第一智能设备拿到一个以上的智能设备上。 2.根据权利要求1所述的数据同步传输方法，其特征在于：智能工具包括电脑、手机、游戏机、电子书、MP4、电子相册中的至少一种。 3.根据权利要求1所述的数据同步传输方法，其特征在于：在虚拟物品被拿取时，其相关联的数据信息被一同移动。 4.根据权利要求1所述的数据同步传输方法，其特征在于：通信过程中，第二智能设备首先发出数据接收请求，第一智能设备接收到数据接收请求后发送数据；
浅谈四种容灾复制技术 数据复制是构建容灾的基石，利用复制软件实时地将数据从一个主机（或磁盘）复制到另一个主机（磁盘），生成一个数据副本。 数据复制有多种分类方法，依据复制启动点的不同，可分为同步复制、异步复制。同步复制，数据复制是在向主机返回写请求确认信号之前实时进行的；对于异步复制，数据复制是在向主机返回写请求确认信号之后实时进行的。 一、四种容灾复制技术说明 根据操作系统的I/O（读写操作）路径以及复制对象划分为四大种类：基于应用层事务复制、基于文件层复制、基于逻辑卷层复制、基于磁盘阵列复制。当然，目前出现了基于SAN交换机的复制，但是相对技术不太成熟，应用很少。 按照数据复制软件或硬件安装的位置又可划分为主机型复制和非主机型复制。应用层、文件层、逻辑卷层的都属于主机型复制，主机型复制软件需安装在主机上，需要消耗一定的主机资源。存储层属于非主机型复制，复制直接由磁盘阵列的内部组件完成，理论上无需消耗应用所在主机的资源。 一般而言，容灾要保护的数据是结构化数据，即存储在数据库的数据。以下都用复制数据库来说明。 1．基于应用层事务复制 基于应用层事务的复制，一般采用采用异步复制机制，复制对象为应用事务，其过程为：捕获应用系统的事务，例如SQLServer或Oracle数据库的事务，经由传输组件传输到目标服务器，然后目标装载进程按照数据库的关系原理排序事务，将事务保存到目标数据库。 这层的复制完全能保障数据库的一致性，且目标数据库处于在线运行状态。当生产数据库发生故障时，直接使用目标数据库即可恢复业务，容灾的RTO指标趋于零。但是支持的应用有限，一般为SQLServer、Oracle、Sybase、DB2、MySQL等等数据库。另外复制速度较慢，因为数据要通过数据库的装载接口才能写入数据库。 应用层代表厂商：浪擎、DSG、Goldengate、Quest、Oracle、微软等。 2．基于磁盘阵列复制 基于磁盘阵列层的复制，磁盘阵列厂商的复制技术，其原理与逻辑卷层的相似，属于非主机型的复制。但与硬件绑定，成本高昂，实施复杂。 基于磁盘阵列层的复制不能完全保障数据库一致性，目标数据库处于脱机状态。当生产数据库发生故障时，需要启动数据库才能恢复业务，正是由于不能保障数据库一致性，很可能数据库不能正常启动。尽管存在这样的缺陷，但这一层的复制对主机的影响极其轻微，所以还是可应用在一些非常大型、繁忙的数据库容灾，作为一种补充保护手段。 磁盘阵列层代表厂商：IBM、HP、EMC、HDS等。 3．基于逻辑卷层复制 基于逻辑卷层的复制，一般采用采用同步复制机制，复制对象为逻辑卷层的变化Block，其过程为：捕获
MacroSAN 数据复制技术白皮书 杭州宏杉科技股份有限公司
1. 概述 企业级存储架构能够提供24小时×7天全年无休的数据可用性。除了按照计划的停机维护和升级，是不允许出现服务中断的。然而，有时因为文件系统/数据的误操作，或者更简单的像电缆意外断开，数据损失仍可能发生，迅速恢复关键数据是相当重要的。 对于企业赖以运行的数据来说，灾难涵盖了所有可能导致数据遭到破坏的计划外事件都属于灾难的范畴，其中包括自然灾害（地震、台风、火灾、水灾等），企业运行所依赖的服务的中断（电力中断、租用网络中断等），IT系统故障（IT设备硬件、软件故障），人员错误操作，恶意攻击（黑客、病毒），以及恐怖袭击等。 大部分企业用户早已充分认识到了数据的重要性，并都采取了必要的保护措施，这些措施在一定程度上提高了数据的安全性和可用性，但它们都还存在比较大的缺陷。常见的数据保护方式有本地备份和本地RAID保护两种。对于备份，受备份时间间隔的影响，一般会有较大的数据丢失量，而且数据恢复时间相对较长。对于本地RAID保护，它无法抵御火灾、停电、关键设备故障这类发生概率相对较高的灾难。 数据的丢失会导致企业正常的业务运作中断，带来巨大的经济损失、声誉损失、以及客户忠诚度下降等各种损失。而事实上，这样的事故是屡有发生，其后果也是非常惨痛的。IDC统计数字表明，美国在911发生灾难受影响的公司中，有55％当时倒闭。剩下的45％中，因为数据丢失，有29％也在两年之内倒闭，生存下来的仅占16％。如何保证大集中数据在各种灾难面前的安全性，以支撑业务的连续性运行就成为了一个现实的问题。 2. 技术介绍 采用MacroSAN基于存储的复制技术能够实现本地或远程数据保护，并在发生意外灾难时通过副本资源对数据进行快速恢复，确保用户业务的连续性。其中策略性复制可以保证数据一致性，使RTO很小，自适应复制可以使RPO很短。 存储系统提供的数据复制是一个基于复制策略的服务，将数据从生产存储按一定的复制策略复制到备份存储中，是将源盘拷贝到远程的一个过程，按照事先设定的策略，对源盘做一次
Oracl e DataGuard数据同步技术及配置详解 一、DataGuard数据同步技术 DataGuard是Oracle数据库自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用（Apply）这些日志文件，从而使目标数据库与源数据库保持同步。DataGuard提供了三种日志传输（Redo Transport）方式，分别是ARCH传输、LGWR同步传输和LGWR异步传输。在上述三种日志传输方式的基础上，提供了三种数据保护模式，即最大性能（Maximum Performance Mode）、最大保护（Maximum Protection Mode）和最大可用（Maximum Availability Mode），其中最大保护模式和最大可用模式要求日志传输必须用LGWR同步传输方式，最大性能模式下可用任何一种日志传输方式。 最大性能模式：这种模式是默认的数据保护模式，在不影响源数据库性能的条件下提供尽可能高的数据保护等级。在该种模式下，一旦日志数据写到源数据库的联机日志文件，事务即可提交，不必等待日志写到目标数据库，如果网络带宽充足，该种模式可提供类似于最大可用模式的数据保护等级。 最大保护模式：在这种模式下，日志数据必须同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交。这种模式可确保数据零丢失，但代价是源数据库的可用性，一旦日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库将会被关闭。这也是目前市场上唯一的一种可确保数据零丢失的数据同步解决方案。 最大可用模式：这种模式在不牺牲源数据库可用性的条件下提供了尽可能高的数据保护等级。与最大保护模式一样，日志数据需同时写到源数据库的联机日志文件和至少一个目标库的备用日志文件（standby redo log），事务才能提交，与最大保护模式不同的是，如果日志数据不能写到至少一个目标库的备用日志文件（standby redo log），源数据库不会被关闭，而是运行在最大性能模式下，待故障解决并将延迟的日志成功应用在目标库上以后，源数据库将会自动回到最大可用模式下。 根据在目标库上日志应用（Log Apply）方式的不同，DataGuard可分为Physical Standby（Redo Apply）和Logical Standby（SQL Apply）两种。 Physical Standby数据库，在这种方式下，目标库通过介质恢复的方式保持与源数据库同步，这种方式支持任何类型的数据对象和数据类型，一些对数据库物理结构的操作如数据文件的添加，删除等也可支持。如果需要，Physical Standby 数据库可以只读方式打开，用于报表查询、数据校验等操作，待这些操作完成后再将数据库置于日志应用模式下。 Logical Standby数据库，在这种方式下，目标库处于打开状态，通过LogMiner 挖掘从源数据库传输过来的日志，构造成SQL语句，然后在目标库上执行这些
数据实时同步或抽取上收的技术分析(社保、电力营销、财政、税务征管、公安警务等地市数据省级大集中应用/异地灾备) 收藏 1 实现数据集中的技术手段分析比较 根据业界提供数据同步或抽取的解决方案来看，主要包括以下几大类： l 存储复制技术 l 数据库复制技术 l ETL抽取技术 1.1 存储复制技术 实现原理 存储复制技术主要由磁盘阵列复制技术、主机卷复制技术以及一些文件复制技术。 存储复制方案的技术核心是利用存储阵列自身的盘阵对盘阵的数据块复制技术实现对生产数据的远程拷贝，从而实现生产数据的灾难保护。在主数据中心发生灾难时，可以利用灾备中心的数据在灾备中心建立运营支撑环境，为业务继续运营提供IT支持。同时，也可以利用灾备中心的数据恢复主数据中心的业务系统，从而能够让企业的业务运营快速回复到灾难发生前的正常运营状态。 基于存储的复制方案有两种方式：同步方式和异步方式，说明如下：同步方式，可以做到主/备中心磁盘阵列同步地进行数据更新，应用系统的I/O写入主磁盘阵列后(写入Cache中)，主磁盘阵列将利用自身的机制（如EMC的SRDF/S）同时将写I/O写入后备磁盘阵列，后备磁盘阵列确认后，主中心磁盘阵列才返回应用的写操作完成信息。异步方式，是在应用系统的I/O写入主磁盘阵列后(写入Cache中)，主磁盘阵列立即返回给主机应用系统“写完成”信息，主机应用可以继续进行读、写I/O操作。同时，主中心磁盘阵列将利用自身的机制（如EMC的SRDF/A）将写I/O写入后备磁盘阵列，实现数据保护。采用同步方式，使得后备磁盘阵列中的数据总是与生产系统数据同步，因此当生产数据中心发生灾难事件时，不会造成数据丢失。为避免对生产系统性能的影响，同步方式通常在近距离范围内（FC连接通常是200KM范围内，实际用户部署多在35KM左右）。而采用异步方式应用程序不必等待远程更新的完成，因此远程数据备份的性能的影响通常较小，所以一般可以到100KM左右。 采用基于存储数据复制技术建设复制方案的必要前提是： l 通常必须采用同一厂家的存储平台，通常也必须是同一系列的存储产品，给用户的存储平台选择带来一定的限制。 l 复制中心的主机平台也需要和生产中心为相同类型。 l 采用同步方式可能对生产系统性能产生影响，而且对通信链路要求较