复制监视器数据库教程

复制监视器数据库教程（精选9篇）

篇1：复制监视器数据库教程

在SQL Server 中，复制是功能最为强大而又最为复杂的组件，所以在具体的应用中复制出现错误是难以避免的事情，但同时令人欣慰的是，SQL Server 提供了复制管理工具――复制监视器来帮助DBA 查出复制错误发生的原因。利用复制监视器可以：

浏览所有的出版者出版物以及由该分发者所支持的订购;

浏览复制代理的状态信息和历史;

监视与复制事务有关的复制警报。

同时利用复制监视器可约嗍涌煺沾理、日志阅读代理、分发代理、合并代理?br> 注意：只有在服务器扮演分发者角色，且当前用户具有sysadmin角色时，复制临视器才能激活。

如果准备监视快照代理的活动状况，请执行以下步骤;

(1) 启动SQL Server Enterprise Manager， 登录到指定的服务器，顺次打开 Replication Monitor， Agents 文件夹，

(2) 选中Snapshot Agents， 此时在右面窗格中显示已创建的快照代理。

(3) 右击准备查看的代理，在弹出菜单中选择Agent History 选项，打开Snapshot Agent History 对话框，如图16-57 所示;

(4) 单击Session Details 按钮，打开Session Details of Snapshot Agents 对话框，如图16-58 所示。在该对话框中能了解到目前为止快照代理都执行了哪些处理、运行的起始时间等信息。

本章小结

本章主要讲述了SQL Server 最为重要的内置组件--复制内容涉及到复制的基本概念、术语、复制的拓扑结构，而且详细介绍了快照复制、事务复制、合并复制的工作原理和适合的场合。还介绍了如何配置复制，创建出版物。最后让读者了解复制监视器在定位复制错误、查看复制信息中所显示出的令人兴奋的功能。

篇2：复制监视器数据库教程

也许读者对下面的实际例子并不陌生，在某一大型企业的分销系统中，销售经理或一些销售骨干人员经常要外出处理业务，将签订的合同通过手边的笔记本电脑传递到总部销售信息数据库，在这一例子中有两个主要的特;征任何销售经理和销售骨干都可以修改销售信息数据库;只有在进行数据传递时才将源数据库与目标数据库相连。在SQL Server 中，合并复制为这一情况提供了较好的解决方案。

合并复制作为一种从出版者向订购者分发数据方法允许出版者和订购者对出版数据进行修改，而不管订购者与出版者是相互连接或断开，然后当所有(或部分)节点相连时便合并发生在各个节点的变化。在合并复制中，每个节点都独立完成属于自己的任务，不像事务复制和快照复制那样订购者与出版者之间要相互连接，完全不必连接到其它节点，也不必使用MS DTC 来实现两阶段提交就可以在多个节点对出版进行修改，只是在某一时刻才将该节点与其它节点相连(此时所指的其它节点并不一定指所有其它节点)，然后将所发生的数据变化复制到这些相连节点的数据库中。如果在复制时因更新同一数据而发生冲突，则数据的最终结果并不总是出版者修改后的结果，也不一定包含在某一节点上所做的所有修改。因为各节点都有自主权，都可以对出版物(复制数据)进行修改，这样在按照所设定的冲突解决规则对冲突处理之后，数据库最终的结果往往是包含了多个节点的修改。

可以看出尽管最后所有的数据库都有相同的结果集，但这个结果是在多个节点共同参与下形成的，是多个修改合并到目标数据库的结果。因此合并复制并不维护事务的一致。

与创建快照复制和事务复制出版物相比，当创建一个合并出版物时，SQL Server 会对数据库以及出版表进行以下处理(见图16-54)：

(1) SQL Server 把出版表中的每一行都加上一个标识列，这样在表的多个拷贝间能惟一标识出该行。如果基本表上已存在具有ROWGUIDCOL 属性的标识列，则 SQL Server 将自动把其作为复制表的行标识，如果没有，则或在创建出版物过程中这些表被激活时，或在SQL Server Agent 第一次为该出版物提供服务时， SQL Server 将向表中添加一个具有ROWGUIDCOL 属性的rowguid，

(2) SQL Server 添加一个触发器来跟踪每一行或列数据的变化，并把捕捉到的变化存储到几个系统表中，或在创建出版物过程中复制表被激活时，或在SQL Server Agent 第一次为出版物提供服务时，将创建这些跟踪触发器。

(3) SQL Server 把用户跟踪的系统表添加到数据库，来执行冲突的检测，解决和记录。MSmerger_contents MSmerger_tombstone 系统表用来跟踪对出版物中数据的UPDATE、 DELETE、 INSERTS 操作。

16.5.2 合并复制的执行步骤

合并复制的执行需要快照代理和合并代理。其主要步骤是：

(1) 与快照复制、事务复制中快照代理的作用一样，合并复制的快照代理在开始复制之前也要完成二项任务;创建快照文件(同步集合)将存储在分发者的复制目录下;在出版数据库记录同步作业。合并代理将初始快照文件分发给订购者，从而完成订购初始化(出版数据库与订购数据库同步)。

(2) 当在某一节点(订购者)对出版物中表的某一行进行修改时，触发器会触发，并将该行的生成列generation column 设置为零。当合并代理执行时，它把所有生成列为零的合成一组或多组，凡是新的生成列值比原来的大，则用新值替换旧值。

