Abstract: Disclosed is an approach to implement a multi-tenant DNS resolver for secure communications for a virtual cloud environment. The approach can perform split-horizon DNS forwarding via an intermediate customized DNS server.

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

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

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

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

Abstract: Disclosed is an approach to implement a multi-tenant DNS resolver for secure communications for a virtual cloud environment. The approach can perform split-horizon DNS forwarding via an intermediate customized DNS server.

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

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

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

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

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

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

Abstract: A computer program product, system, and computer implemented method for management of a consolidated database and implementing pluggable database recovery with efficient 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.

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

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

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

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

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

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

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