CN109478183A - 数据库中的存储器中单元的版本化和非破坏性服务 - Google Patents

数据库中的存储器中单元的版本化和非破坏性服务 Download PDF

Info

Publication number
CN109478183A
CN109478183A CN201780043813.0A CN201780043813A CN109478183A CN 109478183 A CN109478183 A CN 109478183A CN 201780043813 A CN201780043813 A CN 201780043813A CN 109478183 A CN109478183 A CN 109478183A
Authority
CN
China
Prior art keywords
imu
data
outmoded
data item
copy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201780043813.0A
Other languages
English (en)
Other versions
CN109478183B (zh
Inventor
A·穆里克
N·穆克尔杰
S·哈塞
T·拉希里
J·洛伊扎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Oracle International Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oracle International Corp filed Critical Oracle International Corp
Publication of CN109478183A publication Critical patent/CN109478183A/zh
Application granted granted Critical
Publication of CN109478183B publication Critical patent/CN109478183B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2315—Optimistic concurrency control
    • G06F16/2329—Optimistic concurrency control using versioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/84—Using snapshots, i.e. a logical point-in-time copy of the data

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

提供了用于数据库中的存储器中单元的非破坏性版本化的技术。数据库服务器生成并维护反映直到第一快照时间对镜像数据集做出的更改的第一IMU；以及反映直到第二快照时间对镜像数据集做出的更改的第二IMU。在第一时段期间，数据库服务器通过存储第一陈旧性元数据来响应对镜像数据中的第一数据项的更新，第一陈旧性元数据指示第一IMU中的第一数据项的副本是陈旧的。在第二时段期间，数据库服务器通过存储第二陈旧性元数据来响应对镜像数据中的第二数据项的更新，第二陈旧性元数据指示第二IMU中的第二数据项的副本是陈旧的。数据库服务器通过访问第一IMU或第二IMU来响应请求。

Description

数据库中的存储器中单元的版本化和非破坏性服务
技术领域
本文描述的实施例一般而言涉及数据库系统，并且更具体而言，涉及与生成和维护存储器中(in-memory)数据库对象的多个版本相关的技术，该存储器中数据库对象对以另一种格式驻留在持久性存储装置中的数据进行镜像。
背景技术
数据库系统通常将数据持久性地存储在盘块中。通常，在每个盘块内，数据以行为主的格式进行布置。即，一行中的所有列的值后面跟着下一行的所有列的值。为了提高性能，一些盘块可以被高速缓存在易失性存储器内的缓冲区高速缓存中。从易失性存储器访问(access)数据比从盘访问数据要快得多。但是，即使在易失性存储器内，数据仍然是处于行为主的盘块格式，这对于某些类型的数据库操作不是最佳的。
与行为主的盘块相比，列式格式对于存储器中的查询处理具有许多吸引人的优点，诸如高速缓存局部性和压缩性。因此，一些数据库服务器现在采用新的表类型用于以列为主的格式持久性地存储数据。当列为主的格式的数据被读取到易失性存储器中时，它可以用于比如果数据存储在行为主的盘块时将可能更高效地处理某些查询。
代替在每个项的基础上加载各个数据项，可以将整个数据库对象或其部分预先加载到易失性存储器中。用于将整个数据库对象或其选定部分加载到易失性存储器中以加速查询处理的各种方法在于2014年7月21日提交的编号为14/377，179、标题为“Mirroring，InMemory，Data From Disk To Improve Query Performance”的美国专利申请(“镜像申请)中进行了描述，该专利申请的内容被整体并入本文。该申请描述了以与那些相同对象在盘上具有的格式不同的格式将数据库对象或其部分存储在易失性存储器中。例如，对象的存储器中副本可以以列为主的格式存储，而持久性副本以行为主的格式存储。使用行为主数据最高效处理的查询可以使用持久性副本，并且使用列为主数据最高效处理的查询可以使用存储器中副本。
当维护数据集的多个副本并且该多个副本用于响应数据库请求时，数据库服务器必须确保维持事务一致性。例如，当在持久性数据集中更新特定项的副本作为数据库事务的一部分时，数据库服务器可以通过也更新存储器中数据中的特定项作为同一事务的一部分来维持事务一致性。当存储器中数据和持久性数据在事务上被同步时，无论是使用从存储器中数据还是从持久性数据获得的数据项来处理查询，查询的结果集都将是相同的。
遗憾的是，由于在被复制的系统之间发生的滞后，这种技术并不能很好地工作。具体而言，在任何给定的时间点，在复制品(replica)中的一个复制品处做出的一些更改将尚未被应用到另一个复制品。因此，在复制机制中固有的滞后可能导致不可预测的伪像，并且可能导致不正确的结果。此外，使存储器中数据保持最新以及对持久性数据进行所有更改可能是昂贵的。例如，存储器中数据可能处于压缩格式，该压缩格式需要解压缩整个列式数据集合以执行任何对应的更新。
用于Oracle数据库存储器中(DBIM)的另一种技术存储存储器中列式单元(IMCU)。IMCU是截至某个时间点的基础数据(underlying data)的快照(snapshot)，并且对它们的访问最适合于分析查询。任何DML活动(例如，插入、更新或删除行)都被记录为单元内的无效行，从而避免同步的存储器消耗和处理开销。扫描IMCU的查询从IMCU检索有效数据，并从IMCU以外的源获取与无效记录对应的行。另一个源可以是，例如，IMCU的存储器中日志、缓冲区高速缓存中高速缓存的块、或从盘中检索到的块。随着IMCU中无效行数的增加，数据库必须更频繁地从IMCU以外的源检索项(item)。这种IMCU外的项检索增加了IMCU的扫描延迟。最终，IMCU可能包含许多无效项，导致使用IMCU执行扫描不再高效。为避免这种情况，当无效数量超过阈值时，可以用有效数据重建或重新填充IMCU。
在重建IMCU之后，所有数据截至第二时间点是有效的。但是，IMCU重新填充是耗时的处理，在该处理期间IMCU不可用。即，现有的IMCU在其重新开始之前首先针对查询被标记为离线。只有在重新填充过程完成时，才使新的IMCU可用于查询。重新填充期间IMCU的不可用性意味着其中包含的所有项(无论是否无效)都必须从另一个源(诸如持久性数据块)检索，即使访问另一个源更低效。这导致在非平凡(non-trivial)时间窗口上扫描延迟的退化。当对同一个表同时发出多个查询时，退化恶化，因为这些查询中的每个查询会受到IMCU不可用性的影响。在密集的在线事务分析处理(OLTAP)环境中，导致对基础数据的更新的大量DML活动可能需要对应的IMCU以进行频繁的重新填充。这将导致针对大量查询的IMCU的不可用性，从而影响性能。
本部分中描述的方法是可以追求的方法，但不一定是先前已经构思或追求的方法。因此，除非另有说明，否则不应认为本部分中描述的任何方法仅仅因为它们被包含在本部分中就有资格作为现有技术。
附图说明
在附图中：
图1是根据实施例的数据库系统的框图，该数据库系统同时维护易失性存储器中的镜像格式数据和持久性存储装置中的持久性格式数据；
图2A是用于示例的表的框图；
图2B是根据实施例的如何可以在持久性数据集和一组或多组存储器中版本的镜像数据集中同时维护镜像数据集中的数据项的副本的框图；
图3是根据实施例的针对镜像数据集和对应的陈旧性(staleness)元数据的一组存储器中数据集的框图；
图4是图示根据实施例的用于生成和维护镜像数据集的存储器中版本的组的处理的流程图；
图5是图示根据实施例的用于为镜像数据集生成新的存储器中版本的处理的流程图；
图6是图示根据实施例的用于通过访问第一存储器中数据集、第二存储器中数据集或持久性数据集来响应与目标快照时间相关联的请求的处理的流程图；
图7是图示根据实施例的用于通过访问持久性数据集或可用的存储器中数据集的集合中的一个来响应与目标快照时间相关联的请求的处理的流程图；
图8是图示根据实施例的用于从可用的存储器中数据集的集合中移除存储器中数据集的处理的流程图；
图9是图示可以用于实现本文描述的技术的计算机系统的框图。
具体实施方式
在以下描述中，出于解释的目的，阐述了许多具体细节以便提供对实施例的透彻理解。但是将显而易见的是，可以在没有这些具体细节的情况下实践这些实施例。在其它实例中，以框图形式示出了众所周知的结构和设备，以避免不必要地模糊实施例。
总体概述
其项目既(a)以一种格式存储在持久性存储装置上，又(b)以另一种格式存储在易失性存储器中的数据集合在本文中被称为“镜像数据集”。镜像数据集的存储器中版本在本文中被称为存储器中单元(in-memory unit)或“IMU”。本文描述的技术用于为单个镜像数据集生成、维护和使用多个IMU。即，代替维护镜像数据集的单个存储器中副本，为同一镜像数据集维护多个存储器中副本。镜像数据集的IMU在本文中被统称为镜像数据集的“存储器中组(in-memory-group)”。
存储器中组中的每个IMU包括与存储器中组相关联的镜像数据集的每个数据项的副本。例如，假设特定的镜像数据集包括表T的列A、B和C。在这些情况下，该镜像数据集的存储器中组将包括一个或多个IMU，该一个或多个IMU中的每个IMU将包括表T的列A、B和C的所有项。
在一些实施例中，存储器中组中的每个IMU具有对应的快照时间。IMU的快照时间指示IMU中数据项的副本最新时的时间。即，特定IMU中的数据项的副本反映了截至快照时间已经对这些数据项做出和提交的所有更改。换句话说，每个IMU是截至对应快照时间其镜像数据集的快照映像。
在一些实施例中，在任何给定时间，镜像数据集的一个IMU被指定为镜像数据集的“当前IMU”。例如，第一IMU可以被指定为第一时间段的镜像数据集X的当前IMU，第一时间段诸如直到确定应该重新填充存储器中数据为止。当执行重新填充时，生成镜像数据集X的第二IMU并且该第二IMU成为镜像数据集X的当前IMU。
在一些实施例中，当IMU是当前IMU时，陈旧性元数据与IMU相关联地存储。针对特定IMU的陈旧性元数据识别特定IMU中在对应时段期间已被更新的数据项。在当前时段期间，当镜像数据集中的数据项被更新时，陈旧性元数据可以与当前IMU相关联地存储，以指示当前IMU中的数据项的副本是陈旧的，并且不再与数据项的持久性副本同步。
当维护镜像数据集的多个IMU时，即使当前IMU不可用，诸如当正在重新填充当前IMU时，数据库服务器也可以使用一个或多个非当前IMU来处理查询。根据一个实施例，数据库服务器至少部分地基于(a)与查询相关联的目标快照时间，以及(b)与可用IMU相关联的快照时间来确定要访问以执行查询的适当数据源。
例如，如果请求的目标快照时间落在与特定IMU对应的时段中，则该特定IMU及其陈旧性元数据可以用于响应该请求。如果陈旧性元数据指示特定IMU中的特定数据项是陈旧的，则数据库服务器可以从另一个源访问这些特定数据项的最新版本，该另一个源诸如但不限于一个或多个持久性数据块、缓冲区高速缓存、事务日志和/或另一个事务记录。因此，即使目标快照时间是在生成镜像数据集的当前IMU之前，维护存储器中组也允许数据库服务器使用IMU来准确地响应查询。
总体体系架构
图1是根据一些实施例的数据库系统的框图。参考图1，数据库系统100包括易失性存储器102和持久性存储装置110。易失性存储器102通常表示由数据库系统使用的随机存取存储器，并且可以由任何数量的存储器设备来实现。通常，当发生故障时，易失性存储器102中存储的数据丢失。
持久性存储装置110通常表示任何数量的持久性存储设备，诸如磁盘、闪存(FLASH)存储器和/或固态驱动器。与易失性存储器102不同，存储在持久性存储装置110中的数据在发生故障时不会丢失。因此，在故障之后，持久性存储装置110中的数据可以用于重新填充在易失性存储器102中丢失的数据。
在易失性存储器102内，数据库服务器120执行由一个或多个数据库应用(未示出)提交给数据库服务器的数据库命令。通常，服务器(诸如数据库服务器)是计算资源(诸如存储器、节点和用于执行集成软件组件的节点上的处理)的分配和集成软件组件的组合，其中软件和计算资源的组合专用于代表服务器的客户端提供特定类型的功能。数据库服务器管理并促进对一个或多个数据库的访问，处理客户端访问一个或多个数据库的请求。
数据库服务器在持久性存储装置110中维护持久性格式数据108。持久性格式数据108驻留在持久性存储设备110中。持久性格式数据108可以包括例如行为主的盘块。虽然行为主的盘块用于说明的目的，但是持久性格式结构可以采取任何形式，诸如列为主的盘块、混合压缩单元(其中一些数据以列为主的格式进行布置，并且其它数据以行为主的格式进行布置)、另一种格式或其任何组合。
在一些实施例中，易失性存储器102还包括持久性格式数据的高速缓存106。在高速缓存106内，数据以基于数据在持久性格式数据108内驻留的格式的格式进行存储。例如，如果持久性格式是行为主的盘块，则高速缓存106可以包含行为主的盘块的高速缓存副本。例如，高速缓存106可以包括截至特定时间为当前的持久性格式数据108的一部分的副本，诸如持久性存储装置110中的一个或多个盘块。
另一方面，镜像格式数据104处于与持久性格式无关的格式。例如，在其中持久性格式是行为主的盘块的情况下，镜像格式可以是列为主的压缩单元。因为镜像格式与持久性格式不同，因此镜像格式数据104通过对持久性格式数据执行变换来产生。这些变换既在易失性存储器102被初始地用镜像格式数据104填充时发生(无论在启动时还是根据需要时)，又在易失性存储器102周期性地或者在发生故障之后用镜像格式数据104重新填充时发生。
重要的是，镜像格式数据104的存在对于向使用镜像格式数据104的数据库服务器提交数据库命令的数据库应用是透明的。例如，被设计为与专门以持久性格式数据108操作的数据库系统交互的那些相同应用可以在不加修改的情况下与除了持久性格式数据108之外还维护镜像格式数据104的数据库服务器交互。进一步地，对那些应用透明的是，该数据库服务器可以使用镜像格式数据104来更高效地处理那些数据库命令中的一些或全部。因为镜像格式数据104仅仅是持久性格式数据中的一些数据的镜像(虽然以不同格式)，因此镜像格式数据104中包含的所有数据项也是持久性格式数据。因此，对于需要访问镜像数据集中的数据项的任何查询，数据库服务器可以选择从镜像格式数据104、从持久性格式数据、或者部分地从镜像格式数据104并且部分地从持久性格式数据来获得该数据。
镜像格式数据104可以对所有持久性格式数据108或其子集进行镜像。在一些实施例中，用户可以指定对持久性格式数据108的哪个部分进行镜像。可以在任何粒度(granularity)级别做出镜像数据集的指定，并且可以指定一个或多个镜像数据集。如本文所使用的，术语“级别(level)”是指粒度级别。例如，可以至少在以下粒度级别做出对哪些持久性格式数据108进行镜像的指定：
·整个数据库
·指定的表
·指定的列
·指定的行范围
·指定的分区
·指定的段
·指定的扩展区(extents)
·其任何组合(例如指定的列和分区)
如将在下文中进行描述的，镜像数据被转换为镜像格式并且作为镜像格式数据104存储在易失性存储器中。因此，当查询需要镜像数据时，数据库服务器可以选择从持久性格式数据108或者从镜像格式数据104提供数据。转换和加载可以在数据库启动时发生，或者以懒惰(lazy)或按需的方式发生。当查询需要未被镜像的数据时，数据库服务器不能选择从镜像格式数据104获得数据。
镜像格式数据
出于解释的目的，将假设由数据库系统100管理的数据库包括图2A中所示的表200。表200包括三列C1-C3和六行R1-R6。虽然图2A中图示的表200描绘了数据如何在逻辑上被组织，但是数据被物理存储的实际格式可能非常不同。
图2B图示了如何可以在数据库系统100中物理地组织驻留在表200中的数据的实施例。在本示例中，表200的数据存储在三个行为主的盘块202、204和206中。块202存储行R1的所有列的值，接着存储行R2的所有列的值。块204存储行R3的所有列的值，接着存储行R4的所有列的值。最后，块206存储行R5的所有列的值，接着存储行R6的所有列的值。
这些盘块中的一些盘块的副本可以临时存储在高速缓存106中。在图2B所示的示例中，块204的高速缓存副本212驻留在高速缓存106中。可以使用各种高速缓存管理技术中的任何一种来管理高速缓存106，并且本文描述的实施例不限于任何特定的高速缓存管理技术。通常，这些技术试图在易失性存储器102中保留最有可能在不久的将来被请求的盘块的副本。因此，当高速缓存106用完空间时，较不可能被请求的盘块的高速缓存副本被更可能被请求的块的副本替换。
与高速缓存106中的数据相比，镜像格式数据104未以基于持久性格式的方式被格式化。可以为存储在数据库中的所有数据库对象或数据库对象的子集和/或其任何部分维护镜像格式数据104。例如，可以为表的一个或多个分区和/或列来维护镜像格式数据104。
在所示的示例中，仅表200的列C1和C3被镜像，因此仅列C1和C3中出现的数据存储在镜像格式数据104中。在这种情况下，由于镜像格式数据104不包括表200的列2的列向量，因此镜像格式数据104对持久性格式数据108的子集进行镜像。需要来自列C2的值的查询必须从持久性格式数据108获得这些值。因此，给定示例中的镜像数据集包括列C1和列C3。
镜像数据也可以是多个镜像数据集的组合。多个镜像数据集的粒度可能不同。例如，镜像数据集的粒度可以是表、列、行范围、分区、段、扩展区或其它粒度级别。例如，可以为列C1和列C3维护不同的IMU结构。在给定示例中，镜像格式数据104包括针对包括来自表200的列C1的值的镜像数据集的存储器中组220。镜像格式数据104也包括针对包括来自表200的列C3的值的特定镜像数据集的存储器中组230。每个存储器中组220和230包括对应的镜像数据集的一个或多个IMU 222-224和232-234的集合。镜像数据集的IMU版本将在下文中更详细地描述。
可以压缩镜像格式数据104或其部分。但是，根据一些实施例，并非所有镜像数据需要以相同方式或相同程度来压缩。例如，如果确定频繁地使用来自表200的列C1的数据，并且不频繁地使用来自列C3的数据，则列C1的对应IMU 222-224中的镜像数据项的副本可以被轻微压缩，而列C3的对应IMU 232-234中的镜像数据项数据的副本可以被高度压缩。
在一些实施例中，在每个IMU的基础上应用压缩方案。压缩算法和/或应用于每个部分的算法所使用的压缩程度可以由用户指定，或者可以由数据库服务器基于各种因素来自动确定。可能的压缩算法包括但不限于基于字典的压缩、行程长度编码(run-lengthencoding，RLE)、Ozip压缩等。Ozip压缩在于2014年3月19日提交的编号为61/955,574的美国临时专利中描述，该专利的内容通过引用并入本文。由数据库服务器用于确定镜像格式数据104的每个部分如何被压缩的因素可以包括，例如，访问每个部分的频率、以及该部分中有多少数据，以及有多少易失性存储器可用。通常，镜像格式数据的一部分越频繁地被访问，数据就被压缩得越少。作为另一个一般性规则，可用于存储镜像格式数据的易失性存储器越少和/或镜像格式数据的部分的尺寸越大，压缩就越高。
存储器中单元
如上所述，镜像格式数据作为存储器中单元(IMU)在易失性存储器中进行维护。如何可以实现IMU的一个示例是作为存储器中压缩单元(IMCU)。IMCU在镜像申请中详细描述。以下描述的示例实施例参考IMU，但是可以应用于与镜像数据集合对应的任何存储器中数据集。
IMU与快照时间相关联。特定IMU中的数据项的副本反映了直到相关联的快照时间对数据项做出和提交的更改。IMU的一个示例是在Oracle DBIM中实现的IMCU。以下描述的示例实施例参考IMU，但是可以应用于与镜像数据集合对应的任何IMU。
如本文所使用的，术语“快照时间”是指可用于唯一确定任何两个快照时间之间的次序的任何逻辑时间戳数据。在一些实施例中，使用共享逻辑时钟服务来生成快照时间，该逻辑时钟服务将逻辑时间戳指派给动作、记录、更新、请求或其它事件。逻辑时间戳可以基于实际时间、次序或可用于指示次序的任何其它数据。如本文所使用的，术语“时间”可以指实际时间和/或逻辑时间。
在一些实施例中，存储器中组220和230每个包括与特定镜像数据集对应的IMU集合。在本示例中，IMU 222是包括来自表200的C1的值的镜像数据集的第一IMU V1。IMU 222反映直到第一快照时间对特定镜像数据集中的数据项做出的更改。类似于IMU 222，IMU224是包括来自C1的值的第n个IMU Vn。但是，与UMU 222不同，IMU 224反映直到第n个快照时间对数据项做出的更改。
同样地，IMU 232是包括来自表200的C3的值的镜像数据集的第一IMU V1。IMU 232反映直到第一快照时间对数据项做出的更改。IMU 234是包括来自C3的值的镜像数据集的第m个IMU Vm。IMU234反映直到针对组的第m个快照时间对数据项做出的更改。在一些实施例中，各种镜像数据集不一定同时被重新填充。因此，存储器中组220的IMU 222的第一快照时间不必与存储器中组230的IMU232的第一快照时间是相同的快照时间。
可以预先确定、自动确定或动态确定镜像数据集的IMU的数量。此外，对于不同的镜像数据集，该数量可能不同。在一些实施例中，当遇到限制条件时，诸如当检测到存储器压力时，减少IMU的数量。对于每个存储器中组220和230，IMU的数量可以是不同的。为特定镜像数据集维护的IMU的数量可以基于一个或多个因素，诸如但不限于可用的存储器、更新的频率、访问的频率、其它陈旧性度量、重新填充的频率、其它因素或其任何组合。
在一些实施例中，实现一个或多个保留策略。如本文所使用的，术语“保留策略(retention policy)”是指用于确定是否应该保留一个或多个IMU的任何规则、启发式方法或其它指导方针。IMU的保留将在下文中更详细地描述。
根据一些实施例，即使镜像格式数据使用与持久性格式数据不同的格式，镜像格式数据也以与持久性格式数据的组织对应的方式进行组织。例如，在持久性存储装置110中，持久性格式数据可以存储在驻留在扩展区中的块中，而扩展区进而被组织为段。在这些情况下，在易失性存储器102内，可以基于数据所属的扩展区和/或段来组织镜像格式数据104。因此，列向量220可以被划分为向量部分，每个向量部分与扩展区和/或段的特定范围相对应。
在扩展区内，数据通常按rowid排序。类似地，在一些实施例中，镜像格式数据104基于rowid进行排序。在一些实施例中，一个或多个IMU 222-224和232-234被存储为列向量，每个列向量存储一系列连续值的版本。例如，列向量222-224中的值基于用于在块202、204和206中对持久性格式数据进行排序的相同rowid进行排序。在替代实施例中，镜像格式数据104中的一些或所有数据项在镜像格式数据104内没有按rowid进行排序。
陈旧性元数据
如本文所使用的，术语“陈旧性元数据”是指指示镜像数据集的IMU中的哪些特定值不再最新的数据。例如，当更新特定镜像数据项的持久性副本时，当前IMU中对应的存储器中副本变得陈旧。更新可以包括更改、插入、删除或以其它方式修改一个或多个数据项的操作。在一些实施例中，针对镜像数据集的每个IMU，在存储器中维护陈旧性元数据，但仅针对当前IMU更新陈旧性元数据。即，在每个特定时间段期间发生的更改被记录在针对镜像数据集的特定IMU的陈旧性元数据中。
IMU1的生成可能涉及从另一个源读取一个或多个数据项。例如，数据项可以从持久性存储装置中的持久性格式副本、驻留在高速缓存中的持久性格式副本、来自非当前IMU的镜像格式副本或其任何组合获得。当不存在当前IMU时，在不使用IMU的情况下生成IMU。当确实存在当前IMU时，当前IMU的非陈旧部分可以用于生成或重新填充下一个IMU。在一些实施例中，使IMU不可用于响应查询，直到在完成时间(例如，IMU1的tC1)完成IMU的生成为止。
如本文所使用的，术语“陈旧性元数据单元”(SMU)是指陈旧性元数据集合，其指示特定IMU中的数据项的副本是否陈旧。在一些实施例中，SMU是位向量，其中SMU中的有序位对应于包括列向量的IMU中的有序值。位向量中的值被设置为“1”以指示在IMU的快照时间之后的某个点处在对应于SMU的IMU中已经更新了与该位对应的行或条目。例如，参考图3，SMU1是位向量，其指示IMU1中的一个值是陈旧的。更具体而言，SMU1的第三位被设置为1，从而指示IMU1中的第三个值(R3C11)是陈旧的。即，R3C11的值可能不再反映表200中的R3C1的值。IMU中的每个数据项的每个副本被保证截至特定快照时间在事务上是一致的。在特定快照时间之后，仅当对应的陈旧性元数据不指示特定数据项被更新时，IMU中的特定数据项的副本才被保证在事务上是一致的。
存储陈旧性元数据的方式可能因实现而异。例如，数据库服务器可以在易失性存储器中维护那些无效数据项和/或数据块的列表。作为另一个示例，数据库服务器可以在易失性存储器中维护位图，其中每个位对应于数据项，并且该位的值指示对应的数据项是否已经失效。作为又一个示例，SMU可以与IMU集成，使得IMU中的每个数据项副本具有“有效位”，该“有效位”的值指示数据项是否有效。存在仅是跟踪IMU内的哪些数据项已经失效的多种方式的示例。为了清楚起见，本文描述的一些实施例是根据IMU和SMU来描述的。但是，可以根据这些示例实现其它陈旧性元数据和其它IMU结构。
在一些实施例中，陈旧性元数据可以包括附加信息。例如，在一些实施例中，陈旧性元数据可以指示特定数据项被修改的时间，从而如果查询的目标快照时间落入对应的时间段但是修改时间发生在查询快照时间之后，则允许使用存储在特定IMU中的值。在一些实施例中，陈旧性元数据可以附加地指示更新数据项值是否可以从另一个源获得，该另一个源诸如但不限于一个或多个持久性数据块、缓冲区高速缓存、事务日志和/或另一个事务记录。例如，陈旧性元数据可以指示特定数据项的当前版本是否存在于对相关数据项的更新的存储器中日志记录中。更新的存储器中日志记录可以用于提供对更新数据的更快访问，而不会引入更新当前IMU的开销，这可能包括解压缩IMU并且然后在对更新值进行更新之后重新压缩IMU。
例如，在许多数据库系统中，事务(或事务内的各个语句)被指派快照时间，并返回反映截至该快照时间的数据库状态的数据。具体而言，如果事务被指派快照时间T3，则事务必须被提供包括在T3之前被提交的所有更改并且不包括截至T3尚未提交的更改(事务本身做出的更改除外)的数据项的版本。对于这样的事务，特定SMU中的设置位不一定指示特定IMU不能用于作为对应数据项的源。更具体而言，即使在对应的SMU中设置了该行的对应位，但是如果该对应位是在事务的快照时间之后被首先设置的，则这样的事务仍然可以使用IMU来获得数据项。
维护IMU和SMU
图3是根据实施例的针对镜像数据集和对应的陈旧性元数据的IMU的存储器中组的框图。IMU1222是包含表200中的列C1的值的第一IMU。IMU1包括对应的镜像数据集中的每个数据项的副本，并且反映截至第一快照时间tS1对这些数据项做出的所有更改。在一个实施例中，IMU1的生成在第一快照时间tS1开始并且在第一快照完成时间tC1完成。下面将更详细地描述快照完成时间的使用。
在从tS1开始的第一时段期间，数据库服务器通过更改持久性数据集中的数据项的副本而不更新镜像数据集的当前IMU中的数据项的副本来响应对镜像数据集中的数据项的更新。通过存储陈旧性元数据242来记录更新的发生，该陈旧性元数据242指示数据项的副本在对应的存储器中数据集中是陈旧的。
例如，在所示示例中，存储器中组220对应于镜像数据集R1C1-R6C1。IMU1222在第一时间段330期间是当前的。在图3所示的实施例中，第一时间段330在第一快照时间ts1开始并在第二快照时间ts2结束。在第一时间段330期间，数据库服务器通过更改受影响的数据项的持久性副本并且在不更新IMU1中的存储器中副本的情况下记录SMU1312中的变化来响应对对应的镜像数据集R1C1-R6C1的更新。在所示示例中，在第一时间段330期间发生对表200的R3C1的更新。即使在持久性存储装置110中的块204中值R3C1已经更改，IMU1也不被修改。因此，由于更新，IMU1中的值R3C11变得陈旧。数据库服务器将SMU1中的第三位设置为“1”，以指示IMU1中的值R3C11是陈旧的。
所示示例示出了在IMU2是当前IMU时的时间点处的IMU和SMU的存储器中组。SMU1指示R3C1在第一时段期间被更新，因此IMU1中对应的副本R3C11可能未反映对R3C1的更新。此外，SMU1指示其它值R1C1、R2C1、R4C1、R5C1和R6C1在第一时段期间未被更新，因此IMU1中对应的副本R1C11、R2C11、R4C11、R5C11和R6C11应该反映截至从tS1到tS2的第一时段中的任何时间的数据项的值。
在后续时段期间，数据库服务器通过更改持久性数据集中的数据项的副本而不更新针对镜像数据集的当前IMU中的数据项的副本来响应对镜像数据集中的数据项的更新。
IMU2304是包含表200中的列C1的值的第二IMU。IMU2包括对应的镜像数据集中的每个数据项的副本，如在第二快照时间tS2持久性地存储在数据库中的。在所示实施例中，IMU2的生成在第二快照时间tS2开始并且在第二完成时间tC2完成。在一些实施例中，IMU2的生成涉及从持久性存储装置(或另一个源)获得陈旧数据项以及从IMU1获得非陈旧项，其中陈旧性由SMU1指示。当压缩针对镜像数据集的IMU的存储器中组中的IMU时，IMU2的生成可能涉及解压缩IMU1，从而从持久性存储装置中获得陈旧数据项的当前版本、从IMU1中获得非陈旧项、并且压缩IMU2。
IMU2在第二时间段332期间是当前的。在本示例中，第二时间段332在第二快照时间tS2开始并且在与生成的下一个IMU对应的稍后快照时间结束。在所示示例中，尚未发起下一个IMU的生成，并且IMU2是当前IMU。在第二时间段332期间，数据库服务器通过更改受影响的数据项的持久性格式副本并且在不更新IMU2中的存储器中副本的情况下记录SMU2中的变化来响应对对应镜像数据集的更新。在所示示例中，在时间段332期间，发生对表200的R2C1、R5C1和R6C1的更新。因此，由于更新，IMU2中的值R2C12、R5C12和R6C12变得陈旧。SMU2中的第二位、第五位和第六位被设置为“1”以指示IMU2中的对应值是陈旧的。
在一些实施例中，一个或多个SMU 312-314可以包括分层结构，该分层结构不仅包括行级别位向量，而且还包括与不同级别的数据(诸如数据库、表、扩展区和/或块)对应的附加级别的陈旧信息。例如，扩展区级别陈旧信息可以指示包括被更新的数据项的任何扩展区，并且块级别陈旧信息可以指示包括被更新的数据项的任何块。
在一些实施例中，根据需要创建陈旧性元数据242。例如，在执行对数据项R3C1的实际更新之前，可能不会触发SMU1的创建，导致IMU1 222中的值R3C11变得陈旧。因此，如果IMU中的所有数据项都是当前的，则一些实施例不创建对应的SMU数据结构。通过仅存储自IMU的快照时间以来已经被改变或添加的数据项或其它层级的更改行信息，陈旧性元数据242的大小可能显著小于否则如果针对所有镜像数据集的所有IMU的每一行预先分配位的情况下的大小。
为请求选择IMU
对于一个或多个镜像数据集，维护多个IMU。数据库服务器基于与请求相关联的目标快照时间，确定要访问以响应请求的适当数据源。如本文所使用的，术语“目标快照时间”是指与查询或其它请求相关联的时间。预期数据库服务器返回与目标快照时间相一致的结果。
例如，如果请求的目标快照时间落在对应于IMU的特定版本的时段中，则特定IMU及其SMU可以用于响应对数据项的请求。更具体而言，对于SMU指示在特定IMU中不陈旧的数据项，数据库服务器可以使用特定IMU来响应请求。另一方面，对于SMU指示在特定IMU中陈旧的数据项，数据库服务器可以从另一个源访问数据项的最新版本。因此，IMU的存储器中组允许数据库服务器使用IMU来准确地响应查询。
陈旧性元数据可以用于确定IMU的版本中的哪些数据项是陈旧的。在当前IMU响应具有当前时段中的目标快照时间的查询时，当前SMU指示哪些数据项在当前IMU中是陈旧的。当使用先前的IMU时，相关联的SMU指示哪些数据项在先前IMU是当前的相关联时间段中变得陈旧。通过参考后续SMU，即使查询具有在与先前IMU相关联的时间段之后的目标快照时间，先前IMU也可以用于响应查询。后续SMU指示哪些数据项在后续的时间段中变得陈旧。
特别地，在重新填充期间可以使用多个SMU。在重新填充期间，IMU的新版本在重新填充完成之前将不可用，但IMU的之前版本仍维护在存储器中。当新版本的生成尚未完成时，数据库服务器可以基于IMU的之前版本、对应于之前版本的陈旧性元数据、以及对应于新版本的陈旧性元数据来响应该请求。例如，如果之前版本或新版本的陈旧性元数据指示IMU的之前版本中的数据项的副本在目标时间是陈旧的，则数据库服务器可以从另一个源，诸如从持久性副本访问特定数据项的最新版本。这允许避免由于在重新填充期间存储器中数据的不可用而导致的扫描延迟的退化。
对于具有落在时间段328中的目标快照时间的请求，没有IMU可用。数据库服务器将通过从另一个源(诸如从持久性存储装置110或高速缓存106)访问所需的数据项来处置这样的请求。
对于具有落在时间段330中但不在时间段320内的目标快照时间的查询或其它请求，可以使用IMU1。IMU1反映在第一快照时间tS1镜像数据集的持久性副本的值，并且SMU1包含识别IMU1中已经变得陈旧的数据项副本的陈旧性元数据。因此，如由SMU1所指示的，IMU1的非陈旧值可以用于响应具有落入时间段330中的目标快照时间的请求或查询。
但是，如果在时间段320期间处理这样的请求，则IMU1将不可用。虽然在时间段320期间IMU1是当前IMU，但是在tC1之前，IMU重新填充未完成。因此，在使用IMU1时，无法保证原子性、一致性、隔离性、耐久性(数据库的ACID属性)。此外，当IMU1的最终格式是压缩格式时，在IMU1完成之前，IMU1的各个值可能并不总是可访问的。
对于具有落在时间段332中的目标快照时间的查询或其它请求，只要IMU2可用，就可以使用IMU2。IMU2反映在第二快照时间ts2镜像数据集的持久性副本的值，并且SMU2包含识别IMU2中已经变得陈旧的数据项副本的陈旧性元数据。因此，如由SMU2所指示的，IMU2的非陈旧值可以用于响应具有落入时间段332的目标快照时间的请求或查询。对于陈旧的数据项，数据库服务器将通过从另一个源，诸如从持久性存储装置110或高速缓存106访问所需的数据项来处置这样的请求。
在一些实例中，IMU2可能不可用于处理具有落入时间段332中的目标快照时间的请求。例如，如果在时间段324期间处理这种请求，则IMU2可能不可用，因为IMU2的生成在时间段324期间尚未生成。虽然IMU2在时间段324期间是当前IMU，但IMU重新填充直到第二完成时间tc2才完成。因此，在使用IMU2时无法保证数据库的ACID属性。
但是，当IMU1仍然维护在存储器中时，IMU1可以用于响应请求。SMU1包含识别IMU1中已经变得陈旧直到第二快照时间ts2的数据项副本的陈旧性元数据，而SMU2包含识别自第二快照时间tS2以来已经变得陈旧的数据项副本的陈旧性元数据。因此，SMU1和SMU2的组合可以用于确定IMU1中的哪些数据项副本在落入时间段332中的目标快照时间可能是陈旧的。
生成初始IMU
根据一些实施例，对于特定的镜像数据集，基于持久性存储装置110中的持久性格式数据108来生成初始IMU(镜像数据集的第一IMU)。例如，IMU1是针对与表200的列C1的行R1-R6中的值的镜像数据集对应的存储器中组220的第一IMU。在给定示例中，镜像格式是列式的。但是，可以使用其它形式的镜像格式数据，包括处于与持久性格式不同的另一种格式的其它形式的镜像格式数据。
无论使用何种特定镜像格式，镜像格式数据104都是基于现有的持久性格式数据108在存储器中创建的，而不导致对持久性格式数据108的更改。与高速缓存106不同，镜像格式数据不仅仅是存储在持久性存储装置110中的数据的副本。相反，因为镜像格式不基于持久性格式，因此通过从持久性存储装置110读取持久性格式数据并将获得的持久性格式数据转换为镜像格式数据来初始地填充易失性存储器102。例如，可以通过从持久性存储装置110中的块202-206读取表200的列C1的行R1-R6中的值来创建IMU1。
执行持久性格式到镜像格式转换所需的开销量将基于镜像格式与持久性格式的不同程度而视情况而异。例如，如果持久性格式是已经以一种方式被压缩的行为主的盘块，并且镜像格式是以另一种方式被压缩的列向量，则执行转换所需的开销量可能很大。
当在特定的粒度级别(诸如块级别)上应用格式时，特定格式用于格式化应用该格式的整个块的数据。在一些实施例中，对于持久性格式数据，诸如行为主的格式的持久性格式可以在块级别上应用于持久性格式数据108的一个或多个块202-206。在一些情况下，持久性格式允许访问个体值。但是，如果持久性格式不允许访问存储在块202-206中的个体值，则块202-206必须被转换为检索值R1C1-R6C1。
在一些实施例中，镜像格式可以在数据集级别上应用于镜像格式数据104的一个或多个IMU。存储器中组220的IMU 222-224处于镜像格式。在一些实施例中，镜像格式可以是应用于存储在每个IMU 222-224中的整个列向量R1C1-R6C1的向量级别压缩格式。在这种情况下，在从持久性格式数据108获得值R1C1-R6C1之后，通过应用生成处于镜像格式的IMU1所需的向量级别压缩来生成处于镜像格式的存储器中组220的初始IMU1。
在一些实施例中，镜像数据集中的每个个体值(individual value)R1C1-R6C1可以以不同格式存储在持久性格式数据和镜像格式数据中。例如，除了应用于块202-206的任何块级别压缩方案或应用于IMU 222-224的列级别压缩方案之外，个体值R1C1-R6C1可以以第一个体值格式存储在块202-206中，同时个体值R1C1-R6C1可以以第二个体值格式格式存储在IMU 222-224中。例如，第一个体值格式和/或第二个体值格式可以是不同的压缩格式、编码和/或未压缩数据。当第一个体值格式和第二个体值格式不同时，在生成IMU1之前，从块202-206获得的值必须从第一个体值格式格式转换为第二个体值格式。在块202-206上的任何所需的解压缩之后并且在应用任何所需的向量级别压缩以生成IMU1222之后执行转换。
重新填充
如本文所使用的，术语“重新填充(repopulate)”是指使用针对镜像数据集的当前IMU和对应的陈旧性元数据来为镜像数据集生成新IMU。镜像数据集的新IMU成为镜像数据集的当前IMU。
重新填充利用以下事实：生成IMU的新版本所需的一些数据项可能已经驻留在易失性存储器102中IMU的当前版本中。更具体而言，与IMU的当前版本对应的陈旧性元数据可以用于确定哪些数据项在IMU的当前版本中是陈旧的。
在一些实施例中，针对IMU的每个版本单独地维护陈旧性元数据。因此，当在给定时间重新填充IMU时，新的陈旧性元数据与新版本相关联地单独存储。因此，与先前版本相关联地存储的先前陈旧性元数据将指示先前版本中的哪些数据项截至该给定时间而不是之后是陈旧的。
新版本反映在后续时间在持久性格式数据108中的镜像数据集的状态。对于在先前版本中不陈旧的数据项，可以从IMU的先前版本中检索副本，从而消除了访问持久性存储装置110的需要。对于在先前版本中陈旧的数据项，从另一个源检索副本，因为IMU的先前版本中的副本是陈旧的。例如，可以从持久性存储装置110、高速缓存106或其它源检索副本。
如本文所使用的，“重新填充IMU”是指基于当前IMU及其对应的SMU来生成新IMU。新IMU是反映如在更近的时间点持久性地存储在数据库中的镜像数据集的状态的IMU。随着时间的推移，IMU内的无效数据项的数量将增加。IMU内的无效数据项的数量越多，IMU的使用变得越低效。例如，如果90％的IMU是无效的，则数据库服务器引入检查IMU的开销，同时仍然需要在90％的时间引入从另一个源获得期望数据项的开销。
在一些实施例中，当IMU中的阈值量的数据变得陈旧时，触发重新填充。阈值可以是触发重新填充的数个其它因素中的一个，诸如但不限于访问的频率、用户偏好、可用存储器或其任何组合。此外，对于不同的镜像数据集，重新填充可以独立地发生。在一些实施例中，特定列或其它镜像数据集合被划分为多个镜像数据集，每个镜像数据集对应于其自己的IMU存储器中组，IMU重新填充针对该IMU存储器中组独立地发生。当仅有数据块的子集在正常OLTP工作负载中引起DML活动时，通常仅有小部分IMU存储器中组成为重新填充候选者。
在所示实施例中，执行IMU重新填充以生成从第二快照时间tS2开始的新IMU(IMU2)。在SMU1中记录与对从时间tS1到tS2发生的表200的列C1中的基础数据的更新对应的陈旧性元数据。对于在时间tS2之后发生的基础数据的更新，陈旧性元数据被记录在SMU2而不是SMU1中。
可以基于来自IMU1的非陈旧的一个或多个组成部分(component)来生成IMU2。在一些实施例中，如果需要，IMU1被解压缩，并且IMU1中的陈旧数据项被来自另一个源的陈旧数据项的非陈旧副本替换，该另一个源诸如但不限于一个或多个持久性数据块、缓冲区高速缓存、事务日志等。可以基于SMU1识别陈旧的数据项。在所示示例中，SMU1是对应于IMU1中的列向量的位向量，并且SMU1中设置为“1”的位指示IMU1中的对应数据项R3C11是陈旧的。为了生成IMU2，可以使用IMU1中的存储器中的非陈旧数据项的副本(R1C11、R2C11、R4C11、R5C11和R6C11)。数据项R3C1的非陈旧副本从另一个源获得，该另一个源诸如持久性存储装置110中的块204、高速缓存106中的高速缓存块204、事务日志和/或另一个事务记录。IMU2中的结果值集合包括数据项的副本(R1C12、R2C12、R3C12、R4C12、R5C12和R6C12)，这些副本反映了直到第二快照时间tS2对镜像数据集中的数据项做出的更改。如果需要，该值集合被压缩以生成IMU2。
在一些实施例中，重新填充从新的陈旧性元数据(诸如SMU2)的存储器分配开始。在分配新的陈旧性元数据之后，取一组锁存器用于对先前IMU(例如，IMU1)和新的陈旧性元数据(例如，SMU2)的独占访问，直到重新填充完成为止。
选择要镜像的数据集
决定要镜像哪个持久性格式数据以及何时加载它可以基于各种因素。例如，如果系统具有大量易失性存储器102和相对小的数据库，则可能期望对整个数据库进行镜像。因此，所有的持久性格式数据也将被镜像在镜像格式数据中。另一方面，如果相对于数据库的大小存在相对少量的易失性存储器102，则仅镜像数据库的非常小的部分可能是最优的。通常，当不是所有数据库要被镜像时，被选择要进行镜像的部分是基于哪个部分将最大程度地提高系统的整体性能的。通常，对频繁使用的数据进行镜像将对较不频率使用的数据进行镜像提供更多益处。因此，如果一个表、表的一列、或表的一个分区比数据库中的其它数据更频繁地被访问，则该表、列或分区可以被选择在易失性存储器102中进行镜像。可以在任何粒度级别上选择要镜像的数据库的部分。例如，可以在每个表的基础上、每个列的基础上、每个扩展区的基础上、每个段的基础上、每个表分区的基础上等做出选择。
关于何时创建镜像格式数据的决定可以基于各种因素。例如，如果在系统启动时有足够的时间可用，则已经被选择用于镜像的所有持久性格式数据可以在启动时被预先加载到易失性存储器102中。如上所述，加载镜像格式数据涉及从持久性存储装置110中读取对应的持久性格式数据，并且然后将该持久性格式数据转换为镜像格式。
在一些实施例中，镜像格式数据在数据库系统启动时被预加载到易失性存储器中。例如，在针对包含镜像数据项的数据结构执行任何数据库操作之前，可以通过后台处理来执行预加载。可以一次一个IMU地创建镜像格式数据。
生成和维护IMU的示例处理
图4是图示根据实施例的用于为镜像数据集生成和维护IMU的处理的框图。处理400可以由一个或多个计算设备和/或其进程执行。例如，处理400的一个或多个方框可以由计算设备900执行。在一些实施例中，处理400的一个或多个方框由数据库服务器(诸如数据库服务器120)执行。
在方框402处，数据库服务器生成第一IMU。第一IMU包括镜像数据集中的每个数据项的副本，每个副本反映直到第一快照时间对数据项做出的更改。在生成第一IMU之前在易失性存储器中没有镜像数据集的IMU时，基于从持久性存储装置、持久性存储数据的高速缓存或另一个源获得的镜像数据集中的项的持久性副本来生成第一IMU。数据库服务器在易失性存储器中维护第一IMU。
在方框404处，数据库服务器通过更改持久性数据集并存储第一陈旧性元数据来响应对第一更新数据项集合的更新。数据库服务器更改第一更新数据项集合的持久性副本，而不更新第一IMU中的对应副本。例如，数据库服务器可以执行更新数据库中的第一数据项的持久性副本的一个或多个事务。数据库服务器存储第一陈旧性元数据，该第一陈旧性元数据指示第一IMU中的第一数据项的副本是陈旧的。在一些实施例中，第一陈旧性元数据被存储为第一位向量。
在方框406处，数据库服务器生成第二IMU。以下更详细地讨论用于生成第二IMU的示例处理500。在一些实施例中，当数据库服务器确定应该重新填充IMU时，生成第二IMU。第二IMU包括镜像数据集中的每个数据项的副本，每个副本反映直到第二快照时间对数据项做出的更改。在一些实施例中，基于第一IMU和第一陈旧性元数据生成第二IMU。更具体而言，第一陈旧性元数据用于确定第一IMU中的哪些数据项是陈旧的；从第一IMU获得非陈旧数据项的副本，而从另一个源获得陈旧数据项的副本。数据库服务器在易失性存储器中维护第二IMU。
在方框408处，数据库服务器通过更改持久性数据集并存储第二陈旧性元数据来响应更新。数据库服务器更改第二更新数据项集合的持久性副本，而不更新第二IMU中的对应副本。例如，数据库服务器可以执行修改数据库中的第二数据项的持久性副本的一个或多个事务。数据库服务器存储第二陈旧性元数据，该第二陈旧性元数据指示第二IMU中的第二数据项的副本是陈旧的。在一些实施例中，第二陈旧性元数据被存储为第二位向量。
第二更新数据项集合和第一更新数据项集合可以相同或不同；镜像数据集中的每个特定数据项可以属于第一更新数据项集合(特定数据项在第一时段中被更新)、第二更新数据项集合(特定数据项在第二时段中被修改)、两者(特定数据项在第一时间段中被修改并且再次在第二时间段中被修改)，或皆不属于两者(特定数据项在任一时段都没有被修改)。
在方框410处，处理400返回和/或终止。例如，处理可以继续处理相继(successive)数据项、将控制传递给调用进程、生成任何适当的记录或通知、在方法或函数调用之后返回、或者终止。
图5是图示根据实施例的通过为镜像数据集生成新IMU来重新填充IMU的处理的框图。处理500可以由一个或多个计算设备和/或其进程执行。例如，处理500的一个或多个方框可以由计算设备900执行。在一些实施例中，处理500的一个或多个方框由数据库服务器(诸如数据库服务器120)执行。在处理500的开始，第一IMU是IMU的当前版本。
在方框502处，数据库服务器在第二快照时间发起第二IMU的创建。例如，数据库服务器可以基于一个或多个因素来发起第二1MU的创建，诸如阈值量的陈旧数据和/或其它因素，包括但不限于访问的频率、用户偏好、可用存储器或其任何组合。IMU的新版本将包括镜像数据集中每个数据项的副本，每个副本反映直到第二快照时间对数据项做出的更改。在一些实施例中，在确定发起第二IMU的创建后，数据库服务器停止更新第一陈旧性元数据，并且响应于对基础数据的更新而开始存储第二陈旧性元数据，即使第二IMU的创建未完成。
在方框504处，数据库服务器使用第一陈旧性元数据确定第一IMU中的无效数据项。与第一IMU相关联的第一陈旧性元数据包括在第一快照时间开始并在第二快照时间结束的第一时段期间对镜像数据集的更新的记录。因此，第一陈旧性元数据可以用于识别第一IMU中的哪些数据项副本在第二快照时间是陈旧的或有效的。
在方框506处，数据库服务器从除第一IMU之外的源提取无效数据项(其中数据项的副本在第一IMU中是陈旧的)，除第一IMU之外的源诸如持久性存储装置上的持久性数据集、高速缓存中的一个或多个持久性数据块的副本，或另一个源。
在方框508处，数据库服务器基于第一IMU和所提取的数据项生成第二IMU。可以从第一IMU中读取第一IMU中的非陈旧数据项。在一些实施例中，通过解压缩第一IMU(如果需要)、用从其它源提取的数据项替换第一IMU中的陈旧数据项、并且然后如果需要，则压缩或以其它方式格式化或修改结果用以生成第二IMU的产生的数据来生成第二IMU。
在方框510处，在完成快照时间完成第二IMU的生成。在第二IMU的完成快照时间，可以使第二IMU可用，诸如以响应查询和其它数据库请求。
在方框512处，处理500返回和/或终止。例如，处理可以继续处理相继数据项、将控制传递给调用进程、生成任何适当的记录或通知、在方法或函数调用之后返回、或者终止。
处置请求的示例处理
图6是描绘根据实施例的用于通过访问第一IMU、第二IMU或持久性数据集来响应与目标快照时间相关联的请求的处理的流程图。处理600可以由一个或多个计算设备和/或其进程执行。例如，处理600的一个或多个方框可以由计算设备900执行。在一些实施例中，处理600的一个或多个方框由数据库服务器(诸如数据库服务器120)执行。在所示示例中，IMU的当前版本是IMU2。
在方框602处，数据库服务器接收与目标快照时间tT相关联的请求。该请求需要访问镜像数据集中的一个或多个特定数据项。数据库服务器在存储器中为镜像数据集维护IMU的存储器中组。在数据库服务器维护第一IMU和第二IMU二者时接收到请求。以下将关于请求需要访问的一个特定数据项来讨论处理600；处理600的各部分可以被重复以处理请求需要访问的附加数据项。
在判定框604处，数据库服务器确定请求的目标快照时间tT是否小于与第一IMU(IMU1)相关联的第一快照时间tS1。IMU1包括镜像数据集中每个数据项的副本，每个副本反映直到第一快照时间tS1对数据项做出的更改。
如果确定目标快照时间tT小于第一快照时间tS1，则处理继续到方框610，其中从另一个源(例如，持久性存储装置)获得数据项。在这种情况下，请求的目标快照时间tT落在没有维护IMU和SMU的时段中，因此数据库服务器不使用任何IMU来响应查询。
返回到判定框604，如果确定目标快照时间tT不小于第一快照时间tS1，则处理继续到判定框606。在判定框606处，数据库服务器确定目标快照时间tT是否小于与第二IMU(IMU2)相关联的第二快照时间ts2。IMU2包括镜像数据集中每个数据项的副本，每个副本反映直到第二快照时间tS2对数据项做出的更改。
如果数据库服务器确定目标快照时间tT小于第二快照时间tS2，则处理继续到方框612。在方框612处，数据库服务器确定应该使用SMU1和IMU1检索特定数据项。即，数据库服务器已经确定目标快照时间tT落在从第一快照时间tS1到第二快照时间tS2的第一时段中。在第一时段期间，IMU1是包含特定数据项的镜像数据集的IMU存储器中组中的当前IMU。
在判定框614处，数据库服务器使用在方框612处确定的SMU(SMU1)来确定IMU1中的特定数据项的副本是否陈旧。如果数据库服务器确定特定数据项在IMU1中不是陈旧的，则处理继续到方框616，其中通过访问易失性存储器中的IMU1来获得数据项的副本。返回到判定框614，如果数据库服务器确定在IMU1中的特定数据项是陈旧的，则处理继续到判定框610，其中从另一个源(例如，持久性存储装置)获得数据项的副本。
返回到判定框606，如果数据库服务器确定目标快照时间tT不小于第二快照时间tS2，则处理继续到判定框608。此时，数据库服务器已经确定目标快照时间tT不落入与先前IMU相关联的时段中，并因此落入与当前IMU(IMU2)相关联的时段中。在所示示例中，IMU的当前版本是IMU2。但是，如果在存储器中维护IMU的两个以上的版本，则可以执行附加步骤来确定目标快照时间tT是否落入与存储器中维护的另一个先前IMU相关联的时段中，如将关于处理700更详细描述的。
在判定框608处，数据库服务器确定当前时间tcurrent是否小于IMU2的完成时间tC2。在完成时间tC2之前，仍然生成IMU2，并且IMU2不可用于响应请求。因此，虽然目标快照时间tT指示可以使用当前IMU(IMU2)来回答查询，但是IMU2在当前时间tcurrent不可用于使用。在一些实施例中，未显式存储当前时间tcurrent，并且数据库基于由数据库服务器维护的状态信息来确定当前时间tcurrent是否在完成时间之前。例如，完成标志可以用于指示当前IMU的生成是否完成。因此，标志的存在指示当前IMU是否在当前时间tcurrent完成。作为另一个示例，当通过将新IMU设置为当前IMU，诸如通过将当前IMU引用设置为新IMU来完全生成新IMU时，可以更新数据库和/或数据库服务器的状态。在这种情况下，当前IMU引用指向先前IMU(例如，IMU1)，直到新IMU(例如，IMU2)完成为止。
如果数据库服务器确定当前时间tcurrent小于完成时间tc2，则处理继续到方框618，其中数据库服务器确定SMU1、SMU2和IMU1用于响应查询。虽然IMU1不是当前的IMU，但可以使用IMU1、SMU1和SMU2的组合来代替IMU2和SMU2。更具体而言，即使请求的目标快照时间tT落入与IMU2相关联的时间段中，但如果IMU1中的数据项在目标快照时间tT之前尚未变为陈旧，IMU1中的数据项也可以用于响应查询。当处理继续到判定框614时，SMU1和SMU2的组合可以用于做出该确定。即，当从方框618到达判定框614时，数据库服务器使用SMU1和SMU2两者来确定特定数据项的副本在IMU1中是否陈旧。仅当SMU1指示特定数据项在第一时段期间未被修改且SMU2指示特定数据项在第二时段期间未被修改时，IMU1中的特定数据项才不陈旧。
返回到判定框608，如果数据库服务器确定当前时间tcurrent不小于完成时间tC2，则处理继续到方框620。在方框620处，数据库服务器确定SMU2和IMU2用于响应查询。
在判定框622处，数据库服务器使用在方框620中确定的SMU(SMU2)来确定IMU2中的特定数据项的副本是否陈旧。如果数据库服务器确定特定数据项在IMU2中是陈旧的，则处理继续到判定框610，其中从另一个源(例如，持久性存储装置)获得数据项的副本。
返回到判定框622，如果数据库服务器确定特定数据项在IMU2中不是陈旧的，则处理继续到方框624，其中通过访问易失性存储器中的IMU2来获得特定数据项的副本。
在方框626处，处理600返回和/或终止。例如，处理可以继续处理相继数据项、将控制传递给调用进程、生成任何适当的记录或通知、在方法或函数调用之后返回、或者终止。
图7是图示根据实施例的用于通过访问可用IMU集合或持久性数据集中的一个来响应与目标快照时间相关联的请求的处理的流程图。处理700可以由一个或多个计算设备和/或其进程执行。例如，处理700的一个或多个方框可以由计算设备900执行。在一些实施例中，处理700的一个或多个方框由数据库服务器(诸如数据库服务器120)执行。在所示示例中，IMU的当前版本是IMUcurrent。
在方框702处，数据库服务器接收与目标快照时间tT相关联的请求。该请求需要访问镜像数据集中的一个或多个特定数据项。当数据库服务器在存储器中为镜像数据集维护IMU的存储器中组时接收到请求。以下将关于请求需要访问的一个特定数据项来讨论处理700；处理700的各部分可以被重复以处理请求需要访问的附加数据项。
在方框704处，数据库服务器基于相关联的目标快照时间tT来确定对应的IMU(IMUx)。数据库服务器可以通过确定目标快照时间tT落入哪个时间段来确定IMUx。即，IMUx是在目标快照时间tT时的当前IMU。如果在存储器中没有维护对应的IMU，则不使用IMU，并且从另一个源(未示出)获得特定数据项。
在判定框706处，数据库服务器确定IMUx是否是当前IMU(IMUcurrent)。如果IMUx是当前IMU，则存在IMU不可用的可能性，因为IMUcurrent未完成(例如，生成或重新填充尚未结束)。如果数据库服务器确定IMUx不是当前IMU，则处理继续到方框718，其中数据库服务器选择SMUx和IMUx以用于响应查询。
返回到判定框706，如果数据库服务器确定IMUx是当前IMU，则处理继续到判定框708，其中数据库服务器确定IMUcurrent是否完成。如果IMUcurrent完成，则处理继续到方框718，其中数据库服务器确定IMUx和SMUx用于响应请求。
在判定框720处，数据库服务器使用SMUx来确定IMUx中的特定数据项的副本是否陈旧。如果数据库服务器确定IMUx中的特定数据项的副本不是陈旧的，则处理继续到方框722，其中数据库服务器从IMUx获得特定数据项的副本。返回到判定框720，如果数据库服务器确定IMUx中的特定数据项的副本是陈旧的，则处理继续到方框716，其中从另一个源(例如，持久性存储装置)获得特定数据项的副本。
返回到判定框708，如果数据库服务器确定IMUcurrent未完成，则处理继续到方框710，其中数据库服务器选择先前IMU(IMUx-1)用于响应查询。SMUx和SMUx-1也被选择，因为这两个SMU都是确定IMUx-1中的特定数据项的副本在目标快照时间tT是否陈旧所必需的。
在判定框712处，数据库服务器使用SMUx-1和SMUx来确定IMUx-1中的特定数据项的副本是否陈旧。如果数据项在SMUx-1或SMUx中被指示为陈旧，则该数据项被视为陈旧。如果数据库服务器确定IMUx-1中的特定数据项的副本不是陈旧的，则处理继续到方框714，其中从IMUx-1获得特定数据项的副本。如果数据库服务器确定IMUx-1中的特定数据项的副本是陈旧的，则处理继续到方框716，其中从另一个源(例如，持久性存储装置)获得特定数据项的副本。
在方框724处，处理700返回和/或终止。例如，处理可以继续处理相继数据项、将控制传递给调用进程、生成任何适当的记录或通知、在方法或函数调用之后返回、或者终止。
在一些实施例中，数据库服务器执行如判定框706-708中所示的类似动作，以确定IMUx(与目标快照时间tT对应的IMU)是否可用。在一些实施例中，数据库服务器选择使用除IMUx-1之外的另一个先前IMUp而不是IMUx。在这种情况下，使用从SMUp到SMUx的SMU集合来确定在IMUp中特定数据项是否陈旧。
版本保留
在一些实施例中，实现确定镜像数据集的一个或多个IMU的保留期的一个或多个保留策略。如本文所使用的，术语“保留策略”是指用于确定是否应该保留一个或多个IMU(例如IMU)的任何规则、启发式方法或其它指导方针。当保留策略指示IMU不应该再被保留时，该版本“到期”。
可以针对镜像数据集的各个版本在每个版本的基础上应用保留策略、针对每个镜像数据集在每个组的基础上应用保留策略、针对属于特定数据库结构(例如，表、列或其它数据库结构)的镜像数据集在每个结构的基础上应用保留策略、或者针对整个数据库在每个数据库的基础上应用保留策略。此外，可以在不同级别(每个版本、每个组、每个结构、每个数据库或另一个级别)应用不同的保留策略。
保留策略的一个示例是存储器中组的大小限制。在这种情况下，为特定镜像数据集在存储器中维护的IMU的数量限于存储器中组的大小。存储器中组的大小可以是预定的和/或动态的，并且可以基于一个或多个因素，诸如但不限于用户偏好、更新的频率、访问的频率、其它陈旧性度量、重新填充的频率、其它因素或其任何组合。当生成将导致IMU的数量超过存储器中组的大小的新版本时，存储器中组中最旧的版本不再被保留在存储器中。
保留策略的另一个示例是基于时间的保留策略。例如，保留时段可以与特定版本、特定镜像数据集(版本组)、特定数据库结构或数据库系统相关联。在相对于特定开始时间经过保留时段之后，IMU到期，该特定开始时间可以是版本快照时间、下一个版本快照时间、版本进入特定状态的时间或任何其它时间。
垃圾收集(garbage collection)
在一些实施例中，垃圾收集进程确保存储器仅在任何其它进程不再需要版本时才被重用。如本文所使用的，术语“释放(release)”是指确定将不再保留IMU。如本文所使用的，术语“释放的版本”是指数据库服务器已经确定将不再保留在存储器中的IMU。
在一些实施例中，一个或多个后台进程定期地评估一个或多个镜像数据集的IMU，以检查适用于IMU的任何保留策略。当一个或多个后台进程确定特定IMU已经到期时，则释放该特定IMU。
通常，在版本被释放时，释放的版本对后续查询不可见。仅当所有现有查询(或执行现有查询的进程)已经对释放的版本释放其插针(pin)、锁存器(latch)、锁(lock)和/或其它同步机制时，基础存储器才成为重用的候选者。这时，可以解除分配并重用与释放的版本对应的存储器。
存储器压力
在一些实施例中，当遇到限制条件时，诸如当检测到存储器压力时，减少IMU的数量。如本文所使用的，术语“存储器压力(memory pressure)”是指低存储器状况，其可以基于一个或多个因素(诸如但不限于阈值、百分比或其它因素)来检测。
当遇到诸如存储器压力的限制条件时，可以释放一个或多个IMU。在一些实施例中，即使根据任何保留策略IMU尚未到期，IMU也是用于释放的候选者。在一些实施例中，评估一个或多个因素以确定哪些镜像数据集将被释放，该一个或多个因素诸如但不限于用户偏好、一个或多个IMU的年龄、限制条件的严重程度(例如，需要多少存储器)、对镜像数据集的更新频率、对镜像数据集的访问频率、其它陈旧性度量、重新填充的频率、其它因素或其任何组合。在一些实施例中，所有之前版本都成为垃圾收集和重用的候选者，而与保留到期与否无关，从而仅留下一个或多个镜像数据集的单个当前IMU。
存储器管理的示例处理
图8是图示根据实施例的用于从可用IMU的集合中移除IMU的处理的流程图。处理800可以由一个或多个计算设备和/或其进程执行。例如，处理800的一个或多个方框可以由计算设备900执行。在一些实施例中，处理800的一个或多个方框由数据库服务器(诸如数据库服务器120)执行。
在判定框802处，数据库服务器选择特定的IMU用于释放。例如，根据保留策略，当数据库服务器确定IMU已经到期时，可以选择该IMU用于释放。在一些实施例中，当检测到限制条件时(诸如低存储器状况)，选择IMU用于释放。
在方框804处，数据库服务器在处理后续查询时使IMU不可用于使用。在一些实施例中，通过从将镜像数据集映射到IMU的存储器中组的数据中移除对IMU的引用，使IMU不可用。
在判定框806处，数据库服务器确定是否剩余任何活动查询仍然在使用释放的IMU。例如，垃圾收集进程可以检查以查看所有现有查询(或执行现有查询的进程)是否已经对释放的IMU释放其插针、锁存器、锁和/或其它同步机制。在一些实施例中，垃圾收集进程定期地针对释放的IMU的集合执行该检查。当数据库服务器确定不再有可能访问释放的IMU的查询时，处理继续到方框808。
在方框808处，数据库服务器将用于IMU和对应SMU的存储器解除分配。
在方框810处，处理800返回和/或终止。例如，处理可以继续处理相继数据项、将控制传递给调用进程、生成任何适当的记录或通知、在方法或函数调用之后返回、或者终止。
对工作负载的影响
本文描述的技术保证了存储器中数据(例如，IMU或其它IMU)的高可用性，即使在由于更新(例如，DML活动)而重新填充存储器中数据时也是如此。因此，混合OLTP环境中的分析查询永久地收货了存储器中列式格式优化的益处，而不必落回到基础存储装置。
当多个并发查询访问正在进行重新填充的IMU时，增加的可用性的影响尤为明显。在没有这些技术的情况下，并发查询必须在给定时间对基础存储资源进行竞争。因此，工作负载吞吐量退化与查询的数量成比例地增加。利用本文描述的技术，针对单个查询改进的吞吐量随着系统中并发查询的数量而进行缩放。当IMU由于重新填充而不可用时，已经观察到在高并发扫描工作负载下吞吐量的退化大于两个量级。另一方面，随着IMU的可用性增减，查询吞吐量线性地缩放。
示例实现系统
根据一些实施例，本文所描述的技术由一个或多个专用计算设备实现。专用计算设备可以是硬连线的以执行该技术，或者可以包括诸如被持久性地编程以执行该技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)的数字电子设备，或者可以包括被编程为按照固件、存储器、其它存储装置或者组合中的程序指令执行该技术的一个或多个通用硬件处理器。这种专用计算设备还可以合并定制的硬连线逻辑、ASIC或FPGA与定制的编程来实现该技术。专用计算设备可以是台式计算机系统、便携式计算机系统、手持式设备、联网设备或者结合硬连线和/或程序逻辑来实现该技术的任何其它设备。
例如，图9是图示可以在其上实现实施例的计算机系统900的框图。计算机系统900包括总线902或用于传送信息的其它通信机制，以及与总线902耦合用于处理信息的硬件处理器904。硬件处理器904可以是例如通用微处理器。
计算机系统900还包括耦合到总线902用于存储信息和要由处理器904执行的指令的主存储器906，诸如随机存取存储器(RAM)或其它动态存储设备。主存储器906也可以用于在执行要由处理器904执行的指令期间存储临时变量或其它中间信息。这些指令当存储在处理器904可访问的非瞬态存储介质中时，使计算机系统900成为被定制以执行指令中所指定的操作的专用机器。
计算机系统900还包括耦合到总线902用于为处理器904存储静态信息和指令的只读存储器(ROM)908或者其它静态存储设备，。提供了诸如磁盘、光盘或固态驱动器的存储设备910，并且存储设备910耦合到总线902用于存储信息和指令。
计算机系统900可以经总线902耦合到诸如阴极射线管(CRT)的显示器912用于向计算机用户显示信息。包括字母数字和其它键的输入设备914耦合到总线902，用于向处理器904传送信息和命令选择。另一种类型的用户输入设备是光标控件916，诸如鼠标、轨迹球或者光标方向键，用于向处理器904传送方向信息和命令选择并且用于控制显示器912上的光标移动。这种输入设备通常具有在两个轴(第一个轴(例如x)和第二个轴(例如y))中的两个自由度，这允许设备在平面内指定位置。
计算机系统900可以使用定制硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文所描述的技术，定制硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑与计算机系统结合，使计算机系统900成为或者将计算机系统900编程为专用机器。根据一些实施例，由计算机系统900响应于执行被包含在主存储器906中的一条或多条指令的一个或多个序列的处理器904而执行本文的技术。可以从诸如存储设备910的另一个存储介质将这种指令读取到主存储器906中。执行被包含在主存储器906中的指令的序列使得处理器904执行本文所述的处理步骤。在替代实施例中，硬连线的电路系统可以代替软件指令或者与软件指令组合使用。
如在本文所使用的，术语“存储介质”是指存储使机器以特定方式操作的数据和/或指令的任何非暂态介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘、磁盘或固态驱动器，诸如存储设备910。易失性介质包括动态存储器，诸如主存储器906。存储介质的常见形式包括例如软盘、柔性盘、硬盘、固态驱动器、磁带、或者任何其它磁性数据存储介质、CD-ROM、任何其它光学数据存储介质、具有孔图案的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒式磁带。
存储介质与传输介质截然不同但是可以与传输介质结合使用。传输介质参与在存储介质之间传送信息。例如，传输介质包括同轴线缆、铜线和光纤，包括包含总线902的引线。传输介质还可以采取声波或光波的形式，诸如在无线电波和红外线数据通信中产生的那些波。
各种形式的介质可以参与把一条或多条指令的一个或多个序列携带到处理器904以供执行。例如，最初可以在远端计算机的磁盘或固态驱动器上携带指令。远端计算机可以将指令加载到该远端计算机的动态存储器中并且使用调制解调器经电话线发送指令。位于计算机系统900本地的调制解调器可以在电话线上接收数据并且使用红外线发射器将数据转换为红外线信号。红外线检测器可以接收在红外线信号中携带的数据并且适当的电路系统可以将数据放在总线902上。总线902将数据携带到主存储器906，处理器904从该主存储器906检索并执行指令。由主存储器906接收的指令可以可选地在被处理器904执行之前或之后被存储在存储设备910上。
计算机系统900还包括耦合到总线902的通信接口918。通信接口918提供耦合到网络链路920的双向数据通信，其中网络链路920连接到本地网络922。例如，通信接口918可以是综合业务数字网络(ISDN)卡、线缆调制解调器、卫星调制解调器，或者提供到对应类型的电话线的数据通信连接的调制解调器。作为另一个示例，通信接口918可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。也可以实现无线链路。在任何此类实现中，通信接口918发送和接收携带表示各种类型信息的数字信号流的电信号、电磁信号或光信号。
网络链路920通常通过一个或多个网络向其它数据设备提供数据通信。例如。网络链路920可以通过本地网络922提供到主计算机924或者到由互联网服务提供商(ISP)926操作的数据装置的连接。ISP 926进而通过现在通常称为“互联网”928的全球分组数据通信网络提供数据通信服务。本地网络922和互联网928两者都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号以及在网络链路920上并通过通信接口918的信号是传输介质的示例形式，其中该信号将数字数据携带到计算机系统900或者从计算机系统900携带数字数据。
计算机系统900可以通过(一个或多个)网络、网络链路920和通信接口918发送消息和接收数据，包括程序代码。在互联网示例中，服务器930可以通过互联网928、ISP 926、本地网络922和通信接口918发送对应用程序的所请求的代码。
接收到的代码可以在其被接收时由处理器904执行，和/或存储在存储设备910或其它非易失性存储装置中以供以后执行。
在前述说明书中，已经参考许多具体细节描述了本发明的实施例，这些具体细节可以因实现而异。因而，说明书和附图被认为是说明性的而不是限制性的意义。本发明的范围的唯一且排他的指示以及申请人所预期作为本发明的范围的内容，是从本申请产生的一组权利要求的以该组权利要求产生的具体形式的书面范围和等效范围，该组权利要求包括任何后续的校正。

