Patent application number | Description | Published |
20110178984 | REPLICATION PROTOCOL FOR DATABASE SYSTEMS - Database management architecture for recovering from failures by building additional replicas and catching up replicas after a failure. A replica includes both the schema and the associated data. Modifications are captured, as performed by a primary replica (after the modifications have been performed), and sent asynchronously to secondary replicas. Acknowledgement by a quorum of the replicas (e.g., primary, secondaries) at transaction commit time is then awaited, and desired to be obtained. The logging of changes for recovery from failures is implemented, as well as online copying (e.g., accepting modifications during the copy) of the data when replica catch-up is not possible. Modifications can be sent asynchronously to the secondary replicas and in parallel. | 07-21-2011 |
20110179008 | HOSTING MULTIPLE LOGICAL DATABASES CONTAINED IN PHYSICAL DATABASE - Architecture that defines a logical database that shares physical resources with a containing physical database. The architecture isolates the relational engine system metadata parts of a database in horizontal scopes to form separate namespaces, and shares the underlying storage engine system metadata. Sharing physical database resources enables efficient input/output (I/O) utilization and instantaneous database creation and growth. In addition, logical databases can be backed up as a single transactionally consistent unit. | 07-21-2011 |
20110191299 | LOGICAL DATA BACKUP AND ROLLBACK USING INCREMENTAL CAPTURE IN A DISTRIBUTED DATABASE - Architecture that eliminates the need for on-disk full backups of data retaining only changes that have occurred, in a separate table. Thus, the architecture provides for incremental recovery of incremental changes in a relational database (e.g., SQL). The architecture provides improved recovery time and recovery point objectives. By using the incremental capture of changed data (e.g., in an XML format), the capability is provided to capture schema changes, query the incremental change data and efficiently restore user data to an earlier point-in-time state. Changes (e.g., insert, update and delete operations) are tracked (e.g., continuously) by a set of triggers and the incrementally captured changed rows are inserted in a data capture table (a differential change “delta” table) in a human-readable format (e.g., XML). Rollback is also provided. | 08-04-2011 |
20110225122 | REORGANIZATION OF DATA UNDER CONTINUOUS WORKLOAD - Architecture that provides the capability to automatically (e.g., dynamically) reorganize (repartition) an existing partition by dividing (splitting) or recombining (merging) logical databases. This reorganization can be performed to logical databases belonging to the same customer, and based on the partitioning of the tables in these databases. This can include not only splitting secondary replicas of a partition or merging secondary replicas of the partition, but also splitting off secondary replicas of the partition to create a new partition and merging two partitions into one partition. Moreover, these operations can occur while the logical databases are accepting workload (online). | 09-15-2011 |
20120109892 | PARTITIONING ONLINE DATABASES - The present invention extends to methods, systems, and computer program products for partitioning online databases. Online database operations, such as, for example, SPLIT, MERGE, and DROP, are used to alter the arrangement of partitions in a federated database. A SPLIT operation splits rows at one partition across a plurality of other partitions. A MERGE operation merges rows at a plurality of partitions in to one partition. A DROP operation shifts responsibility for rows of data from one partition to another partition and then drops the rows from the one partition. | 05-03-2012 |
20120124001 | INCREASING DATABASE AVAILABILITY DURING FAULT RECOVERY - Embodiments are directed to providing database access during database reconfiguration and to maintaining replication connections during database reconfiguration. In an embodiment, a computer system establishes multiple quorum sets of replicas to replicate the data of a data partition. The quorum sets of replicas ensure that at least a minimum number of replicas are operating to commit pending transactions during partition reconfiguration. The computer system determines that a data partition reconfiguration has been initiated and provides access to the data partition's data during reconfiguration of the data partition using at least a quorum of replicas in each of the quorum sets of replicas. | 05-17-2012 |
20120239616 | SEAMLESS UPGRADES IN A DISTRIBUTED DATABASE SYSTEM - Embodiments are directed to providing distributed database service upgrades of database server instances in a computer cluster using multiple database server instances and to monitoring and maintaining a distributed database service during upgrade. In an embodiment, each computer system in a computer cluster instantiates at least two different database server instances on each of the nodes in the cluster. The first database server instances are configured to operate using a current distributed database version and the second instances are configured to operate using a new, updated distributed database service version. The computer system receives an indication that the distributed database service is to be upgraded. Then, based on the received indication, the computer system migrates database replicas from the first database server instances to the second database server instances which operate the new, updated service version, substantially without user-visible downtime. | 09-20-2012 |
20130212068 | DATABASE POINT-IN-TIME RESTORE AND AS-OF QUERY - A database is queried as of any wall-clock time within a retention period, via undo that uses database snapshots and a list of page level modifications. The snapshot is user-identified, automatically generated, or extracted from a backup. The list is maintained in a transaction log by persisting page content before a page is re-used, persisting deleted rows before they are moved, persisting compensation log record undo information, and/or logging a full page. To rewind an entire database, the undo scans the transaction log in reverse LSN order and undoes all page modifications. Undo reverses reallocated pages, table truncation, and/or table deletion, as well as page-level modifications of a schema, metadata values, and/or system tables. An as-of query is handled using as-of page(s) from a sparse page file. If the sparse page file does not already contain the responsive page(s), they are created and added to it. | 08-15-2013 |
20140236887 | DATA SEEDING OPTIMIZATION FOR DATABASE REPLICATION - Streaming database replication is provided by merging a stream of user transactions with a stream of copy transactions comprising copy data into a combined stream on a source. A target receives a single stream that includes copy transaction and concurrent user transactions in an order that enables conflicts between data being copied and user transactions to be handled correctly. Furthermore, locks applied to data subject to a copy transaction or user transaction can be released once the copy transaction or user transaction is added to the combined stream. | 08-21-2014 |
20140236891 | RECOVERY POINT OBJECTIVE ENFORCEMENT - A maximum lag between data stores can be specified that corresponds to a recovery point objective defined in a service level agreement. Lag can be monitored during a data replication between a primary data store and a secondary data store located in geographically different regions. Activity on the primary data store including incoming data transactions can be throttled as a function of the lag and the maximum lag. | 08-21-2014 |
20140258229 | RECONCILIATION OF GEO-REPLICATED DATABASE CLUSTERS - A database associated with a primary database cluster may be replicated in a backup database cluster located in a different location in order to provide a highly-available fault tolerant database service. The databases are reconciled through a cluster management module distributed in each database cluster. The cluster management module uses a set of reconciliation data structures to track locally the reconciled states of each database in each database cluster, the operations made locally to the databases in each database cluster, and the author of the operations. The cluster management module in each database cluster engages in a stateless messaging protocol using the set of reconciliation data structures to determine whether or not the databases may be reconciled. | 09-11-2014 |
20140344221 | PARTITIONING ONLINE DATABASES - Methods, systems, and computer program products are provided for partitioning online databases. Online database operations, such as, for example, SPLIT, MERGE, and DROP, are used to alter the arrangement of partitions in a federated database. A SPLIT operation splits rows at one partition across a plurality of other partitions. A MERGE operation merges rows at a plurality of partitions in to one partition. A DROP operation shifts responsibility for rows of data from one partition to another partition and then drops the rows from the one partition. | 11-20-2014 |