1.本申请涉及用于数据库事务到副本表的实时表复制(real-timetablereplication，rtr)的方法和系统。
背景技术：
：：2.企业可以使用数据库管理系统来处理大量的数据库事务。例如，当数据库管理系统被保险公司、金融服务公司、电子商务网站等使用时，可能就是这种情况。为了帮助处理大量的数据库事务，数据库管理系统可以将读取事务分发到副本节点处的副本表。数据库管理系统可以通过将改变从源节点处的源表复制到副本节点处的对应的副本表来维护副本表。然而，复制这些改变可能很慢，尤其是当源表频繁更新时。这可能会限制数据库管理系统的读取事务性能，并在源表和副本表之间产生可见性差距。3.在一些情况下，异步表复制(asynchronoustablereplication，“atr”)可以高效地促进这样的过程。然而，atr的使用可能限于与源表位于相同环境(landscape)中(例如，位于相同系统中并共享相同数据库软件)的副本表。因此，可能需要以安全、自动和准确的方式提供实时跨环境数据库表复制。技术实现要素：4.数据库事务到副本表的rtr可以包括接收(表示数据库事务的)复制日志条目和事务提交日志条目。复制日志条目具有行id值，并且副本表中的行具有行id值。可以将复制日志条目分派给并行日志重放器，并将相关联的事务提交日志条目分派给事务提交日志重放器。可以比较行id值，并且基于所述比较在并行日志重放器处重放复制日志条目。然后，可以通过在事务日志重放器处重放相关联的事务提交日志条目，将数据库事务提交给副本表，其中，数据库事务与具有事务一致性(transactionalconsistency)的行级并行重放相关联，并且副本系统处的ddl语句的ddl复制和重构与一个或多个元数据更新日志条目相关联。5.一些实施例包括：用于由至少一个处理器接收复制日志条目和相关联的事务提交日志条目的装置，复制日志条目和相关联的事务提交日志条目一起表示要被重放到副本表中的行的数据库事务，复制日志条目具有行id值，并且副本表中的行具有行id值；用于由至少一个处理器将复制日志条目分派给并行日志重放器并将相关联的事务提交日志条目分派给事务提交日志重放器的装置；用于由至少一个处理器将复制日志条目的行id值与副本表中的行的行id值进行比较的装置；用于由至少一个处理器基于所述比较在并行日志重放器处重放复制日志条目的装置；以及用于由至少一个处理器通过在事务日志重放器处重放相关联的事务提交日志条目来将数据库事务提交给副本表的装置，其中，数据库事务与具有事务一致性的行级并行重放相关联，并且副本系统处的ddl语句的ddl复制和重构与一个或多个元数据更新日志条目相关联。6.本文公开的一些实施例的一些技术优点是以安全、自动和准确的方式提供实时跨环境数据库表复制的改进系统和方法。附图说明7.图1是利用异步表复制的分布式数据库系统的框图。8.图2是利用用于异步表复制的事务和并行日志重放的分布式数据库系统的框图。9.图3是根据一些实施例的利用混合云的弹性伸缩的实时表复制使用示例。10.图4是根据一些实施例的来自多个远程系统的高效数据虚拟化的实时表复制使用示例。11.图5是根据一些实施例的整体实时表复制架构。12.图6a示出了根据一些实施例的跨环境实时表复制。13.图6b至图6h与rtr建立、激活和去激活相关联。14.图7示出了根据一些实施例的包括源系统和副本系统的架构。15.图8是不同二进制版本之间的跨数据库异步表复制。16.图9示出了根据一些实施例的如何复制副本表。17.图10表示根据一些实施例的数据定义语言日志重放。18.图11示出了根据一些实施例的数据定义语言语句的实时表复制激活和生成。19.图12是根据一些实施例的实时表复制方法。20.图13是根据一些实施例的实时表复制显示。21.图14是用于实施各种实施例的计算机系统的示例。具体实施方式22.在以下详细描述中，阐述了许多具体细节，以便提供对实施例的透彻理解。然而，本领域普通技术人员将理解，实施例可以在没有这些具体细节的情况下实践。在其他实例中，没有详细描述众所周知的方法、过程、组件和电路，以免模糊实施例。23.下面将描述本发明的一个或多个具体实施例。为了提供这些实施例的简明描述，在说明书中可能没有描述实际实施方式的所有特征。应当理解，在任何这样的实际实施方式的开发中，如在任何工程或设计项目中，必须做出许多特定于实施方式的决定来实现开发者的特定目标，诸如符合系统相关和业务相关的约束，这些约束可能因实施方式的不同而不同。此外，应当理解，这种开发努力可能是复杂和耗时的，但是对于受益于本公开的普通技术人员来说，仍然是设计、制作和制造的例行任务。24.本文提供了系统、方法和/或计算机程序产品实施例，和/或其组合和子组合，用于在源表频繁更新的情况下提高复制性能，并减小源表和副本表之间的可见性差距。实施例通过接收要被重放到副本表中的行的数据库事务的复制日志条目和事务提交日志条目来进行操作。基于复制日志条目的行id列值与副本节点处的副本表中的行的行id列值的比较，复制日志条目被并行重放到副本表。通过串行重放事务提交日志条目，数据库事务以被事务一致性地提交给副本表。因此，因为复制日志条目被并行重放，并且数据库事务被事务一致性地提交，所以数据库管理系统在源表和副本表之间执行更快的复制，这减小了源表和副本表之间的可见性差距。25.数据库管理系统是控制数据库中数据的组织、存储和检索的计算机软件程序的集合。数据库是数据的有组织的集合。数据库可以根据数据库模型来组织。数据库模型确定数据库的逻辑结构以及数据如何被存储、组织和操纵。例如，关系模型是一种流行的数据库模型。26.关系数据库模型将数据组织成表的集合，从中可以以多种不同的方式访问或重新装配数据，而不必重新组织这些表。每个表可以以列的形式包含一个或多个数据类别。每一行可以包含由列定义的类别的唯一数据实例。例如，业务订单条目数据库可以包括以姓名、地址、电话号码等列描述客户的表。每一行可以具有主键。主键是列或列的组合，被指定来唯一地标识行。27.每个表可以使用基于行的存储或基于列的存储来表示。在基于行的存储中，数据库管理系统在数据库中逐行存储数据。在基于列的存储中，数据库管理系统在数据库中逐列存储数据。28.使用基于列的存储的数据库管理系统通常比使用基于行的存储的数据库管理系统更快。当数据库管理系统对大数据存储库执行读取密集型操作时，通常出现这种情况。这是因为面向列的数据库管理系统在执行操作时仅需要扫描相关的列。相反，面向行的数据库管理系统必须扫描它正在读取的行的列。29.在操作可能仅在几个列上执行的情况下通常选择面向行的数据库系统。类似地，在表具有大量列、或者表具有大量行并且通常由数据库管理系统执行列操作的情况下可以选择面向列的数据库系统。30.可以使用数据库语言向数据库管理系统作出查询、插入或更新数据库的请求。数据库语言是用于作出对数据库管理系统的请求的计算机语言。例如，结构化查询语言(structuredquerylanguage，“sql”)是用于与数据库管理系统通信的数据库语言。31.数据库管理系统可以将查询、插入或更新数据库的请求作为数据库事务来执行。数据库事务由一个或多个独立的工作单元组成，每个工作单元向数据库读取或写入数据。数据库事务可以是读取或写入。读取数据库事务不会将数据写入数据库。例如，查询是读取数据库事务。写入数据库事务将数据写入数据库。例如，插入是写入数据库事务。32.数据库管理系统要么完整地执行数据库事务，要么根本不执行。如果在数据库事务的执行期间没有发生错误，则数据库管理系统将事务提交给数据库。数据库管理系统通过执行事务提交操作将数据库事务提交给数据库。事务提交操作使得数据库管理系统将数据库事务范围内的所有数据操纵应用于数据库。33.如果在数据库事务的执行期间发生错误，则数据库管理系统不将数据库事务范围内的任何数据操纵应用于数据库。在任何情况下，数据库管理系统都不能将部分完成的数据库事务提交给数据库。换句话说，数据库管理系统对数据库事务的执行总是使数据库处于一致状态(consistentstate)。34.数据库管理系统独立于其他数据库事务来执行数据库事务。此外，数据库管理系统检查执行数据库事务的结果满足现有的数据库约束。为了跟踪和管理每个数据库事务，数据库管理系统为每个数据库事务分配事务id。35.图1示出了根据示例实施例的具有表复制的分布式数据库系统100。分布式数据库系统100包括数据库管理系统102和分布式数据库104。36.数据库管理系统102是控制分布式数据库104中数据的组织、存储和检索的计算机软件程序的集合。数据库管理系统102将查询、插入或更新分布式数据库104中的数据的请求作为数据库事务来执行。37.分布式数据库104存储在源节点106和副本节点108中。源节点106和副本节点108可以是位于相同物理位置的独立计算机。源节点106和副本节点108也可以是分散在互连计算机的网络上的独立计算机。38.分布式数据库104是关系数据库。例如，分布式数据库104包括表a、b、c、d、e和f。分布式数据库104的表存储在源节点106和副本节点108中。39.存储在源节点106中的表是源表。源节点106中的源表包含分布式数据库104中的当前数据。如本领域普通技术人员将理解的，源节点106中的源表可以跨多个源节点存储。具体地，多个源节点中的每个源节点可以存储分布式数据库104中的源表的子集，并且专门对该特定子集进行操作。40.存储在副本节点108中的表是副本表。副本表是源节点106中的源表的副本。如本领域普通技术人员将理解的，副本表可以跨多个副本节点存储。41.数据库管理系统102可以指定存储在源节点106中的一个或多个源表，用于复制到副本节点108。数据库管理系统102然后在副本节点108处维护这些指定的源表的副本作为副本表。例如，数据库管理系统102将源节点106处的表e和f复制为副本节点108处的表e’和f’。换句话说，表e’和f’是表e和f的副本。如本领域普通技术人员将理解的，数据库管理系统102可以根据使用需求将源节点106中的所有源表或源表的适当子集复制到副本节点108。42.通过在副本节点108处维护副本表，数据库管理系统102可以在源节点106处的源表和副本节点108处的副本表当中分发读取数据库事务。换句话说，数据库管理系统102可以通过将读取数据库事务分发给副本表来执行负载平衡。这可以通过减少源节点106处的中央处理单元(centralprocessingunit，“cpu”)消耗和表争用来提高分布式数据库104的数据库管理系统102的整体读取数据库事务性能。43.数据库管理系统102可以向源表或副本表提交读取数据库事务。这是因为数据库管理系统102用副本节点108中的副本表的状态来维护源节点106中的源表的状态。44.数据库管理系统102必须向源节点106中的源表提交写入数据库事务。这是因为源节点106中的源表包含当前数据。数据库管理系统102不能将写入数据库事务直接发送到副本节点108中的副本表，因为源节点106中的源表最终将包含过时的数据。具体地，源节点106中的源表中的数据将变得与副本节点108中的副本表中的数据不一致。45.为了确保源节点106中的源表中的数据与副本节点108中的副本表中的数据一致，数据库管理系统102将源节点106中的源表处的所有写入数据库事务重放到副本节点108中的对应的副本表。这确保了副本表中的数据与对应的源表中的数据一致。46.数据库管理系统102可以同步或异步地将源表处的所有写入数据库事务重放到对应的副本表。在同步表复制中，数据库管理系统102同时更新源表和对应的副本表。换句话说，数据库管理系统102在与源表相同的事务边界期间更新副本表。这确保了副本表将包含与源表相同的数据。然而，同步表复制通常增加数据库管理系统102的写入数据库事务响应时间。这是因为副本表与对应的源表同时被数据库管理系统102更新。47.在atr中，数据库管理系统102不同时更新源表和副本表。相反，数据库管理系统102可以在在源表处提交写入数据库事务之后更新副本表。这意味着与源表相比，副本表可能包含过时的数据。然而，对于数据库管理系统102来说，atr通常比同步表复制招致显著更少的性能开销。48.虽然数据库管理系统102在执行atr时通常招致更少的性能开销，但是它通常会在表复制中引入显著的延迟。这是因为数据库管理系统102当在副本表处重放写入数据库事务时必须确保事务一致性。具体地，数据库管理系统102可能必须更慢地在副本表处重放写入数据库事务，以便确保事务一致性。49.图2示出了根据示例实施例的利用用于atr的事务和并行日志重放的分布式数据库系统。atr的该示例实施例通过并行重放写入数据库事务同时仍然确保事务一致性来最小化表复制延迟。具体地，该示例实施例中的数据库管理系统并行重放复制日志条目，同时串行化事务提交日志条目的重放。50.数据库管理系统并行重放写入数据库事务的技术问题是，当事务更新分布式数据库中副本表的相同行时确保事务一致性。在图2的示例中，对于图2的实施例，对于源表中的相同行，存在三个连续的写入数据库事务(例如，t1、t2和t3)。事务t1是第一个事务，其在源表中插入行。事务t2是第二个事务，其更新源表中的行。事务t3是最终事务，其也更新源表中的行。51.数据库管理系统必须在副本表处按顺序重放这三个数据库写入事务，以便确保事务一致性。例如，如果在事务t3之后重放事务t2，则副本表中的行的第1列的最终值将是“b”。然而，这将与源表中的行的第1列的值“c”不一致。52.在示例实施例中，数据库管理系统可以通过基于表id在副本节点处重放数据库写入事务来确保事务一致性。换句话说，数据库管理系统可以一次向副本表重放单个数据库写入事务。然而，如果数据库管理系统频繁地更新源表，则数据库管理系统可能必须将数据库写入事务串行重放到副本表。这可能会显著限制数据库管理系统可能重放数据库写入事务的速度。53.图2中的实施例通过在源表和副本表中创建行id列克服了这个技术问题。具体地，源表或副本表中的每一行都具有行id列。行id列可以具有小的长度。例如，行id列可以是8字节的长度。然而，本领域普通技术人员将理解，行id列可以具有不同的长度。54.在图2的实施例中，数据库管理系统针对对行的写入数据库事务递增源表中的该行的行id列的值。数据库管理系统在在副本表处重放写入数据库事务之后，类似地递增副本表的对应行的行id列的值。55.行id列值不同于行的主键列值，因为行id列的值在行被更新时递增。相反，行的主键列值从不更新。换句话说，行id列值是改变标识符，而主键列值是行标识符。56.在图2的实施例中，数据库管理系统可以用最小的性能开销为每个写入数据库事务递增行id列值。这是因为图2中实施例的两个方面。57.第一，在图2的实施例中，行id列值具有小的长度。具体地，行id列值的长度可以是8字节的长度。因为行id列值具有小的长度，所以数据库管理系统可以使用单个原子硬件指令来递增行id列值。例如，可以使用比较和交换(compare-and-swap)指令来递增行id列值。因为数据库管理系统可以以最小的开销执行单个原子硬件指令，所以数据库管理系统可以高效地递增行id列值。58.第二，数据库管理系统可以不需要记录行id列值的递增，因为下一个行id列值可以被重置为行id列中可用值的最大值。例如，数据库管理系统可以在数据库管理系统重启之后，将行id列值重置为行id列中可用值的最大值。59.图2中的实施例包括来自图1的分布式数据库系统104。分布式数据库104的表存储在源节点106和副本节点108中。源节点106和副本节点108也来自图1。60.源节点106包括写集合提取器202、复制日志生成器204、日志发送缓冲器206、日志发送器208和事务管理器210。写集合提取器202为源节点106中的源表的行上的每个写入数据库事务提取操作类型、表id、事务id、新的行图像(rowimage)、和行id列值。61.操作类型表示正在执行的写入数据库事务的类型。例如，写入数据库事务可以是插入、更新或删除操作。表id是唯一标识包含正被更新的行的表的值。数据库管理系统可以为每个源表分配唯一表id值。62.事务id是唯一标识要由数据库管理系统执行的写入数据库事务的值。事务id允许数据库管理系统确保执行写入数据库事务的顺序。例如，对于同一给定行，事务id为101的写入数据库事务必须在事务id为102的写入数据库事务之前执行。否则，该行将包含不准确的数据。63.复制日志生成器204为源表的改变的行生成复制日志条目。具体地，复制日志条目可以包含操作类型、表id、事务id、由写集合提取器202提取的改变的行的新的行图像。此外，复制日志条目可以包含一个或多个行id列值。64.对于插入操作，复制日志条目包含插入的行的新的行id列值。对于更新操作，复制日志条目包含更新操作之前行的旧的行id列值和更新操作完成之后的新的行id列值。对于删除操作，复制日志条目包含删除操作完成之前要删除的行的旧的行id列值。如本领域普通技术人员将理解的，复制日志条目可以以各种方式表示和存储。65.复制日志生成器204将生成的复制日志条目附加到日志发送缓冲器206。日志发送缓冲器206存储复制日志条目和事务提交日志条目。66.日志发送器208将日志发送缓冲器206中的复制写入日志条目和事务提交日志条目发送到副本节点108。例如，在源节点106和副本节点108通过计算机网络连接的情况下，日志发送器208通过计算机网络将日志发送缓冲器206中的复制日志条目发送到副本节点108。67.为了确保源节点106的源表处的事务一致性，事务管理器210执行事务提交操作以将写入数据库事务应用于源表。此外，当写入数据库事务被事务管理器210提交给源表时，事务管理器210创建事务提交日志条目。68.事务提交日志条目包括提交的写入数据库事务的事务id。事务管理器210将事务提交日志条目附加到日志发送缓冲器206。日志发送器208将日志发送缓冲器206中的事务提交日志条目发送到副本节点108，以将提交的写入数据库事务应用于副本表。69.在副本节点108处，复制日志接收器和分派器212从源节点106接收复制日志条目和事务提交日志条目。复制日志接收器和分派器212根据日志条目的类型将接收到的日志条目分派给并行日志重放器214或事务日志重放器216。70.如果接收到的日志条目是复制日志条目，则复制日志接收器和分派器212将复制日志条目分派给并行日志重放器214。并行日志重放器214可以包括多个队列，并且每个队列可以被分配复制日志条目用于重放。并行日志重放器214可以并行地同时重放分配给每个队列的复制日志条目。通过并行重放复制日志条目，并行日志重放器214可以最小化源节点106和副本节点108之间的表复制延迟。71.此外，并行日志重放器214可以并行重放相同副本表的两个复制日志条目。这是可能的，因为事务日志重放器216如下所述串行重放事务提交日志条目。72.如果接收到的日志条目是事务提交日志条目，则复制日志接收器和分派器212将事务提交日志条目分派给事务日志重放器216。这对于在并行日志重放器214并行重放复制日志条目期间确保事务一致性是必要的。73.图2的实施例通过施行两个条件来在并行日志重放器214并行重放复制日志条目期间确保事务一致性。第一，复制日志条目的重放结果可以仅在重放对应的事务提交日志条目之后在副本表处变得可见。换句话说，数据库管理系统必须在源表处所做的改变被实际保存在副本表处之前重放对应的事务提交日志条目。第二，复制日志条目可以独立于它们在源表处的执行顺序而并行重放，但是事务提交日志条目必须以与它们在源表处被执行的顺序完全相同的顺序重放。74.图2的实施例通过在事务提交重放器216处串行重放事务提交日志条目，并基于复制日志条目的行id列值在并行日志重放器214处并行重放它们，来确保满足这两个条件。具体地，并行日志重放器214在用于更新或删除操作的复制日志条目的旧的行id列值在副本表中可见之后，重放该复制日志条目。这确保了对相同行的两个冲突的写入数据库事务中的第二个写入数据库事务仅在其前一个写入数据库事务被重放和提交之后被重放。这是因为在提交第一个写入数据库事务之后，第一个写入数据库事务的结果(包括行id列值更新)在副本表处变得可见。并且当事务日志重放器重放与第一个写入数据库事务相同的事务id的事务提交日志条目时，第一个写入数据库事务被提交。如果并行日志重放器214重放受制于该条件的复制日志条目，则副本表中的行的行id列值用复制日志条目中包括的新的行id列值来更新(在更新日志条目的情况下)。75.因为图2中的实施例对冲突的写集合执行基于行id列值的动态检测，所以复制日志条目可以由复制日志接收器和分派器212不受限制地自由分派给并行日志重放器214处的多个队列。具体地，复制日志接收器和分派器212可以分派复制日志条目，而无需执行表级串行化。这可以显著增进复制日志重放性能，也将减少atr下源表和副本表之间的可见性差距。76.请注意，数据库复制在许多企业任务关键型数据库系统中用于实际目的，诸如灾难恢复、高可用性和负载平衡。复制选项的示例包括：77.·系统复制：通过将恢复重做日志运送到副本系统来复制整个数据库内容；主要用于灾难恢复或高可用性。78.·如前所述，atr系统可以通过将所选表的数据操纵语言(datamanipulationlanguage，“dml”)请求运送到副本系统来复制所选表的内容；主要用于多节点扩展(scale-out)部署中的负载平衡(即，将那些所选表的工作负载分发到多个节点，以便在处理工作负载时利用更多的计算资源)。79.·基于触发器的表复制：通过运送由结构化查询语言(“sql”)触发器提取的改变的行来复制所选表的内容；主要用于负载平衡，如atr。其中，当系统出于负载平衡的目的想要复制表或子表(子表分区或列)时，以及当系统想要对源系统实现更短的传播延迟和更低的开销时，atr可以是更好的选项。atr最初被设计为属于相同扩展系统实例的数据库节点当中的复制选项。80.然而，随着跨多个独立环境(例如，系统实例)的实时表复制的业务需求的增加，atr的设计和实现可以通过本文描述的实施例显著扩展。atr的这个新扩展版本可以被称为实时(或远程)表复制(real-timetablereplication或remotetablereplication，“rtr”)。通过这样的扩展，rtr可以服务于更广泛的数据库复制应用，包括以下两种示例情况。81.在第一种示例情况下，当系统必须处理动态变化的工作负载量时，弹性地伸缩系统容量是理想的。在没有预先购买假设最坏情况的潜在峰值工作负载的硬件的情况下，所需的处理容量可以替代地按需动态添加(利用经由云可用的硬件资源)。例如，图3是根据一些实施例的具有内部部署(on-premise)服务器310和云资源320两者的、使用利用弹性伸缩的rtr的系统300。如图表330所示，当负载增加得超过预定量时(例如，在年底或季度末)，可以分配来自云320的额外资源来补充内部部署服务器310。82.虽然这种架构在理论上利用atr是可能的，但rtr的优点在于：(1)它不需要源系统和副本系统之间的相同事务域，以及(2)副本系统不需要与源系统具有相同版本的数据库软件。作为结果，与源系统相比，副本系统可以利用不同的生命周期进行修补或升级，这为整个系统架构带来了更大的灵活性。例如，虽然传统的企业资源规划(enterpriseresourceplanning，“erp”)工作负载可以以内部部署版本的数据库软件(源系统)来服务，但新型的高级分析工作负载可以以更加新(和/或更频繁升级)的云版本的数据库软件(副本系统)来服务。83.在第二种示例情况下，与atr相比，利用rtr可以更有效地查询分散在多个远程系统中的数据。例如，当新的分析查询需要来自erp系统的数据库表和来自客户关系管理(customerrelationshipmanagement，“crm”)系统的其他数据库表两者时，这两个源可以单独查询，并在应用层以特定(ad-hoc)方式合并。例如，图4是根据一些实施例的使用来自多个远程系统(erp410和crm420)的高效数据虚拟化的rtr系统400。云环境430中的新的分析然后可以使用rtr来从两个远程系统410、420收集所需信息。通过对多个远程源系统410、420使用rtr，查询可以被高效地处理，而不涉及每次执行时的网络跳跃，并且还通过在数据库层本地处理查询而更加透明。根据一些实施例，这种基于rtr的实时数据虚拟化可以是云计算环境的特征。84.为了实现这种实时跨系统复制，与atr相比，rtr可能需要处理以下附加方面：85.·源系统和副本系统之间的独立事务域；86.·源系统和副本系统之间的独立元数据域；87.·源系统和副本系统之间潜在不同的软件二进制版本；和88.·源系统和副本系统之间的地理距离。89.根据一些实施例，rtr的关键架构特征可以包括：90.·确保严格事务一致性的行级并行重放；91.·数据定义语言(datadefinitionlanguage，“ddl”)复制和从一个或多个元数据更新日志条目在副本系统处重构ddl语句；92.·确保严格事务一致性的表级并行ddl复制；93.·支持多种复制对象粒度：表的集合、表、子表(一个或多个列、一个或多个分区)；94.·支持各种复制拓扑，包括从多个不同的远程源系统的复制(“n到1复制”)、到多个不同的远程副本系统的复制(“1到n复制”)以及其中第一副本表为第二副本表的源的链复制；95.·不依赖于典型的存储并转发(store-and-forward)机制的内存内(in-memory)日志复制；96.·基于推送和早期(push-basedandearly)日志运送，以减少源系统和副本系统之间的传播延迟。97.图5是根据一些实施例的整体实时表复制架构500。系统由主服务器520(以及相关联的恢复日志530和检查点540)和一个或多个副本服务器522(以及相关联的恢复日志560和检查点570)组成，主服务器520和副本服务器522中的每一个可以通过商品网络互连彼此连接，而不需要任何共享存储。所有写入请求通过嵌入在应用进程510中的数据库客户端库自动导向到主服务器520。在处理接收到的写入请求的过程期间，主服务器520生成对启用复制的表进行任何改变的写入请求的复制日志条目。请注意，rtr可以仅应用于表的选定列表，不一定要复制整个数据库。生成的复制日志条目经由网络互连被运送到副本522，然后在副本522处重放。通过重放传播的复制日志条目，副本522的内存内数据库副本被保持在可查询和事务一致状态。如果副本数据库状态满足给定的查询新鲜度要求，则数据库客户端库透明地将只读查询路由到副本。98.尽管rtr也可以被扩展用于高可用性或灾难恢复目的，但是rtr的一个目的是从被保留用于处理在线事务处理(on-linetransactionprocessing，“oltp”)式的事务工作负载的主服务器520卸载在线分析处理(on-lineanalyticalprocessing，“olap”)式的分析工作负载。此外，通过让相同的主服务器520具有多个副本522，rtr可以弹性地扩展olap式分析工作负载的可承受量。此外，通过在数据平台(诸如可从sap获得的)中将主表520配置为oltp偏好的内存内行存储，同时将其副本522配置为olap偏好的内存内列存储，rtr可以在公共数据库模式(schema)下和在单个事务域下最大化处理混合oltp和olap工作负载的能力。99.图6a示出了根据一些实施例的跨环境rtr600。具体地，具有两个租户数据库的源云系统610使用开放数据库连接(opendatabaseconnectivity，“odbc”)连接与具有两个租户数据库的副本云系统620通信。atr在相同环境中复制表，而rtr在两个不同的数据平台系统之间复制表。请注意，已经有类似的复制方法，称为环境变换(landscapetransformation，“slt”)。然而，slt是基于触发器的复制，会给源系统带来大量开销。rtr使用类似atr的日志发送方法来提供更好的性能和更轻的开销。出于安全原因，来自源系统610的更新日志可以通过直接的odbc连接(而不是使用trexnet协议)被传送到副本系统620。100.系统600将复制信息存储到系统表中。该信息也存储在内存内结构中(因此在常规条件下没有对系统表的直接访问)。对系统表的访问仅在服务器启动时发生，以便将数据加载到内存内结构以及ddl日志重放。在dml日志重放期间，仅使用内存内结构。初始化参数可能与indexserver.ini相关联，indexserver.ini包括：“元数据”(默认值＝false(假)，并且在复制之前对源系统和副本系统均设置为true(真))；“元数据”和“crossdb_atr_ddl_test_mode”(对于python和单元测试，默认值＝false)；等等。101.系统表可以持久保存有关远程表复制的复制信息。可以有五个系统表，一个用于源系统，并且其他的用于目标系统：102.·sys.remote_table_replica_sources_(保存在源系统处的复制关系信息)；103.·sys.remote_table_replica_targets_(保存在目标系统处的复制关系信息)；104.·sys.remote_table_replica_columns_(保存在目标系统处的源表的列信息)；105.·sys.remote_table_replica_indexes_(保存在目标系统处的源表的索引信息)；106.·以及sys.remote_table_replica_partitions_(保存在目标系统处的源表的分区规格(partitionspec)信息)。107.remote_table_replica_sources_表可以存储rtr信息作为源系统。这示出了该系统的哪些表被复制到哪个(哪些)副本系统。利用该表的内容，当服务器重启时,内存内rtr信息被恢复。remote_table_replica_targets_表可以存储rtr信息作为副本系统。这示出了该系统的哪些表是源系统的哪些表的副本。利用该表的内容，当服务器重启时，内存内rtr信息被恢复。remote_table_replica_columns_表可以存储rtr信息作为目标系统。该信息在ddl重放期间使用。利用该表的内容和从源系统接收的元数据重做日志，rtrddl重放器为副本表生成与列相关的ddl语句，如addcolumn(添加列)、altercolumn(更改列)或dropcolumn(丢弃列)。108.remote_table_replica_indexes_表可以存储rtr信息作为目标系统。该信息在ddl重放期间使用。利用该表的内容和从源系统接收的元数据重做日志，rtrddl重放器为副本表生成与索引和约束相关的ddl语句，如addconstraint(添加约束)或dropconstraint(丢弃约束)以及createindex(创建索引)或dropindex(丢弃索引)。109.remote_table_replica_partitions_表可以存储rtr信息作为目标系统。该信息在ddl重放期间使用。利用该表的内容和从源系统接收的元数据重做日志，rtrddl重放器为副本表生成与表分区相关的ddl语句，如partitionby(按..分区)、addpartitionfromothers(从其他添加分区)、droppartition(丢弃分区)等。110.根据一些实施例，内置过程可以与rtr创建、激活和去激活(在副本系统处由ddl语句触发)相关联。在副本系统处执行rtr相关的ddl语句期间，其调用相关的内置过程，其中这些内置过程经由远程源在源系统处执行。例如，在副本系统中执行“createreplica(创建副本)”ddl期间，可以在源系统处执行“sys.remote_table_replica_create_dev”过程，以用于源侧的rtr初始化。可以针对副本侧的“enablereplica(启用副本)”ddl在源侧执行“sys.remote_table_replica_enable_dev”，以及针对“disablereplica(禁用副本)”ddl执行“sys.remote_table_replica_disable_dev”。“sys.remote_table_replica_log_transfer_dev”用于将atr日志从源系统发送到副本系统，因此其在源侧调用，并且在副本侧执行。111.根据一些实施例，内存内结构可以与持久存储在系统表中的rtr信息相关联(并且相关信息也可以在内存内管理)。此内存内信息可在mdr::replicationinfo下管理，并通过rtrreplicationmanager访问。当使用mdr::replicationinfohelper类重启索引服务器(indexserver)时，也可以从系统表中还原此信息。在源系统中，当表上有改变(dml或ddl)时，复制管理器(replicationmanager)检查该表是否是rtr复制的。如果是，则复制管理器获得副本位置以发送atr日志。此外，获取相关的远程源名称和目标远程源名称来发送日志。利用源表oid，复制管理器可以获取以下信息：(多个)副本位置：以获得(多个)副本位置；远程源名称：以经由远程源发送atr日志；和(目标)远程源名称。因为rtr日志是经由远程源(而不是trexnet协议)发送的，所以复制管理器可能需要根据从m_logsender_map获取的副本位置获得远程源名称。哈希表可以用于从副本位置获得远程源名称(并且该哈希表也可以用于副本侧)。在副本系统中，接收到的atr日志包括源表oid和目标远程源名称。为了重放atr日志，atr日志重放器需要找到用于atr日志重放的目标表。112.关于rtr建立、激活和/或去激活，一些实施例可以提供远程源的准备。图6b至图6h是与rtr建立、激活和去激活相关联的方法。在通过rtr复制表之前，应当在源系统和副本系统两者处向彼此创建远程源。源系统可以具有到副本系统的智能数据访问(smartdataaccess，“sda”)远程源，而副本系统必须具有到源系统的sda远程源。这些远程源可以用于atr日志传送和复制激活/去激活。113.可以通过执行以下ddl语句在副本侧发起rtr复制：114.csreatetable<schema_name>.<table_name>like<remote_source_name_at_target>.<remote_schema_name>.<remote_table_name>asynchronousreplicausingremotesource<remote_source_name_at_source>115.图6b是根据一些实施例的rtr表创建ddl方法。rtr表创建ddl(voidqueryexecutor::create_remote_table_replica())中的步骤可以包括s611，以经由目标远程源(remote_source_name_at_target)调用sys.remote_table_replica_create_dev()，因此该内置过程在源系统处执行。在该内置过程中，可以在源系统处执行以下内部步骤：116.·获得源表的元数据(如json格式)和表组信息。117.·在此源表上创建视图。此视图的名称可以是_sys_remote_replica_source_{source_table_oid}。此视图用于rtr激活阶段期间的表数据同步。因为此数据同步是基于源表和副本表之间的“$rowid$”比较由“插入”和“删除”sql语句执行的，所以此视图包括源表的所有列加rowid(行id)列。因为“$rowid$”语法不能由副本侧在远程源上的虚拟表上使用，所以副本侧上的虚拟表不能直接创建在源表上。因此，此视图具有名为“_rowid_for_rep”的列，其选择源表的“$rowid$”列，并且副本侧上的虚拟表创建在此视图上，而不是直接创建在源表上。118.·将rtr信息插入系统表(sys.remote_table_replica_sources_)和内存内。119.·向复制管理器注册rtr信息(尚未激活，仅注册)。120.·使此源表的异步计划(asyncplan)无效，以便此新注册的复制可以被源表上的dml识别。121.在s612处，系统可以创建副本表，并将rtr复制插入系统表。利用通过上述内置过程获取的元数据，生成并执行相关的ddl语句，从而创建空的副本表(基于导入导出组件api)。系统也可以将rtr信息插入系统表。在副本系统中，不仅sys.remote_table_replica_targets_，sys.remote_table_replica_columns_、sys.remote_table_replica_indexes_和sys.remote_table_replica_partitions_表也被填充。这些系统表是稍后的ddl重放所需要的。122.在s613处，系统可以为远程源上的源表上的视图创建虚拟表。可以在由源系统处的内置过程创建的视图上创建虚拟表。请注意，在虚拟表上可能不允许“$rowid$”语法，因此系统可以在具有rowid列(作为_rowid_for_rep的名称)和源表的所有其他列的视图上创建虚拟表。在s614处，系统可以设置内存内rtr复制信息和atr复制管理器。123.图6c是根据一些实施例的rtr复制激活方法。请注意，可以在副本侧通过以下ddl语句触发rtr激活：124.altertable<schema_name>.<table_name>enableasynchronousreplica125.激活rtr副本可以在rtr去激活时段的某些时间之后执行。在rtr去激活时段中，复制被断开，因此不仅dml而且ddl仅能够对源表进行。因此，在重新激活atr日志传送之前，应当首先同步dml和ddl差异。126.rtr激活ddl(voidqueryexecutor::alter_table_enable_remote_table_replica())中的步骤可以包括s621，以同步源表和副本表的模式。请注意，源表的元数据(通过调用带有特定选项的sys.remote_table_replica_create_dev)被获取并与副本表的元数据进行比较。如果检测到存在元数据差异，则生成ddl语句并对副本表执行，以便表模式首先被同步。127.在s622处，系统可以在没有x锁的情况下同步源表和副本表的数据差异。根据一些实施例，通过执行2个sql语句来进行数据同步：128.(1)通过比较行的“$rowid$”，从副本表中删除不再存在于源表中的行；和129.(2)通过比较行的“$rowid$”，将仅存在于源表而不存在于副本表中的行插入副本表。130.如果rtr未激活时段的时间较长，则这种数据差异可能很大。不在源表上长时间保持x锁，系统可以首先在没有x锁的情况下同步数据。如果源表和副本表的列上有改变，则在执行上述sql时可能会发生错误，因为这些sql语句涉及(到源系统上的相关视图的)虚拟表。然后丢弃并重新创建源系统处的视图和副本系统处的相关虚拟表，并重试数据同步。131.在s623处，系统可以经由目标远程源调用sys.remote_table_replica_enable_dev()，因此该内置过程在源系统处执行。在该内置过程中，在源系统处执行以下内部步骤。请注意，当第二次数据同步正在进行时，源表上的x锁可能会阻止源表上的任何dml/ddl。系统还可以设置源系统上的复制管理器来将atr日志发送到副本系统。在s624处，系统可以再次同步源表和副本表的数据差异。因为源表上的x锁在源系统处被保持，所以源表上不能有任何dml/ddl。因此，在该第二次数据同步之后，源表和副本表具有完全相同的数据。通过s622处的第一次数据同步，应当不会有太多的数据差异，所以这次delete/insertsql的执行预期花费时间不长。在s625处，系统可以设置副本系统处的复制管理器来准备获取atr日志。在s626处，系统可以释放源表上的x锁。通过提交此ddl事务，在步骤3处获得的x锁将被释放，并且源表上的dml/ddl将被解除阻止。132.一些实施例可以优化激活逻辑以避免第二次差异同步并最小化x锁持续时间。例如，图6d是根据一些实施例的可以利用源表上的短x锁来实现rtr复制的工作流630。具体地，工作流630使用短持续时间的x锁来生成快照(takeasnapshot)并更新状态。根据一些实施例，然后利用ix锁来执行长时间运行的工作(longrunningjob)。请注意，在启用(enabling)状态下，运送的dml日志不应被丢弃，并且日志分派器应阻止传入的dml日志。关于初始同步，在锁被降级为ix之后，系统可以在副本表上应用ddl改变。此外，可以从源获得json，并且可以更新副本。此外，ddl不应在源上执行(被获取的ix锁阻止，并且在线ddl应在源表上被阻止)。根据一些实施例，日志分派器需要阻止分派dml日志。在将锁降级为ix模式之后，dml日志然后可以被运送到副本。在dml日志重放时，日志分派器可以用replicatableinfo(由副本表元数据生成)构建准备的语句。根据一些实施例，系统可能需要等待启用副本(enablereplica)提交，因为它应当看到最新的表元数据(通过applyddlchange更新)，然后可以清理replicatableinfo缓存。此外，日志分派器可以阻止分派，直到提交enablereplicaddl。请注意，如果enablereplicaddl失败，则启用(enabled)状态可能会回滚(例如，使用try/catch处理)。此外，状态启用(enabling)可能与atr情况下的语句路由有关(也就是说，rtr可能不需要此状态)。133.图6e是根据一些实施例的rtr表去激活方法。根据一些实施例，可以在副本侧通过以下ddl语句触发rtr去激活：134.altertable<schema_name>.<table_name>disableasynchronousreplica135.rtr去激活ddl(queryexecutor::alter_table_disable_remote_table_replica())内的步骤可以包括s641，以经由目标远程源调用sys.remote_table_replica_disable_dev()，因此该内置过程在源侧执行。在此过程中，在源侧执行以下内部步骤。系统可以设置源系统的复制管理器来停止向副本发送atr日志。如果针对disablereplica调用此过程，则它在此处返回。当针对droptable(丢弃表)调用此过程时，可以执行附加工作—这将结合“丢弃(drop)副本表”进行描述。在s642处，系统可以设置副本系统的复制管理器以停止重放atr日志。136.图6f是根据一些实施例的rtr表数据导出/导入方法。在s651处，在“创建(create)副本”和“启用(enable)副本”之间，支持手动导出/导入表。如果源表的内容非常大，通过“插入到…选择…(insertinto…select…)”语句进行数据同步可能需要很长时间。因此，在这种情况下，导出源表并导入到副本表中可以实现高效和快得多的初始数据同步。导出表应当使用“asbinary”(作为二进制)选项来进行(在s652处)，并且导入表应当使用“dataonly”(仅数据)选项来进行(在s653处)。步骤可以包括以下137.·在副本系统中，首先创建副本表：138.createcolumntable…like…asynchronousreplicausingremotesource…139.·在源系统中：140.exportschema.tableasbinaryinto…141.·(将导出的文件复制到副本系统之后)142.·在副本系统中：143.importschema.tableasbinaryfrom…withdataonly144.·在副本系统中，现在“启用副本”：145.altertableschema.tableenablereplica146.如果可用，一些实施例还可以支持自动表导出和/或导入。也就是说，在一些实施例中，enablereplica可以包括二进制导出、传送和/或导入的步骤。147.图6g是根据一些实施例的rtr副本表丢弃方法。请注意，当副本表被丢弃时，源系统和副本系统两者的rtr信息都被清除：droptable<schema_name>.<table_name>。当调用disablereplicaddl时，(queryexecutor::alter_table_disable_remote_table_replica())也再次用于droptable。但是对于这种情况，参数“calledatdroptable”为真，所以它多做了一项工作——清理副本系统和源系统两者上的rtr信息。步骤可包括s661，以经由目标远程源调用sys.remote_table_replica_disable_dev()，因此该内置过程在源侧执行。请注意，此过程的参数“calledfordroptarget”可以被设置为“真”。在此过程内，在源侧执行以下内部步骤：148.·从源系统的复制管理器中注销rtr信息。149.·从系统表(sys.remote_table_replica_sources_)中和也从内存内删除rtr信息。150.·使atrayncplan无效151.·如果此复制是此表的最后一次复制因此不再有更多副本，则丢弃视图(dropview)(_sys_remote_replica_source_{source_table_oid})。152.如果当副本表被丢弃时源系统不可用，则源系统中的rtr信息不能被清除并作为垃圾数据留下。因为当另一侧不可用时，rtr策略上不禁止表丢弃，所以源系统中的这种垃圾rtr信息可以被创建，但也可以在稍后通过变通方法清除。153.在s662处，系统可以从副本系统的复制管理器中注销rtr信息。在s663处，系统可以从系统表和内存内删除关于该表的rtr信息。最后，在s664处，系统可以丢弃该复制的虚拟表。154.图6h是根据一些实施例的rtr源表丢弃方法。请注意，当源表被丢弃时，源系统和副本系统两者的rtr信息都被清除：155.droptable<schema_name>.<table_name>156.当源表被删除时，不仅源系统的rtr信息，而且所有副本的rtr信息也被清理。(queryexecutor::drop_table_disable_remote_table_replicated())内的步骤可以包括在s671处，对于每个副本，经由远程源执行“altertablereplica_tabledisablereplica”，以便在每个副本侧执行该ddl。对于每个副本，rtr被去激活(例如，副本表没有被丢弃)。如果当源表被丢弃时一些副本系统不可用，则副本系统中的rtr信息不能被清除并作为垃圾数据留下。因为当另一侧不可用时，rtr策略上不禁止表丢弃，所以如果首先丢弃源表，则副本系统中的这种垃圾rtr信息可以被创建。157.对于每个副本，在s672处调用sys.remote_table_replica_disable_dev()，因此该过程在源侧执行。如果上面的“disablereplica”ddl被成功执行，则此过程可能已经被执行，所以这次的过程调用可能什么都不做。但是如果副本系统不可用，因此上面的“disablereplica”ddl没有被执行，则此过程调用至少可以在源侧清除rtr信息。158.一些实施例可以附加地支持利用智能数据集成(smartdataintegration，“sdi”)语法的rtr。请注意，rtr源于atr，它是用于实时直接/推送复制的，而相反sdi是订阅模型。即使系统可以保持不同的内部机制(rtr和sdi)，一些实施例也可以合并两者之间的sql接口，以便提供单个最终用户(end-user)抽象。因为rtr接口将被切换到sdi式的sql接口，所以用户可以使用具有相同接口的rtr。除了适配器名称之外，rtr可以遵循(follow)接口。用户可以通过在副本系统上执行{create|alter|drop}remotesubscription({创建|更改|丢弃}远程订阅)语句来创建、激活、去激活和/或丢弃远程表复制。为建立远程表复制，用户可以创建虚拟表、目标表、远程订阅，并在副本系统上激活复制。159.如果发生异常，其可以通过在副本系统处执行processremotesubscriptionexception(处理远程订阅异常)语句来处理。当来自虚拟表的远程源的适配器类型为hanaodbc时，createremotesubscription(创建远程订阅)语句进行远程表复制[0160][0161][0162]当满足以下条件时，可以支持rtr的createremotesubscription：(1)源对象类型为使用on子句的虚拟表，以及(2)目标对象类型为表。如果不满足这些条件，则系统可以抛出特征不支持错误。[0163][0164]请注意，对于远程表复制，withschemachanges选项可以总是为真(因为在没有模式同步的情况下rtr不能被激活)。[0165]激活复制(activatereplication)可以对复制进行激活。它首先禁用复制，然后将模式和记录与源表同步。在所有同步完成之后，它将启用复制。去激活复制(deactivatereplication)可以停止源系统和副本系统两者处的表复制。在视图m_remote_table_replicas中，复制状态将被标记为“disabledbyuser(被用户禁用)”。丢弃复制(dropreplication)可以丢弃副本信息，并将其改变为常规表。processremotesubscriptionexception语句可以让用户指示应当如何处理异常。[0166]图7示出了根据一些实施例的包括源系统710和与rtr日志重放相关联的副本系统720的架构700。请注意，rtr源表上的dml/ddl改变经由远程源，通过调用内置过程(sys.remote_table_replica_log_transfer_dev())由atr日志发送器传送到副本系统。在副本系统720处，传送的日志由atr重放器处理，因此改变被应用到副本表。[0167]对于dml改变，atr在日志传送和日志重放中添加了扩展应用程序接口(extendedapplicationprograminterface，“eapi”)层。图8是根据一些实施例的不同二进制版本之间的跨数据库atr800。对于更新源表810，eapi层之后是表更新、应用改变、从tu转换和基于eapi的atr日志。对于复制副本表820，eapi层之后是表更新和应用改变。对于ddl改变，atr仅发送在源系统上生成的原始mdredodata。[0168]在副本系统中，因为这些mdredodata不能直接应用于副本表，所以它们被解析并转换成ddl语句，并在副本表上执行，如图9所示，图9示出了根据一些实施例的如何复制副本表的900。具体地，mdredolog920之后是生成ddl语句和执行ddl。[0169]请注意，每个mdredodata可以包括描述元数据改变的javascript对象标记(javascriptobjectnotation，“json”)字符串。利用该json字符串，系统可以反向生成ddl语句。单个ddl语句可以在源系统处形成多个元数据重做日志，并且为了在副本系统上转换正确的ddl，应当收集所有相关的元数据重做日志。因此，在副本系统中的atr日志处理机中，接收到的ddl日志首先在每个表的ddl日志队列中排队，直到检测到事务提交日志。当其事务提交日志被传送时，排队的ddl日志被转换为ddl语句。[0170]图10表示根据一些实施例的数据定义语言日志重放1000。具体地，atr日志处理机将ddl日志发送到ddl日志处理机1020，并将dml日志发送到dml日志处理机1030。ddl日志重放过程可以如下：[0171]·当接收到第一个ddl日志时，创建副本表的日志队列。根据一些实施例，mdr::logqueue::getinstance()->register_queue()可以用于“voidtransactioncontainer::pushddllog()”。[0172]·ddl日志在此队列中排队，直到事务提交。根据一些实施例，mdr::logqueue::getinstance()->push()可以用于“voidtransactioncontainer::pushddllog()”。[0173]·当提交事务后，将利用此队列和(多个)重放ddl创建ddl重放器：voidtransactioncontainer::replayddllog()中的mdr::replayerreplayer(log_queue)和replayer.reply()[0174]·然后可以销毁日志队列。根据一些实施例，mdr::logqueue::getinstance()->unregister_queue()可以用于voidtransactioncontainer::replayddllog()。[0175]关于ddl生成，单个ddl语句可以形成多个ddl日志(元数据重做日志)。例如：[0176]·“altertablesrcadd(bint)”形成单个元数据重做日志。[0177]·“altertablesrcadd(cintgeneratedbydefaultasidentity(startwith10maxvalue100))”形成2个元数据重做日志。[0178]·“altertablesrcadd(iintunique)”形成3个元数据重做日志。[0179]因此，系统不能为每个单个元数据重做日志生成ddl语句，但必须检查来自队列的下一个元数据重做日志是否与前一个元数据重做日志相关。[0180]根据一些实施例，当rtr被重新激活时，模式同步可以与ddl重放相关联。例如，源表上的ddl可以通过传送重做日志重放到副本表。但是如果在rtr去激活期间源表上有ddl执行，则它的重做日志不会被传送。并且当rtr被重新激活时，系统可以不选择性地获得源表的旧的元数据重做日志(并且作为结果，系统不能以这种方式同步表元数据改变)。[0181]因此，当rtr被重新激活时，将比较源表和副本表的当前元数据，并将检测到的改变生成作为ddl并重放到副本表。图11示出了根据一些实施例的rtr激活和ddl语句的生成1100。具体地，源表1110的元数据可以与副本表1120的元数据进行比较。通过比较源表1110和副本表1120的元数据，模式同步如下进行：[0182]·如果源表和副本表的“_truncatedcount”不同，则截断副本表(并将源表的相同“_truncatedcount”值设置到副本表)。[0183]·丢弃/重命名副本表的索引(约束)。通过比较索引的oid，丢弃不存在于源表中的副本索引。如果索引的名称(不是以_sys_开头的系统生成的名称)不同，索引名称将被重命名(丢弃索引/约束比丢弃列更早进行，以便在重放ddl时不产生异常)。[0184]·丢弃/重命名/更改副本表的列。通过比较列的oid和名称，丢弃不存在于源表中的副本列。具有相同oid但不同名称或不同列信息的副本列被重命名和更改。[0185]·向副本表添加列(仅存在于源表中的列被添加到副本表)。[0186]·在副本表上创建索引或约束。仅存在于源表中的索引(约束)被添加到副本表(创建索引/约束应当在所有列被同步之后进行)。[0187]·如果源表和副本表的分区规格(partitionspec)不同，则更改分区。[0188]图12是可以由本文描述的任何实施例的一些或所有元素执行的方法。本文描述的流程图并不意味着步骤的固定顺序，并且本发明的实施例可以以任何可实践的顺序实践。请注意，本文描述的任何方法可以由硬件、软件、命令的自动脚本或这些方法的任何组合来执行。例如，计算机可读存储介质可以在其上存储指令，这些指令在被机器执行时产生根据本文描述的任何实施例的性能。[0189]在s1210处，系统可以接收复制日志条目和相关联的事务提交日志条目。复制日志条目和相关联的事务提交日志条目一起可以表示要被重放到副本表中的行的数据库事务。根据一些实施例，复制日志条目具有行id值，并且副本表中的行具有行id值。[0190]在s1220处，系统可以将复制日志条目分派给并行日志重放器，并将相关联的事务提交日志条目分派给事务提交日志重放器。然后，在s1230处，系统可以将复制日志条目的行id值与副本表中的行的行id值进行比较。在s1240处，基于比较，在并行日志重放器处重放复制日志条目。[0191]在s1250处，系统可以通过在事务日志重放器处重放相关联的事务提交日志条目来将数据库事务提交给副本表。根据一些实施例，数据库事务与具有事务一致性的行级并行重放相关联。此外，副本系统处的ddl语句的ddl复制和重构可以与一个或多个元数据更新日志条目相关联。[0192]图13是根据一些实施例的rtr显示1300。显示1300包括包含源系统和副本系统的rtr系统的图形元素1310。对图形元素的选择(例如，经由触摸屏或计算机鼠标指针1390)可以让操作员或管理员查看关于该元素的附加信息(例如，经由弹出窗口)和/或调整与该元素相关联的参数(例如，表映射或选择、副本系统细节等)。此外，选择“建立”图标1320可以让用户配置系统的操作。[0193]可以例如使用一个或多个众所周知的计算机系统(诸如图14所示的计算机系统1400)来实施各种实施例。计算机系统1400可以是能够执行本文描述的功能的任何众所周知的计算机。计算机系统1400包括一个或多个处理器(也被称为cpu)，诸如处理器1404。处理器1404连接到通信基础设施或总线1406。[0194]一个或多个处理器1404各自可以是图形处理单元(graphicsprocessingunit，gpu)。在实施例中，gpu是一种处理器，它是被设计成处理数学密集型应用的专用电子电路。gpu可以具有并行结构，该并行结构对于大数据块(诸如计算机图形应用、图像、视频等常见的数学密集型数据)的并行处理是高效的。[0195]计算机系统1400还包括通过(多个)用户输入/输出接口1402与通信基础设施1406进行通信的(多个)用户输入/输出(input/output，i/o)设备1403，诸如监视器、键盘、指点设备等。[0196]计算机系统1400还包括主(main或primary)存储器1408，诸如随机存取存储器(randomaccessmemory，“ram”)。主存储器1408可以包括一级或多级缓存。主存储器1408中存储有控制逻辑(即，计算机软件)和/或数据。[0197]计算机系统1400还可以包括一个或多个辅助存储设备或存储器1410。辅助存储器1410可以包括例如硬盘驱动器1412和/或可移动存储设备或驱动器1414。可移动存储驱动器1414可以是软盘驱动器、磁带驱动器、光盘驱动器、光存储设备、磁带备份设备和/或任何其他存储设备/驱动器。[0198]可移动存储驱动器1414可以与可移动存储单元1418交互。可移动存储单元1418包括其上存储有计算机软件(控制逻辑)和/或数据的计算机可用或可读存储设备。可移动存储单元1418可以是软盘、磁带、光盘、dvd、光存储盘和/或任何其他计算机数据存储设备。可移动存储驱动器1414以众所周知的方式从可移动存储单元1418读取和/或向可移动存储单元1418写入。[0199]根据示例性实施例，辅助存储器1410可以包括用于允许计算机程序和/或其他指令和/或数据被计算机系统1400访问的其他装置、工具或其他方法。这种装置、工具或其他方法可以包括例如可移动存储单元1422和接口1420。可移动存储单元1422和接口1420的示例可以包括程序盒(cartridge)和盒接口(诸如在视频游戏设备中找到的)、可移动存储器芯片(诸如eprom或prom)和相关联的插座、记忆棒和usb端口、存储器卡和相关联的存储器卡插槽、和/或任何其他可移动存储单元和相关联的接口。[0200]计算机系统1400还可以包括通信或网络接口1424。通信接口1424使得计算机系统1400能够与远程设备、远程网络、远程实体等的任何组合(单独地和共同地由附图标记1428引用)进行通信和交互。例如，通信接口1424可以允许计算机系统1400通过通信路径1426与远程设备1428进行通信，通信路径1426可以是有线和/或无线的，并且可以包括lan、wan、互联网等的任何组合。控制逻辑和/或数据可以经由通信路径1426传输到计算机系统1400和从计算机系统1400传输。[0201]在实施例中，包括其上存储有控制逻辑(软件)的有形计算机可用或可读介质的有形装置或制品在本文中也被称为计算机程序产品或程序存储设备。这包括但不限于计算机系统1400、主存储器1408、辅助存储器1410和可移动存储单元1418和1422，以及体现上述中的任意组合的有形制品。当由一个或多个数据处理设备(诸如计算机系统1400)执行时，这种控制逻辑使得这种数据处理设备如本文所述进行操作。[0202]基于包含在本公开中的教导，对于(多个)相关领域的技术人员来说，如何使用不同于图14所示的数据处理设备、计算机系统和/或计算机架构来形成和使用本发明的实施例将是显而易见的。具体地，实施例可以用不同于本文描述的那些的软件、硬件和/或操作系统实现来操作。[0203]因此，实施例可以以安全、自动和准确的方式提供实时跨环境数据库表复制。此外，内部部署系统的弹性伸缩可以用混合云资源来补充。此外，可以从多个远程系统和/或表(其可以与不同的二进制软件版本相关联)提供高效的数据虚拟化。[0204]下面示出了本发明的各种附加实施例。这些并不构成所有可能实施例的定义，并且本领域技术人员将理解，本发明可应用于许多其他实施例。此外，尽管为了清楚起见简要描述了以下实施例，但是本领域技术人员将理解如何对上述装置和方法进行任何改变(如果需要)以适应这些和其他实施例和应用。[0205]尽管本文已经描述了特定的硬件和数据配置，但是请注意，根据本发明的一些实施例，可以提供任何数量的其他配置(例如，与本文描述的数据库相关联的信息中的一些可以被组合或者存储在外部系统中)。此外，尽管一些实施例关注于特定类型的应用和服务，但是本文描述的任何实施例都可以应用于其他类型的应用和服务。此外，本文所示的显示仅作为示例提供，并且可以实施任何其他类型的用户界面。[0206]仅出于说明的目的，已经根据几个实施例描述了本发明。本领域技术人员将从该描述中认识到，本发明不限于所描述的实施例，而是可以利用仅受所附权利要求的精神和范围限制的修改和变更来实践。当前第1页1 2 3 当前第1页1 2 3