Oracle International Corporation

Kumar Rajamani

Jaebock Lee

Giridhar Ravipati

Sanket Jain

Yunrui Li

Andre Kruglikov

Hochak Hung

Philip Yam

Margaret Susairaj

Namit Jain

Muthu Olagappan

Prashanth Shanthaveerappa

Thomas Baby

Shrikanth Shankar

Chandrasekharan Iyer

Chi Cao Minh

Jonghyun Lee

Russell John Green

Alexander Chen

Jen-Cheng Huang

Guhan Viswanathan

Ho Chak Hung

Tirthankar Lahiri

William H Waddington

Wei-Ming Hu

Sumanta Kumar Chatterjee

Niloy Mukherjee

Jia Shi

Vinay H Srihari

Mark Dilman

J William Lee

Susan M Kotsovolos

Neil MacNaughton

Subhransu Basu

Bharat Chandra Baddepudi

Kiran Badrinarain Goyal

Vipin Gokhale

John E McHugh

Rajagopalan Govindarajan

David M Alpern

Nicolas Michael

Jing Zheng

Rahul Manohar Kadwe

Yixiao Shen

Alan Choi

Todd A Bottger

Harsha Vardhan Nhs

Uday Kiran Jangolla

Debaditya Chatterjee

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

Techniques are provided for synchronizing database system metadata between primary and standby persistent storage systems using an object store. A first persistent storage system enabled to store first configuration metadata describing the configuration of the first persistent storage system. A first broker process of the first persistent storage system detects receipt, at an object store endpoint, of a new version of an object message sent by a second broker process of a second persistent storage system. The object message specifies a particular value of a configuration attribute of second configuration metadata from the second persistent storage system. In response to detecting receipt of the new version of the object message, the first broker process reads the particular value of the configuration attribute in the object message. The first broker process sets the configuration attribute in the first configuration metadata to the particular value.

Object storage based asynchronous mailbox, eventual consistency for cross-region communication

Techniques described herein automatically check for persistently inactive instances, based on defined metrics, and auto-archive such instances to lower-cost cloud resources. An inactivity time threshold is dynamically adjustable to a longer or shorter time period based on current load running on limited/more expensive resources to more aggressively or less aggressively archive the inactive instances, thus enabling additional active instances to run on the limited/more expensive resources and supporting more total users.

Optimization of resources providing public cloud services based on adjustable inactivity monitor and instance archiver

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 herein make and use a pluggable database archive file (AF). In an embodiment, a source database server of a source container database (SCD) inserts contents into an AF from a source pluggable database (SPD). The contents include data files from the SPD, a listing of the data files, rollback scripts, and a list of patches applied to the SPD. A target database server (TDS) of a target container database (TCD) creates a target pluggable database (TPD) based on the AF. If a patch on the list of patches does not exist in the TCD, the TDS executes the rollback scripts to adjust the TPD. In an embodiment, the TDS receives a request to access a block of a particular data file. The TDS detects, based on the listing of the data files, a position of the block within the AF. The TDS retrieves the block based on the position.

Pluggable database archive

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

A refreshable PDB clone is associated with a PDB-specific logical timestamp (LT) service that continuously reflects the LT of the most recent changes that have fully committed within the PDB clone during a refresh operation. Such an LT service is used to perform queries over the changing data in the PDB clone while the PDB clone is undergoing a refresh operation. Furthermore, a PDB-specific LT service can facilitate write operations in a standby CDB, where the standby CDB is a physical standby of a source CDB. Specifically, a standby CDB is configured with a private read-write PDB that does not replicate data from the source CDB. This private PDB may accommodate a write operation required by a query over data in the standby CDB. A PDB-specific LT service provides LTs for such a private PDB where the PDB-specific LT service provides LTs to order changes made within the private PDB.

Facilitating operations on pluggable databases using separate logical timestamp services

Techniques are described herein for cloning a database. According to some embodiments, a database server receives a request to clone a source database. In response to receiving the request, the database server retrieves a set of one or more storage credentials for a set of one or more respective storage systems on which a set of files of the source database are stored. The set of storage credentials grant permission to the database server to create snapshot copies on the set of storage systems. The database server generates, for a target database using the set of storage credentials, a snapshot copy of each respective file in the set of files of the source database. The snapshot copy of the respective file points to the same set of one or more data blocks as the respective file until at least one of the data blocks is modified.

Storage integrated snapshot cloning for database

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

Growing community of inventors

San Ramon, CA, United States of America

Kumar Rajamani