Oracle International Corporation

Jaebock Lee

Kumar Rajamani

Giridhar Ravipati

Sanket Jain

Yunrui Li

Hochak Hung

Philip Yam

Andre Kruglikov

Shrikanth Shankar

Chi Cao Minh

Chandrasekharan Iyer

Jonghyun Lee

Russell John Green

Alexander Chen

Guhan Viswanathan

Ho Chak Hung

Jen-Cheng Huang

Tirthankar Lahiri

William H Waddington

Wei-Ming Hu

Niloy Mukherjee

Vinay H Srihari

Jia Shi

Mark Dilman

J William Lee

Margaret Susairaj

Neil MacNaughton

Susan M Kotsovolos

Muthu Olagappan

Subhransu Basu

Bharat Chandra Baddepudi

Kiran Badrinarain Goyal

John E McHugh

Vipin Gokhale

Rajagopalan Govindarajan

Nicolas Michael

David M Alpern

Yixiao Shen

Alan Choi

Churn Don Lee

Phillip Yam

Embodiments minimize downtime involved in moving a PDB between CDBs by allowing read-write access to the PDB through most of the moving operation, and by transparently forwarding connection requests, for the PDB, from the source CDB to the destination CDB. The files of a source PDB are copied from a source CDB to a destination CDB, during which the source PDB may be in read-write mode. The source PDB is then closed to write operations so that changes to the source PDB cease. Another round of recovery is performed on the PDB clone, which applies all changes that have been performed on the source PDB during the copy operation and the PDB clone is opened for read and write operations. Forwarding information is registered with the source location, which information is used to automatically forward connection requests, received at the source location for the moved PDB, to the destination location.

Near-zero downtime relocation of a pluggable database across container databases

Provided herein are data cloud administration techniques that achieve autonomy by using a rules engine that reacts to a database system event by autonomously submitting an asynchronous job to reconfigure a database. In an embodiment, a rules engine receives an event from a DBMS. Based on the event, the rules engine executes a rule to generate a request that indicates configuration details for a database. The rules engine sends the request to a request broker. The request broker dispatches an asynchronous job based on the request. The asynchronous job configures the database based on the configuration details. Thus, databases in a cloud, data grid, or data center may be administered autonomously (without human intervention) base on dynamic conditions that are foreseen and unforeseen.

Rule-based autonomous database cloud service framework

Provided herein are workload management techniques that asynchronously configure pluggable databases within a compute cloud. In an embodiment, the compute cloud receives an administrative request that indicates configuration details for a pluggable database. The compute cloud generates a configuration descriptor that specifies an asynchronous job based on the configuration details of the request. The compute cloud accesses hosting metadata to detect at least one of: a) a current container database that already hosts the pluggable database, b) a target container database that will host the pluggable database, or c) a particular computer that hosts at least one of: the current container database, or the target container database. The compute cloud executes the asynchronous job to configure the pluggable database based on at least one of: the hosting metadata, or the configuration descriptor. Thread pools, lanes, and queues may facilitate load balancing to avoid priority inversion, starvation, and denial of service.

Autonomous multitenant database cloud service framework

Techniques are provided for using a sparse file to create a hot archive of a pluggable database of a container database. In an embodiment and while a source pluggable database is in service, a source database server creates a clone of the source pluggable database. Also while the source pluggable database is in service, the source database server creates an archive of the source pluggable database that is based on the clone. Eventually, a need arises to consume the archive. A target database server (which may also be the source database server) creates a target pluggable database based on the archive.

Periodic snapshots of a pluggable database in a container database

Embodiments create a clone of a PDB while the PDB accepts write operations. While the PDB remains in read-write mode, the DBMS copies the data of the PDB and sends the data to a destination location. The DBMS performs data recovery on the PDB clone based on redo entries that record changes made to the source PDB while the DBMS copied the source PDB files. This data recovery makes all changes, to the PDB clone, that occurred to the source PDB during the copy operation. The redo information, on which the data recovery is based, is foreign to the PDB clone since the redo entries were recorded for a different PDB. In order to apply foreign redo information to perform recovery on the PDB clone, a DBMS managing the PDB clone maintains mapping information that maps PDB source reference information to corresponding information for the PDB clone.

Cloning a pluggable database in read-write mode

Embodiments incrementally refresh a clone of a source PDB while the source PDB accepts write operations. Specifically, refreshing the PDB clone incorporates changes made to the source PDB since a refresh reference time stamp, which marks the time at which the PDB clone was created or, if the PDB clone has been previously refreshed, the time at which the PDB clone was last refreshed. A PDB clone is incrementally refreshed by incorporating, into the PDB clone data, those source data blocks that have changed since the refresh reference time stamp. Recovery is performed on the PDB clone, once the blocks are copied, to apply any changes made to the source PDB while the blocks were being copied, which recovery makes the PDB clone files consistent. This recovery is based on redo entries recorded for the source PDB during the time it took to copy the blocks to the PDB clone.

Techniques for keeping a copy of a pluggable database up to date with its source pluggable database in read-write mode