Claims (13)

1.一种方法，包括：
在持久性存储装置中维护数据库服务器能够访问的数据库；
其中所述数据库包括镜像数据集中每个数据项的持久性副本；
所述数据库服务器在易失性存储器中生成和维护包括所述镜像数据集中的每个数据项的副本的第一IMU，每个副本反映直到第一快照时间对数据项做出的更改；
在从第一快照时间到晚于第一快照时间的第二快照时间的第一时段期间，所述数据库服务器通过以下来响应对所述镜像数据集中的第一数据项的更新：
更改第一数据项的持久性格式副本，而不更新第一IMU中的第一数据项的副本；以及
存储第一陈旧性元数据，所述第一陈旧性元数据指示第一IMU中的第一数据项的副本是陈旧的；
所述数据库服务器在易失性存储器中生成和维护第二IMU，第二IMU包括所述镜像数据集中的每个数据项的副本，每个副本反映直到第二快照时间对数据项做出的更改；
在第二快照时间开始的第二时段期间，数据库服务器通过以下来响应对所述镜像数据集中的第二数据项的更新：
更改第二数据项的持久性格式副本，而不更新第二IMU中的第二数据项的副本；以及
存储第二陈旧性元数据，所述第二陈旧性元数据指示第二IMU中的第二数据项的副本是陈旧的；
当所述数据库服务器维护第一IMU和第二IMU两者时，所述数据库服务器：
接收需要访问所述镜像数据集中的特定数据项的请求；
通过从包括第一IMU和第二IMU的所述镜像数据集的存储器中组选择IMU来响应所述请求；以及
从所选择的IMU获得至少一些数据项以生成对所述请求的响应；
其中所述方法由一个或多个计算设备执行。
如权利要求1所述的方法，其中在从第二快照时间开始的第二时段期间，所述数据库服务器响应对所述镜像数据集中的第二数据项的更新包括：
所述数据库服务器响应更新而不做出对第一陈旧性元数据的任何进一步更新。
如权利要求1所述的方法，其中在从第二快照时间开始的第二时段期间，所述数据库服务器响应对所述镜像数据集中的第二数据项的更新包括所述数据库服务器响应更新而不做出对第一陈旧性元数据的任何进一步更新。
2.如权利要求1所述的方法，其中所述数据库服务器响应所述请求包括：
当与所述请求相关联的目标快照时间在第一快照时间和第二快照时间之间时，所述数据库服务器选择第一IMU；
基于第一陈旧性元数据，所述数据库服务器确定第一IMU中的所述特定数据项的副本是否陈旧；
当确定第一IMU中的所述特定数据项的副本不陈旧时，访问第一IMU以检索所述特定数据项。
3.如权利要求1所述的方法，
其中生成第二IMU在完成时间结束；
其中所述数据库服务器响应所述请求包括：
当与所述请求相关联的目标快照时间在第二快照时间和完成时间之间时，所述数据库服务器选择第一IMU；
基于第一陈旧性元数据和第二陈旧性元数据，所述数据库服务器确定第一IMU中的所述特定数据项的副本是否陈旧；
当确定第一IMU中的所述特定数据项的副本不陈旧时，访问第一IMU以检索所述特定数据项。
4.如权利要求1所述的方法，
其中生成第二IMU在完成时间结束；
其中所述数据库服务器响应所述请求包括：
当与所述请求相关联的目标快照时间是在完成时间之后时，数据库服务器选择第二IMU；
基于第二陈旧性元数据，所述数据库服务器确定第二IMU中的所述特定数据项的副本是否陈旧；
当确定第二IMU中的所述特定数据项的副本不陈旧时，访问第二IMU以检索所述特定数据项。
5.如权利要求1所述的方法，其中，第一IMU和第二IMU以列为主的格式存储，并且所述持久性副本以行为主的格式存储在持久性数据集中。
6.如权利要求5所述的方法，还包括：当确定所述特定数据项在选自第一IMU和第二IMU的所选IMU中是陈旧的时，所述数据库服务器通过访问处于行为主的格式的持久性数据块或处于行为主的格式的持久性数据块的高速缓存版本来检索所述特定数据项。
7.如权利要求1所述的方法，其中生成第二IMU包括：
基于第一陈旧性元数据，识别第一IMU中在第二快照时间不陈旧的有效数据项集合；
基于第一IMU中不陈旧的所述有效数据项集合来填充第二IMU的第一部分；
通过从第一IMU以外的另一个源访问第一IMU中陈旧的数据项的副本来填充第二IMU的第二部分。
8.如权利要求1所述的方法，还包括：
所述数据库服务器在易失性存储器中生成和维护包括第一IMU和第二IMU的IMU集合；
其中，在版本开始快照时间和版本完成时间之间生成所述IMU集合的每个数据集版本；
在对应于特定数据集版本的版本开始快照时间开始并且在下一个数据集版本的版本开始快照时间结束的每个时段期间，所述数据库服务器通过以下来响应对所述镜像数据集中的数据项的更新：
更改数据项的持久性副本，而不更新所述特定数据集版本中的数据项的副本；以及
存储所述特定数据集版本的陈旧性元数据，所述陈旧性元数据指示所述特定数据集版本中的数据项的副本是陈旧的。
9.如权利要求8所述的方法，还包括：
当所述数据库服务器正在维护数据集的IMU集合时，所述数据库服务器接收需要访问第二特定数据项的第二请求；
基于所述请求的目标快照时间，所述数据库服务器确定数据集的IMU集合的当前版本，其中所述目标快照时间在当前版本的版本开始快照时间和当前版本的版本结束快照时间之间；
所述数据库服务器通过访问当前版本、紧挨着的先前版本或第二特定数据项的持久性副本来响应第二请求；
其中，当所述目标快照时间是在当前版本的版本完成时间之前时，当基于紧挨着的先前版本的陈旧性元数据和当前版本的陈旧性元数据，在紧挨着的先前版本中的第二特定数据项的副本不陈旧时，所述数据库服务器从紧挨着的先前版本检索第二特定数据项；
其中，当所述目标快照时间是在当前版本的版本完成时间之后时，当基于当前版本的陈旧性元数据，在当前版本中的第二特定数据项的副本不陈旧时，所述数据库服务器从当前版本检索第二特定数据项。
10.如权利要求8所述的方法，
其中，数据集的IMU集合中的版本的数量受限于特定大小，
还包括当生成导致超过所述特定大小的数据集的新IMU时，从易失性存储器中移除数据集的IMU集合中的最早版本。
11.如权利要求8所述的方法，还包括当检测到存储器压力状况时，从易失性存储器中移除数据集的IMU集合中的一个或多个IMU。
12.如权利要求1所述的方法，其中在从第二快照时间开始的第二时段期间，所述数据库服务器响应对所述镜像数据集中的第二数据项的更新包括所述数据库服务器响应更新而不做出对第一陈旧性元数据的任何进一步更新。
13.存储指令的一种或多种非瞬态计算机可读介质，所述指令当由一个或多个计算设备执行时，使得执行如权利要求1-12中任一项所述的方法。
CN201780043813.0A 2016-05-31 2017-05-30 用于数据库中的存储器中单元的非破坏性版本化的方法和设备 Active CN109478183B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/169,013 2016-05-31
US15/169,013 US10572469B2 (en) 2016-05-31 2016-05-31 Versioning and non-disruptive servicing of in-memory units in a database
PCT/US2017/034939 WO2017210157A1 (en) 2016-05-31 2017-05-30 Versioning and non-disruptive servicing of in-memory units in a database

