Oracle International Corporation

Sanket Jain

Kumar Rajamani

Jaebock Lee

Giridhar Ravipati

Yunrui Li

Andre Kruglikov

Chi Cao Minh

Hochak Hung

Jonghyun Lee

Alexander Chen

Jen-Cheng Huang

Margaret Susairaj

Muthu Olagappan

Chandrasekharan Iyer

John E McHugh

Philip Yam

Nicolas Michael

Yixiao Shen

Prashanth Shanthaveerappa

Churn Don Lee

Phillip Yam

A database query processing service is provided for efficiently processing query workloads with natural language statements and native database commands. The database query processing service may receive some database queries that do not contain a natural language marker and process these database queries without using large language models to generate replacement query content. The database query processing service may also receive other database queries that do contain the natural language marker and process the other database queries using large language model(s) to generate replacement query content or leverage replacement query content already generated by the large language model(s). The replacement query content is checked to ensure the content is natively valid for the content to retrieve data from database structures referenced in the content. The database query processing service may use the natively valid replacement query content to cause execution of operations responsive to the other database queries.

Efficiently processing query workloads with natural language statements and native database commands

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

Techniques are described herein for allowing a container DBMS to impose restrictions, on a per-pluggable-database basis, on operations based on the pluggable database to which the users that request the operations belong. In one embodiment, lockdown profiles can be created and mapped to pluggable databases. Lockdown profiles specify PDB-wide restrictions on operations. The restrictions may apply to all operations of a given type, may apply to specific features, may require use of specific parameter values, etc. All users that belong to a pluggable database are restricted by the restrictions specified in the lockdown profile to which their pluggable database is mapped, unless the lockdown profile has a user-specific exemption for them. Bitmaps and/or hash tables may be used to more quickly determine, at query runtime, whether a query violates any profile-specified restrictions. Execution of queries that violate any profile-specified restrictions is prevented.

Pluggable database lockdown profile

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

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 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.

Growing community of inventors

Sunnyvale, CA, United States of America

Sanket Jain