Abstract: Herein are resource-constrained techniques that plan ahead for resiliently moving pluggable databases between container databases after a failure in a high-availability database cluster. In an embodiment, a computer identifies many alternative placements that respectively assign each pluggable database to a respective container database. For each alternative placement, a respective resilience score is calculated for each pluggable database that is based on the container database of the pluggable database. Based on the resilience scores of the pluggable databases for the alternative placements, a particular placement is selected as an optimal placement that would maximize utilization of computer resources, minimize database latencies, maximize system throughput, and maximize the ability of the database cluster to avoid a service outage.

Abstract: Disclosed is an improved approach to implement a mechanism to provide customer control over access to cloud infrastructure by the cloud provider's operator employees. This mechanism allow customer controlled access to any cloud infrastructure that belongs to or is otherwise allocated to the customer.

Abstract: Techniques described herein include frameworks and models for identifying, analyzing, and addressing hangs within distributed and heterogenous computing environments. A hang detection framework may model a distributed computing environment as a complex forest of interrelated requests. The hang detection framework may generate hang graphs based upon requests that are being processed and/or waited upon within the distributed environment. For example, a node within an acyclic graph may represent an execution entity that is currently processing one or more requests. Directed edges that connect one node to another may represent requests upon which an execution entity is waiting for another execution node to fulfill. The model may be used to isolate and address the root cause of hangs within the computing environment.

Abstract: New data structures for analyzing a log are generated. A hierarchical data structure includes a plurality of hierarchical nodes. Each node is associated with data and metadata. Each node may also be associated with analysis data. Information (data, metadata, and/or analysis data) of an ancestor node is imputed to a descendant node; a descendant node inherits the information of an ancestor node. When determining analysis data for a particular hierarchical node, information from any ancestor node to the particular hierarchical node may be used; however, information from non-ancestor nodes is not necessarily used. A timeline data structure includes a reference to a hierarchical node within a hierarchical data structure and a reference to an event type. The timeline data structure is thereby associated with the information of the referenced hierarchical node and information of any ancestor nodes to the referenced hierarchical node.

Abstract: Plugins that are independently written are executed in a collaborative manner to analysis a log. A plugin executing with respect to a particular node of a hierarchical data structure determines values for a set of keys based on information of the particular node and/or any ancestor nodes, and information stored in a shared repository. The plugin stores the values for the keys as additional information of the particular hierarchical node and/or into the shared repository. The plugin does not access information of non-ancestor nodes when executing with respect to the particular hierarchical node. Each plugin writes into and retrieves from the shared repository using the shared naming convention, thereby sharing information. The sequence of execution of the plugins is not dependent on dependencies amongst the plugins. If a dependent plugin requiring an output from a requisite plugin is first executed, the dependent plugin is flagged as pending and subsequently re-executed.

Abstract: Plugins that are independently written are executed in a collaborative manner to analysis a log. A plugin executing with respect to a particular node of a hierarchical data structure determines values for a set of keys based on information of the particular node and/or any ancestor nodes, and information stored in a shared repository. The plugin stores the values for the keys as additional information of the particular hierarchical node and/or into the shared repository. The plugin does not access information of non-ancestor nodes when executing with respect to the particular hierarchical node. Each plugin writes into and retrieves from the shared repository using the shared naming convention, thereby sharing information. The sequence of execution of the plugins is not dependent on dependencies amongst the plugins. If a dependent plugin requiring an output from a requisite plugin is first executed, the dependent plugin is flagged as pending and subsequently re-executed.

Abstract: Plugins that are independently written are executed in a collaborative manner to analysis a log. A plugin executing with respect to a particular node of a hierarchical data structure determines values for a set of keys based on information of the particular node and/or any ancestor nodes, and information stored in a shared repository. The plugin stores the values for the keys as additional information of the particular hierarchical node and/or into the shared repository. The plugin does not access information of non-ancestor nodes when executing with respect to the particular hierarchical node. Each plugin writes into and retrieves from the shared repository using the shared naming convention, thereby sharing information. The sequence of execution of the plugins is not dependent on dependencies amongst the plugins. If a dependent plugin requiring an output from a requisite plugin is first executed, the dependent plugin is flagged as pending and subsequently re-executed.

Abstract: Plugins that are independently written are executed in a collaborative manner to analysis a log. A plugin executing with respect to a particular node of a hierarchical data structure determines values for a set of keys based on information of the particular node and/or any ancestor nodes, and information stored in a shared repository. The plugin stores the values for the keys as additional information of the particular hierarchical node and/or into the shared repository. The plugin does not access information of non-ancestor nodes when executing with respect to the particular hierarchical node. Each plugin writes into and retrieves from the shared repository using the shared naming convention, thereby sharing information. The sequence of execution of the plugins is not dependent on dependencies amongst the plugins. If a dependent plugin requiring an output from a requisite plugin is first executed, the dependent plugin is flagged as pending and subsequently re-executed.

Abstract: Techniques are described herein for automatically determining optimal placement for VM clusters in multi-device infrastructure. Potential combinations of host nodes for a VM cluster are selected based on applicable constraints on host nodes for the cluster. Further, applicable optimization criteria (OC) for the VM cluster and/or the infrastructure are formally defined and modeled for automatic performance. Application of this placement model to the potential combinations of host nodes results in one or more OC metrics that may be directly compared so that alternate potential host node combinations may be ranked based on the determined OC metrics. The highest-ranked node combination is identified as the optimal VM cluster placement. The placement model can be used to implement initial, incremental, shuffling, or scaling placements of VM clusters. Further, hierarchical decisions may be made based on the determined OC metrics, allowing for application of the placement model to large and complex infrastructures.

