Automatic retry method, device and system for query exception and medium

Abstract

The invention discloses an automatic retry method, device and system for query exception.The method comprises the steps that exceptions of an original query statement in the execution process are intercepted, and corresponding execution exception information is obtained; identifying an exception type according to the execution exception information, and determining whether the currently intercepted exception is a memory resource type exception and meets a preset retry condition; if yes, automatically matching a corresponding optimization strategy list according to the execution exception information and a preset query retry rule set; and optimizing the memory resources based on the optimization strategy list, and performing query retry on the original query statement to obtain a corresponding query retry result. According to the embodiment of the invention, when the memory resource abnormality is intercepted and the preset retry condition is met, the corresponding optimization strategy is automatically matched to optimize the memory resource and execute the query retry, so that self-adaptive retry recovery can be carried out when the query fails due to the resource abnormality, and the database query robustness and the query success rate are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to an automatic retry method, apparatus, system, and medium for query anomalies. Background Technology

[0002] With the rapid development of the big data era, enterprises are increasingly demanding real-time data analysis capabilities. Modern database management systems (DBMS) widely adopt distributed architectures and massively parallel processing (MPP) technologies to support complex queries with high concurrency and low latency. Currently available analytical database systems can break down an SQL query into multiple execution fragments, which are then executed in parallel on multiple computing nodes, thereby significantly improving query performance.

[0003] However, in real-world production environments, distributed query execution is highly susceptible to factors such as resource constraints, data skew, and memory pressure, leading to query failures. Insufficient memory resources are a major cause of query anomalies. Current systems, when faced with query interruptions caused by memory pressure, typically only passively return error messages, requiring users to manually retry or adjust their statements. They cannot adaptively recover from anomalies, severely impacting system availability and user experience.

[0004] Therefore, how to accurately identify and adaptively recover from resource anomalies while ensuring system stability has become a key technical problem that urgently needs to be solved in current distributed database systems. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide an automatic retry method, device, system and medium for query anomalies that can be applied to financial technology or other related fields, aiming to achieve accurate identification and intelligent retry of resource-related anomalies, and improve the robustness and success rate of database queries.

[0006] The technical solution of the present invention is as follows: An automatic retry method for query exceptions includes: Intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; Based on the execution exception information, the exception type is identified to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. If the exception is a memory resource type and the preset retry condition is met, then the corresponding optimization strategy list will be automatically matched according to the execution exception information and the preset query retry rule set. Based on the optimization strategy list, memory resources are optimized, and the original query statement is retried to obtain the corresponding query retry results.

[0007] In one embodiment, the step of identifying the exception type based on the execution exception information and confirming whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions includes: Perform keyword matching analysis on the execution exception information to confirm whether the execution exception information contains preset keywords. If so, confirm that the currently intercepted exception is a memory resource type exception. Based on the current system configuration information, confirm whether the automatic retry function has been enabled and whether no retry has been performed in the current query. If so, confirm that the preset retry conditions are met.

[0008] In one embodiment, if the exception is a memory resource-related exception and the preset retry condition is met, then the corresponding optimization strategy list is automatically matched based on the execution exception information and the preset query retry rule set, including: If it is a memory resource type exception and the preset retry condition is met, the exception triggering scenario is confirmed according to the preset keyword in the execution exception information; Based on the abnormal triggering scenario, optimization strategies are matched in a preset query retry rule set to confirm the optimization strategies applicable to the abnormal triggering scenario and their corresponding priorities, thereby obtaining a corresponding list of optimization strategies.

[0009] In one embodiment, optimizing memory resources based on the optimization strategy list and retrying the original query statement to obtain the corresponding query retry results includes: Save the original values ​​of the current session variables; Based on the optimization strategy list, the original value of the current session variable is optimized for a preset number of memory parameters according to the preset retry strategy, and the original query statement is retried for a preset number of times to obtain the corresponding query retry results. Restore the optimized current session variables to their original values.

[0010] In one embodiment, the step of optimizing the memory parameters of the original value of the current session variable a preset number of times according to the optimization strategy list and retrying the original query statement a preset number of times, and obtaining the corresponding query retry results, includes: Initialize the preset retry counter; Based on the priority order of different optimization strategies in the optimization strategy list, a polling trigger is performed, and the optimization strategy with the highest priority is executed to optimize the memory parameters of the original value of the current session variable; A new statement executor is constructed to retry the original query statement and the value of the retry counter is incremented by one; If the query is successful, the corresponding query results will be returned, and the current session variables will be restored to their original values. If the query retry fails, the next priority optimization strategy is executed to perform the next memory parameter optimization and query retry, until the value of the retry counter reaches the preset number, at which point the query retries are terminated.

[0011] In one embodiment, after restoring the optimized current session variable to its original value, the method further includes: Clear the status flags associated with retry and release statement executor resources.

[0012] In one embodiment, after intercepting exceptions during the execution of the original query statement and obtaining the corresponding execution exception information, the method further includes: Based on the execution segment identifier in the execution exception information, identify other related execution segments that are currently running; A cancellation signal is sent to the running associated execution segment to cancel the execution of the associated execution segment.

[0013] An automatic retry device for query anomalies, comprising: The exception interception module is used to intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; The exception identification module is used to identify the exception type based on the execution exception information, and to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. The strategy matching module is used to automatically match the corresponding optimization strategy list based on the execution exception information and the preset query retry rule set if the exception is a memory resource type and the preset retry conditions are met. The query retry module is used to optimize memory resources based on the optimization strategy list, retry the original query statement, and obtain the corresponding query retry results.

[0014] An automatic retry system for query anomalies, the system comprising at least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the aforementioned automatic retry method for query exceptions.

[0015] A non-volatile computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the aforementioned automatic retry method for query exceptions.

[0016] Beneficial Effects: This invention discloses an automatic retry method, apparatus, system, and medium for query anomalies. Compared to existing technologies, this invention intercepts anomalies during the execution of the original query statement to obtain corresponding execution anomaly information; identifies the anomaly type based on the execution anomaly information, confirming whether the currently intercepted anomaly is a memory resource anomaly and meets preset retry conditions; if it is a memory resource anomaly and meets the preset retry conditions, automatically matches a corresponding optimization strategy list based on the execution anomaly information and a preset query retry rule set; optimizes memory resources based on the optimization strategy list, and retryes the original query statement to obtain the corresponding query retry results. By automatically matching corresponding optimization strategies to optimize memory resources and execute query retries when a memory resource anomaly is intercepted and the preset retry conditions are met, adaptive retry recovery can be performed when the query fails due to resource anomalies, effectively improving the robustness and success rate of database queries. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 A flowchart of an automatic retry method for query anomalies provided in an embodiment of the present invention; Figure 2 This is a flowchart of step S102 in the automatic retry method for query anomalies provided in an embodiment of the present invention. Figure 3 This is a flowchart of step S103 in the automatic retry method for query anomalies provided in an embodiment of the present invention. Figure 4 This is a flowchart of step S104 in the automatic retry method for query anomalies provided in an embodiment of the present invention. Figure 5 A flowchart of step S402 in the automatic retry method for query anomalies provided in an embodiment of the present invention; Figure 6 This is another flowchart of the automatic retry method for query anomalies provided in this embodiment of the invention; Figure 7 A schematic diagram of the functional modules of the automatic retry device for query anomalies provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the hardware structure of the automatic retry system for query anomalies provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention is further described in detail below. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. The embodiments of the invention are described below in conjunction with the accompanying drawings.

[0019] Current analytical database systems can break down a SQL query into multiple execution fragments, which can then be executed in parallel on multiple computing nodes, thereby significantly improving query performance.

[0020] However, in real-world production environments, distributed query execution is highly susceptible to factors such as resource constraints, data skew, and memory pressure, leading to query failures. Insufficient memory resources are a major cause of query anomalies. Current systems, when faced with query interruptions caused by memory pressure, typically only passively return error messages, requiring users to manually retry or adjust their statements. They cannot adaptively recover from anomalies, severely impacting system availability and user experience.

[0021] To address the aforementioned problems, this invention proposes an automatic retry method for query anomalies, applied to the query execution engine of a distributed analytical database system, such as... Figure 1 As shown, the automatic retry method for query anomalies provided in this embodiment includes the following steps: S101. Intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information.

[0022] In this embodiment, a unified exception interception mechanism is pre-deployed in the query execution engine of the distributed analytical database system. This mechanism monitors for various exceptions in the original query statement in real time throughout the entire lifecycle of query execution. When an exception is thrown during query execution, it is immediately captured, and complete execution exception information is collected simultaneously. This execution exception information includes, but is not limited to, the original query SQL statement, query context, the identifier of the currently executing fragment, the original error message, information about the data source tables involved, and real-time system resource usage (such as memory usage and CPU load). By capturing exceptions throughout the entire lifecycle and collecting complete information through the unified interception mechanism, comprehensive data support is provided for subsequent exception identification and strategy matching, avoiding misjudgments or invalid processing due to missing information, and laying the foundation for automatic retries.

[0023] S102. Identify the exception type based on the execution exception information, and confirm whether the currently intercepted exception is a memory resource type exception and meets the preset retry conditions.

[0024] In this embodiment, based on the collected execution exception information, an exception type identification process is first initiated. For example, a preset keyword matching algorithm is used to analyze the exception stack information and error description to identify the currently intercepted exception type, and then determine whether the exception is related to memory resources. Subsequently, by reading system configuration parameters and querying execution status, it is verified whether the current condition meets the preset retry conditions. If both the exception type identification process and the preset retry conditions are met, the subsequent automatic retry process is triggered; otherwise, the exception information is directly thrown upwards. By accurately distinguishing memory resource exceptions from other exceptions through exception type identification, and verifying the preset retry conditions, including retry switches and retry status, the system avoids blindly retrying non-memory exceptions and prevents infinite recursive retries from consuming system resources, thus ensuring the retry mechanism's targetedness and security.

