Oracle International Corporation

Yunrui Li

Mahesh Baburao Girkar

Vinay H Srihari

Kumar Rajamani

Giridhar Ravipati

Tirthankar Lahiri

Jaebock Lee

Jonghyun Lee

Juan R Loaiza

Wei Ming Hu

Sanket Jain

Graham Ivey

Vsevolod Panteleenko

Chi Cao Minh

Amrish Srivastava

Teck Hua Lee

Tolga Yurek

Shampa Chakravarty

Jing Zheng

Garret Frederick Swart

Wei-Ming Hu

Vivekanandhan Raja

Jia Shi

Vasudha Krishnaswamy

Sukhada Pendse

Muthu Olagappan

Kartik Kulkarni

Benedicto Elmo Garin, Jr

Meichun Hsu

Shasank Kisan Chavan

Boris Klots

Thomas Baby

Wilson Wai Shun Chan

Jesse Kamp

William Havinden Bridge, Jr

J William Lee

Ajit Mylavarapu

Allison Holloway

Margaret Susairaj

Hideaki Kimura

Neil MacNaughton

Aurosish Mishra

Ramana Yerneni

Anjan Kumar Amirishetty

Nitin Karkhanis

Sachin Vijaykumar Sonawane

Sadhana Kyathappala

David Gagne

Ian Stuart Neall

Shanshan Song

Qingguang Cui

Kothanda Umamageswaran

Carol L Colrain

Niloy Mukherjee

Yi Ding

Krishnan Meiyyappan

Mark Dilman

Kevin S Neel

Gianfranco Putzolu

Wilson Wai Chan

Bharat Chandra Baddepudi

Neil J S MacNaughton

Kiran Badrinarain Goyal

Zuoyu Tao

Andre Kruglikov

Chandrasekharan Iyer

Stephen John Vivian

Vijay Sridharan

Adam Y Lee

Jonathan Giloni

Vipin Gokhale

Hochak Hung

Philip Yam

Nilesh Choudhury

Sushil Kumar

Semen Ustimenko

Frank De Lange

Hongjie Yang

Carlos Ruiz

Xiaoli Qi

Shih-Yu Huang

Zheren R Zhang

German Shegalov

Ping-Hsiu Hsieh

Hongyi Yao

Theocharis Kampouris

Michael Jennings

Ramana Yemeni

Qiang Cao

Shruti Gautam

Henry Chau

Steven J Mcgee

Kai Zhang

Michael Cusson

Salini Selvaraj Kowsalya

Ian Neall

Somayeh Sardashti

Yiliang Jin

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

The present disclosure relates to adaptively overlapping redo writes. A log writer, while operating in a thin mode, may assign a first log writer group of a plurality of log writer groups to write one or more first redo log records to an online redo log in response to determining that a pipelining parameter is satisfied. The thin mode may be associated with one or more target sizes that are less than one or more target sizes associated with a thick mode. The log writer may determine to operate the thick mode based at least in part on at least a portion of the plurality of log writer groups being unavailable to write one or more second redo log records to the online redo log. The log writer, while operating in the thick mode, may assign a second log writer group of the plurality of log writer groups to write one or more second redo log records from the log buffer to the online redo log in response to determining that an amount of redo log records in the log buffer meets one of the one or more target sizes associated with the thick mode. The log writer, while operating in the thick mode, may assign a third log writer group of the plurality of log writer groups to write one or more second redo log records from the log buffer to the online redo log in response to determining that a highest busy group number meets or exceeds a core threshold.

Adaptively overlapping the writing of redo log records

Techniques are described for preserving the inflight sessions failing over from a primary database to the replicated logical database of the primary database. In an implementation, prior to failover, when the primary database server receives a commit for a transaction, the process stores a commit indication that the transaction has been committed by performing a corresponding SQL command. The commit indication is replicated to the logical replica database by virtue of the replication of the SQL command and its execution on the logical replica database. Accordingly, the standby database server in the failover session may successfully request for the outcome of the transaction. Techniques are also described for the client-side LOB references to be preserved when failing over to the logical replica database, for AS OF queries preserved, and for versioning of checksums, signatures and structures across logical replicas.