(3) 在进行同步处理时，合并代理把所有生成列值为零的列(被修改的列)复制到所有其它订购者。

篇3：数据同步复制实践

银行业信息系统承载着我国金融机构核心业务和金融服务, 其中一个环节出现问题, 都可能引发多米诺骨牌式的传递效应, 导致系统性金融信息安全风险。灾备体系是保障银行业金融机构业务连续性的重要防线, 是维护银行业信息和网络安全的重要措施。虽然近年来, 我国银行业金融机构陆续建立了灾难备份体系和灾备中心, 但仍存在许多不足。

为规范银行容灾备份和灾备中心的建设, 人民银行在2005年提出要求:各银行数据灾难备份标准应至少达到2~3级, 在完成数据集中后的2年内灾难备份标准必须达到5~6级。依据GB/T 20988-2007《信息安全技术信息系统灾难恢复规范》中目标恢复时间 (RTO) /目标恢复点 (RPO) 与灾难恢复能力等级的关系, 5级系统要求RTO在数分钟到2天, RPO在0至30分钟;六级系统要求RTO为数分钟, RPO为0。提高灾备等级重点是减少RPO与RTO。从5级系统的要求来看, 目前大多数的灾备中心的切换均能满足RTO的要求, 因此, 本文将探讨如何通过数据复制技术减少RPO以提高灾备等级。

一、常见容灾技术综述

近年来, 容灾已经成为数据中心建设的热门课题。目前容灾技术多样, 分类也比较复杂, 总体上可以分为离线容灾 (冷容灾) 和在线容灾 (热容灾) 两种类型。

离线容灾主要依靠备份技术来实现, 主要有两种方式:一种是将数据通过备份系统备份到磁带再将磁带运送到灾备中心保存管理, 另一种是将数据先备份到本地磁盘再通过网络传输到灾备中心存储。离线式容灾具有实时性低、可备份多个副本、备份范围广、投资较少等特点。由于备份方式是压缩后存放到磁带 (磁盘) , 所以数据恢复较慢, 而且备份窗口内的数据都会丢失, 因此离线容灾一般用于数据恢复的RTO和RPO要求较低的容灾。也有很多客户将离线式容灾和在线容灾结合起来增加系统容灾的完整性和安全性。目前主流的备份软件主要有:Symantec Veritas Net Backup, EMC Legato Net Worker, IBM Tivoli Storage Manager, Quest Bak Bone Net Vault。

在线容灾要求生产中心和灾备中心同时工作, 生产中心和灾备中心之间由传输线路连接。数据自生产中心实时复制传送到灾备中心, 因此实现在线容灾的关键是数据的复制。和数据备份相比, 数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。根据数据复制的层次, 数据复制技术的实现可以分为3种:存储系统层数据复制、操作系统数据复制和数据库数据复制。

(一) 存储系统层数据复制

基于存储的复制一般都是采用ATM或光纤通道作为远端的链路连接, 不仅可以做到异步复制, 还可以做到同步复制, 使两端数据实时同步, 保证了数据的一致性。缺点是存储设备是由存储硬件厂商提供的, 在兼容性方面有局限性。用户要使用同一厂商的设备, 选择面太小, 成本高, 并且对线路带宽的要求也较高。

存储系统层的数据复制基于同构的存储, 各个存储厂商都有自己的复制软件, 如IBM PPRC, EMC SRDF, HP Continues Access, HDS True Copy等。

近年来, 随着存储技术的不断发展, 存储系统层次技术上还出现基于网络的存储虚拟化设备来实现数据复制。这种方式的特点是依靠外加的网络层设备来实现两个存储设备之间的数据复制, 数据复制过程不占用主机资源, 两个存储之间的数据同步在网络层完成。CDP技术就是虚拟化容灾方式所衍生出来的一种实时系统备份技术, 是一种容灾和备份的合成技术。

(二) 操作系统数据复制

操作系统数据复制主要通过操作系统数据卷管理器来实现数据远程复制。这种复制技术要求本地系统和远端系统主机同构, 其实现方式是基于主机的数据复制, 容灾方式工作在主机卷管理器层, 通过磁盘卷镜像复制, 实现数据容灾。这种方式也不需要在两边采用同样的存储设备, 具有较大的灵活性, 但是复制功能会占用一些主机的CPU资源, 对主机的性能有一定的影响。

目前基于原厂的逻辑卷管理软件如IBM AIX LVM, HP-UINX Mirror Disk, Sun Solaris SVM等可以实现在本厂平台上的逻辑卷镜像;专业的数据复制软件包括Symantec VERITAS Storage Foundation等, 提供了更大的灵活性, 支持多个平台的逻辑卷镜像。

(三) 数据库数据复制

数据库数据复制技术通常采用日志复制功能, 依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。这种复制技术对系统的依赖性小, 有很好的兼容性。缺点是本地复制软件向远端复制的是日志文件, 这需要远端应用程序重新执行和应用才能生产可用的备份数据。

目前基于数据库的复制技术主要有:O r a cle Data Guard, Oracle Golden Gate, DSG Real Sync, Quest Share Plex, IStream DDS等。

二、基于存储的数据复制原理

基于存储的数据复制不依赖主机系统、文件系统、数据库系统。工作机制是利用存储系统控制器的控制台来启动、监控、控制远程数据备份的操作。优点是能节省主机系统的CPU资源, 提供用户高可用性的开放服务。

(一) 同步复制