In an approach, a database management system is configured in a manner that allows all pluggable databases within a cluster to be treated, from the perspective of a user, as though stored on a single container database, even when the pluggable databases are distributed across a plurality of container databases. When a command is received by a database server that is to be executed on all or a subset of the pluggable databases within the cluster, the database inspects mapping information replicated on all container databases within the cluster by a cluster synchronization server to determine which container databases store pluggable databases implicated by the command. The command is then forwarded to the database servers responsible for the determined container databases for execution. As a result, the commands issued by the user can be agnostic in regard to the actual location of the pluggable databases within the cluster.

Ability to group multiple container databases as a single container database cluster

Embodiments provide a migration instruction that effectuates the migration of a pluggable database from a source database server instance to a destination database server instance. Upon receiving the migration instruction, the migrating pluggable database is opened at the destination instance. Connections are terminated at the source instance at a rate that is determined based on statistics maintained for one or more of: the migrating pluggable database, the source instance, the destination instance, a container database, etc. Furthermore, once the migration instruction is received, a certain amount of time is provided before the source instance flushes the dirty buffers for the migrating pluggable database from the buffer cache of the source instance. The delay in flushing dirty buffers from buffer cache allows the source instance to provide data blocks, of the migrating pluggable database, directly to the destination database server instance from the cache.

Migrating a pluggable database between database server instances with minimal impact to performance

A pluggable database (PDB) that is encoded using a particular character set (differing character set) may be plugged into a container database (CDB) and queried, even when the CDB in which the particular PDB resides is encoded using a different character set. The DBMS records what character set is used to encode the PDB. Any predicate that may prune results from a PDB that is encoded in a differing character set is converted to the differing character set as needed, such that the predicate may be applied within the PDB to prune results. At times, cross-container views will require data from a PDB that is encoded using a differing character set. The data returned from a recursive query over the PDB is converted to being encoded using the character set of the root database of the CDB.

Supporting pluggable databases with heterogeneous database character sets in a container database

A database server instance automatically detects configuration issues when a pluggable database (PDB) is plugged into a new destination container database (CDB). The database server instance identifies one or more update templates, within the destination CDB, that, when run over the relocated PDB, will update the configuration of the PDB to conform to the configuration of the destination CDB. Instead of requiring an administrator to initiate update scripts from a DBMS kernel to reconfigure a PDB, the DBMS creates the update templates by recording commands run within PDBs in connection with system updates. These recorded update templates may then be run over relocated PDBs, to configure the PDBs according to the configuration of the destination CDB. Further, the update templates may be pre-recorded update templates, which record commands to perform configuration updates, to PDBs, that have never before been performed within the CDB.

Automatic reconfiguration of relocated pluggable databases

Techniques for common users and roles, and commonly-granted privileges and roles are described. In one approach, the DBMS of a container database allows for the creation of common roles and common users that are shared across the container database. Thus, when a common role or a common user is established, the common role or common user is propagated to each database of the container database. In another approach, the DBMS of a container database allows privileges and roles to be granted commonly or locally. When a privilege or role is granted commonly, the privilege applies in each of the databases of a container database. When a privilege or role is granted locally, the privilege applies only in the database to which the grantor of the privilege or role established a connection.

Common users, common roles, and commonly granted privileges and roles in container databases

A method and apparatus for efficiently managing cached objects is provided. A mapping is a typed relationship between cached objects. A base object contains content, and a mapped object is mapped to a base object when there is a particular relationship between the mapped object and the base object. The type of mapping defines how the objects in the relationship are treated when the mapped object is created, read, or written. At creation time, the mapping type may define how the mapping relationship is recognized. Sometimes recognizing a relationship requires establishing equivalence between the objects. At read and write time, the mapping type may define on which object a mutual exclusion lock is held, which content is returned or which object's content is updated. A wide range of applications can benefit from enhanced object caching performance, and in addition, application may define application-specific semantics on mapping types as well.

Memory-mapped objects

A container database stores redo records and logical timestamps for multiple pluggable databases. When it is detected that a first read-write instance of the pluggable database is opened and no other read-write instances of the pluggable database are open, offline range data associated with the pluggable database is updated. When it is detected that a second read-write instance of the pluggable database is closed, and the second read-write instance is the last open read-write instance, the offline range data associated with the pluggable database is updated. The pluggable database is restored to a logical timestamp associated with a restore request based on the offline range data.

Techniques for backup restore and recovery of a pluggable database

A pluggable database is transported between a source DBMS and a destination DBMS, in a way that minimizes downtime of the pluggable database. While a copy of the pluggable database is being made at the destination DBMS, transactions continue to execute against the pluggable database at the source DBMS and change the pluggable database. Eventually, the transactions terminate or cease executing. Redo records generated for the transactions are applied to the copy of the pluggable database at the source DBMS. Undo records generated for at least some of the transactions may be stored in a separate undo log and transported to the destination DBMS. The transported pluggable database is synchronized at a destination DBMS in a 'pluggable-ready state', where it may be plugged into the destination container DBMS.

Instantaneous unplug of pluggable database from one container database and plug into another container database

Growing community of inventors

Sunnyvale, CA, United States of America

Jaebock Lee