Oracle International Corporation

Sachin Vijaykumar Sonawane

Mahesh Baburao Girkar

Juan R Loaiza

Yunrui Li

James William Stamos

Thomas Baby

Vivekanandhan Raja

Wei-Ming Hu

Wei Ming Hu

Amrish Srivastava

Hongjie Yang

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

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

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.

Growing community of inventors

Redwood City, CA, United States of America

Sachin Vijaykumar Sonawane