基于存储的数据同步复制技术为用户的任何数据提供了实时的、同步的远程镜像保护功能, 远端的拷贝数据与本地的拷贝数据或生产数据保持一致, 远端拷贝永远是本地数据盘的镜像, 具体流程如图1所示。

备份磁盘系统在更新时总是与生产同步, 在不需要主机干预的情况下, 生产磁盘与备份磁盘同步进行相同的I/O更新。磁盘系统保持完全一致的顺序 (一个I/O就发送一次) , 以保证数据和连续更新的完整性。当生产中心发生灾难时, 就不会出现数据丢失的情况。由于备份数据总是最新的, 应用程序就能够在最短的时间内重新启动。

由于需要等待远程写入数据的完成, 同步方式有性能上的缺陷, 系统和应用程序的性能因此受到一些影响。受应用系统I/O读写的活动频率、网络带宽、可以容忍的交易响应时间和其他因素的影响, 远程同步工作方式有距离的限制, 一般小于25千米。

(二) 异步复制

基于存储的数据异步复制以异步方式实现可靠的、经济的、可实施的容灾解决方案, 解决由于远程同步镜像方式给生产应用系统性能造成的巨大冲击和系统的压力, 以及异地长距离的场地部署问题, 具体流程如图2所示。

在异步方式下, 生产系统所发出的I/O操作至本地存储系统, 本地存储系统处理结束后立即通知主机本次I/O结束。然后, 本地生产存储系统将多个累计的I/O异步 (几乎实时发送) 且不一定按顺序传送到备份中心的存储系统中。

由于I/O操作不是同步地传送到备份中心, 存在数据的传送顺序与实际的数据的操作顺序不一致问题。为了解决这一问题, 容灾软件对每个写入生产中心存储系统的I/O都打上一个时间戳 (Time Stamp) 并进行一致性分组 (Consistency Group) , 在数据传输至备份中心时, 备份中心存储系统严格按照此时间戳的时间顺序重新排列并写入相应的逻辑卷中, 同一个一致性组内的I/O将被同时写入或者同时放弃, 从而保证备份数据逻辑的一致性与完整性。

由于数据异步远程更新, 应用程序不必等待远程更新的完成, 因此远程数据备份的性能影响通常较小, 并且备份磁盘的距离和生产磁盘间的距离理论上没有限制。只有在当传送中的数据在生产磁盘控制器或在TCA中还没有形成数据一致组时生产中心发生灾难, 这些“in-flight”的数据才会丢失。但True Copy通过Consistency Group技术保证灾难发生时已经发送到备份中心的数据将保持一致性, 因此在系统和应用程序重新启动之前, 需要恢复那些“in-flight”丢失的数据。所花费的时间和造成的影响取决于客户的环境, 例如应用程序和设备配置的复杂性、更新的完整性等。

三、基于存储的数据同步复制实践

为提高灾备等级, 各大商业银行都进行了数据复制保护, 多数采用了基于存储的数据复制技术, 其中光大银行、民生银行等用了惠普的CA技术, 中行、农行、工行、建行等使用了日立的True Copy技术。考虑到人行主要集中存储, 品牌一致性比较高, 人行选择了True Copy数据远程容灾解决方案。

为降低实施复杂度, 作为数据复制的一个探索性实践, 我们选择了灾备等级要求较高但数据量相对较小的货金系统进行了数据复制探索。该系统原来每天晚上由生产中心自动进行数据备份并将备份通过网络传输到同城灾备中心, 然后在灾备中心将备份恢复成为可用环境。其RTO<2小时, RPO为1天, 灾备等级为3级, 不满足人行对重要系统的灾备等级为5级的要求。我们使用True Copy同步复制技术, 实时将生产系统存储与灾备系统存储进行数据同步, 如图3所示。

我们将生产中心的HDS存储与同城灾备中心的HDS存储通过数据复制专用的光纤交换机 (博科5320) 连通 (由于距离大于25千米, 使用了华为DWDM设备) 。使用CCI服务器给HDS存储下发True Copy数据同步复制命令, 实施后货金系统所有写到生产集中存储的写I/O都将被同步写到灾备存储, 并且当灾备存储回复写入完成后才会返回。

由于NAS的数据放在了集中存储上, 因此也具备了实现NAS数据同步复制的条件。原有的创先科NAS并不能够很好地支持True Copy同步复制技术, 因此, 我们将货金系统的NAS迁移到了一台日立NAS上, 通过存储层的同步复制实现了对NAS数据的实时保护。

四、实施经验总结

(一) 方案设计要切合实际

每个单位的物理部署和网络都不大一样, 每个系统的情况和特点也可能不同, 因此在方案设计过程中, 对于重要参数应该搭建测试系统充分测试, 在获取实验数据的基础上合理选择。

1. 合理建设数据复制链路

一是应根据实际情况选择数据同步或者异步技术, 如果距离长应购买光纤交换机厂商的长距离级联许可, 如果超过20千米应考虑选择DWDM等连接设备;二是数据复制链路数据传输速率由光纤交换机、存储、长距离连接设备 (DWDM等) 中速度最低的设备决定, 采购设备时应注意短板效应;三是建议采用单独的光纤交换设备, 将数据复制链路与生产环境数据链路隔离, 避免压力情况下影响生产环境。

2. 合理设置True Copy相关参数