Abstract: Embodiments described herein include a log management system that detects and addresses excessive log patterns at runtime. In some embodiments, the log management system tracks cumulative attributes associated with patterns that repeat within a set monitoring files, such as a set of log or trace records. The cumulative attributes that are monitored may include the cumulative storage size and/or cumulative count of patterns detected in the monitoring files. The log management system may determine whether a triggering condition is satisfied for initiating a responsive action to reduce the amount of log data that is transmitted and/or stored. If the triggering condition is satisfied, then the log management system may remove one or more instances of the pattern from the monitoring files and/or perform other actions to reduce the overhead of logging operations.

Abstract: Plugins that are independently written are executed in a collaborative manner to analysis a log. A plugin executing with respect to a particular node of a hierarchical data structure determines values for a set of keys based on information of the particular node and/or any ancestor nodes, and information stored in a shared repository. The plugin stores the values for the keys as additional information of the particular hierarchical node and/or into the shared repository. The plugin does not access information of non-ancestor nodes when executing with respect to the particular hierarchical node. Each plugin writes into and retrieves from the shared repository using the shared naming convention, thereby sharing information. The sequence of execution of the plugins is not dependent on dependencies amongst the plugins. If a dependent plugin requiring an output from a requisite plugin is first executed, the dependent plugin is flagged as pending and subsequently re-executed.

Abstract: New data structures for analyzing a log are generated. A hierarchical data structure includes a plurality of hierarchical nodes. Each node is associated with data and metadata. Each node may also be associated with analysis data. Information (data, metadata, and/or analysis data) of an ancestor node is imputed to a descendant node; a descendant node inherits the information of an ancestor node. When determining analysis data for a particular hierarchical node, information from any ancestor node to the particular hierarchical node may be used; however, information from non-ancestor nodes is not necessarily used. A timeline data structure includes a reference to a hierarchical node within a hierarchical data structure and a reference to an event type. The timeline data structure is thereby associated with the information of the referenced hierarchical node and information of any ancestor nodes to the referenced hierarchical node.

Abstract: Herein are resource-constrained techniques that plan ahead for resiliently moving pluggable databases between container databases after a failure in a high-availability database cluster. In an embodiment that has a database cluster that hierarchically contains many pluggable databases in many container databases in many virtual machines, a computer identifies many alternative placements that respectively assign each pluggable database instance (PDB) to a respective container database management system (CDBMS). For each alternative placement, a respective placement score is calculated based on the PDBs and the CDBMSs. Based on the placement scores of the alternative placements, a particular placement is selected with a best placement score that indicates optimal resilience for accommodating adversity such as failover and overcrowding.

Abstract: Herein are resource-constrained techniques that plan ahead for resiliently moving pluggable databases between container databases after a failure in a high-availability database cluster. In an embodiment, a computer identifies many alternative placements that respectively assign each pluggable database to a respective container database. For each alternative placement, a respective resilience score is calculated for each pluggable database that is based on the container database of the pluggable database. Based on the resilience scores of the pluggable databases for the alternative placements, a particular placement is selected as an optimal placement that would maximize utilization of computer resources, minimize database latencies, maximize system throughput, and maximize the ability of the database cluster to avoid a service outage.

Abstract: Disclosed is an improved approach to implement a mechanism to provide customer control over access to cloud infrastructure by the cloud provider's operator employees. This mechanism allow customer controlled access to any cloud infrastructure that belongs to or is otherwise allocated to the customer.

Abstract: Techniques are described herein for isolating a network stack in a multitenant container DBMS. A first and second pluggable database are established within a container database. A first network stack is assigned to the first pluggable database and a second network stack is assigned to the second pluggable database. A request is received to connect to the first pluggable database and a connection is established to the first pluggable database using the first network stack. A request is received to connect to the second pluggable database and a connection is established to the second pluggable database using the second network stack.

Abstract: Techniques are described herein for isolating runtime environments in a multitenant container DBMS. A CDB may contain a database dictionary that defines a plurality of pluggable databases and a respective database nest for each pluggable database. Each respective database nest of said each pluggable database is associated with different operating system privileges. When database sessions are established on a container DBMS, each database session is given access to a pluggable database by attaching the respective database nest of the pluggable database to each database session.

Abstract: Techniques are described herein for isolating runtime environments in a multitenant container DBMS. A CDB may contain a database dictionary that defines a plurality of pluggable databases and a respective database nest for each pluggable database. Each respective database nest of said each pluggable database is associated with different operating system privileges. When database sessions are established on a container DBMS, each database session is given access to a pluggable database by attaching the respective database nest of the pluggable database to each database session.

Abstract: Techniques are described herein for isolating a network stack in a multitenant container DBMS. A first and second pluggable database are established within a container database. A first network stack is assigned to the first pluggable database and a second network stack is assigned to the second pluggable database. A request is received to connect to the first pluggable database and a connection is established to the first pluggable database using the first network stack. A request is received to connect to the second pluggable database and a connection is established to the second pluggable database using the second network stack.