Oracle International Corporation

J William Lee

Juan R Loaiza

William Havinden Bridge, Jr

Wei-Ming Hu

Alex Tsukerman

Gianfranco Putzolu

Jonathan D Klein

Adam Y Lee

Vipin Gokhale

Kothanda Umamageswaran

Bharat Chandra Baddepudi

Neil J S MacNaughton

Tirthankar Lahiri

Yunrui Li

Alok Kumar Srivastava

Roger J Bamford

Gary C Ngai

Vinay H Srihari

Jia Shi

William Bridge

Mark Dilman

Dmitry Mikhailovich Potapov

Alok Pareek

Neil MacNaughton

Wei Ming Hu

Kiran Badrinarain Goyal

Michael James Stewart

Hasan Rizvi

Amit Ganesh

Garret Frederick Swart

Kumar Rajamani

Mahesh Baburao Girkar

Vivekanandhan Raja

Bipul Sinha

Niloy Mukherjee

David Vengerov

Jaebock Lee

Michael P Stewart

Sanket Hase

Arvind Nithrakashyap

Selcuk Aya

Muthu Olagappan

Madhusudan Krishnapuram

Michael John Skarpelos

Sreedhar Mukkamalla

Steven Wertheimer

Hochak Hung

Boris Erlikhman

Amrish Srivastava

Wanli Yang

Ankur Kemkar

Francisco Sanchez

Alexander Hwang

Carlos Ruiz

Shen-Ban Meng

Vishvesh Mohanarangam Selvakumaar

Sivaram Prasad Soma

Neil JS Macnaughton

Juan R Loiza

Kiran B Goyal

Neil Js Macnaughton

Wei Hu

William H Bridge

Jr William H Bridge

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

Techniques herein store database blocks (DBBs) in byte-addressable persistent memory (PMEM) and prevent tearing without deadlocking or waiting. In an embodiment, a computer hosts a DBMS. A reader process of the DBMS obtains, without locking and from metadata in PMEM, a first memory address for directly accessing a current version, which is a particular version, of a DBB in PMEM. Concurrently and without locking: a) the reader process reads the particular version of the DBB in PMEM, and b) a writer process of the DBMS replaces, in the metadata in PMEM, the first memory address with a second memory address for directly accessing a new version of the DBB in PMEM. In an embodiment, a computer performs without locking: a) storing, in PMEM, a DBB, b) copying into volatile memory, or reading, an image of the DBB, and c) detecting whether the image of the DBB is torn.

Persistent memory file store for directly mapped persistent memory database

A method and an apparatus for implementing a buffer cache for a persistent file system in a non-volatile memory is provided. A set of data is maintained in one or more extents in a non-volatile random-access memory (NVRAM) of a computing device. At least one buffer header is allocated in a dynamic random-access memory (DRAM) of the computing device. In response to a read request by a first process executing on the computing device to access one or more first data blocks in a first extent of the one or more extents, the first process is granted direct read access of the first extent in the NVRAM. A reference to the first extent in the NVRAM is stored in a first buffer header. The first buffer header is associated with the first process. The first process uses the first buffer header to directly access the one or more first data blocks in the NVRAM.

Directly mapped buffer cache on non-volatile memory

A method and apparatus for implementing a buffer cache for a persistent file system in non-volatile memory is provided. A set of data is maintained in one or more extents in non-volatile random-access memory (NVRAM) of a computing device. At least one buffer header is allocated in dynamic random-access memory (DRAM) of the computing device. In response to a read request by a first process executing on the computing device to access one or more first data blocks in a first extent of the one or more extents, the first process is granted direct read access of the first extent in NVRAM. A reference to the first extent in NVRAM is stored in a first buffer header. The first buffer header is associated with the first process. The first process uses the first buffer header to directly access the one or more first data blocks in NVRAM.

A storage device uses non-volatile memory devices for caching. The storage device operates in a mode referred to herein as write-back mode. In write-back mode, a storage device responds to a request to write data by persistently writing the data to a cache in a non-volatile memory device and acknowledges to the requestor that the data is written persistently in the storage device. The acknowledgement is sent without necessarily having written the data that was requested to be written to primary storage. Instead, the data is written to primary storage later.

Write-back storage cache based on fast persistent memory