Publications (2)

Publication Number Publication Date
CN109478183A true CN109478183A (zh) 2019-03-15
CN109478183B CN109478183B (zh) 2023-08-08

Family

ID=59031401

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780043813.0A Active CN109478183B (zh) 2016-05-31 2017-05-30 用于数据库中的存储器中单元的非破坏性版本化的方法和设备

Country Status (4)

Country Link
US (1) US10572469B2 (zh)
EP (1) EP3465473B1 (zh)
CN (1) CN109478183B (zh)
WO (1) WO2017210157A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10067974B2 (en) 2015-05-29 2018-09-04 Oracle International Corporation Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object
US10635541B2 (en) * 2017-10-23 2020-04-28 Vmware, Inc. Fine-grained conflict resolution in a shared log
US10649981B2 (en) 2017-10-23 2020-05-12 Vmware, Inc. Direct access to object state in a shared log
US11392567B2 (en) 2017-10-30 2022-07-19 Vmware, Inc. Just-in-time multi-indexed tables in a shared log
US10891234B2 (en) * 2018-04-04 2021-01-12 Sap Se Cache partitioning to accelerate concurrent workloads
US11347743B2 (en) 2020-04-01 2022-05-31 Sap Se Metadata converter and memory management system
US11347709B2 (en) * 2020-04-01 2022-05-31 Sap Se Hierarchical metadata enhancements for a memory management system
US11797600B2 (en) 2020-11-18 2023-10-24 Ownbackup Ltd. Time-series analytics for database management systems
WO2022106977A1 (en) * 2020-11-18 2022-05-27 Ownbackup Ltd. Continuous data protection using retroactive backup snapshots
US20230086203A1 (en) * 2021-09-15 2023-03-23 International Business Machines Corporation Stale data recognition
CN114610740B (zh) * 2022-05-12 2022-08-16 上海柯林布瑞信息技术有限公司 医疗数据平台的数据版本管理方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1842789A (zh) * 2004-03-29 2006-10-04 微软公司 用于在数据库恢复期间快照查询的系统和方法
US20160085834A1 (en) * 2014-09-24 2016-03-24 Oracle International Corporation Prioritizing repopulation of in-memory compression units
CN105556519A (zh) * 2013-09-21 2016-05-04 甲骨文国际公司 对oracle存储器中数据库的存储器中快照存储的多版本并行控制
CN105556520A (zh) * 2013-09-21 2016-05-04 甲骨文国际公司 在存储器中镜像盘中的数据以提高查询性能

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1332631A (en) 1971-02-26 1973-10-03 Ibm Data processing system
SE8307228D0 (sv) 1983-12-30 1983-12-30 Grundstenen 16808 Ab Datakomprimering
US5544347A (en) 1990-09-24 1996-08-06 Emc Corporation Data storage system controlled remote data mirroring with respectively maintained data indices
US5778430A (en) 1996-04-19 1998-07-07 Eccs, Inc. Method and apparatus for computer disk cache management
US5870759A (en) 1996-10-09 1999-02-09 Oracle Corporation System for synchronizing data between computers using a before-image of data
US6009432A (en) 1998-07-08 1999-12-28 Required Technologies, Inc. Value-instance-connectivity computer-implemented database
US7149769B2 (en) 2002-03-26 2006-12-12 Hewlett-Packard Development Company, L.P. System and method for multi-destination merge in a storage area network
US7555497B2 (en) 2003-08-21 2009-06-30 Microsoft Corporation Systems and methods for separating units of information manageable by a hardware/software interface system from their physical organization
US7349925B2 (en) 2004-01-22 2008-03-25 International Business Machines Corporation Shared scans utilizing query monitor during query execution to improve buffer cache utilization across multi-stream query environments
US7499917B2 (en) 2005-01-28 2009-03-03 International Business Machines Corporation Processing cross-table non-Boolean term conditions in database queries
US7430553B2 (en) 2005-12-30 2008-09-30 Microsoft Corporation Managing states with delta pager
US7574560B2 (en) 2006-01-03 2009-08-11 Emc Corporation Methods, systems, and computer program products for dynamic mapping of logical units in a redundant array of inexpensive disks (RAID) environment
US20080059492A1 (en) 2006-08-31 2008-03-06 Tarin Stephen A Systems, methods, and storage structures for cached databases
US7664866B2 (en) 2007-04-10 2010-02-16 Apertio Limited Sub-tree access control in network architectures
US8671076B2 (en) 2007-05-08 2014-03-11 Bmc Software, Inc. Database recovery using logs applied to consistent copies
US8782075B2 (en) 2007-05-08 2014-07-15 Paraccel Llc Query handling in databases with replicated data
US7979399B2 (en) 2008-06-10 2011-07-12 International Business Machines Corporation Database journaling in a multi-node environment
US10152504B2 (en) 2009-03-11 2018-12-11 Actian Netherlands B.V. Column-store database architecture utilizing positional delta tree update system and methods
US8401996B2 (en) 2009-03-30 2013-03-19 Commvault Systems, Inc. Storing a variable number of instances of data objects
US8583692B2 (en) 2009-04-30 2013-11-12 Oracle International Corporation DDL and DML support for hybrid columnar compressed tables
US8868510B2 (en) 2009-12-03 2014-10-21 Sybase, Inc. Managing data storage as an in-memory database in a database management system
US8433684B2 (en) 2010-03-30 2013-04-30 Sybase, Inc. Managing data backup of an in-memory database in a database management system
US8880508B2 (en) 2010-12-30 2014-11-04 Sap Se Processing database queries using format conversion
US20120323971A1 (en) 2011-06-14 2012-12-20 Sybase, Inc. Optimizing data storage and access of an in-memory database
US8504542B2 (en) 2011-09-02 2013-08-06 Palantir Technologies, Inc. Multi-row transactions
US8918436B2 (en) 2011-12-22 2014-12-23 Sap Ag Hybrid database table stored as both row and column store
US20140040218A1 (en) 2012-07-31 2014-02-06 Hideaki Kimura Methods and systems for an intent lock engine
US8856484B2 (en) 2012-08-14 2014-10-07 Infinidat Ltd. Mass storage system and methods of controlling resources thereof
US20140075493A1 (en) 2012-09-12 2014-03-13 Avaya, Inc. System and method for location-based protection of mobile data
US9842053B2 (en) * 2013-03-15 2017-12-12 Sandisk Technologies Llc Systems and methods for persistent cache logging
US9323799B2 (en) 2013-09-21 2016-04-26 Oracle International Corporation Mechanism to run OLTP workload on in-memory database under memory pressure
US9430390B2 (en) 2013-09-21 2016-08-30 Oracle International Corporation Core in-memory space and object management architecture in a traditional RDBMS supporting DW and OLTP applications
US10067974B2 (en) 2015-05-29 2018-09-04 Oracle International Corporation Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1842789A (zh) * 2004-03-29 2006-10-04 微软公司 用于在数据库恢复期间快照查询的系统和方法
CN105556519A (zh) * 2013-09-21 2016-05-04 甲骨文国际公司 对oracle存储器中数据库的存储器中快照存储的多版本并行控制
CN105556520A (zh) * 2013-09-21 2016-05-04 甲骨文国际公司 在存储器中镜像盘中的数据以提高查询性能
US20160085834A1 (en) * 2014-09-24 2016-03-24 Oracle International Corporation Prioritizing repopulation of in-memory compression units

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALFONS KEMPER: "HyPer: A Hybrid OLTP&OLAP Main Memory Database System Based on Virtual Memory Snapshots", 《IEEE》 *
HAO ZHANG: "In-Memory Big Data Management and Processing: A Survey", 《IEEE TRANSACTIONS ON KNOWLEDGE AND DATA ENGINEERING》 *

