Versioned Metadata Access for Snapshot-Isolated Database Schemas
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional relational database systems require full synchronization between read queries and data definition language operations, leading to operational limitations and performance impacts due to exclusive locks on schema objects, causing unavailability and unexpected failures.
Innovation Solution
Implementing versioned metadata and new lock schemes in relational database systems to enable concurrent access to metadata objects, allowing multiple versions of metadata to be accessed simultaneously, thereby reducing blocking and improving performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If full exclusive lock (SCH-M) is required for DDL operations to synchronize with concurrent read queries, then schema consistency is maintained, but DDL operations are blocked until all queries complete, causing significant unavailability and performance impact
Solution Approach 1:
The patent segments the monolithic schema lock into fine-grained locks at the catalog view level. Instead of requiring a single SCH-M lock on all schema objects, the system allows concurrent DDL operations on different catalogs by implementing separate locks for each catalog view (e.g., sys.objects, sys.columns). This segmentation enables parallel execution of DDL operations while maintaining consistency within each catalog, resolving the contradiction between schema consistency and DDL throughput.
Solution Approach 2:
The patent introduces catalog views as intermediaries between DDL operations and the underlying schema objects. The lock manager mediates access by allowing DDL operations to acquire locks on catalog views rather than directly on schema objects. This intermediary layer enables coordination of concurrent operations while reducing blocking, as the lock scope is limited to specific catalog views rather than the entire schema.
2Reliability
If DDL operations wait for ongoing queries to complete before acquiring schema modification lock, then data consistency is ensured, but the window of unavailability is extended and new queries are blocked
Solution Approach 1:
The patent implements dynamic lock escalation and release mechanisms. Instead of holding locks for the entire duration of query execution, the lock manager dynamically acquires and releases locks at appropriate checkpoints during DDL operations. This allows ongoing queries to complete their current operations while enabling DDL progress, reducing the overall unavailability window while maintaining consistency through controlled lock transitions.
Solution Approach 2:
The patent performs preliminary validation and lock acquisition attempts before fully blocking DDL operations. The system checks whether concurrent queries are using schema-affected operations and prepares lock acquisition in advance. This preliminary action allows the system to minimize blocking by only acquiring locks when necessary, reducing the unavailability window while ensuring consistency through proactive lock management.
3Device complexity
If DDL operations require full exclusive lock on all schema objects, then metadata versioning is simplified, but secondary replicas experience log replication delays and accumulate large logs
Solution Approach 1:
The patent applies local quality by implementing versioning and locking at the catalog level rather than globally. Each catalog view maintains its own version information and lock state, allowing independent progression of DDL operations in different catalogs. This local approach enables secondary replicas to process log replication more efficiently, as they only need to reapply changes to specific catalogs rather than waiting for global schema lock releases, improving log replication speed while maintaining manageable versioning complexity.
Data Source
AI summary
Relational database systems are disclosed that are enabled to operate with versioned metadata. The relational database system includes a lock manager, a transaction manager and a version aware metadata storage and cache configured to store to store and manage versions of metadata, to determine which of such versions should be visible at any given point in time, and to enable creation of the proper versions of metadata. In an aspect, the transaction manager manages transaction identifiers and their associated start times, abort times and/or commit times. Such data enables determination of transaction visibility, and consequently the metadata version visibility, for any point in time. In an aspect, such metadata versioning support enables snapshot isolation of metadata transactions.