True Copy相关参数包括数据保护级别、同时复制的磁盘数量、通道轮询和通道失效时间等, 应根据测试情况及性能要求合理设置。我们采取了NEVER的数据保护级别, 当链路出现问题导致写操作失败时 (如出现问题一般会出现通道响应超时, 如果所有通道均不可用, 系统判定为链路故障) , 存储将自动停止True Copy, 避免DATA模式下数据复制链路出现异常导致数据库停顿, 用户端无法写入的情况。通道失效时间用于判断链路故障, 时间设置得越大, 故障发生时生产端的用户体验就越差, 时间设置得越小, 可能平时一点小抖动就可能造成True Copy被终止, 应根据具体性能要求及网络条件合理设置。复制的磁盘数量也是一个重要参数, 其值越大, 对灾备环境的性能要求越高, 应根据具体灾备端存储性能和网络条件综合考虑。

3. 适当设计冗余

实施方案一般都采取冗余设计, 确保任何一个单点故障都不会影响整个系统的独立运行。在我们的实施方案中, 数据复制链路由联通线路和歌华线路实现双路冗余, 确保其中一个运营商的线路发生故障时, 还能够使用另一个运营商的线路而不影响数据复制。但是依据邮储银行的经验, True Copy的数据复制链路如果同时使用不同运营商线路可能会对同步复制产生一定的影响。生产端操作系统层的写入操作在生产存储层将被分成多个I/O, 通过不同的线路到达灾备端存储, 由于一致性组的概念, 必须等到所有的I/O都到达后才能一次写入, 因此, 可能部分线路速度偏慢, 导致整体I/O速度慢, 从而影响生产端主机响应速度会进而影响用户体验。另外, DWDM线路本身就有工作路径和保护路径, 线路质量可靠性比较高, 因此其考虑的是每一个数据复制应用只使用一条运营商线路。具体实施过程中应根据测试结果选择适合本单位的冗余设计。

4. 一致性分组合理

将磁盘分为多少个一致性分组也是个很重要的问题, 可以根据应用来分, 也可以根据逻辑卷组 (VG) 来分。一般来说, 分组数量越多 (同一组内磁盘少) , 可能导致有的数据不可用、一致性相对较差的情况。比方说如果将数据库的索引和数据的磁盘分成不同的组, 则可能出现数据库数据写进去了, 但是索引没有写进去, 导致数据索引不可用。分组数量越少 (将更多的磁盘放到一个一致性组) , 会带来RPO上的损失, 因为发生故障后, 可能会丢掉一大堆的I/O。实施过程中应依据实际业务情况选择合适的分组。

(二) 切实防范实施风险

实施过程中最大的风险是方向的正确性, 数据复制的方向一定要从生产端到灾备端, 如果方向弄反了, 将冲垮生产环境的存储, 导致系统不可用。一般情况下, 都是在生产环境部可用时, 发生生产环境切换, 从生产切换到灾备。因此, 虽然存储技术提供了双向复制选择, 可以来去自如, 但现实情况下没有必要建立从灾备到生产环境的数据复制通道。在切换发生后, 如果生产和灾备中心的地位改变了, 再建立从灾备到生产的复制通道即可。此外, 应在实施前做好应急预案, 将生产端存储备份, 做好万一生产端存储遭受毁灭性毁坏也能恢复的准备。

(三) 实施前充分考虑运维风险

采取数据同步复制, 对生产系统有较大影响, 特别是当线路出现抖动或者光纤虚接等情况时, 可能造成生产端存储I/O堆积, 进一步引发数据库端进程堆积, 轻则导致用户响应延迟, 严重时可能导致生产环境数据库重启等后果。因此, 应探索建立一体化运维机制, 实现监控预警与自动化处理。

1. 建立监控预警机制

通过对相应指标的监控, 对超过阈值的指标 (存储的Cache Write Pending、光纤交换机enc out值) 和异常的复制状态 (非PAIR状态) 进行预警, 使管理员在问题发生时能够及时介入处理。

在实施过程中我们对光纤交换机enc out值和True Copy的异常的复制状态进行了监控, enc out值超过一定阈值或者True Copy状态为非PAIR状态时, 将通过短信报警平台给管理员发送告警信息。

2. 实现复制关系自动断开

篇4：国产数据库复制“高铁”模式

2014年10月，IBM将开放Informix数据库源码给国产数据库厂商天津南大通用数据技术股份有限公司（以下简称“南大通用”）的消息引起了业界的广泛关注，根据协议，南大通用可以基于IBM Informix推出自有的数据库。如今该数据库正式对外亮相，这就是GBase 8t（t表示这是一款交易型数据库），它与南大通用原有的分析型数据库GBase 8a、安全数据库GBase 8s、内存数据库GBase 8m等共同构成了南大通用未来参与数据库市场竞争的产品组合。

“GBase 8t是南大通用基于IBM的Informix自主构造的面向国内关键行业应用需求的交易型数据库，它具有与Oracle、DB2等国际一流数据库产品一样的高稳定性、高性能和高可用性。”南大通用CTO武新在GBase 8t的产品发布会上表示。

GBase 8t的推出意味着我国有了一款具有自主可控能力的高端数据库产品，有了可以和这些一流数据库同台竞技的机会。据介绍，GBase 8t可胜任大并发量核心事务处理，具有完备的高可用集群解决方案；容易维护，可通过零宕机实现计划内数据库软件的升级和维护；具有完备的自我配置、自我管理、自我恢复的能力；支持云部署，完全可以部署于要求极为严苛的数据库应用环境，将为中国的数据库用户带来新的选择。

众所周知，我国的IT产业长期处于缺“芯”（CPU）少“魂”（基础软件）的尴尬局面。作为基础支撑软件的数据库就属于这里所说的“魂”之列。和操作系统一样，数据库的核心技术长久以来被Oracle、IBM等少数厂商把持，虽然国家从政策和资金等方面给予国产数据库厂商支持，然而，一直没有根本性的改变。其根本原因在于，一直以来各种国内自主可控的产品缺乏市场历练，难以获得行业核心项目的信任。很多时候不是产品的技术不行，而是根本没有机会。

而GBase 8t选择了一条不同的路，在引进、消化、吸收再创新的基础上，推出了一套自主创新、能自主可控的高端数据库产品。武新称之为复制“高铁模式”：中国高铁正是通过引进、消化、吸收、再创新走出了一条属于自己的发展之路。

“Informix是一款可以与Oracle、DB2比肩的非常成熟的产品，出道30多年来拥有庞大的用户群，赢得了用户的信任。这要比从头来开发一个自己的数据库更容易为市场所接受。”武新告诉计算机世界记者。

显然，武新的预言不虚，中国市场对GBase 8t给予高度肯定。在新闻发布会上还举行了与合作伙伴的签约仪式，这些合伙伙伴包括浪潮、华为、中标软件、东软、东方通、启明星辰等，它们将与南大通用一起共同推出整合了GBase 8t的各种应用解决方案。而在此之前，南大通用已经与这些厂商进行了紧密合作，针对这些合作的软硬平台对GBase 8t进行产品优化和适配。

为了打开市场，在发布会上，南大通用还宣布启动“GBase高校行”计划，将向一些高校免费赠送GBase 8t等软件，并提供技术指导，其用意也在于为国产数据库建立起一支人才队伍，进而打造一个更好的应用环境。

篇5：Excel监视窗口动画教程

演示动画

操作步骤

我们有时候需要在Excel中同时查看多个工作表中不同单元格内的数值，可以用监督窗口来查看，

选中相应的单元格，右击鼠标，在随后弹出的快捷菜单中，选择“添加监视点”命令。

重复相述操作，将需要监视的单元格一一添加为监视点。

篇6：复制监视器数据库教程

那么，如果不需要要进行高级粘贴操作时，有没有办法把这个“粘贴选项按钮”隐藏呢?

很简单：

以Office 为例，任意打开一程序(如 Excel 2010)，单击“文件-选项”，

打开“高级”选项卡，从右边的细节窗口“剪切、复制和粘贴”栏下找到“粘贴内容时显示粘贴选项按钮”，取消它前面复选框的勾选。然后按“确定”保存修改。

现在其它的 Office 程序也会同步应用这个更改，Word 中的“粘贴内容时显示粘贴选项按钮”复选框也变成了未勾选状态。

篇7：复制监视器数据库教程

Xcopy 复制文件和目录，包括子目录。

xcopy source [destination] [/w] [/p] [/c] [/v] [/q] [/f] [/l] [/d[:date]] [/u] [/i] [/s [/e]] [/t] [/k] [/r] [/h] [/a|/m] [/n] [/exclude:filename] [/y | /-y] [/z]

参数

source

指定要复制的文件的位置和名称。该参数必须包含驱动器或路径。

destination

指定要复制的文件的目标。该参数可以包含驱动器盘符和冒号、目录名、文件名或者组合。

/w

在开始复制文件之前将显示以下消息并等待您的响应： Press any key to begin copying file(s)

/p

提示您确认是否要创建每个目标文件。

/c

忽略错误。

/v

在写入目标文件时验证每个文件，以确保目标文件与源文件完全相同。因为该功能是 Windows 2000 操作系统固有的，所以将忽略该开关。接受该开关只是为了与以前版本的 MS-DOS 兼容性。

/q

禁止显示 xcopy 消息。

/f

复制时显示源文件名和目标文件名。

/l

不复制文件，仅显示(列出)要复制的文件。

/d[:date]

只复制那些在指定日期或指定日期之后更改过的源文件。如果 date 值丢失，xcopy 将复制所有比现存 destination 文件时间新的 source 文件。该选项使您可以只更新更改过的文件。如果指定了日期，请使用连字符 (-) 作为分隔符而不是使用正斜杠 (/)，以便日期不会解释为另一个参数。

/u

只从 source 复制(更新) destination 中已有的文件。

/i

如果 source 是目录或包含通配符，并且不存在 destination，xcopy 将假定 destination 指定目录名并创建新目录，然后将所有指定的文件复制到新目录中，

默认情况下，xcopy 将提示您指定 destination 是文件还是目录。

/s

复制非空的目录和子目录。如果省略此开关，xcopy 将在一个目录中工作。

/e

复制所有子目录，包括空目录。与 /s 和 /t 开关一起使用。

/t

只复制子目录结构(树)，而不复制文件。要复制空目录，必须包含 /e 开关。

/k

复制文件，如果源文件具有只读属性，则在目标文件中保留该属性。默认情况下，删除只读属性。

/r

复制时跳过只读文件。

/h

复制具有隐藏和系统文件属性的文件。xcopy 命令在默认情况下不复制隐藏文件或系统文件。

/a

只复制那些具有存档文件属性设置的源文件。该开关不修改源文件的存档文件属性。有关如何设置存档文件属性的信息，请查看 attrib 命令。