Also Published As

Publication number Publication date
EP3465473B1 (en) 2023-09-13
US10572469B2 (en) 2020-02-25
CN109478183B (zh) 2023-08-08
US20170344593A1 (en) 2017-11-30
WO2017210157A1 (en) 2017-12-07
EP3465473A1 (en) 2019-04-10

Similar Documents

Publication Publication Date Title
CN109478183A (zh) 数据库中的存储器中单元的版本化和非破坏性服务
US10120895B2 (en) Mirroring, in memory, data from disk to improve query performance
US10268746B2 (en) Mechanism to run OLTP workload on in-memory database under memory pressure
CN105556519B (zh) 对oracle存储器中数据库的存储器中快照存储的多版本并行控制
US9606921B2 (en) Granular creation and refresh of columnar data
US7117294B1 (en) Method and system for archiving and compacting data in a data storage array
US10430102B2 (en) Storage device, program, and information processing method
US8140495B2 (en) Asynchronous database index maintenance
CN107835983A (zh) 使用一致的数据库快照在分布式数据库中进行备份和还原
US20200301882A1 (en) Determining differences between two versions of a file directory tree structure
CN108140040A (zh) 存储器中数据库的选择性数据压缩
CN109074362A (zh) 分布式系统中的拆分和移动范围
WO2010048595A2 (en) Partition management in a partitioned, scalable, and available structured storage
CN111309720A (zh) 时序数据的存储、读取方法、装置、电子设备及存储介质
Petrov Database Internals: A deep dive into how distributed data systems work
Beineke et al. DXRAM's Fault-Tolerance Mechanisms Meet High Speed I/O Devices

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant