Description
obdiag supports root cause analysis of scenarios where SQL execution memory is too high since V4.2.0.
Applicable scenarios
This article applies to scenarios where the work area memory usage is too high during SQL execution. It is analyzed based on the internal tables and views of the OceanBase database to locate the cause of execution memory consumption.
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 data, only current data is supported for analysis.
Analyze content
This scenario checks for the following:
- Execution memory usage: Get SQL execution memory usage from
__all_virtual_memory_info. - GV$OB_SQL_WORKAREA_MEMORY_INFO: If the OceanBase database version supports it (V4.3 and above), query the workspace memory details.
- GV$SQL_WORKAREA: If the OceanBase database version supports it (V2.2.77 and above), query the active workspace information.
- Memory parameters:
ob_sql_work_area_percentageand related parameters. - Top consumption: SQL and modules with the highest memory consumption.
- Log Collection: Collect OceanBase database logs for further analysis.
Usage example
The default execution command is as follows:
obdiag rca run --scene=execute_memory_high
Interpretation of results
After the analysis is completed, the results will be saved to the directory specified by --store_dir (default is ./obdiag_rca/), including the records of each inspection step and the collected log files.