/m

复制具有存档文件属性设置的源文件。与 /a 开关不同，/m 开关关闭源中指定的文件的存档文件属性。有关如何设置存档文件属性的信息，请单击“相关主题”列表 [JG1] 中的 attrib 。

/n

使用 NTFS 短文件或目录名复制。当将文件或路径从 NTFS 卷复制到 FAT 卷或者当目标卷需要 FAT 文件系统命名约定 (8.3) 时，必需该开关。目标文件系统可以是 FAT 或 NTFS。

/exclude:filename

排除对指定文件中列出的文件进行复制操作。排除的文件可以拥有排除样式列表(每行一个，不支持通配符)。如果文件中某个排除样式与主题文件路径的任何部分匹配，将不复制该文件。

/y

禁止提示您确认要覆盖现存目标文件。

/y

开关可以在 COPYCMD 环境变量中预置。该开关可以由命令行上的 /-y 替代。默认为在覆盖时提示，除非 copy 命令从批处理脚本内部执行。

要附加文件，请指定单个目标文件，多个源文件(使用通配符或文件 1 + 文件 2 + 文件 3 格式)。

/-y

提示您确认是否要替代现存的目标文件。

/z

篇8：复制监视器数据库教程

关键词：Oracle数据库,高级复制,应用

一些大的信息系统往往由多地的不同用户同时使用, 由相距较远的多个站点构成的广域网, 并且各个站点之间需要数据共享, 通常将这些共享的数据存储在其中一个站点上, 作为数据中心, 所有用户都从该站点存取数据。这种方案很容易就能保证数据一致性, 但会造成数据中心的负载过大, 使远程用户的数据响应很慢, 甚至造成系统瘫痪。数据复制技术可以有效地解决这个问题, 它通过将这些共享数据复制到多个不同站点的数据库中, 实现数据的本地访问, 减少网络负荷, 并提高数据访问的性能, 而且通过数据同步, 确保数据实时性和一致性[1]。该技术适用于用户数较多、地理分布较广、而且需要实时地访问相同数据的应用模式。

Oracle数据库的复制是由数据库的后台进程自动实现的, 通过设置数据库参数, 确定后台负责复制任务的进程数和被激活的时间。数据库的后台进程是由系统按设定的时间间隔执行预定的操作, 以实现数据定期地从源数据库到目标数据库的传输, 并由系统进行控制。Oracle数据库复制支持基本复制和高级复制两种形式, 这里主要讲述Oracle高级复制技术在应用时的设计, 以及可能遇到的问题和解决办法。

1 基本概念

Oracle高级复制, 即对称复制, 既可支持整个表的复制也可支持基于部分表的复制两种复制方案, 其主要是通过多主复制和可更新快照复制两种机制实现的。同时还可以将这两种复制机制结合起来以满足不断变化的业务需求。

2 高级复制设计步骤

2.1 多主复制

(1) 创建复制环境, 明确高级复制的站点和参与复制的数据表;保证各站点具有复制关系的表结构的一致性; (2) 使用数据库复制管理器, 定义参加复制的站点, 在复制的各站点, 建立包含复制实体的用户和复制的数据库链路, 建立复制的管理用户, 配置数据更新的计划; (3) 建立主复制组, 不同的需参与复制的实体可加入不同的组中; (4) 给用户分配适合的权限, 防止由于用户权限过大而造成的复制冲突。

2.2 可更新快照复制

(1) 创建复制环境, 明确高级复制的站点、参与复制的数据表和可更新快照复制的站点;保证各站点具有复制关系的表结构的一致性; (2) 在复制的各站点建立快照管理用户, 建立包含可更新快照实体的用户和复制的数据库链路, 配置数据更新的时间和间隔; (3) 在主站点建立快照日志; (4) 在复制点建立必要的更新组; (5) 建立快照组, 快照组可包含表、存储过程、包、函数、同义词、视图等实体; (6) 给用户分配适合的权限, 防止由于用户权限过大而造成的复制冲突。[3]

3 需要注意事项

3.1 确保网络连接的稳定。如果服务器网络连接中断, 则造成数据无法访问和传输;网络不稳定, 会导致数据传输过程中出现丢包现象, 影响数据的完整性。

3.2 要有较高的网络传输速度。各个站点之间要进行大量的、频繁的数据传输, 速度过慢的话将影响其访问速度。

3.3 服务器应保持开机状态或定时开机。否则会造成大量的延迟任务, 无法进行数据发布。

3.4 不能在参与复制的表上面直接执行DDL语句。因为OR-ACLE自动在参与复制的表上建立了支持复制的TRIGGER和PACKAGE, 在其上面直接执行任何DDL语句都会破坏这些复制支持。应该先SUSPEND要修改表所在的复制组, 在REPICATION MANAGER中或调用REPCAT API执行DDL语句, 然后重新GEN-ERATE该表的复制支持, 最后将复制组状态恢复为NORMAL。注意一定要在修改表结构的DDL语句中的表名前带上属主, 并且最后不加分号。若直接执行了DDL语句, 应先将该表移出复制环境删掉, 再重新建立或复制表。

3.5 如需要在表中增加字段并设置默认值时, 在9i之前的版本中要分成两部分执行, 不能一次执行。例

ALTER TABLE owner.table_name ADD field_name

ALTER TABLE owner.table_name MODIFY field_name DE-FAULT'abc'

