Oracle International Corporation

Mahesh Baburao Girkar

Yunrui Li

Juan R Loaiza

Amrish Srivastava

Sachin Vijaykumar Sonawane

Wei-Ming Hu

Vinay H Srihari

Stephen John Vivian

Benedicto Elmo Garin, Jr

George H Claborn

Nitin Karkhanis

Steve Lee

Hongjie Yang

Vivekanandhan Raja

Joydip Kundu

Raymond Guzman

Benedicto Garin

Jing Zheng

Robert McGuirk

Steven McGee

David Gagne

Sachin Vijakumar Sonawane

Thomas Baby

James William Stamos

Giridhar Ravipati

Wei Ming Hu

Douglas Andrew Voss

Jonghyun Lee

Jiangbin Luo

Sadhana Kyathappala

Michael Harvey

Benedito Elmo Garin, Jr

Qingguang Cui

Frank De Lange

Tirthankar Lahiri

Garret Frederick Swart

Gopalan Arun

Jia Shi

Ramesh Vasudevan

J William Lee

Vasudha Krishnaswamy

Neil MacNaughton

Richard James Anderson, Jr

Sukhada Pendse

Tolga Yurek

Kartik Kulkarni

Ashok M Joshi

Adam Y Lee

Vsevolod Panteleenko

Prabuddha Biswas

Carlos Ruiz

Mark Rakhmilevich

Ian Stuart Neall

Shanshan Song

Hongyi Yao

Jin-Jwei Chen

Theocharis Kampouris

Michael Jennings

Robert R McGulrk

Shruti Gautam

Henry Chau

Ian Neall

Frank Lange

Techniques are described herein for an integrated in-front database cache ('IIDC') providing an in-memory, consistent, and automatically managed cache for primary database data. An IIDC comprises a database server instance that (a) caches data blocks from a source database managed by a second database server instance, and (b) performs recovery on the cached data using redo records for the database data. The IIDC instance implements relational algebra and is configured to run any complexity of query over the cached database data. Any cache miss results in the IIDC instance fetching the needed block(s) from a second database server instance managing the source database that provides the IIDC instance with the latest version of the requested data block(s) that is available to the second instance. Because redo records are used to continuously update the data blocks in an IIDC cache, the IIDC guarantees consistency of query results.

Diskless active data guard as cache

Herein is high availability for online transaction processing with redundancy and redo for a federation of pluggable databases and container databases. In an embodiment of a federation of container database management systems that includes a first container database, first redo data of a first pluggable database in a second container database is obtained based on a database dictionary in the first container database. To the first pluggable database in the first container database, the first redo data of the first pluggable database in the second container database is applied. Based on the database dictionary in the first container database, second redo data of a second pluggable database in a third container database is obtained. To the second pluggable database in the first container database, without modifying content of the first pluggable database in the first container database, the second redo data of the second pluggable database in the third container database is applied.

Data guard at PDB (pluggable database) level

A blockchain object stores multiple user blockchains, each blockchain comprising an ordered set of records in the blockchain object. The records of a user blockchain have the same blockchain key value. Users can create multiple blockchains by establishing respective blockchain key values for the blockchains. Like blocks in a blockchain, the records in a user blockchain are ordered by a sequence of numbers that is specific to the user blockchain; each user blockchain has its own sequence of numbers. Each record in a user blockchain holds a sequence number in a field of the blockchain object. An efficient mechanism maintains and assigns a sequence number to a record when appended to a user blockchain.

User-specified chains and row versions in a blockchain table

In Secure-Asynchronous Signing, when a record is inserted into a collection of records by a user, the user specifies a registered digital certificate to associate with the record. The digital certificate was previously registered by the user. To subsequently sign a record, the user provides a digital signature. The digital signature is validated using data in the record and a public key of the digital certificate that was associated with the row. Invalid digital signatures are detected and rejected regardless of how long afterward the attempt to sign the row occurs after inserting the row.

Deferred and secure data signing

Disclosed is a system, method, and computer program product that generates masked data from within a database infrastructure. Instead of requiring an external tool to generate masked data, a database generates masked data using its internal processing mechanisms.

Real-time masking in a standby database

Techniques described herein allow a standby DBMS to maintain consistency of results for transactions that include redirected DML commands without requiring the standby DBMS to delay execution of queries that do not require changed objects. Specifically, a standby session records DML target object (DTO) record with information regarding DML-changed objects and transaction information from the primary DBMS. Using DTO records, the standby DBMS ensures that results of any additional queries include changes made by the redirected DML commands without delaying execution of queries that do not access changed objects. If a target object in a standby query is in a DTO record, then query execution is delayed until the standby database is updated to the timestamp indicated in the DTO record. Thus, the delayed query has access to changes made by the DML command. Otherwise, the query is immediately executed without waiting for the standby database synchronization.

Optimized synchronization for redirected standby DML commands

