CREATE TABLE DEPARTMENT (
DEPTNO …, <--
DEPTNAME …, <--
MGRNO …,
ADMRDEPT …,
LOCATION …) 源表CREATE TABLE CD20030805296530(
IBMSNAP_UOWID …,
IBMSNAP_INTENTSEQ…,
IBMSNAP_OperaTION …,
DEPTNO…, <--
DEPTNAME …) <-- CD表 DB2日志类型： 循环日志 归档日志： DB2数据复制的组件 DB2 DataPRopagator由三部分组成：治理界面、更改捕捉机制、应用程序 注重：此处应用程序（Apply program）与我们通常所说的应用程序是不同的概念，本文中如无非凡说明，“应用程序”都是指DB2数据复制的组件。 治理界面 我们主要用它来创建用于存储复制标准的控制表。控制表有多种类型，用来存放要复制哪些表哪些列等信息，我们在后面再仔细探讨。我们可以使用的治理界面有两种： 1.DB2 Control Center（DB2 控制中心） 只能针对DB2服务器之间的数据复制 12345678910下一页 2.DataJoiner Replication Administration (DJRA) 可包含非IBM数据库的数据复制（本文不具体讨论） 具体控制表类型可通过查看文件“SQLLIBsamplesepldpcntl.udb”来获得，本文涉及到的控制表主要有：ASN.IBMSNAP_REGISTER、ASN.IBMSNAP_UOW等。 更改捕捉机制 在建立复制环境之后，利用该机制去捕捉源数据库发生的更改，且将更改临时存放于CD表中。 DB2数据复制解决方案提供两种捕捉数据的机制： 1.捕捉DB2源表的捕捉程序 当源是DB2表时，捕捉程序会捕捉在源上所发生的更改。捕捉程序使用数据库日志去捕捉发生于源数据库上的更改，并将更改临时存储在表里。捕捉程序运行在源服务器上。 2.捕捉非IBM数据库源表的捕捉触发器（本文不具体讨论） 应用程序 当捕捉程序将源表发生的更改临时存放于CD表中后，应用程序再从这些表中读出源数据库的更改，将它应用于目标数据库，或者直接将数据从源数据库拷贝到目标数据库。 1.当刚搭建起复制环境时，有一个初始化过程，该过程应用程序将直接从源表或视图读数据来初始目标表。而后假如你想复制更改，应用程序从CD表中读取临时存储的变化数据，将它应用于目标表。 2.应用程序通常运行在目标服务器上，但它也可以运行在可以连接到源、控制和目标服务器的网络上的任一服务器上。多个应用程序实例可以运行在相同或不同的服务器上。 3.每一个应用程序与一个包含着控制表的控制服务器相关联，控制表中包含着预订集的定义。控制表可以被多个应用程序实例使用。比如：你有一个源服务器和两个目标服务器，那么，你就可以将应用程序分别运行于每一台目标服务器上。这两个应用实例可以共享控制表，控制表中有特定的信息与每一应用实例相关联。 上一页1234567下一页 各复制组件之间如何通讯 各复制组件之间是相互独立的，所以他们依靠于控制表中的信息进行通信。捕捉、应用程序通过更新控制表以指示复制的进程及协调变化进程。 对于DB2之间的复制，捕捉程序通过读取源服务器上的日志来捕捉源表中数据的更改。然后捕捉程序将更改的数据放入称之为更改数据（CD）表的表中。 每次应用程序拷贝数据到目标数据库，目标数据库的内容将反映出在源数据库上发生的更改。应用程序是通过应用自应用程序所知道的对于目标的上一次更新以来累加的事务来实现的，即只应用还没应用的更改。 基于日志的通讯 捕捉程序使用部分控制表去记录发生在源数据库上的更改，而应用程序使用这些控制表中的值去检测什么需要拷贝到目标库中。 重要：假如应用程序没有通知捕捉程序，捕捉程序不会捕捉任何更改信息。同样，除非你定义一个复制源并将它和预订集相关联，否则应用程序不会通知捕捉程序开始捕捉更改。 下面讲解在典型的复制环境下，应用程序和捕捉程序如何通讯以保证数据的一致性： 从源数据库捕捉数据 1.捕捉程序通过读控制表ASN.IBMSNAP_REGISTER来判定哪些复制源需要开始捕捉更改。假如在捕捉程序运行期间，用户定义了新的复制源，那么你必须重新初始化或重启捕捉程序，它才会开始生效。 2.捕捉程序通过监控DB2的日志去检测那些定义为复制源的源表所更改的记录。 3.每一复制源都有一张CD表。当捕捉程序在DB2日志中发现有一行数据发生更改时，它会在CD表中加入一行相应的数据，以记录发生的更改（假如updates被定义为DELETE和INSERT时，则加入两行）。 4.捕捉程序将提交的事务信息存储在控制表ASN.IBMSNAP_UOW中。该控制表中的行标志着在源服务器上发生的已提交的事务。对于基于日志的捕捉程序，每一个DB2源服务器都存在一张控制表ASN.IBMSNAP_UOW。 上一页12345678下一页 5.捕捉程序会更新控制表ASN.IBMSNAP_REGISTER来记录每一个复制源有多少已提交的数据被捕捉。 将数据应用于目标数据库 6.对于所有的预订集，应用程序首先通过将源表的所有数据拷贝到目标表中，以达到与复制源的同步。这个步骤称之为全更新拷贝。在进行全更新拷贝之后，捕捉程序开始捕捉数据源发生的更改。 7.假如任何预订集预备复制，应用程序通过检查控制表ASN.IBMSNAP_REGISTER来判定是否有发生变化以需要复制。 8.应用程序通过更新修剪控制表来同步存储在CD表中相关源表的更改 9.应用程序从CD表和控制表ASN.IBMSNAP_UOW的连接中拷贝变化的数据到目标表中。通过连接这两个控制表，应用程序确保只拷贝在数据源上已提交的变化。 修剪表 10.应用程序用一个指向拷贝变化到目标数据库的值来更新修剪控制表ASN.IBMSNAP_PRUNCNTL。 11.当应用程序修剪CD表和UOW控制表时，它先确定哪些更改已经应用，然后将其从那两个控制表中删除。 DB2数据复制概念 这部分介绍一些DB2数据复制的重要概念。你应该阅读整个部分以获得一个整体的概念。 复制源 一个复制源其实就是一张你想从中拷贝数据的用户表或视图。在你可以复制数据之前，你必须先定义一个复制源用来描述更改捕捉机制所使用的信息。当你定义一个复制源时，你必须指定你想复制的列，还有决定你想把更新当做UPDATE操作处理还是DELETE和INSERT操作。另外，你必须决定： －是否想对一列捕捉前映象 －你是否想使用更改捕捉（差别更新拷贝）还是不使用更改捕捉（全更新拷贝） －对于任何地方的更新复制（复制源有读/写目标表）想使用什么级别的冲突检测 后映象列和前映象列 上一页123456789下一页 一列后映象列包含源表中一列数据列被更新后的那列数据。一列前映象列包含源表中一列数据列被更新前的那列数据。当你定义一个复制源的时候，你可以选择只捕捉后映象（默认）或者后映象和前映象一起捕捉。这取决于你打算使用这些数据的方法和你正在使用的表的类型。例如：表DEPARTMENT中有一列DEPTNO，若在定义复制源时指定该列捕捉后映象和前映象，该列有一行数据为’A00’，若使用UPDATE语句将’A00’更新为’A01’，则在其相应的CD表中同时记录了更新前后的值： 红色部分为用户指定的，要捕捉更改的列（后映象列），蓝色部分为前映象列，存放对应列被更新前的值。CREATE TABLE DEPARTMENT (
DEPTNO …, ‘A00’
DEPTNAME …,
MGRNO …,
ADMRDEPT …,
LOCATION …) 源表CREATE TABLE CD20030805296530(
IBMSNAP_UOWID …,
IBMSNAP_INTENTSEQ…,
IBMSNAP_OPERATION …,
XDEPTNO…, ‘A00’
DEPTNO…, ‘A01’
XDEPTNAME …,
DEPTNAME …) CD表 在需要审计或回滚能力的应用系统中，前映象列是非常有用的。 全更新和差别更新拷贝 应用程序通过全更新或差别更新拷贝从源表拷贝数据到目标表中。 －在只进行全更新拷贝时，应用程序执行一下任务： 1.删除目标表中的所有行 2.从源表中读取所有行 3.拷贝这些行到目标表中 －在进行差别更新拷贝时，应用程序只拷贝更改的数据到目标表中。 上一页12345678910下一页 冲突检测级别 冲突检测仅适用于“任何地方的更新(update-anywhere)”复制配置。它是在同一个复制周期，源和目标表中的同一行被更新的检测程序。对于标准冲突检测，应用程序在那些已经捕捉到CD表中的行中查找冲突。对于增强的冲突检测，应用程序锁住所有目标表，因此确保了在检查冲突时所有更改都被考虑到。 预订集和预订集成员 在开始从复制源复制数据前，你必须先将复制源和复制目标相关联起来，复制源所发生变化将被复制到复制目标中。我们使用预订集和预订集成员来定义这种信息。我们定义的这些信息将存储在各种复制控制表中。 一个预订集包含一个复制预订的属性。当你创建一个预订集时，要定义下面的属性： －预订名 －源服务器和目标服务器 －应用限定符 －什么时候开始复制，复制频率，是否使用基于时间或基于事件或者基于两者的复制频率 －假如你有大量的更改，是否将数据分块提交 预订集中对每一张目标表或视图，必须有一个预订集成员。当你创建一个预订集成员，要定义以下属性： －源表或视图、目标表或视图 －目标表或视图的结构 －要复制的列（子查询列） －要复制的行（用SQL谓词WHERE限定过滤条件） 预订集确保所有预订集成员在复制期间是相同的：更改要么被应用于所有的目标，要么不被应用于所有的目标。在一个预订集中的所有预订成员的更改数据通过单一的一个事务复制到指定的目标表中。因为在一个预订集中的目标表是在一个事务中处理的，预订集使性能最优化。预订集也保持着参照一致性。 一个预订集被一个应用程序使用，然而，每个应用程序可以通过相同的应用限定符处理多个预订集。 上一页234567891011下一页 应用限定符 应用限定符将一个应用程序和一个或多个预订集关联起来。当你定义一个预订集时，指定一个名称（区分大小写）作为应用限定符。 通过使用多个应用限定符，你可以只使用一个用户ID运行多个应用程序实例。例如：假设你想从两个源数据库复制数据到你计算机上的目标表。源表A中的数据使用“全更新拷贝”复制到目标表A，源表B中的数据使用“差别更新拷贝”复制到目标表B中。你定义了两个预订集（一个对应表A，一个对应表B），而且你使用各自的应用限定符以答应应用程序的两个实例在不同的时间拷贝数据。你也可以将两个预订集用同一个应用限定符定义，用同一个应用程序实例拷贝数据。 数据操作 也许你想只复制源表中的子集，可以使用简单的视图来重构从源表到目标表的数据，或者使用复杂的连接或联合。 源表的子集 你可以复制源表中的某些列或某些行，而不是复制整个表。 对于目标的连接和联合 你可以创建和维护包含由多张已存在的源表连接或联合成的内容的目标表。 你可以使用下面的连接类型： －跨越一个或多个定义的复制源的简单内部连接，可能和其它的复制源的其它表或视图组合。 你可以通过下面的方法采用连接和联合来操作数据： －从单一的DB2源服务器上连接表（通过定义一张由某些表连接成的DB2视图） －从一个源服务器上联合的表（通过在一个预订集中使用包含相同目标表的多个预订集成员） －从多个源服务器的联合，有时称之为多点联合（通过创建在多个预订集中的多个预订集成员）目标表 当你定义一个预订集成员时，你必须指定你所使用目标表的类型。有下面几种表类型可以用： 上一页3456789101112下一页 －用户拷贝表 －时间点表 －聚集表 －CCD表 －副本或行副本表 －用户表 下面介绍一下这些目标表类型的特点： 用户拷贝表 这些表是复制源的只读拷贝，不带有附加的复制控制列，就像普通的源表。它们是目标表最普通的类型。 时间点表 这些表是复制源的只读拷贝，附带有一时间戳列。时间戳列初始为空。当复制更改时，该列被赋予相应值以指示更新的时间。当你想跟踪更改的时间时，可以使用这种类型的表。 聚集表 这些是只读的表，使用SQL列函数（如SUM、AVG）来计算源表全部或最近发生更改的数据的摘要。行会随时间追加到聚集表。 基础聚集表汇总一张源表的内容。用基础聚集表来定期地跟踪源表状态。例如，假设你想知道你每个月的顾客平均数。假如你的源表中一个顾客对应一行，你每月将你源表中的行数取平均，而后将平均值存储到一张基础聚集表中。 基础聚集表没有跟踪更改信息。例如，假设你一月份平均有500个顾客，二月份也有500个顾客。然而，在二月份，你失去两个现有的客户，同时新增两个新客户。基础数据表显示这两个月平均顾客数是一样的，但它没有反映出二月份的变化。假如你想跟踪变化信息，可以使用更改聚集表。 更改聚集表使用控制表中的更改数据，而不使用源表中的内容。使用更改聚集表来跟踪随时间发生的更改（UPDATE、INSERT、DELETE操作）。例如，假设你想知道每个月你增加多少新客户（INSERTS）失去多少现有客户（DELETES）。你将按月统计你源表中行所发生的更改，将统计结果存储在更改聚集表中。 CCD表 涉及非IBM数据库，本文不予讨论。 副本或行副本表 这些是唯一能被直接被我们的应用程序（此处的应用程序指用户的应用系统）更新的目标表。发生于副本或行副本的更改会被复制到相关的源表中；源表再依次复制更改至其它副本。使用副本表类型适用于任何地方的更新的复制。 上一页456789101112下一页 用户表你不用直接指定一张用户表作为目标表；然而，对于任何地方的更新的复制，一张用户表将自动做为与其相关的副本或行副本的目标。用户表是副本的父母，而且它的拷贝依靠于副本。副本的父母从依靠副本那里接受更新，假如没有冲突检测，它将复制更改到其它依靠副本。副本的父母是主要数据源。假如任何更新冲突被检测到，副本的父母的内容成功。典型情况下，你的应用程序访问依靠的副本表；然而，当副本不可用时，它们将连接至包含用户表的服务器上。 应用更新的调度 同步复制将连续的递送更新。当源数据发生改变，它将临时存储起来，继而转送到目标。只有更改已经复制到目标数据库，源数据库才进行提交。这种类型的复制也称之为实时复制。 异步复制将分阶段递送更新。当源数据发生改变，它将在事先设定的时间间隔内临时存储起来，而后再继续转送到目标。时间间隔可以用时间（秒、分、时）度量或用指定的事件（午夜，或一天中的其它时间）来度量。假如更改没能被应用于目标数据库（例如，目标数据库或者网络停机），它们将被存储起来稍后再被应用，应用的顺序将按照在源数据库上的发生顺序。这种复制类型提供了比同步复制更多的好处：更好的利用网络资源，更少的数据库连接，在数据到达目标数据库之前有机会提高数据。 例子 以下操作或命令主要在DB2的控制中心或命令控制台中进行（红色部分根据具体情况调整），相关命令更具体的使用参见DB2帮助文档。 建立复制环境 先创建文件夹C:示例以存放一些脚本文件 1.创建源数据库DB2 CREATE DB DB_S 2.将数据库日志改为归档日志CaptureDB2 UPDATE DB CFG FOR DB_S USING LOGRETAIN Capture 上一页56789101112下一页 3.根据需要调整日志大小（假如需要的话） 4.备份数据库（改为归档日志的数据库必须先备份才能对其进行操作）DB2 BACKUP DB DB_S 5.创建源表DB2 CONNECT TO DB_S USER UserName USING PassWord
DB2 CREATE TABLE TAB_1_S (COL_1 VARCHAR(20) NOT NULL, COL_2 VARCHAR(20), PRIMARY KEY(COL_1)) 6.定义复制源 在控制中心左边树型列表中数据库DB_S下选中表，右边列表列出了所有的表，用右键点击表TAB_1_S，在弹出的菜单中选中定义为复制源—>定制，接受默认选项，点击确定，弹出现在运行还是保存窗口，接受默认的保存设置，点击确定，弹出选择系统名窗口，选择数据库所在系统，点击确定，弹出文件浏览器，把当前目录定位到C:示例，在路径中输入文件名tab_1_replscr.sql，点击确定。保存成功后可以用文本编辑器查看tab_1_replscr.sql中的内容，可以发现里边主要是生成CD表，和注册复制源（通过往表ASN.IBMSNAP_REGISTER中插入记录）的SQL语句。 7.运行复制源 用右键点击控制中心左边树型列表中数据库DB_S下的复制源，在弹出菜单中选择运行SQL文件…，弹出选择系统名窗口，选择数据库所在系统名，确定，在弹出的文件浏览器中选择tab_1_replscr.sql后确定，假如成功，用右键进行刷新，将显示出新定义的复制源TAB_1_S。 8.将捕捉程序与源数据库绑定（注重：必须转跳到DB2的SQLLIBnd目录下）CD C:Program FilesSQLLIBnd
DB2 CONNECT TO DB_S USER UserName USING Password
DB2 BIND @CAPTURE.LST ISOLATION UR BLOCKING ALL
DB2 BIND @APPLYUR.LST ISOLATION UR BLOCKING ALL
DB2 BIND @APPLYCS.LST ISOLATION CS BLOCKING ALL 上一页6789101112下一页 新闻热点
疑难解答
