Cisco Technology, Inc.

Oracle International Corporation

Chi Cao Minh

Yunrui Li

Jonghyun Lee

Jad Naous

Kumar Rajamani

Jaebock Lee

Giridhar Ravipati

Sanket Jain

Vinay H Srihari

Wilson Wai Chan

Tolga Yurek

Steven A Bolton

Srinivasan Arashanipalai

Ping-Hsiu Hsieh

The disclosed technology includes ranking entities in real-time to show the relative importance of those entities. The ranking is based on attributes of the entities that vary in real-time. An example of an entity is a process (e.g., an executing computer program) and the associated attributes can include the process' current CPU memory consumption. While the process runs, its CPU and memory consumption vary in real-time.

Real-time ranking of monitored entities

In one embodiment, a monitoring device ingests a plurality of data records sequentially from a data stream, each having an associated timestamp, and builds a cluster pattern for a plurality of time periods by placing each data record into a corresponding cluster of a particular time period based on the associated timestamp of each data record. The monitoring device then establishes connection between clusters of different time periods by assigning each data record of each particular time period to both an adjacent preceding and succeeding time period. The monitoring device may detect cluster transitions based on the established connections between clusters of different time periods, and can compute cluster migration metrics based on the cluster transitions. The monitoring device then predicts future cluster migration metrics based on computed cluster migration metrics, detects an anomaly about the predicted future cluster migration metrics, and reacts to the anomaly, accordingly.

Predictive data capture with adaptive control

In one embodiment, a method for event-triggered distributed data collection in a distributed transaction monitoring system is disclosed. The method illustratively comprises receiving, by a device, application performance data of an instance of a distributed business transaction from a first agent, the application performance data including a unique identifier associated with the instance and limited to a time window; receiving, by the device, infrastructure performance data of the instance of the distributed business transaction from a second agent, the infrastructure performance data including the unique identifier associated with the instance; grouping, by the device, the application performance data and the infrastructure performance data based on the unique identifier; and identifying, by the device, a performance issue with the instance of the distributed business transaction through an analysis of the grouping of the application performance data and the infrastructure performance data.

Event-triggered distributed data collection in a distributed transaction monitoring system

Techniques are provided for managing cached data objects in a mixed workload environment. In an embodiment, a system, log data is stored in one or more buffers. In response to receiving a request to perform a logical write, a first process writes a first portion of the log data to a log file in persistent storage. While the first portion of the log data is being written to the log file, a second process writes a second portion of the log data in the one or more buffers to the log file in persistent storage. In another embodiment, a request to perform a second logical write may be received before the first logical write completes. While the first log data is being written to the log file, one or more processes write second log data for the second logical write to the log file.

Techniques to parallelize CPU and IO work of log writes

An agent manager manages and configures a plurality of agents suitable for execution on different types of applications and server platforms. The agent manager may receive a collection of rules for determining how to deploy, manage and maintain different agents. The agent manager may collect data about the agents and a local machine, communicate with and configure the agents, and communicate with remote machines such as a controller. The agent manager may configure the agents based on one or more rules the agent receives, such as for example a set of rules provided by a controller. The agent manager may parse the received rules, identify any agents that need to be installed or uninstalled, installed agents that need to be turned on, off, or restarted, or agents that should be otherwise modified, for example with an update, a plug-in, a feature enabled or disabled, or some other update.

Agent manager for distributed transaction monitoring system

Embodiment provide that each pluggable database (PDB) in a container database is associated with a distinct distributed lock manager (DLM) domain. Thus, in order to access a PDB, a database server instance joins the DLM domain for the PDB. To perform actions on the PDB, the instance secures locks that belong to the DLM domain for the particular PDB. As such, buffers storing data for the PDB may be managed separately from buffers storing data for other PDBs using the PDB-specific DLM domains. An instance forcefully closing a particular PDB marks the DLM domain of the PDB as invalid, which allows detection of the forceful closure by a recovery instance. Detection of an invalid DLM domain by an instance causes the instance to automatically recover the PDB by accessing pertinent ranges of redo logs and replaying changes made to data blocks for the PDB indicated in the logs.

Forceful closure and automatic recovery of pluggable databases in a shared-everything cluster multitenant container database

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 method, system, and computer program product for adaptive high-performance database redo log synchronization. The method commences upon performing a write operation of a redo log entry, the write operation concluding with an indication of completion of the write operation of the redo log entry. Any number of committing processes may be waiting for the indication of completion, and upon indication of completion, then (using a first synchronization mode) the processes or proxy measures the waiting time as experienced by the committing processes (e.g., while waiting for the indication of completion of the write operation of the redo log entry). In some cases a second synchronization mode would introduce less latency than the first synchronization mode, so the system changes to a second synchronization mode. The system can also change mode when a predicted second mode waiting time is smaller than the measured waiting time.

Adaptive high-performance database redo log synchronization

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

San Mateo, CA, United States of America

Chi Cao Minh