因为在高级复制环境中, 执行任何DDL语句, 都需要SUSPEND复制组, 此时复制表只能查询, 不能再执行DML语句。如何在一个SQL语句中执行添加字段同时赋缺省值, 则添加字段后插入缺省值的DML操作不会执行, 并且报错。分成两步操作能解决该问题。

3.6 执行任何对复制环境的管理命令前, 都要保证此时没有堆积的DEFERRED TRANS。

3.7 ADMIN REQUEST (对复制环境的管理命令) 须一步一步执行。用一个REPCATLOG表保存ADMIN REQUEST语句, 从第一条到最后一条顺序执行, 只有执行完上一条后才能执行下一条。每次发出ADMIN REQUEST后, 都要检查REPCATLOG表是否为空, 只有当所有的REPCATLOG表都为空后, 才能将复制组设置为NOR-MAL, 发出下一条命令。

3.8 如果REPCATLOG表中有无法执行的命令, 可以APPLY或PURGE掉, 再重新执行命令。若只是其中一个节点上有遗留命令, 则可在该节点上多执行几次APPLY。

3.9 当出现死锁现象时, 可以先尝试中断掉该ADMIN RE-QUEST对应的任务, 重新刷新命令, 若能继续执行, 则恢复任务, 否则从V$SESSION和V$LOCK中查出死锁进程, 用ALTER SYSTEM KILL SESSION将其杀掉。如果无法杀掉, 则需查出类型为'RQ'的分布式死锁, 根据SID查出对应的后台进程, 从操作系统中杀掉后台进程, 最后再恢复任务和相关复制环境的状态。

4 实际应用

某地下水监测系统由省级主站、市级分站和县级分站组成, 数据存储采取省级数据中心和市级数据中心分布式存储, 均采用Oracle数据库, 以确保全省数据储存的快速、稳定、安全。各市分站只为本市所辖县级分站提供存储服务, 并将所有测报数据传送汇总到省级主站数据中心, 同时其为各市级分站数据实现异地备份, 提供跨地市数据查询, 当各地市分站数据出现故障时, 可从省级主站读取数据, 恢复数据。

整个数据同步机制主要采用Oracle复制技术的可更新快照机制。整个分布式数据库系统采用的是“一主多从”的结构 (如图1) , 设置省级主站的数据库系统为主数据库, 各市分站的数据库系统为从数据库。使用Oracle系统中的增量复制技术, 定时或手动进行主数据库与从数据库的数据更新。从数据库复制到主数据库的是全部数据, 只要从数据库中的数据有变化, 就会反映到主数据库中;主数据库复制到从数据库的是与本市分站相关的测报数据。

5 结束语

分布式数据库系统适应于地理上分散而管理上又有不同程度集中的大型信息系统的需求, Oracle高级复制机制提供了高可靠性、高可用性以及改善了系统的性能, 同时也提供了很好的各数据中心数据同步实现方案。在具体应用中, 也还有许多比较复杂的问题需要解决, 需要逐步探索、深入研究。

参考文献

[1]郑振楣, 于戈, 郭敏.分布式数据库[M].北京:科学出版社, 1998

[2]丁铖.Oracle8/8I数据库系统原理[M].北京:人民邮电出版社, 2001

篇9：复制监视器数据库教程

关键词：分布式数据库；松耦合；数据分片；数据库复制

引言

当今社会飞速发展，许多企业的经营和管理规模不断扩大，营业和管理机构的分散造成了业务数据的分散，总公司与各分公司处于不同的城市或城市中的各个地区，在业务上它们处理各自的数据，但也需要彼此之间数据的交换和处理，如何协调处理分散的数据和集中的管理，是企业发展的关键问题之一，也是MIS／ERP系统开发者要研究和解决的重点。分布式数据库系统技术在这个方面就起到了至关重要的作用，使企业在运作中能够得心应手地管理处于分布环境下的各种数据。

1分布式数据库特点介绍

分布式数据库(DDB)的数据分布在计算机网络的不同节点(亦称场地)上，网络中的每个节点具有独立处理的能力(称为场地自治)，可以执行局部应用，同时，每个节点也能通过网络系统执行全局应用。系统强调节点的自治性而不强调系统的集中控制，且应保持数据的分布透明性，在编写应用程序时可完全不考虑数据的分布情况。分布式数据库的显著特点是：

(1)分布性

数据库中的数据不是存储在同一计算机。这有别于集中式数据库。

(2)逻辑相关性

数据库逻辑上是相互联系的一个整体，而不是分散的局部物理数据库的集合。

(3)分布式透明性

所谓分布式透明性就是在编写程序时好像数据没有被分布一样，因此，数据转移不会影响程序的正确性。

(4)数据冗余

与集中式数据库系统不同，数据冗余是分布式系统的重要特性，其原因在于：首先，如果在需要的节点复制数据，则可以提高系统局部的应用能力。其次，当某节点发生故障时，可以操作其它节点上的复制数据，因此，提高了系统的有效性。

(5)数据存储途径

在分布式数据库中，数据存储通过以下三种途径实现。

复制：系统维护多个完全相同的副本，这些副本存储在不同的节点上。

分片：关系被划分为几个片段，各个片段存储在不同的节点上。

复制＋分片：关系被划分为几个片段，系统为每个片段维护几个副本。

2分布式数据库技术在企业数据管理中的应用现状及特点