[0025] S103. If the exception is a memory resource type and the preset retry condition is met, then the corresponding optimization strategy list is automatically matched according to the execution exception information and the preset query retry rule set.

[0026] In this embodiment, the preset query retry rule set is stored in the configuration center of the database system. It can be defined in a structured format, specifically including core fields such as exception triggering scenarios, session variable conditions, optimization strategy lists, strategy parameters, and effective scope, as well as their corresponding field contents. When it is confirmed that the exception is memory resource-related and meets the preset retry conditions, the query retry rule set is precisely matched based on the key features in the execution exception information (such as memory-related keywords that specifically triggered the exception). This selects a list of optimization strategies suitable for the current exception. This list of optimization strategies includes at least one execution strategy for optimizing memory resources, such as enabling Spill to Disk (writing intermediate data to disk), enabling low memory mode, adjusting concurrency or buffer size, etc. This allows memory resources to be optimized based on the corresponding execution strategy after a memory resource-related exception occurs, thus avoiding repeated failures. By matching the execution exception information with the query retry rule set to the appropriate optimization strategy list, it is ensured that subsequent retries will automatically execute targeted memory optimization schemes in sequence, improving the retry success rate and avoiding inefficiency caused by indiscriminate attempts.

[0027] S104. Optimize memory resources based on the optimization strategy list, and retry the original query statement to obtain the corresponding query retry results.

[0028] In this embodiment, the list of optimization strategies obtained through matching includes one or more optimization strategies that help reduce memory pressure. Each optimization strategy corresponds to specific memory configuration parameter adjustment rules, such as enabling data persistence to disk, adjusting the memory buffer size, limiting the number of concurrent execution threads, and temporarily adjusting memory usage limits. Therefore, an optimization strategy can be selected from the list, and the memory resource usage configuration of the current query can be dynamically optimized based on the memory configuration parameter adjustment rules corresponding to the currently selected optimization strategy. This optimization only applies to the execution context of the retried query, ensuring the isolation of the optimization operation. After optimization, a new query execution context is constructed, the original query statement is loaded, and the query is retried to obtain the query retry result after automatic retry. Through the strategy-adaptive automatic retry mechanism, when a memory resource anomaly occurs, the query is not simply terminated, but the corresponding optimization strategy is automatically activated to reduce memory pressure and automatically retry, effectively improving the query robustness of the database system in resource-constrained environments.

[0029] Specifically, if no exception occurs during the retry process and the query result is successfully returned, the result is output as the final result of this query, completing the retry process. If the retry execution triggers an exception again, it is determined that the currently selected optimization strategy has not solved the memory problem. The system automatically switches to another optimization strategy in the optimization strategy list and repeats the above memory configuration optimization and query retry process. When all strategies in the optimization strategy list have been traversed and the retry still fails, or when the number of retries reaches the system's preset maximum retry threshold, the retry process is terminated, a query failure message is returned, and the reason for the failure and all tried optimization strategies are recorded to provide a basis for subsequent troubleshooting.

[0030] In one embodiment, such as Figure 2 As shown, step S102 includes: S201. Perform keyword matching analysis on the execution exception information to confirm whether the execution exception information contains a preset keyword. If so, confirm that the currently intercepted exception is a memory resource type exception. S202. Based on the current system configuration information, confirm whether the automatic retry function has been enabled and whether the current query has not performed a retry. If so, confirm that the preset retry conditions are met.

[0031] In this embodiment, preset keywords are stored in the system configuration file, including but not limited to characteristic strings related to memory resources such as "FULL_GC", "MINOR_GC", and "MEMORY_ALLOCATOR". When identifying the type of the currently intercepted exception, a string matching algorithm is used to traverse the exception stack and error description fields in the exception information. If any preset keyword is detected, the current exception is determined to be a memory resource exception. For example, when the exception information contains "FULL_GC", it indicates that heap memory is tight; when it contains "MINOR_GC", it indicates that the object allocation rate is too high; and when it contains "MEMORY_ALLOCATOR", it indicates that the local memory allocation exceeds the limit. All of these are classified as memory resource exceptions, thereby achieving accurate identification of the exception type.

[0032] When confirming retry conditions, the current system configuration information and retry status are used for verification. The system configuration information includes automatic retry function switch parameters (such as retry_on_memory_limit_exceeded), and the query execution context maintains a retry status flag (hasRetried). By reading the switch parameter value, if the value is "true", it indicates that the system has enabled the automatic retry function for memory limit exceptions. The status of the hasRetried flag is also checked. If the flag is "false", it indicates that the current query has not yet been retried. When both of the above conditions are met, it is confirmed that the current query meets the preset retry conditions, avoiding infinite recursive retries.

[0033] This embodiment accurately identifies memory resource-related anomalies using keywords and clarifies that the criteria for retrying are automatic retry enabled and no retry has been performed in the current query. This avoids misjudgment of anomaly types and invalid retries, ensuring that memory anomalies that meet the criteria enter the retry process, thereby improving the accuracy of anomaly handling and the utilization rate of system resources.

[0034] In one embodiment, such as Figure 3 As shown, step S103 includes: S301. If it is a memory resource type exception and the preset retry condition is met, the exception triggering scenario is confirmed according to the preset keyword in the execution exception information. S302. Based on the abnormal triggering scenario, perform optimization strategy matching in the preset query retry rule set, confirm the optimization strategy applicable to the abnormal triggering scenario and the corresponding priority, and obtain the corresponding optimization strategy list.

[0035] In this embodiment, different preset keywords correspond to different exception triggering scenarios, and the mapping relationship between keywords and triggering scenarios is stored in the query retry rule set. For example, when the execution exception information contains the keyword "FULL_GC", the exception triggering scenario is confirmed as "heap memory shortage scenario"; when it contains the keyword "MINOR_GC", the triggering scenario is confirmed as "object allocation rate too high scenario"; when it contains the keyword "MEMORY_ALLOCATOR", the triggering scenario is confirmed as "local memory overrun scenario"; if no specific keyword is matched but it has been determined to be a memory resource type exception, the triggering scenario is "default memory overrun scenario".

[0036] Meanwhile, the pre-defined query retry rule set also stores corresponding retry rules categorized by exception triggering scenarios. For example, each exception triggering scenario corresponds to several optimization strategies and their respective priorities. Each exception triggering scenario also corresponds to core fields such as session variable conditions, strategy parameters, and effective scope, along with their corresponding content. Therefore, after confirming the exception triggering scenario, all corresponding optimization strategies can be extracted from the pre-defined query retry rule set and arranged in descending order of priority to generate an optimization strategy list. For example, the optimization strategy list for a heap memory shortage scenario includes "Force Spill to Disk," "Enable Low Memory Mode," and "Reduce Query Concurrency," and is executed in this order.

[0037] In practice, in addition to the different optimization strategies corresponding to each exception triggering scenario having priorities, different exception triggering scenarios can also be preset with corresponding priorities. This allows the system to match and obtain the corresponding optimization strategy list according to the priority of the corresponding scenario when a query triggers multiple memory exceptions at the same time (such as FULL_GC and MINOR_GC occurring simultaneously), ensuring that high-urgency scenarios are responded to first.

[0038] In practice, the preset query retry rule set includes the following four cases: (1) Optimization of heap memory pressure triggered by FULL_GC (priority of scenario 1) Triggering scenario: When the exception message contains the keyword "FULL_GC", it indicates that heap memory is tight, triggering a heap memory tightness scenario; Session variable conditions: The automatic retry function must be enabled in the system configuration (retry_on_memory_limit_exceeded=true), and the data persistence function must be disabled (spill_to_disk=false). Optimization strategy list: 1. Force Spill to Disk; 2. Enable low memory mode; 3. Reduce query concurrency; Strategy parameters: Query concurrency is adjusted to exec_parallelism=2 (50% of the original configuration); buffer size is set to buffer_size=64MB; low memory mode is set to low_mem_mode=true; Scope of application: Applicable to all OLAP-type SELECT queries, excluding point queries and small queries.

[0039] (2) Optimization of excessively high object allocation rate triggered by MINOR_GC (Priority of Scenario 2) Triggering scenario: When the exception message contains the keyword "MINOR_GC", it indicates that the object allocation rate is too high, triggering the scenario of excessively high object allocation rate; Session variable conditions: The automatic retry function must be enabled in the system configuration (retry_on_memory_limit_exceeded=true), and the memory allocation rate must exceed 100MB / s (mem_alloc_rate>100MB / s). Optimization strategy list: 1. Adjust object allocation buffer; 2. Enable batch release of intermediate results; 3. Disable memory pre-allocation; Strategy parameters: The object allocation buffer is set to object_alloc_buffer=32MB; the intermediate result batch release threshold is set to batch_release_threshold=10000; Scope of application: Applicable to large result set queries (more than 1 million rows) and aggregate queries.

[0040] (3) Local memory overrun optimization triggered by MEMORY_ALLOCATOR (priority of scenario 3) Triggering scenario: When the exception message contains the keyword "MEMORY_ALLOCATOR", it indicates that the local memory allocation has exceeded the limit, triggering the local memory over-limit scenario; Session variable conditions: The automatic retry function must be enabled in the system configuration (retry_on_memory_limit_exceeded=true), and the local memory limit must be less than 2GB (local_mem_limit<2GB). Optimization strategy list: 1. Temporarily increase local memory limit; 2. Enable memory sharding; 3. Disable columnar storage preloading; Policy parameters: Local memory limit temporarily adjusted to 4GB (doubled); memory shard count set to mem_shard_count=4; Scope of application: Applicable to all queries that involve local memory allocation, such as JOIN, sorting, and aggregation queries.

[0041] (4) Default memory overrun fallback rule (priority of scenario 4) Triggering scenario: If the above three specific rules are not matched, but the memory exceeds the limit, the default memory exceed the limit scenario will be triggered. Session variable condition: The automatic retry function must be enabled in the system configuration (retry_on_memory_limit_exceeded=true); Optimization strategy list: 1. Enable all memory throttling mechanisms; 2. Limit memory usage per query; 3. Shorten memory holding time; Strategy parameters: Single query memory limit is set to query_mem_limit=1GB; memory hold timeout is set to mem_hold_timeout=5s; Scope of application: Applicable to all query types.

[0042] By configuring multiple memory exception scenarios in the query retry rule set, along with the scenario priority and specific query optimization rules for each scenario, it is ensured that when memory resource exceptions occur, the more urgent memory exception scenarios are handled first, and higher-priority optimization strategies are tried first. This guarantees both the accuracy of processing and avoids invalid attempts. It is understood that the specific parameters of the above query retry rule set are for illustrative purposes only and are not limiting. They can be flexibly adjusted according to actual needs, and this embodiment does not impose any limitations on them.

[0043] This embodiment establishes a mapping relationship between keywords and abnormal triggering scenarios, and matches the corresponding optimization strategies according to the scenario and their execution priority. This ensures that the optimization strategies are accurately adapted to the abnormal scenarios, avoids the abuse of strategies, and also ensures that core abnormalities (such as heap memory shortage) are handled in a targeted manner by prioritizing the scenarios, further improving the retry success rate.

[0044] In one embodiment, such as Figure 4 As shown, step S104 includes: S401. Save the original values ​​of the current session variables; S402. Based on the optimization strategy list, optimize the memory parameters of the original value of the current session variable a preset number of times according to the preset retry strategy, and retry the original query statement a preset number of times to obtain the corresponding query retry results. S403. Restore the optimized current session variables to their original values.

[0045] In this embodiment, before retrying the query, the original values ​​of the current session variables are saved. Specifically, the current session variables include, but are not limited to, parameters related to memory usage and query execution, such as query concurrency (exec_parallelism), buffer size (buffer_size), data write-to-disk switch (spill_to_disk), local memory limit (local_mem_limit), and low memory mode switch (low_mem_mode). All currently effective session variable values ​​are read and stored in a temporary cache area, and the mapping relationship between variable names and original values ​​is recorded, providing a basis for subsequent configuration recovery. This ensures that the retry process has no lasting impact on the user session state and does not affect subsequent query behavior, providing good isolation and security. Then, based on several optimization strategies in the optimization strategy list, the original value of the current session variable is optimized for a preset number of memory parameters according to the preset retry strategy. The preset number of retry times is stored in the system configuration (e.g., max_retry_times=3). The preset retry strategy can be "execute optimization strategy by priority" or "execute optimization strategy by usage frequency", etc. The specific retry strategy can be flexibly set according to the requirements to call the corresponding optimization strategy in the optimization strategy list. Each time an optimization strategy is selected according to the preset retry policy, the corresponding session variable values ​​are modified according to the policy parameter requirements of that optimization strategy in the query retry rule set (e.g., adjusting exec_parallelism from 4 to 2, and spill_to_disk from false to true) to optimize memory parameters. After optimization, the original query statement is retried a preset number of times, and the corresponding query retry results are obtained. For example, if the retry is successful, the query result is obtained directly; if the retry fails, it is determined whether the preset number of optimizations and retries has been performed. If not, the preset retry policy is switched to another optimization strategy and the above process is repeated until the preset number of times is reached, at which point the final query retry is recorded as successful or unsuccessful.

[0046] During the query retry process, regardless of whether a single retry succeeds or fails, or when the entire retry process terminates (after reaching the preset number of attempts or all strategies have been tried), the session variable recovery mechanism is triggered. The original values ​​of the previously stored session variables are read from the temporary cache area and overwritten one by one to restore the current session variable configuration to the original values. This ensures that modifications to session variables during the retry process are not persisted and do not affect the execution of subsequent queries.

[0047] In this embodiment, by saving the original value of the session variable, performing a limited number of optimizations and retries, and then restoring the original value of the session variable, it is possible to adaptively initiate memory optimization and query retries, and ensure that the modification of memory parameters during the retry process only affects the current query and does not affect the execution environment of subsequent queries. This achieves the isolation and security of retry operations. At the same time, by controlling the number of retries by a preset number, system overload caused by unlimited retries is avoided.

[0048] In one embodiment, such as Figure 5 As shown, step S402 includes: S501. Initialize the preset retry counter; S502. Based on the priority order of different optimization strategies in the optimization strategy list, a polling trigger is performed, and the optimization strategy with the highest priority is executed to optimize the memory parameters of the original value of the current session variable. S503. Construct a new statement executor to retry the original query statement and increment the value of the retry counter. S504. If the query is successful, return the corresponding query results and restore the current session variables to their original values; S505. If the query retry fails, the next priority optimization strategy is executed to perform the next memory parameter optimization and query retry, until the value of the retry counter reaches the preset number, at which point the query retry is terminated.

[0049] In this embodiment, a priority-based round-robin execution optimization strategy is adopted to perform a limited number of query retries. First, a preset retry counter is initialized. This retry counter is an integer variable used to record the number of retries that have been executed. Its value is set to 0 during initialization, and the value of the counter is dynamically updated as the query execution process proceeds.

[0050] The optimization strategies in the list are sorted by priority from highest to lowest, and are selected sequentially in the list order. For example, if priority 1 strategy is "force Spill to Disk", priority 2 strategy is "enable low memory mode + reduce query concurrency", and priority 3 strategy is "enable memory sharding + temporarily increase local memory limit", then the highest priority strategy, "force Spill to Disk", will be executed first during the first retry. The corresponding session variable parameters will be modified. After executing the optimization strategy, a new statement executor (StmtExecutor) will be rebuilt. This executor loads the optimized session variable configuration and the original query statement, starts the query execution process to retry the query. After execution, the retry counter value is incremented by 1, the counter status of the query execution context is updated, and the initial memory optimization and query retry process is completed.

[0051] If the newly constructed statement executor executes the original query statement and successfully returns the query result (without throwing an exception), the query result is returned to the user as a successful retry result. At the same time, the session variable recovery process is triggered, the original values ​​are read from the temporary cache, and all modified session variables are restored to ensure that subsequent queries are not affected. If an exception is thrown again during the query retry process (execution failure), the value of the retry counter is first checked to see if it is less than the preset number (e.g., 3 times). If it is less than the preset number (e.g., the counter is 1 for the first query retry), the next priority optimization strategy is selected from the optimization strategy list, such as switching to priority 2 strategy "Enable low memory mode + reduce query concurrency", and the above process is repeated for the next memory parameter optimization and query retry. If the value of the retry counter has reached the preset number (e.g., 3 query retries have been performed), the entire retry process is terminated, the query failure result information is returned, and the subsequent configuration recovery operation is triggered.

[0052] This embodiment triggers optimization strategies by polling based on priority and controls the number of retries by using a retry counter. This ensures that high-priority strategies are executed first and can switch to a different strategy in a timely manner when the current strategy is ineffective. This maximizes the success rate of retrying while avoiding unnecessary waste and improves the orderliness and efficiency of the retry process.

[0053] In one embodiment, after step S403, the method further includes: Clear the status flags associated with retry and release statement executor resources.

[0054] In this embodiment, after ending the query retry process and restoring the original values ​​of session variables, further state cleanup is performed. This clears retry-related state flags, specifically the `hasRetried` flag and the `retryCount` in the query execution context. The `hasRetried` flag is reset to "false", the `retryCount` value is reset to 0, and all state records related to this retry are cleared. Subsequently, the currently used statement executor (`StmtExecutor`) is cleared, releasing memory, thread, and database connection resources occupied by the statement executor to prevent resource leaks. By clearing retry state flags and releasing executor resources after a retrieval, residual state is prevented from affecting subsequent queries, while resource leaks (such as memory and thread resource occupation) are prevented, ensuring the cyclical use of system resources and improving the long-term stability of the system.

[0055] In one embodiment, such as Figure 6 As shown, after step S101, the method further includes: S701. Based on the execution segment identifier in the execution exception information, identify other related execution segments that are currently running; S702. Send a cancellation signal to the running associated execution segment to cancel the execution of the associated execution segment.

[0056] In this embodiment, since the original query statement is split into multiple interconnected execution fragments in a distributed execution environment and executed in parallel on different nodes, each execution fragment is assigned a unique identifier (fragment ID). Therefore, when an execution fragment is intercepted due to an execution exception, the identifier of the execution fragment that triggered the exception recorded in the execution exception information can be used to identify other related execution fragments that are currently running. For example, by querying the execution plan metadata, a list of all execution fragments corresponding to the original query and the relationships between fragments (such as data dependencies and collaborative execution relationships) can be obtained. Based on the identifier of the exception fragment, all related execution fragments that are still in the "Running" state can be filtered out to generate a list of related fragments.

[0057] A unified cancellation signal is sent to all associated execution segments in the associated segment list by a coordinator. This signal carries the query ID and the identifier of the abnormal segment, informing each execution segment that the current query has encountered an error and must be terminated. Upon receiving the cancellation signal, each associated execution segment immediately stops its current computation task, releases occupied memory, CPU, and other resources, and returns a confirmation message of cancellation to the coordinator. This collaborative cancellation mechanism allows for the rapid identification and cancellation of associated execution segments after an error occurs, preventing thread pool blocking, resource leaks, or the entire query execution chain from becoming stuck due to partial segment suspension, thus ensuring the overall stability of the system.

[0058] It should be noted that there is no necessary order between the above steps. Those skilled in the art will understand from the description of the embodiments of the present invention that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in turn, etc.

[0059] Another embodiment of the present invention provides an automatic retry device for query anomalies, such as... Figure 7 As shown, device 1 includes: The exception interception module 11 is used to intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; The exception identification module 12 is used to identify the exception type based on the execution exception information, and to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. The strategy matching module 13 is used to automatically match the corresponding optimization strategy list according to the execution exception information and the preset query retry rule set if the exception is a memory resource type and the preset retry conditions are met. The query retry module 14 is used to optimize memory resources based on the optimization strategy list, retry the original query statement, and obtain the corresponding query retry results.

[0060] The module referred to in this invention is a series of computer program instruction segments that can perform specific functions. It is more suitable than a program for describing the execution process of automatic retry of query exceptions. For specific implementation methods of each module, please refer to the corresponding method embodiments above, which will not be repeated here.

[0061] Another embodiment of the present invention provides an automatic retry system for query anomalies, such as... Figure 8 As shown, system 10 includes: One or more processors 110 and memory 120, Figure 8 The following description uses a processor 110 as an example. The processor 110 and the memory 120 can be connected via a bus or other means. Figure 8 Taking the example of a connection between China and Israel via a bus.

[0062] Processor 110 is used to perform various control logics of system 10, and can be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), microcontroller, ARM (Acorn RISC Machine) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of these components. Furthermore, processor 110 can also be any conventional processor, microprocessor, or state machine. Processor 110 can also be implemented as a combination of computing devices, such as a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors combined with DSP and / or any other such configuration.

[0063] The memory 120, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions corresponding to the automatic retry method for query exceptions in the embodiments of the present invention. The processor 110 executes various functional applications and data processing of the system 10 by running the non-volatile software programs, instructions, and units stored in the memory 120, thereby implementing the automatic retry method for query exceptions in the above method embodiments.

[0064] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created according to the use of the system 10. Furthermore, the memory 120 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the system 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0065] One or more units are stored in memory 120, and when executed by one or more processors 110, perform the following steps: Intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; Based on the execution exception information, the exception type is identified to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. If the exception is a memory resource type and the preset retry condition is met, then the corresponding optimization strategy list will be automatically matched according to the execution exception information and the preset query retry rule set. Based on the optimization strategy list, memory resources are optimized, and the original query statement is retried to obtain the corresponding query retry results.

[0066] In one embodiment, the step of identifying the exception type based on the execution exception information and confirming whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions includes: Perform keyword matching analysis on the execution exception information to confirm whether the execution exception information contains preset keywords. If so, confirm that the currently intercepted exception is a memory resource type exception. Based on the current system configuration information, confirm whether the automatic retry function has been enabled and whether no retry has been performed in the current query. If so, confirm that the preset retry conditions are met.

[0067] In one embodiment, if the exception is a memory resource-related exception and the preset retry condition is met, then the corresponding optimization strategy list is automatically matched based on the execution exception information and the preset query retry rule set, including: If it is a memory resource type exception and the preset retry condition is met, the exception triggering scenario is confirmed according to the preset keyword in the execution exception information; Based on the abnormal triggering scenario, optimization strategies are matched in a preset query retry rule set to confirm the optimization strategies applicable to the abnormal triggering scenario and their corresponding priorities, thereby obtaining a corresponding list of optimization strategies.

[0068] In one embodiment, optimizing memory resources based on the optimization strategy list and retrying the original query statement to obtain the corresponding query retry results includes: Save the original values ​​of the current session variables; Based on the optimization strategy list, the original value of the current session variable is optimized for a preset number of memory parameters according to the preset retry strategy, and the original query statement is retried for a preset number of times to obtain the corresponding query retry results. Restore the optimized current session variables to their original values.

[0069] In one embodiment, the step of optimizing the memory parameters of the original value of the current session variable a preset number of times according to the optimization strategy list and retrying the original query statement a preset number of times, and obtaining the corresponding query retry results, includes: Initialize the preset retry counter; Based on the priority order of different optimization strategies in the optimization strategy list, a polling trigger is performed, and the optimization strategy with the highest priority is executed to optimize the memory parameters of the original value of the current session variable; A new statement executor is constructed to retry the original query statement and the value of the retry counter is incremented by one; If the query is successful, the corresponding query results will be returned, and the current session variables will be restored to their original values. If the query retry fails, the next priority optimization strategy is executed to perform the next memory parameter optimization and query retry, until the value of the retry counter reaches the preset number, at which point the query retries are terminated.

[0070] In one embodiment, after restoring the optimized current session variable to its original value, the method further includes: Clear the status flags associated with retry and release statement executor resources.

[0071] In one embodiment, after intercepting exceptions during the execution of the original query statement and obtaining the corresponding execution exception information, the method further includes: Based on the execution segment identifier in the execution exception information, identify other related execution segments that are currently running; A cancellation signal is sent to the running associated execution segment to cancel the execution of the associated execution segment.

[0072] This invention provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example, to perform the operations described above. Figure 1 The method steps S101 to S104.

[0073] As examples, non-volatile storage media can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) as external cache memory. By way of illustration and not limitation, RAM can be obtained in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The memory components or memories disclosed in the operating environment described herein are intended to include one or more of these and / or any other suitable types of memory.

[0074] In summary, the automatic retry method, apparatus, system, and medium for query anomalies disclosed in this invention intercepts anomalies during the execution of the original query statement to obtain corresponding execution anomaly information; identifies the anomaly type based on the execution anomaly information, confirming whether the currently intercepted anomaly is a memory resource anomaly and meets preset retry conditions; if it is a memory resource anomaly and meets the preset retry conditions, automatically matches a corresponding optimization strategy list based on the execution anomaly information and a preset query retry rule set; optimizes memory resources based on the optimization strategy list, and retryes the original query statement to obtain the corresponding query retry results. By automatically matching corresponding optimization strategies to optimize memory resources and execute query retries when a memory resource anomaly is intercepted and the preset retry conditions are met, adaptive retry recovery can be performed when the query fails due to resource anomalies, effectively improving the robustness and success rate of database queries.

[0075] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The computer program can be stored in a non-volatile, computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The storage medium can be a memory, magnetic disk, floppy disk, flash memory, optical storage, etc.

[0076] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An automatic retry method for query anomalies, characterized in that, include: Intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; Based on the execution exception information, the exception type is identified to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. If the exception is a memory resource type and the preset retry condition is met, then the corresponding optimization strategy list will be automatically matched according to the execution exception information and the preset query retry rule set. Based on the optimization strategy list, memory resources are optimized, and the original query statement is retried to obtain the corresponding query retry results.

2. The automatic retry method for query anomalies according to claim 1, characterized in that, The step of identifying the exception type based on the execution exception information, and confirming whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions, includes: Perform keyword matching analysis on the execution exception information to confirm whether the execution exception information contains preset keywords. If so, confirm that the currently intercepted exception is a memory resource type exception. Based on the current system configuration information, confirm whether the automatic retry function has been enabled and whether no retry has been performed in the current query. If so, confirm that the preset retry conditions are met.

3. The automatic retry method for query anomalies according to claim 1, characterized in that, If the exception is a memory resource-related exception and the preset retry condition is met, then the corresponding optimization strategy list is automatically matched according to the execution exception information and the preset query retry rule set, including: If it is a memory resource type exception and the preset retry condition is met, the exception triggering scenario is confirmed according to the preset keyword in the execution exception information; Based on the abnormal triggering scenario, optimization strategies are matched in a preset query retry rule set to confirm the optimization strategies applicable to the abnormal triggering scenario and their corresponding priorities, thereby obtaining a corresponding list of optimization strategies.

4. The automatic retry method for query anomalies according to claim 1, characterized in that, The process of optimizing memory resources based on the optimization strategy list and retrying the original query statement to obtain the corresponding query retry results includes: Save the original values ​​of the current session variables; Based on the optimization strategy list, the original value of the current session variable is optimized for a preset number of memory parameters according to the preset retry strategy, and the original query statement is retried for a preset number of times to obtain the corresponding query retry results. Restore the optimized current session variables to their original values.

5. The automatic retry method for query anomalies according to claim 4, characterized in that, Based on the optimization strategy list, the original value of the current session variable is optimized for a preset number of memory parameters according to a preset retry strategy, and the original query statement is retried a preset number of times to obtain the corresponding query retry results, including: Initialize the preset retry counter; Based on the priority order of different optimization strategies in the optimization strategy list, a polling trigger is performed, and the optimization strategy with the highest priority is executed to optimize the memory parameters of the original value of the current session variable; A new statement executor is constructed to retry the original query statement and the value of the retry counter is incremented by one; If the query is successful, the corresponding query results will be returned, and the current session variables will be restored to their original values. If the query retry fails, the next priority optimization strategy is executed to perform the next memory parameter optimization and query retry, until the value of the retry counter reaches the preset number, at which point the query retries are terminated.

6. The automatic retry method for query anomalies according to claim 4, characterized in that, After restoring the optimized current session variables to their original values, the method further includes: Clear the status flags associated with retry and release statement executor resources.

7. The automatic retry method for query anomalies according to claim 1, characterized in that, After intercepting exceptions during the execution of the original query statement and obtaining the corresponding execution exception information, the method further includes: Based on the execution segment identifier in the execution exception information, identify other related execution segments that are currently running; A cancellation signal is sent to the running associated execution segment to cancel the execution of the associated execution segment.

8. An automatic retry device for query anomalies, characterized in that, include: The exception interception module is used to intercept exceptions during the execution of the original query statement and obtain the corresponding execution exception information; The exception identification module is used to identify the exception type based on the execution exception information, and to confirm whether the currently intercepted exception is a memory resource exception and meets the preset retry conditions. The strategy matching module is used to automatically match the corresponding optimization strategy list based on the execution exception information and the preset query retry rule set if the exception is a memory resource type and the preset retry conditions are met. The query retry module is used to optimize memory resources based on the optimization strategy list, retry the original query statement, and obtain the corresponding query retry results.

9. An automatic retry system for query anomalies, characterized in that, The system includes at least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the automatic retry method for query exceptions as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the automatic retry method for query exceptions as described in any one of claims 1-7.

Images