Applicable scenarios
This article is applicable to the scenario of lock conflict, and locates the lock-holding session and the lock-waiting session based on the internal table data analysis of OceanBase database.
Description
Since obdiag V4.0.0, this scenario has new log analysis capabilities. In addition to analyzing internal table data, it will also analyze lock conflict-related information in OceanBase cluster logs to provide more comprehensive diagnostic results.
Currently, OceanBase database V4.0.0.0 and later versions are supported. When using obdiag, you need to configure the cluster information in the ~/.obdiag/config.yml file according to your choice, or configure the cluster information through the --config option in the command.
Attention
Due to the timeliness of internal table data, only current data is supported for analysis.
There are differences in the analysis logic between OceanBase database versions before V4.2.0.0 and V4.2.0.0 and later versions.
Can import environment variables
Variable name |
Is it required |
Data type |
Default value |
Description |
|---|---|---|---|---|
| tenant_name | Yes | string | "" | The tenant name to be analyzed |
Usage example
The default execution command is as follows. In the current situation, only the lock-holding session and the lock-waiting session are located based on the analysis of the internal table data of the OceanBase database.
# xxx is the tenant name
obdiag rca run --scene=lock_conflict --env tenant_name=xxx
In view of the fact that the waiting lock ID will continue to change when the transaction is not opened, in the lock conflict strategy of obdiag rca, the analysis in the record is a lock-holding session (the same as OCP performance). At the same time, the information of the query period will be printed, and the ID of the lock-holding ID will be marked. If the lock-waiting session information is obtained by query, it will be recorded, but will not be explained as a key node.