Failover of database sessions to a logical replica database

In an embodiment, before modifying a persistent ORL (ORL), a database management system (DBMS) persists redo for a transaction and acknowledges that the transaction is committed. Later, the redo is appended onto the ORL. The DBMS stores first redo for a first transaction into a first PRB and second redo for a second transaction into a second PRB. Later, both redo are appended onto an ORL. The DBMS stores redo of first transactions in volatile SRBs (SLBs) respectively of database sessions. That redo is stored in a volatile shared buffer that is shared by the database sessions. Redo of second transactions is stored in the volatile shared buffer, but not in the SLBs. During re-silvering and recovery, the DBMS retrieves redo from fast persistent storage and then appends the redo onto an ORL in slow persistent storage. After re-silvering, during recovery, the redo from the ORL is applied to a persistent database block.

Increasing OLTP throughput by improving the performance of logging using persistent memory storage

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 shared-nothing database system is provided in which parallelism and workload balancing are increased by assigning the rows of each table to 'slices', and storing multiple copies (“duplicas”) of each slice across the persistent storage of multiple nodes of the shared-nothing database system. When the data for a table is distributed among the nodes of a shared-nothing system in this manner, requests to read data from a particular row of the table may be handled by any node that stores a duplica of the slice to which the row is assigned. For each slice, a single duplica of the slice is designated as the “primary duplica”. All DML operations (e.g. inserts, deletes, updates, etc.) that target a particular row of the table are performed by the node that has the primary duplica of the slice to which the particular row is assigned. The changes made by the DML operations are then propagated from the primary duplica to the other duplicas (“secondary duplicas”) of the same slice.

System and method for an ultra highly available, high performance, persistent memory optimized, scale-out database

An approach is described to provide a method, a computer program product, and a computer system to implement hole punching. The described approach provides an automated way to free up space without requiring manual intervention by a DBA to manually reorganize database objects to free up space.

Automatic reclamation of storage space for database systems

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

A method and apparatus for elimination of log file synchronization delay at transaction commit time is provided. One or more change records corresponding to a database transaction are generated. One or more buffer entries comprising the one or more change records are entered into a persistent change log buffer. A commit operation is performed by generating a commit change record corresponding to the database transaction and entering a commit buffer entry comprising the commit change record into the persistent change log buffer. The commit operation returns without waiting for the commit change record to be recorded in a change record log file.

Elimination of log file synchronization delay at transaction commit time

A computer's processes and/or threads generate and store in memory, data to reimplement or reverse a transaction on a database, so that the database can be recovered. This data is written to persistent memory storage ('persisted') by another process, for which the processes and/or threads may wait. This wait includes at least a sleep phase, and additionally a spin phase which is entered if after awakening from sleep and checking ('on-awakening' check), the data to be persisted is found to not have been persisted. To sleep in the sleep phase, each process/thread specifies a sleep duration determined based at least partially on previous results of on-awakening checks. The previous results in which to-be-persisted data was found to be not persisted are indications the sleeps were insufficient, and these indications are counted and used to determine the sleep duration. Repeated determination of sleep duration makes the sleep phase adaptive.

Adaptive synchronization for redo writing to persistent memory storage

A computer program product, system, and computer implemented method for management of a consolidated database and implementing pluggable database recovery with redo filtering in a consolidated database according to some embodiments. Generally, the process includes ongoing activities that maintain activity logs and summarize the activity for respective activity logs (e.g., in an activity vector maintained in a consolidated database catalog). In some embodiments, event-based activities corresponding to recovery processes are triggered by an administrator or an automated process, completed and then do not occur again until another triggering event. The event-based activities can leverage the summary information to quickly determine which online activity logs are relevant to the type of recovery operation for a particular pluggable database. In this way the approach provided herein enables recovery without requiring that all log activity be analyzed to determine whether it is relevant to a particular pluggable database.

Efficient pluggable database recovery with redo filtering in a consolidated 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

Growing community of inventors

Fremont, CA, United States of America

Yunrui Li