Techniques are provided for managing cached data objects in a mixed workload environment. In an embodiment, a database system receives request to access a target data object. The database system determines whether the request to access the target data object is associated with a first type of workload or a second type of workload. In response to determining that the request is associated with the first type of workload, the target data object replaces a least recently used data object in a cache. In response to determining that the request is associated with the second type of workload, the target data object is cached based on an associated access-level value.

Caching large objects in a computer system with mixed data warehousing and online transaction processing workload

In an approach, a database server maintains a container database which comprises: one or more pluggable databases, a root database that stores an undo log for rolling back transactions on the consolidated database, and a redo log for replaying modifications to the container database. The database server restores a particular pluggable with a backup version that corresponds to a first point in time. The database server generates a clone database loaded with a backup version of the root database that corresponds to the first point in time. The database server applies the redo log to recover the particular pluggable database and the clone database to a second point in time that is later than the first point in time. The database server identifies, based on the clone database, one or more active transactions on the particular pluggable database. The database server rolls back the one or more active transactions.

In place point-in-time recovery of pluggable databases

A standby database system or another replica data system replicates changes, made to data blocks at a source database system or another primary data copy, to replicas of the data blocks at the standby database system or other replica. While replicating the changes to the data blocks thereof, the standby database system (or other replica) receives queries (or reads) issued thereto and computes the queries based on data read from the data blocks thereof.

Readable physical storage replica and standby database system

Techniques are described herein for returning a repository to a prior state. The repository may be, for example a database, and the prior state may be, for example the consistent state that the database had at a particular point in time in the past. When a operator-caused error has been introduced to the database by changes made by an already-committed transaction, the techniques described herein may be used to recover from the error by returning the database to a point in time prior to the commit time of the transaction that introduced the error. The techniques involve the generation of 'physical undo' information, and the use of the physical undo information in conjunction with physiological undo and physiological redo to efficiently return a repository to the prior state.

Flashback database

Techniques are provided for detecting lost writes so that data corruption can be avoided. According to one technique, lost writes are detected by comparing version numbers that are indicated in redo log entries with version numbers that are indicated in corresponding blocks in a standby database. According to one technique, which may be used in conjunction with the above technique, lost writes are detected by logging read operations that occur relative to a primary database, and comparing version numbers that are indicated in read log entries with version numbers that are indicated in corresponding blocks in a standby database. According to one technique, lost writes are detected by comparing, in response to read operations, (a) version numbers that are stored in a persistent in-memory cache with (b) version numbers that are indicated in corresponding blocks that are read from a primary database.

Lost write detection and repair

A method and apparatus for creating a target database on a target platform based on a source database on a source platform is provided. A target database is created on the target platform based on data, metadata (for example, data in the system tablespace and control files), and external objects (for example, password files and externally stored tables) comprised within the source database. Data and metadata stored in tablespaces of the source database are converted to the format compatible with the target platform. The conversion of the data and metadata may be performed either at the source database or the target database. Redo information and undo information of the source database are not copied from the source database to the target database. Certain files, e.g., a password files, and links to externally stored object may be recreated on the target database.

Cross-platform transportable database

Provided herein is a mechanism that allows a given database system to access data blocks from another database system, where data blocks from the given database system and data blocks from the other database system have different sizes. According to an aspect of the present invention, a tablespace in the other database system contained the data blocks. The tablespace is detached from the other database system and integrated into the given database, which is capable of processing data stored in data blocks of a different sizes.

Integrating tablespaces with different block sizes

A pluggable tablespace is enabled by logically partitioning a database into a set of tablespaces and storing all of the tablespaces disk pointers in tablespace-relative format. A pluggable set of tablespaces is unplugged by generating the associated metadata, and making a binary copy of the tablespaces. The pluggable set of tablespaces is plugged into a target database by making the pluggable set accessible to the target database and incorporating the associated metadata, without patching any of the disk pointers.

Pluggable tablespaces for database systems

A method and system for propagating commit times between a plurality of database servers that have access to a common database is provided. According to the method, each database server is associated with a logical clock. In response to initiating a commit of a transaction executing on a database server, a commit time for the transaction is determined and broadcast to one or more other database servers. According to one aspect, upon receiving the commit time at the one or more other database servers, the database servers compare the transmitted commit time to the time indicated by their logical clock. If the commit time is greater than the time indicated by their logical clock, the database server sets its logical time to reflect a time that is at least as recent as the time reflected by the transmitted commit time.

Method and apparatus for propagating commit times between a plurality of database servers

Growing community of inventors

Belmont, CA, United States of America

J William Lee