Autonomic Lock Escalation in SQL Database Queries

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database management systems (DBMS) typically wait until query execution is degraded before escalating from row-level locking to page-level locking, leading to inefficiencies and concurrency issues due to the delayed switching of locking strategies.

Innovation Solution

A method is introduced to analyze database queries prior to execution, allowing for the proactive selection of locking strategies, such as switching from row-level to page-level locking based on query characteristics and database statistics, to optimize query execution and prevent concurrency issues.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If row level locking is used, then concurrency is improved and other records on the same page remain available, but system overhead increases and query execution efficiency decreases

Engineering Contradiction:
ImproveconcurrencyVSAvoidquery execution efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent implements dynamic lock escalation by monitoring the number of locks acquired during query execution and automatically transitioning from row-level locking to page-level locking when a threshold is reached. This dynamic adjustment allows the system to adapt to changing concurrency conditions, maintaining high concurrency when needed while switching to more efficient page-level locking when the number of locked rows exceeds a predefined threshold, thus resolving the contradiction between concurrency and execution efficiency.

Inventive Principle:
Principle #15Dynamics

2Device complexity

If lock escalation is triggered during query execution, then system overhead is reduced, but performance degradation is already evident and the system is playing catch up

Engineering Contradiction:
Improvesystem overheadVSAvoidperformance degradation delay
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by pre-configuring lock escalation thresholds and policies before query execution begins. The system monitors lock acquisition in real-time and triggers escalation proactively when predetermined conditions are met, rather than waiting for performance degradation to occur. This advance planning and monitoring mechanism ensures that the transition to page-level locking happens at the optimal moment, reducing system overhead before performance issues manifest.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If page level locking is used, then query execution efficiency is improved and fewer locks are required, but the likelihood of deadlock and concurrency problems increases

Engineering Contradiction:
Improvequery execution efficiencyVSAvoiddeadlock and concurrency contention
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent implements segmentation by dividing the locking strategy into two distinct levels: row-level locking for initial query execution to maintain low contention, and page-level locking for bulk operations where efficiency is paramount. The system segments the decision-making process by evaluating query characteristics and lock count thresholds, applying the appropriate locking granularity for each scenario. This segmented approach allows the system to leverage the advantages of both locking strategies while minimizing their respective disadvantages.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS7552121B2Autonomic lock escalation in an SQL environment
Publication Date: 2009.06.23 SAP SE
  • US7552121B2 patent drawing
  • US7552121B2 patent drawing
  • US7552121B2 patent drawing

AI summary

Embodiments of the invention provide a method, article of manufacture, and an apparatus used to optimize the execution of a database query. One embodiment includes a computer-implemented method that includes the steps of receiving a query of a database, prior to executing the query, analyzing the query to select a locking strategy to use in executing the query, and executing the query using the selected locking strategy. Depending on the content of a particular query, or the status of a database, a query optimizer may determine whether to escalate from a row level locking strategy to a page level locking strategy when executing the data query.