In-Memory Computing Technology

本文描述的是如何更改classic replication的scheme，table等更改复制策略以下的更改无需停止复制代理： * Create, alter 或 drop 用户 * Grant or revoke 权限 * 添加subscriber * 添加 PL/SQL 对象其它的更改的过程如下： 1. 停止复制代理 2. alter replication语句，在master和s

复制系统的监控主要通过ttStatus 和 ttRepAdmin命令，也可以从系统表中得到信息。 以下的输出，基于cachedb1为复制源，cachedb2为复制目标显示复制代理的状态ttstatus显示复制代理状态注意Replication agent is running. 这行$ ttstatusTimesTen status report as of Wed Jun 29 18:04:2

通常，数据库复制时，无需指定固定的复制端口，而是两个数据库之间进行在线协商，使用动态的端口。 不过某些特殊情况下需要指定固定的端口，例如TimesTen的Daemon端口为非缺省时。下面的例子给出了设置指定固定端口复制的完整过程，为了测试简便，我在一个虚拟机里安装了两个TimesTen实例,它们的版本不同，Daemon端口分别为53392和55555：[oracle@timesten-hol in

设置复制环境本章全部适用于classic复制，只有少部分适用于ASP复制。创建数据库保持源数据库存在，源复制表存在，目标数据库的DSN存在。然后建立目标的表： * 若是AWT复制，目标表通过ttRepAdmin -duplicate 建立 * 若是Classic复制，目标表通过SQL建立复制数据库的连接属性DatabaseCharacterSet ： 必须相同，复制不字符集转换 Replica

先说明一点，对于classic复制，是不区分普通表和缓存表的，所以普通表和缓存表都可以混搭作为复制的源或目标。置于缓存表后端与Oracle的同步，对于classic复制是透明的。从只读缓存表到非缓存表的复制拓扑如下：示例如下：SQL> select * from a; ID NAME---------- --------------------------------

概述对于带缓存组的复制，推荐的复制策略是 Active-Standby (A/S) pair。因为其复制整个库，并且复制和恢复都比较简单和直接，而且错误切换和恢复都是自动的。带AWT缓存组的ASP复制 - 单站点此种复制不支持灾备 注意数据的流向带只读缓存组的ASP复制注意数据的流向带AWT缓存组的ASP复制 - 多站点此种复制支持灾备从standby到subscriber的克隆使用特殊的ttRe

双向复制是classic复制的典型模式，双向复制即active/active模式，本文定义对于单表的双向复制，两边对于同一表可以同时更改。DSN如下：[master1]Driver=/home/oracle/TimesTen/tt1122/lib/libtten.soDataStore=/tmp/master1DatabaseCharacterSet=AL32UTF8ConnectionCh

简介这时一个集只读，AWT缓存组，Active Standby 复制，client auto failover为一体的集成实验。 整个过程来至于Doc ID 1359840.1, 本文基于此文档按照自己的环境重做了一遍，并更正了其中的小错误，增加了自己的理解。 本文省略了在Oracle端设置缓存组的过程，可以参见前面的文章。搭建的环境为虚拟机 timesten-hol 上安装了两个TimesTe

在Active Standby Pair中复制DDL语句在以下的例子中，active master为cachedb2, standby master为cachedb1在Active Standby Pair复制数据库对象DDLReplicationLevel 连接属性可以控制复制对象的行为。 DDLReplicationLevel = 1：不复制表，索引和同义词的create 和 drop，只复制

带缓存组的Active standby pairs(ASP)在不带缓存组的ASP中，复制发生在TimesTen的表间；而在带缓存组的ASP中，复制发生在cache table之间。带缓冲组的复制仅支持只读和AWT缓存组。对于只读缓存组，复制的意义在于保持状态的连续，而对于AWT，复制可以保证数据不丢失。设置带只读缓存组的ASP(例)假设active master为cachedb1，standby m

本文针对的是classic复制的双向复制模式复制冲突是如何产生的有update冲突，insert冲突，delete/update冲突，在本节中都有示例说明。基本都是由于两个master同时操作同一条记录所致，导致从两方发出的操作交织在一起，导致不一致，如果是串行的倒也无所谓了。还需强调一点，这些冲突可以检测到，但并不会自动解决，需要应用来处理 Within a single database,