DataSync 异构数据同步
|
通常在物理Standby没有执行REDO应用操作的时候，可以将物理Standby数据库以READ?ONLY模式打开，如果数据库中指定了Flashback?Area的话，甚至还可以被临时性的置为READ?WRITE模式，操作完之后再通过Flashback?Database特性恢复回READ?WRITE前的状态，以便继续接收Primary端发送的REDO并应用。 REDO应用。物理Standby通过REDO应用来保持与Primary数据库的一致性，所谓的REDO应用，实质是通过Oracle的恢复机制，应用归档文件（或Standby?Redologs文件）中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作，Oracle数据库就不能被Open。 READ?ONLY模式打开。以READ?ONLY模式打开后，可以在Standby数据库执行查询或备份等操作（变相减轻Primary数据库压力）。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据，不过并不会应用，直到Standby数据库重新恢复REDO应用。 也就是说在READ?ONLY模式下不能执行REDO应用，REDO应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，如先应用REDO，然后将数据库置为READ?ONLY状态，需要与Primary同步时再次执行REDO应用命令，切换回REDO应用状态。呵呵，人生就是循环，数据库也是一样。 ? 提?示：?Oracle?11g版本中增强物理Standby的应用功能，在11g版本中，物理Standby可以在OPEN?READ?ONLY模式下继续应用REDO数据，这就极大地提升了物理Standby数据库的应用场合。 ? READ?WRITE模式打开。如果以READ?WRITE模式打开，那么Standby数据库将暂停从Primary数据库接收REDO数据，并且暂时失去灾难保护的功能。当然，以READ?WRITE模式打开也并非一无是处，如你可能需要临时调试一些数据，但又不方便在正式库中操作，那就可以临时将Standby数据库置为READ?WRITE模式，操作完之后将数据库闪回到操作前的状态（闪回之后，Data?Guard会自动同步，不需要重建物理Standby，不过如果从另一个方向看，没有启动闪回，那就回不到READ?WRITE前的状态了）。 ? 物理Standby特点如下： （1）灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。 （2）数据保护。使用物理Standby数据库，DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制，因此与对象、语句无关，Primary数据库上有什么，物理Standby数据库端也会有什么。 （3）分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。 （4）提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。 ? ? 2．逻辑Standby 逻辑Standby也要通过Primary数据库（或其备份，或其复制库，如物理Standby）创建，因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据，因此逻辑Standby的物理文件结构，甚至数据的逻辑结构都可以与Primary不一致。 与物理Standby不同，逻辑Standby正常情况下是以READ?WRITE模式打开，用户可以在任何时候访问逻辑Standby数据库，就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊，由于SQL应用自身特点，逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED?中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。 ????逻辑Standby?的读写打开可以使它做报表系统，这样减轻系统的压力。 ? 除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外，逻辑Standby还有下列一些特点： （1）有效地利用备机的硬件资源。除灾难恢复外，逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要；又如创建新的SCHEMA（该SCHEMA在Primary数据库端并不存在），然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。 （2）分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态，这使得逻辑Standby数据库能够同时用于数据保护和报表操作，从而将主数据库从报表和查询任务中解脱出来，节约宝贵的?CPU和I/O资源。 （3）平滑升级。可以通过逻辑Standby来实现如跨版本升级，为数据库打补丁等操作。应该说应用的空间很大，而带来的风险却很小（前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心了，所以此项没有作为物理Standby的特点列出），我个人认为这是一种值得可行的在线的滚动的平滑的升级方式，如果你的应用支持创建逻辑Standby的话。 ? ? ? 七．?Log应用服务（Log?Apply?Services） Data?Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性，在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式： REDO应用：物理Standby数据库专用，通过介质恢复的方式保持与Primary数据库的同步。 SQL应用：逻辑Standby数据库专用，核心是通过LogMiner分析出SQL语句在Standby端执行。 ? 因此物理Standby在应用REDO数据时必须是MOUNT状态，而逻辑Standby则是以READ?WRITE模式打开并应用REDO数据，不过被维护的对象默认处于只读状态，无法在逻辑Standby端直接修改。 ? 7.1??Log应用服务配置选项 默认情况下，Log应用服务会等待单个归档文件全部接收之后再启动应用，如果Standby数据库配置了Standby?Redologs，就可以打开实时应用（Real-Time?Apply），这样Data?Guard就不需要再等待接收完归档文件，只要RFS进程将REDO数据写入Standby?Redologs，即可通过MRP/LSP实时写向Standby数据库。 ? 7.1.1．REDO数据实时应用 启动实时应用的优势在于，REDO数据不需要等待归档完成，接收到即可被应用，这样执行角色切换时，操作能够执行得更快，因为日志是被即时应用的。 要启动实时应用也简单，前提是Standby数据库端配置了Standby?Redologs。 ? 物理Standby要启用实时应用，要在启动REDO应用的语句后附加USING?CURRENT?LOGFIE子句，例如： SQL>?ALTER?DATABASE?RECOVER?MANAGED?STANDBY?DATABASE?USING?CURRENT?LOGFILE?;? ? 逻辑Standby要启用实时应用，只需要在启动REDO应用的语句后附加IMMEDIATE子句即可，例如： SQL>?ALTER?DATABASE?START?LOGICAL?STANDBY?APPLY?IMMEDIATE;? ? 7.1.2．REDO数据延迟应用 （编辑：广西网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