Herein is high availability for online transaction processing with redundancy and redo for a federation of pluggable databases and container databases. In a federation of container database management systems that includes a first container database, first redo data of a first pluggable database in a second container database is obtained based on a database dictionary in the first container database. To the first pluggable database in the first container database, the first redo data of the first pluggable database in the second container database is applied. Based on the database dictionary in the first container database, second redo data of a second pluggable database in a third container database is obtained. To the second pluggable database in the first container database, without modifying content of the first pluggable database in the first container database, the second redo data of the second pluggable database in the third container database is applied.

A database session in an active standby server on which an active standby database resides receives a DML statement. The session is suspended while the statement is redirected over a database link to a primary database on which the statement is executed. Information associated with execution of the statement is communicated to the session in the active standby server. Redo records describing changes to the contents of the primary database are applied to the active standby database and control is returned to the session. Prior to commitment of a transaction including the statement, a query directed to data to which the statement was directed is received at the active standby server from a client and executed on the active standby database absent use of a database link based on whether information associated with a database session associated with the client matches the information associated with execution of the statement.

Method and system for supporting data consistency on an active standby database after DML redirection to a primary database

Techniques related to query execution against an in-memory standby database are disclosed. A first database includes PF data stored on persistent storage in a persistent format. The first database is accessible to a first database server that converts the PF data to a mirror format to produce MF data that is stored within volatile memory. The first database server receives, from a second database server, one or more change records indicating one or more transactions performed against a second database. The one or more change records are applied to the PF data, and a reference timestamp is advanced from a first to a second timestamp. The first database server invalidates any MF data that is changed by a subset of the one or more transactions that committed between the first and second timestamps.

Query execution against an in-memory standby database

Herein are high throughput techniques for incorporating cryptographic blockchains into relational data. In an embodiment, a computer indicates, in a database dictionary in a database, that a relational table is for blockchain storage. The relational table contains application column(s). In response to that indication, the relational table is associated with system column(s) that are unmodifiable by administrators and clients of the database. The system column(s) include a cryptographic hash column. A request to store a particular value in a particular application column is received from a client. In response to receiving the request, a cryptographic hash value is calculated for a new row for the relational table. In the relational table, the computer stores the new row that contains: the particular value in the particular application column, and the cryptographic hash value in the cryptographic hash column.

Supporting blockchain collections in a database

Distributed ledgered data is stored within a distributed persistent storage system comprising multiple persistent storage systems as distributed ledgered participants. In various embodiments, the distributed ledgered data is maintained using the native capabilities of a persistent storage system. The distributed ledgered data is replicated as persistent data objects in a 'ledgered repository of objects' that are replicated at each of the persistent storage systems. Changes at one persistent storage system are recorded within a block in a distributed blockchain that is distributed across each of the other distributed ledgered participants. The other distributed ledgered participants read the changes from the blockchain and apply the changes to the respective replicas at each of the other distributed ledgered participants. Hence, this approach is referred to as blockchain apply. Blockchain apply may be used to replicate the repository objects of various forms of PSSs. In a DBMS, a repository of objects is a table, where each record or row is an object in the repository. In a file system, a repository of objects is a directory, where each directory and file therein is an object in the repository. In a document storage system (DOCS), a repository of objects is a collection of documents, where each document is an object in the repository.

Native persistent store support for blockchains

Embodiments allow a primary database system ('primary') to automatically detect queries directed to the primary database that may be offloaded to a standby database system ('standby'), and then to automatically offload the offload-eligible queries to a standby. The primary identifies offload-eligible queries based on a record of up-to-date database objects within each standby that replicates the primary database. The record of up-to-date standby objects is updated based on heartbeat messages from each standby, and commit timestamps for transactions on the primary. Evaluation of whether a query is offload-eligible is triggered by one or more trigger conditions that include: inclusion of an offload optimizer hint in the query, an estimated run-time of the query, etc. Embodiments further allow an offloaded query over particular changed data in the primary database to access, on a standby database, uncommitted changes made to the particular data in the primary database.

Automatic query offloading to a standby database

Disclosed are methods and apparatuses to provide a redo repeater that allows for no data loss protection without the performance impact to the primary database even when a significant geographical distance separates the primary and standby databases. The Repeater is a lightweight entity that receives redo from the primary database with the purpose of redistributing that redo throughout the primary/standby system configuration. The Repeater able to extend no data loss protection and switchover functionality to terminal standby databases even though the primary database does not need to have a direct connection with those destinations.

Method and system for implementing a redo repeater

A method, apparatus, and system for a time-based checkpoint target is provided for standby databases. Change records received from a primary database are applied for a standby database, creating dirty buffer queues. As the change records are applied, a mapping is maintained, which maps timestamps to logical times of change records that were most recently applied at the timestamp for the standby database. On a periodic dirty buffer queue processing interval, the mapping is used to determine a target logical time that is mapped to a target timestamp that is prior to a present timestamp by at least a checkpoint delay. The dirty buffer queues are then processed up to the target logical time, creating an incremental checkpoint. On a periodic header update interval, file headers reflecting a consistent logical time for the checkpoint are also updated. The intervals and the checkpoint delay are adjustable by user or application.

Time-based checkpoint target for database media recovery

Growing community of inventors

Cupertimo, CA, United States of America

Mahesh Baburao Girkar