Historical Top SQL

You can query historical Top SQL in historical resource monitoring views. The historical resource monitoring view records the resource usage (including memory, data flushed to disks, and CPU time), running status (including errors, termination, and exceptions), and performance alarm information when a job is complete. For queries that abnormally terminate due to FATAL or PANIC errors, their status is displayed as aborted and no detailed information is recorded. Status information about query parsing in the optimization phase cannot be monitored.

The following table describes the external interfaces of the historical views.

Level	Monitored Node	View
Query level/perf level	Current CN	History (Database Manager interface)	GS_WLM_SESSION_HISTORY
	Current CN	History (internal dump interface)	GS_WLM_SESSION_INFO
	All CNs	History (Database Manager interface)	PGXC_WLM_SESSION_HISTORY
	All CNs	History (internal dump interface)	PGXC_WLM_SESSION_INFO
Operator level	Current CN	History (Database Manager interface)	GS_WLM_OPERATOR_HISTORY
	Current CN	History (internal dump interface)	GS_WLM_OPERAROR_INFO
	All CNs	History (Database Manager interface)	PGXC_WLM_OPERATOR_HISTORY
	All CNs	History (internal dump interface)	PGXC_WLM_OPERATOR_INFO

The view level is determined by the resource monitoring level, that is, the resource_track_level configuration.
The perf and operator levels affect the values of the query_plan and warning columns in GS_WLM_SESSION_STATISTICS/PGXC_WLM_SESSION_INFO. For details, see SQL Self-Diagnosis.
Prefixes gs and pgxc indicate views showing single CN information and those showing cluster information, respectively. Common users can log in to a CN in the cluster to query only views with the gs prefix.
If instance fault occurs, some SQL statement information may fail to be recorded in historical resource monitoring views.
In some abnormal cases, the status information column in the historical Top SQL may be displayed as unknown. The recorded monitoring information may be inaccurate.
The SQL statements that can be recorded in historical resource monitoring views are the same as those recorded in real-time resource monitoring views. For details, see SQL statements recorded in real-time resource monitoring views.
Historical Top SQL records data only when the GUC parameter enable_resource_record is enabled.
You can query historical Top SQL queries and operator-level data only through the PostgreSQL database.
Historical Top SQL focuses on locating and demarcating query performance problems. It is not used for auditing or recording syntax analysis error statements.

Prerequisites

The GUC parameter enable_resource_track is set to on. The default value is on.
The GUC parameter resource_track_level is set to query, perf, or operator. The default value is query. For details, see Table 2.
The GUC parameter enable_resource_record is set to on. The default value is on.
The value of the resource_track_duration parameter (60s by default) is less than the job execution time.
The GUC parameter enable_track_record_subsql specifies whether to record internal statements of a stored procedure or anonymous block. The default value is off.
Job monitoring rules are as follows:
- Jobs whose execution time recorded in the real-time resource monitoring view (see Table 1) is greater than or equal to resource_track_duration.
If the Cgroups function is properly loaded, you can run the gs_cgroup -P command to view information about Cgroups.

Procedure

Query the load records of the current CN after its latest job is complete in the gs_wlm_session_history view.
Query the load records of all the CNs after their latest job are complete in the pgxc_wlm_session_history view.
Query the load records of the current CN through the gs_wlm_session_info table after the task is complete. To query the historical records successfully, set enable_resource_record to on.
- Top 10 queries that consume the most memory (You can specify a query period.)
- Showing the 10 queries consuming the most CPU resources:
Query for the load records of all the CNs after their jobs are complete in the pgxc_wlm_session_info view. To query the historical records successfully, set enable_resource_record to on.
- Query the top 10 queries that take up the most CN processing time (You can specify a query period.)
- Queries the execution information about a query statement that has been executed. For example, query the execution information about the statement whose queryid is 76561193695026478.
```
SELECT * FROM pgxc_wlm_session_info where queryid = '76561193695026478';
```
Use the pgxc_get_wlm_session_info_bytime function to filter and query the pgxc_wlm_session_info view. To query the historical records successfully, set enable_resource_record to on. You are advised to use this function if the view contains a large number of records.

A GaussDB(DWS) cluster uses the UTC time by default, which has an 8-hour time difference with the system time. Before queries, ensure that the database time is the same as the system time.
- Return the queries started between 2019-09-10 15:30:00 and 2019-09-10 15:35:00 on all CNs. For each CN, a maximum of 10 queries will be returned.
- Return the queries ended between 2019-09-10 15:30:00 and 2019-09-10 15:35:00 on all CNs. For each CN, a maximum of 10 queries will be returned.
Query the recent resource information of the job operators on the current CN in the gs_wlm_operator_history view. Ensure that resource_track_level is set to operator.
Query the recent resource information of the job operators on all the CNs in the pgxc_wlm_operator_history view. Ensure that resource_track_level is set to operator.
Query the recent resource information of the job operators on the current CN in the gs_wlm_operator_info view. Ensure that resource_track_level is set to operator and enable_resource_record to on.
Query for the historical resource information of job operators on all the CNs in the pgxc_wlm_operator_info view. Ensure that resource_track_level is set to operator and enable_resource_record to on.

The number of data records that can be retained in the memory is limited due to the preset memory limit. After the real-time query is complete, the data records are imported to historical views. For a query-level view, when the number of queries to be recorded exceeds the upper limit allowed by the memory, the current query cannot be recorded and the next query is performed based on a new rule. On each CN, the memory usage of the query-level historical view is recorded (100 MB by default). You can query the data in the PG_TOTAL_MEMORY_DETAIL view.
For operator-level views, whether a record can be stored depends on the upper limit allowed by the memory at that time point. If the number of plan nodes plus the number of records in the memory exceeds the upper limit, the record cannot be stored. On each CN, the maximum numbers of real-time and historical operator-level records that can be stored in the memory are max_oper_realt_num (set to 56987 by default) and max_oper_hist_num (set to 113975 by default), respectively. The average number of plan nodes of a query is num_plan_node. Maximum number of concurrent tasks allowed by real-time views on each CN is: num_realt_active = max_oper_realt_num/num_plan_node. Maximum number of concurrent tasks allowed by historical views on each CN is: num_hist_active = max_oper_hist_num/(180/run_time)/num_plan_node.
In high concurrency, ensure that the number of queries to be recorded does not exceed the maximum values set for query- and operator-level views. You can modify the memory of the historical query view by configuring the session_history_memory parameter. The memory size increases in direct proportion to the maximum number of queries that can be recorded.