Hierarchical Triage for Multitenant Cloud DB Contention
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current monitoring tools for multitenant database environments lack visibility into implementation stacks, leading to suboptimal performance and difficulty in diagnosing and resolving performance issues due to security and privacy constraints.
Innovation Solution
The implementation of hierarchical and non-intrusive techniques for detecting and diagnosing incidental contention between database tenants, using a streamlined database monitoring framework that collects, analyzes, and correlates crucial performance metrics at a systemic level, while maintaining data privacy and security.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If current monitoring tools are used for multitenant database environments, then data privacy and security are maintained through isolation, but visibility into implementation stacks is lost and performance issue diagnosis becomes difficult
Solution Approach 1:
The patent introduces an intermediary monitoring framework that sits between the isolated tenant databases and the monitoring system. This framework uses standardized interfaces and abstraction layers to capture performance metrics without requiring direct access to tenant data, thus maintaining security boundaries while enabling comprehensive monitoring and diagnosis capabilities.
Solution Approach 2:
The monitoring system is segmented into multiple hierarchical levels: tenant-level monitoring, database-level monitoring, and infrastructure-level monitoring. Each level operates independently with defined data access permissions, allowing detailed performance visibility at each tier while maintaining data isolation. The segmented architecture enables granular control over what information is collected and shared.
2Reliability
If comprehensive performance monitoring is implemented across all database tenants, then performance degradation can be detected early, but system complexity and resource overhead increase
Solution Approach 1:
The monitoring system divides performance tracking into discrete, manageable segments corresponding to different database operations, tenants, and resource types. Each segment can be independently configured and monitored, reducing overall system complexity. The segmented approach allows selective monitoring of critical paths while maintaining lighter oversight on less critical operations.
Solution Approach 2:
The patent implements a universal monitoring framework that handles multiple database operations, tenant types, and performance metrics through a single standardized system. This multi-functional approach reduces complexity by eliminating the need for separate monitoring mechanisms for different scenarios, while still providing comprehensive performance detection capabilities across all tenants.
3Measurement precision
If detailed performance metrics are collected from all tenants, then incidental contention can be diagnosed accurately, but data privacy constraints are violated
Solution Approach 1:
An intermediary data aggregation layer is introduced that collects detailed performance metrics from all tenants but processes and anonymizes the data before storage and analysis. The intermediary maintains the precision needed for accurate contention diagnosis by preserving operational patterns and performance characteristics while removing or masking any tenant-identifying information, thus balancing measurement accuracy with data privacy protection.
Data Source
AI summary
Herein are hierarchical and non-intrusive techniques to detect and diagnose incidental contention between database tenants. In an embodiment, a computer hosts a database server that operates a container database. The database server monitors level one performance metrics that characterize the performance of at least a first pluggable database (PDB) in the container database. The database server detects, in the level one performance metrics, a performance degradation of the first PDB. Responsively, the database server dynamically configures collection of level two performance metrics that characterize the performance of at least the first PDB and a second PDB in the container database. The database server detects, in the level two performance metrics, that the performance degradation is caused by the second PDB. The database server generates an alert that identifies the second PDB. The alert contains a particular metric of the level two performance metrics, and the particular metric characterizes the performance of the second PDB.