在多数使用了分布式数据库的企业MIS／ERP系统中，总公司与各分公司处于不同的城市或城市中的各个地区，在业务上它们处理各自的数据，但彼此之间也需要进行数据交换和处理。这种处理一般有两种情况：一种是数据的交换和处理必须实时进行以确保数据库的紧密一致性；另一种是定期地进行数据交换和处理，甚至只在必要时进行，这种方式对于数据库的一致性在时间上要求不高，各场地间保持松耦合状态，每个营业机构处理的是本机构的数据，各营业机构之间或下级营业机构与上级营业机构之间只是定期进行数据的交换。大多数企业MIS／ERP应用都是采用松耦合分布式数据环境。

松耦合分布式数据环境从全局应用的角度出发，将分公司的所有数据库自下而上构成分布式数据库系统，实现全局数据的完整性和一致性，各营业机构存放本机构的数据，总公司的数据库则存放所有业务数据，并对数据进行完整性和一致性的检查。这种做法虽然有一定的数据冗余，但在不同场地存储同一数据的多个副本，能提高系统的可靠性和可用性，同时提高局部应用的效率，减少通讯代价。分布式数据库系统可以在对当前机构影响最小的情况下进行扩充，增加新的营业机构时只需增加一个节点就可以了，同时也使得各处理机之间的相互干扰降到最低。

3数据库复制技术在松耦合分布式数据环境中的实现

分布式数据库系统可以通过复制、分片和复制加分片三种方式存储数据。因为各数据库之间存在一定的数据冗余，又存在着差异，我们使用了复制十分片的方式进行数据存储。

3．1数据分片

在分布式数据库系统中，将关系分片，有利于按用户需求组织数据，目前的分片方式有水平分片、垂直分片、导出分片、混合分片等四种。我们根据不同的数据关系采用了不同的分片方式：

水平分片对于总公司与分支营业机构的数据关系，由于分支机构的数据是总公司业务数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。

垂直分片对于总公司数据库服务器与Web数据库服务器的数据关系，数据是按照其应用功能来划分的，所以我们采用了垂直分片的方式。

3．2数据库复制技术

3．2．1选用数据库复制技术的原因

数据库复制技术是在数据库之间对数据和数据库对象进行复制和分发并进行同步以确保其一致性的一组技术。企业生产管理的数据环境特性是：①数据中心(总公司)的新数据或处理后的数据需要复制或分发至一个或多个数据分中心(各营业厅)。②各个数据分中心的数据被汇总到数据中心服务器上，然后由数据中心服务器加以归并整合。因此，我们选择使用数据库复制技术作为这种松耦合分布式数据环境的解决方案。

3．2．2解决方案

数据库复制的过程不像一般的数据传递，它更要将数据进行同步处理。由于总公司数据库服务器与Web服务器之间的数据交换是双向的，总公司业务管理和营业所业务管理都会产生新的业务数据，所以我们使用合并复制方式实现数据同步：把总公司数据库服务器设置为出版者，Web数据库服务器设置为订阅者，合并复制监视源数据库中的改变，并同步出版者和订阅者的数据值，其中无论是出版者还是订阅者均可以更新数据。当出版者同订阅者发生冲突时，我们将出版者设置为高优先级。与此类似，目的数据库中的数据改变将被告知源数据库。合并复制涉及快照代理和合并代理的参与。快照代理将准备包含有被出版数据表的结构与数据的快照文件，在分发者上存储这些文件，并在分发者的分发数据库中记录同步任务。合并代理应用存储在出版数据库表中的初始快照任务于订阅者；它也合并在最初快照建立后改变的数据，并依据用户配置的规则或使用用户自定义的解决方法来协调冲突。

3．2．3具体实施步骤

(1)数据中心配置发布服务器和分发服务器，指定发布数据库和分发数据库和发布类型(合并发布)，指定存储快照文件夹的根位置并创建发布。

(2)数据中心创建请求订阅，添加或指定注册的订阅服务器。

(3)脱机工作时，各个数据分中心可以更新数据。网络连通后，通过使用请求订阅，各数据分中心通过订阅服务器下载数据中心分发的相应数据。

(4)连通数据中心发布数据库服务器，生成订阅。订阅生成后，各个数据分中心更新后的数据将传送到发布服务器和订阅服务器，同时进行同步处理检测并解决冲突。

3．2．4特别说明

在实际操作中，如果由于网络传输速率太低或者掉线会给数据库复制的初始化工作带来不便。因此，我们可以采用在数据中心局域网初始化各分中心的订阅数据库框架，再将该数据库用移动存储的方式移到相应数据分中心的方法解决。

(1)(数据中心)在发布服务器上首先配置发布和分发，使用数据中心局域网的其他计算机作为订阅服务器，对每个分中心的订阅内容进行一次初始化订阅操作(需要用快照初始化框架)，以生成相应的订阅数据库。

(2)各分中心使用移动存储将自己已初始化的订阅数据库从数据中心移到本地订阅服务器上。

(3)分中心连通数据中心发布数据库服务器，生成订阅(此时不需要初始化框架)，订阅生成后马上运行同步处理，其间不要更改任何数据(适用发布服务器，订阅服务器)。

使用这种方式可以有效地避免因网络传输速度慢或者断网以及发布服务器初始化订阅服务器框架不易顺利进行的问题。以这种方式初始化订阅数据库框架后，复制操作按照数据库复制的规范步骤进行即可。

4结束语