Virus killing method, device, computer equipment and storage medium
By traversing the database background tables, identifying and killing large transactions that meet specific conditions, the database blocking problem caused by large transactions occupying resources is solved, and database performance and stability are improved.
Patent Information
- Application Number
- CN202210193030.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-02-28
- Publication Date
- 2025-06-24
- Estimated Expiration
- 2042-02-28
AI Technical Summary
Large transactions running in the database occupy resources for a long time, resulting in database blocking and performance degradation. A method is needed to promptly detect and kill these large transactions.
By traversing each transaction operation information in the preset background table, the target transaction operation information that meets the preset detection and killing conditions is determined, and a killing statement is generated based on the session identifier of the target transaction operation information, and a killing operation is performed on the database server.
It realizes accurate identification and timely detection of major transactions in the database, reduces the workload of manually maintaining the database, and improves the performance and reliability of the database.
Smart Images

Figure CN114461659B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technologies, and in particular, to a method, apparatus, computer device, and storage medium for detecting and killing large transactions. Background Art
[0002] A transaction is a sequence of database operations, which includes database access operations and various other database operations. These operations are either all executed or all not executed, and it is an indivisible unit of work.
[0003] In related technologies, a transaction that takes too long to execute and returns a large number of execution results in a database is called a large transaction. The running of a large transaction will occupy resources such as the central processing unit (CPU), memory, and disk of the database system for a long time, causing database blocking and affecting database performance. Therefore, how to detect and kill large transactions that are running in the database is an urgent problem to be solved. Summary of the Invention
[0004] Based on this, in view of the above technical problems, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for detecting and killing large transactions in a database server in a timely manner.
[0005] In a first aspect, this application provides a method for detecting and killing large transactions. The method includes:
[0006] Traverse each piece of transaction running information in a preset background table to determine the target transaction running information that meets the preset detection and killing conditions;
[0007] Generate a detection and killing statement according to the session identification information corresponding to the target transaction running information;
[0008] Based on the detection and killing statement, detect and kill the transaction corresponding to the target transaction running information on the database server.
[0009] In one embodiment, the transaction running information includes the transaction execution time and the number of rows updated by the operation;
[0010] The step of traversing each piece of transaction running information in a preset background table to determine the target transaction running information that meets the preset detection and killing conditions includes:
[0011] Determine the transaction running information with a transaction execution time exceeding a preset time threshold as the target transaction running information that meets the preset detection and killing conditions;
[0012] Or, determine the transaction running information with the number of rows updated by the operation exceeding a preset quantity threshold as the target transaction running information that meets the preset detection and killing conditions.
[0013] In one embodiment, the transaction running information includes the transaction execution time and the number of rows updated by the operation; the method further includes:
[0014] At each preset time interval, for each transaction in the preset background table, eliminate the transactions whose transaction execution time at the current moment is the same as that at the previous moment;
[0015] and / or; eliminate the transactions whose number of rows updated by the operation at the current moment is the same as that at the previous moment.
[0016] In one embodiment, the method further includes:
[0017] According to the session identification information corresponding to the target transaction running information, obtain multiple operation metric information of the database server corresponding to the session identification information;
[0018] Input the multiple operation metric information into a preset detection and killing judgment algorithm to obtain a detection and killing judgment result;
[0019] When the detection and killing judgment result meets the preset detection and killing feasibility condition, execute the step of generating a detection and killing statement according to the session identification information corresponding to the target transaction running information.
[0020] In one embodiment, after the step of killing the transaction corresponding to the target transaction running information on the database server based on the detection and killing statement, the method further includes:
[0021] Send a detection and killing completion notification message to the operation and maintenance terminal corresponding to the transaction corresponding to the target transaction running information.
[0022] In one embodiment, the method further includes:
[0023] At each preset time interval, periodically access the database server, and based on the system view of the database server and the transaction identifiers in the preset background table, obtain transaction running information, where the transaction running information includes transaction identifier information, operation time-consuming information, and number of rows updated by the operation information;
[0024] Store the transaction running information in a preset background table, where the transaction includes at least one database operation.
[0025] In one embodiment, the transaction running information further includes the transaction execution time, and the method further includes:
[0026] Obtain a target session identifier from a preset session identifier table;
[0027] Determine whether there is a target transaction identifier corresponding to the target session identifier in the preset background table;
[0028] If there is the target transaction identifier in the preset background table, update the transaction execution time of the transaction corresponding to the target transaction identifier according to the operation time-consuming information corresponding to the target transaction identifier;
[0029] If there is no target transaction identifier in the preset background table, insert the target transaction identifier into the preset background table.
[0030] In a second aspect, the present application also provides a killing device. The device includes:
[0031] A first determination module, configured to traverse each transaction operation information in the preset background table to determine target transaction operation information that meets the preset killing conditions;
[0032] A generation module, configured to generate a killing statement according to the session identifier information corresponding to the target transaction operation information;
[0033] A killing module, configured to kill the transaction corresponding to the target transaction operation information on the database server based on the killing statement.
[0034] In one embodiment, the transaction operation information includes transaction execution time and the number of operation update rows;
[0035] The first determination module is specifically configured to:
[0036] Determine the transaction operation information with a transaction execution time exceeding a preset time threshold as the target transaction operation information that meets the preset killing conditions;
[0037] Or, determine the transaction operation information with the number of operation update rows exceeding a preset quantity threshold as the target transaction operation information that meets the preset killing conditions.
[0038] In one embodiment, the transaction operation information includes transaction execution time and the number of operation update rows; the device includes:
[0039] A first elimination module, configured to eliminate, at each preset time interval, for each transaction in the preset background table, the transaction with the same transaction execution time at the current moment and the previous moment;
[0040] A second elimination module, configured to; eliminate the transaction with the same number of operation update rows at the current moment and the previous moment.
[0041] In one embodiment, the device further includes:
[0042] A first acquisition module, configured to acquire multiple operation index information of a database server corresponding to the session identification information according to the session identification information corresponding to the target transaction operation information;
[0043] A first judgment module, configured to input the multiple operation index information into a preset anti-virus judgment algorithm to obtain an anti-virus judgment result;
[0044] An execution module, configured to execute the step of generating an anti-virus statement according to the session identification information corresponding to the target transaction operation information when the anti-virus judgment result meets a preset anti-virus feasibility condition.
[0045] In one embodiment, the device further includes:
[0046] A sending module, configured to send an anti-virus completion notification message to an operation and maintenance terminal corresponding to a transaction corresponding to the target transaction operation information.
[0047] In one embodiment, the device further includes:
[0048] A second acquisition module, configured to periodically access the database server at preset time intervals, and acquire transaction operation information based on a system view of the database server and a transaction identification in a preset background table, where the transaction operation information includes transaction identification information, operation time-consuming information, and operation updated row count information;
[0049] A storage module, configured to store the transaction operation information into a preset background table, where the transaction includes at least one database operation.
[0050] In one embodiment, the transaction operation information further includes a transaction execution time, and the device further includes:
[0051] A third acquisition module, configured to acquire a target session identification from a preset session identification table;
[0052] A second judgment module, configured to judge whether a target transaction identification corresponding to the target session identification exists in the preset background table;
[0053] An update module, configured to, if the target transaction identification exists in the preset background table, update the transaction execution time of the transaction corresponding to the target transaction identification according to the operation time-consuming information corresponding to the target transaction identification;
[0054] An insertion module, configured to, if the target transaction identification does not exist in the preset background table, insert the target transaction identification into the preset background table.
[0055] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:
[0056] Traverse each piece of transaction operation information in a preset background table to determine target transaction operation information that meets the preset detection and killing conditions;
[0057] Generate a detection and killing statement according to the session identification information corresponding to the target transaction operation information;
[0058] Based on the detection and killing statement, detect and kill the transaction corresponding to the target transaction operation information on a database server.
[0059] In a fourth aspect, the present application further provides a computer-readable storage medium. On the computer-readable storage medium, a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:
[0060] Traverse each piece of transaction operation information in a preset background table to determine target transaction operation information that meets the preset detection and killing conditions;
[0061] Generate a detection and killing statement according to the session identification information corresponding to the target transaction operation information;
[0062] Based on the detection and killing statement, detect and kill the transaction corresponding to the target transaction operation information on a database server.
[0063] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:
[0064] Traverse each piece of transaction operation information in a preset background table to determine target transaction operation information that meets the preset detection and killing conditions;
[0065] Generate a detection and killing statement according to the session identification information corresponding to the target transaction operation information;
[0066] Based on the detection and killing statement, detect and kill the transaction corresponding to the target transaction operation information on a database server.
[0067] The above anti-kill method, device, computer device, storage medium, and computer program product traverse each transaction operation information in a preset background table to determine the target transaction operation information that meets the preset anti-kill conditions; generate an anti-kill statement according to the session identification information corresponding to the target transaction operation information; and based on the anti-kill statement, kill the transaction corresponding to the target transaction operation information on the database server. The anti-kill method provided in this embodiment can accurately identify and timely kill large transactions, reduce the workload of manual database maintenance, and improve the reliability and stability of database production operations. BRIEF DESCRIPTION OF THE DRAWINGS
[0068] Figure 1 FIG. is an application environment diagram of the anti-kill method in an embodiment;
[0069] Figure 2 FIG. is a flowchart of the anti-kill method in an embodiment;
[0070] Figure 3 FIG. is a flowchart of the step of determining the target transaction operation information in an embodiment;
[0071] Figure 4 FIG. is a flowchart of the step of excluding transactions in an embodiment;
[0072] Figure 5 FIG. is a flowchart of the step of generating an anti-kill statement in an embodiment;
[0073] Figure 6 FIG. is a flowchart of the generation step of the preset background table in an embodiment;
[0074] Figure 7 FIG. is a flowchart of the step of determining whether there is a target transaction identifier in an embodiment;
[0075] Figure 8 FIG. is a structural block diagram of the anti-kill device in an embodiment;
[0076] Figure 9 FIG. is an internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0077] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0078] The anti-kill method provided in the embodiments of the present application can be applied to, for example Figure 1In the application environment shown. Among them, the monitoring server 102 communicates with the database server 104 through the network. The data storage system can store the data that the database server 104 needs to process. The data storage system can be integrated on the database server 104, or placed on the cloud or other network servers. The monitoring server 102 obtains the information related to various database operations on the database server 104 and stores it. The monitoring server 102 kills the target transactions in the database server 104 based on the obtained information to ensure the running performance of the database server 104. Among them, the monitoring server 102 can be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers, and portable wearable devices. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The database server 104 can be implemented by an independent database server or a server cluster composed of multiple servers. That is to say, the monitoring server 102 and the database server 104 can be in a one-to-n relationship.
[0079] In one embodiment, as Figure 2 shown, a killing method is provided. In this embodiment, the killing method is applied to the monitoring server for illustration. The killing method includes the following steps:
[0080] Step 202, traverse each transaction running information in the preset background table to determine the target transaction running information that meets the preset killing conditions.
[0081] Specifically, the preset background table is a data table stored in the monitoring server. The preset background table stores the records of the transaction running information of each transaction. A transaction is a sequence containing multiple database operations. The monitoring server and the database (database server) are in a one-to-many relationship. The specific implementation manner of each database operation executed on the database server can be an SQL statement. After the database operation is executed through the SQL statement, the execution result corresponding to the database operation is obtained, that is, what operation is actually performed on the database server (such as insert, delete, update, query, etc.). This transaction can be caused by a session.
[0082] In this way, the information stored in each record in the preset background table can include session identification (transaction identification), time-consuming information, transaction execution time information, operation update row number information, database server address information for executing the database operation, and so on. The preset killing condition can be a screening condition determined by the monitoring server according to the actual requirements of the actual application scenario. For example, the preset killing condition can be that the operation update row number is greater than or equal to the preset quantity threshold.
[0083] In this way, the monitoring server traverses the operation information of each transaction in the preset background table, that is, the monitoring server filters the operation information of each transaction in the preset background table to determine the target transaction operation information that meets the preset killing condition for the number of updated rows of the operation.
[0084] Step 204: Generate a killing statement according to the session identification information corresponding to the target transaction operation information.
[0085] Specifically, a transaction is caused by a session. That is to say, the session identifier (session ID) is the same as the identifier of the transaction caused by this session. For a transaction, the ID of this transaction is the ID of the session that caused this transaction. In this embodiment, after the monitoring server filters out the target transaction operation information that meets the preset killing condition, that is, the transaction ID corresponding to the target transaction operation information can be determined. In this way, the monitoring server can generate a killing statement according to this session identification information and the initial killing process SQL statement.
[0086] Step 206: Kill the transaction corresponding to the target transaction operation information on the database server based on the killing statement.
[0087] Specifically, the monitoring server accesses the database server through the database server address information carried in the target transaction operation information. And based on this killing statement, when accessing this database server, kill the transaction corresponding to the target transaction operation information. This killing statement can be a kill session statement. That is to say, the monitoring server can directly push the kill session statement to the database server corresponding to the target transaction operation information based on the database server address information.
[0088] In the above killing method, by traversing the operation information of each transaction in the preset background table, the target transaction operation information that meets the preset killing condition is determined. A killing statement is generated according to the session identification information corresponding to the target transaction operation information. And based on the killing statement, the transaction corresponding to the target transaction operation information is killed on the database server. The killing method provided in this embodiment can accurately identify and timely kill large transactions, reduce the workload of manual database maintenance, and improve the reliability and stability of database production operation.
[0089] In one embodiment, the transaction running information includes the transaction execution time and the number of rows updated by the operations. The transaction execution time is the time that the transaction has been executed, that is, the duration that the transaction has been running. The monitoring server can update the transaction execution time according to the obtained elapsed time information. Specifically, the elapsed time information of the transaction can be extracted through the last_call_et field of the transaction (v$session). The number of rows updated by the operations represents the number of database operation results that have been returned for each database operation included in the transaction, and one database operation corresponds to one database operation result.
[0090] Correspondingly, as Figure 3 shown, the specific processing procedure of step 202, "traverse each piece of transaction running information in the preset background table and determine the target transaction running information that meets the preset killing condition", includes:
[0091] Step 302, determine the transaction running information whose transaction execution time exceeds the preset time threshold as the target transaction running information that meets the preset killing condition.
[0092] Specifically, the preset time threshold can be the search parameter corresponding to the transaction execution time, and the specific value of this preset time threshold can be determined according to the tolerance degree of different database servers for the running time of each transaction. The monitoring server can use a select search statement to search for each piece of transaction running information in the preset background table, that is, search for the transaction running information that is greater than or equal to the search parameter (preset time threshold), and determine the transaction running information whose transaction execution time exceeds the preset time threshold as the target transaction running information that meets the preset killing condition.
[0093] Step 304, determine the transaction running information whose number of rows updated by the operations exceeds the preset quantity threshold as the target transaction running information that meets the preset killing condition.
[0094] Specifically, the preset quantity threshold can be the search parameter corresponding to the number of rows updated by the operations, and the specific value of this preset quantity threshold can be determined according to the tolerance degree of different database servers for the number of rows updated by each operation. The monitoring server can use a select search statement to search for each piece of transaction running information in the preset background table, that is, search for the transaction running information that is greater than or equal to the search parameter (preset quantity threshold), and determine the transaction running information whose number of rows updated by the operations exceeds the preset quantity threshold as the target transaction running information that meets the preset killing condition.
[0095] In a possible implementation, the monitoring server may execute step 302 or step 304, or execute both step 302 and step 304. Those skilled in the art can specifically determine according to the actual application scenario, and this embodiment does not limit this. Among them, the execution order of step 302 and step 304 does not distinguish between before and after.
[0096] In one embodiment, the transaction running information includes the transaction execution time and the number of updated rows of the operation.
[0097] Correspondingly, as Figure 4 shown, the killing method further includes:
[0098] Step 402, at every preset time interval, for each transaction in the preset background table, eliminate the transactions whose transaction execution time at the current moment is the same as that at the previous moment.
[0099] Specifically, the preset time interval can be half an hour or one hour, and the specific time length of the time interval can be specifically determined according to the actual application scenarios of the monitoring server and each database server. The monitoring server screens each transaction included in the preset background table at every preset time interval (such as half an hour). After the monitoring server records the transaction execution time of each transaction in the preset background table after the sampling period corresponding to the current moment, and the transaction execution time of each transaction in the preset background table after the previous sampling period corresponding to the previous moment. Eliminate the transactions with the same transaction execution time in adjacent sampling periods. That is to say, the monitoring server will eliminate the transactions whose transaction execution time no longer changes with the change of the sampling period (the last_call_et field in the session no longer increases), and consider that the transaction execution time of this transaction is no longer updated, that is, the transaction execution ends. That is, there is no relevant session in v$session.
[0100] Step 404, at every preset time interval, for each transaction in the preset background table, eliminate the transactions whose number of updated rows of the operation at the current moment is the same as that at the previous moment.
[0101] Specifically, the preset time interval can be half an hour or one hour, and the specific length of the time interval can be determined according to the actual application scenarios of the monitoring server and each database server. The monitoring server screens each transaction included in the preset background table at every preset time interval (such as half an hour). After the monitoring server records the sampling period corresponding to the current moment, it records the operation update rows of each transaction in the preset background table, and the operation update rows of each transaction in the preset background table after the previous sampling period adjacent to this sampling period. Transactions with the same operation update rows in adjacent sampling periods are removed. That is to say, the monitoring server will remove transactions whose operation update rows no longer change with the change of the sampling period (the last_call_et field in the session no longer increases), and considers that the operation update rows of this transaction no longer update, and no execution result is returned for the transaction, that is, the transaction execution ends. That is, there is no relevant session in v$session.
[0102] In a possible implementation manner, the monitoring server can execute step 402 or execute step 404, or execute step 402 and step 404 together. Those skilled in the art can specifically determine according to the actual application scenario, and this embodiment does not make any limitation in this regard. Among them, the execution order of step 402 and step 404 does not distinguish between before and after.
[0103] In one embodiment, as Figure 5 shown, the killing method further includes:
[0104] Step 502, obtain multiple operation index information of the database server corresponding to the session identification information according to the session identification information corresponding to the target transaction operation information.
[0105] Step 504, input the multiple operation index information into a preset killing judgment algorithm to obtain a killing judgment result.
[0106] Step 506, when the killing judgment result meets the preset killing feasibility condition, execute the step of generating a killing statement according to the session identification information corresponding to the target transaction operation information.
[0107] Specifically, the operation index information can be the operation priority information and the transaction importance degree information of the transaction corresponding to the target transaction operation information. The monitoring server can input the obtained operation priority information of the transaction into a preset killing judgment algorithm, and the killing result output by the preset killing judgment algorithm can be recommended killing and recommended retaining the transaction. If the killing result output by this killing judgment algorithm is recommended killing, the monitoring server can determine that this killing result meets the preset killing feasibility condition. In this way, the monitoring server can execute the step of generating a killing statement according to the session identification information corresponding to the target transaction operation information.
[0108] If the detection result output by the detection and killing judgment algorithm is to recommend retaining the transaction, the monitoring server may determine that the detection result does not meet the conditions of the preset detection and killing feasibility. In this way, the monitoring server may re-execute the steps described in step 102, or output a prompt message indicating the end of traversal.
[0109] In one embodiment, after step 206, "Based on the detection and killing statement, detect and kill the transaction corresponding to the target transaction running information on the database server", the detection and killing method further includes:
[0110] Send the detection and killing completion notification information to the operation and maintenance terminal corresponding to the transaction corresponding to the target transaction running information.
[0111] Specifically, based on the detection and killing statement, the monitoring server can detect and kill the transaction corresponding to the target transaction running information on the database server. After the detection and killing, the monitoring server can automatically generate the detection and killing completion notification information, and send the detection and killing completion notification information to the operation and maintenance terminal related to the transaction by means of email or syslog.
[0112] In this embodiment, by sending the detection and killing completion notification information to each operation and maintenance terminal related to the transaction, the situation of whether the transaction is detected and killed can be notified to each operation and maintenance terminal in a timely manner, reducing the workload of front-line database maintenance personnel and improving the stability of database production operation.
[0113] In one of the embodiments, as Figure 6 shown, the method further includes:
[0114] Step 602, at preset time intervals, periodically access the database server, and based on the system view of the database server and the transaction identifiers in the preset background table, obtain the transaction running information.
[0115] Among them, the transaction running information includes transaction identifier information, operation time-consuming information, operation updated row count information, and the transaction running information further includes the address information of the database server executing the transaction, the identifier information of each SQL operation used in each database operation included in the transaction, etc.
[0116] Specifically, a transaction is initiated by a session. The transaction identifier information is determined according to the session identifier information, that is, the transaction identifier information is the session identifier information. The monitoring server can periodically access each database server at preset time intervals. In this way, the monitoring server can obtain the transaction running information of each transaction on each database server based on the system view (Oracle system view) of each database server.
[0117] Optionally, the monitoring server can monitor the operating resources of the database server. If the monitoring server detects that the operating resources of the database server are less than or equal to the preset operating resource threshold, the monitoring server can access the database server and, based on the system view of the database server and the transaction identifiers in the preset background table, obtain the transaction running information, and kill the transaction based on the transaction running information.
[0118] Step 604, store the transaction running information in the preset background table.
[0119] Among them, a transaction includes at least one database operation.
[0120] Specifically, the preset time interval can be a preset sampling time interval. After the monitoring server periodically accesses the database server and obtains the transaction running information, it can store the sampling time point information corresponding to the preset sampling time interval and the transaction running information collected within the preset sampling time interval in the preset background table in the monitoring server.
[0121] Optionally, a transaction includes at least one database operation. For example, a transaction can include multiple database operations, and each database operation needs to be implemented with an SQL statement. Among them, if any one database operation fails, the transaction corresponding to the database operation fails, and the transaction performs a status rollback to restore the running state of the transaction to the state before the transaction was executed. That is, the various database operations corresponding to the transaction are revoked.
[0122] In one embodiment, the transaction running information further includes the transaction execution time; correspondingly, as Figure 7 shown, the killing method further includes:
[0123] Step 702, obtain the target session identifier from the preset session identifier table.
[0124] Specifically, the preset session identifier table can be determined in advance according to the actual application scenario. The session identifier table contains the identifiers of multiple sessions and is arranged in sequence. The monitoring server can sequentially obtain multiple session identifiers from the preset session identifier table and use them as the target session identifiers respectively.
[0125] Step 704, determine whether there is a target transaction identifier corresponding to the target session identifier in the preset background table.
[0126] Specifically, if the target session identifier exists in the preset background table, execute step 706; if the target session identifier does not exist in the preset background table, execute step 708.
[0127] Step 706, if the target transaction identifier exists in the preset background table, update the transaction execution time of the transaction corresponding to the target transaction identifier according to the operation time-consuming information corresponding to the target transaction identifier.
[0128] Specifically, the monitoring server can monitor the last_call_et field of v$session in the database server to obtain the time-consuming information corresponding to the transaction, and update the transaction execution time of the transaction according to the time-consuming information.
[0129] Optionally, the time-consuming information corresponding to the transaction can be the total time length of all database operations in the transaction, that is, the time length that the transaction has been executed. In this way, the monitoring server can use the obtained time-consuming information under the transaction identifier as the transaction execution time of the transaction.
[0130] Optionally, the time-consuming information corresponding to the transaction can be a sequence including the time lengths of each database operation in the transaction. In this way, the transaction execution information of the transaction is the sum of the time lengths included in the sequence of the time lengths, that is, the transaction execution time of the transaction is the sum of the running times (operation times) of each database operation included in the transaction. The monitoring server can update the transaction execution time according to the sum of the running times, that is, use the sum of the running times as the transaction execution time.
[0131] Step 708, if the target transaction identifier does not exist in the preset background table, insert the target transaction identifier into the preset background table.
[0132] Specifically, if the monitoring server does not find the target transaction identifier in the preset background table, it means that the monitoring server has not obtained the transaction running information corresponding to the target transaction identifier on the database server. In this way, the monitoring server needs to insert the target transaction identifier information into the preset background table for the monitoring server to collect the transaction running information of the transaction corresponding to the target transaction identifier in the next sampling period.
[0133] In this embodiment, by updating the transaction execution time of the transaction according to the obtained time-consuming information, it is possible to monitor and automatically kill large transactions that affect database performance, reduce the workload of front-line database maintenance personnel, and improve the stability of database production operation.
[0134] Next, in combination with a specific implementation method, the specific execution process of the above killing method will be described in detail:
[0135] During the operation of the database server, the monitoring server periodically accesses the database server (production server) and obtains transaction operation information (such as transaction identifiers, elapsed time information, number of updated rows in operations, etc.) from the system view of the database server (Oracle system view). At the same time, the sampling time point and transaction operation information are stored in a preset background table of the monitoring server. Among them, the relationship between the monitoring server and the production database server is one-to-many.
[0136] After each sampling is completed, the monitoring server traverses each piece of transaction operation information in the preset background table and performs the following process: If the transaction ID already exists, the elapsed execution time of the transaction is updated through the last_call_et field of v$session; if the transaction ID does not exist, the transaction ID is inserted into the preset background table of the monitoring server. In this way, the transaction IDs that have not been updated in the monitoring server can be checked at preset time intervals (such as one hour), and these records are deleted. After each sampling cycle, check the transaction IDs in the table whose transaction execution time exceeds the preset time threshold (such as one hour) and the number of updated rows in the operation is greater than the preset quantity threshold, and push a killing statement to the corresponding production database server. At the same time, notify the maintenance personnel by means of email or syslog protocol, etc.
[0137] It should be understood that although the steps in the flowcharts involved in the above embodiments are shown in sequence according to the arrows, these steps do not necessarily have to be executed in the order indicated by the arrows. Unless there is a clear indication in this article, the execution of these steps does not have a strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages do not necessarily have to be executed at the same moment, but can be executed at different moments. The execution order of these steps or stages does not necessarily have to be sequential, but can be executed alternately or in turn with at least a part of the steps or stages in other steps or other steps.
[0138] Based on the same inventive concept, an embodiment of the present application also provides a killing device for implementing the killing method involved above. The implementation solution provided by this device for solving problems is similar to the implementation solution described in the above method. Therefore, the specific limitations in one or more embodiments of the killing device provided below can refer to the limitations on the killing method in the above text, and will not be repeated here.
[0139] In one embodiment, as Figure 8 shown, a killing device is provided, including: a first determination module 801, a generation module 802, and a killing module 803, where:
[0140] The first determination module 801 is configured to traverse each piece of transaction running information in a preset background table and determine the target transaction running information that meets the preset detection conditions.
[0141] The generation module 802 is configured to generate a detection statement according to the session identification information corresponding to the target transaction running information.
[0142] The detection module 803 is configured to detect the transaction corresponding to the target transaction running information on the database server based on the detection statement.
[0143] In one embodiment, the transaction running information includes the transaction execution time and the number of updated operation rows;
[0144] The first determination module is specifically configured to:
[0145] Determine the transaction running information whose transaction execution time exceeds a preset time threshold as the target transaction running information that meets the preset detection conditions;
[0146] Or, determine the transaction running information whose number of updated operation rows exceeds a preset quantity threshold as the target transaction running information that meets the preset detection conditions.
[0147] In one embodiment, the transaction running information includes the transaction execution time and the number of updated operation rows; the device includes:
[0148] The first elimination module is configured to eliminate, at each preset time interval, for each transaction in the preset background table, the transaction whose transaction execution time at the current moment is the same as that at the previous moment;
[0149] The second elimination module is configured to; eliminate the transaction whose number of updated operation rows at the current moment is the same as that at the previous moment.
[0150] In one embodiment, the device further includes:
[0151] The first acquisition module is configured to acquire multiple operation index information of the database server corresponding to the session identification information according to the session identification information corresponding to the target transaction running information;
[0152] The first judgment module is configured to input the multiple operation index information into a preset detection judgment algorithm to obtain a detection judgment result;
[0153] The execution module is configured to execute the step of generating a detection statement according to the session identification information corresponding to the target transaction running information when the detection judgment result meets the preset detection feasibility conditions.
[0154] In one embodiment, the device further includes:
[0155] A sending module, configured to send the anti-virus completion notification information to the operation and maintenance terminal corresponding to the transaction corresponding to the target transaction operation information.
[0156] In one embodiment, the device further includes:
[0157] A second acquisition module, configured to periodically access the database server at preset time intervals, and acquire transaction operation information based on the system view of the database server and the transaction identifiers in the preset background table, where the transaction operation information includes transaction identifier information, operation time-consuming information, and operation updated row count information;
[0158] A storage module, configured to store the transaction operation information into a preset background table, where the transaction includes at least one database operation.
[0159] In one embodiment, the transaction operation information further includes a transaction execution time, and the device further includes:
[0160] A third acquisition module, configured to acquire a target session identifier from a preset session identifier table;
[0161] A second judgment module, configured to judge whether there is a target transaction identifier corresponding to the target session identifier in the preset background table;
[0162] An update module, configured to, if the target transaction identifier exists in the preset background table, update the transaction execution time of the transaction corresponding to the target transaction identifier according to the operation time-consuming information corresponding to the target transaction identifier;
[0163] An insertion module, configured to, if the target transaction identifier does not exist in the preset background table, insert the target transaction identifier into the preset background table.
[0164] Each module in the above anti-virus device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in hardware form or independent of the processor, or stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules.
[0165] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as Figure 9As shown in the figure. The computer device includes a processor, a memory, and a network interface connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store transaction-related data. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a killing method is implemented.
[0166] Those skilled in the art can understand that Figure 9 the structure shown in the figure is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.
[0167] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory. When the processor executes the computer program, the steps in the above method embodiments are implemented.
[0168] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.
[0169] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by the processor, the steps in the above method embodiments are implemented.
[0170] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.
[0171] It should be noted that the methods and devices in the embodiments of this disclosure can be used in the field of artificial intelligence technology, can be used in the field of fintech or other related fields, and the embodiments of the methods and devices in this disclosure do not limit the application fields.
[0172] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, etc., without limitation.
[0173] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.
[0174] The above embodiments only represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.
Claims
1. A killing method, characterized in that, The method includes: Traversing each piece of transaction running information in a preset background table to determine target transaction running information that meets preset detection and killing conditions; Generating a detection and killing statement according to the session identification information corresponding to the target transaction running information, including: Obtaining multiple operation index information of the database server corresponding to the session identification information according to the session identification information corresponding to the target transaction running information, where the operation index information includes the operation priority information and the transaction importance degree information of the transaction corresponding to the target transaction running information; Inputting the multiple operation index information into a preset detection and killing judgment algorithm to obtain a detection and killing judgment result; When the detection and killing judgment result meets the preset detection and killing feasibility condition, generating a detection and killing statement according to the session identification information corresponding to the target transaction running information; Based on the detection and killing statement, killing the transaction corresponding to the target transaction running information on the database server.
2. The method according to claim 1, wherein The transaction running information includes transaction execution time and the number of updated rows of operations; The traversing each piece of transaction running information in the preset background table to determine target transaction running information that meets the preset detection and killing conditions includes: Determining the transaction running information with a transaction execution time exceeding a preset time threshold as the target transaction running information that meets the preset detection and killing conditions; Or, determining the transaction running information with the number of updated rows of operations exceeding a preset quantity threshold as the target transaction running information that meets the preset detection and killing conditions.
3. The method according to claim 1, wherein The transaction running information includes transaction execution time and the number of updated rows of operations; the method further includes: At every preset time interval, for each transaction in the preset background table, eliminating the transactions with the same transaction execution time at the current moment and the previous moment; And / or; eliminating the transactions with the same number of updated rows of operations at the current moment and the previous moment.
4. The method according to claim 1, wherein After the step of killing the transaction corresponding to the target transaction running information on the database server based on the detection and killing statement, the method further includes: Sending a detection and killing completion notification message to the operation and maintenance terminal corresponding to the transaction corresponding to the target transaction running information.
5. The method according to claim 1, wherein The method further includes: At every preset time interval, periodically accessing the database server, and based on the system view of the database server and the transaction identifiers in the preset background table, obtaining transaction running information, where the transaction running information includes transaction identifier information, operation time-consuming information, and the number of updated rows of operations information; Storing the transaction running information into the preset background table, where the transaction includes at least one database operation.
6. The method according to claim 5, wherein The transaction running information further includes transaction execution time, and the method further includes: Obtaining a target session identifier from a preset session identifier table; Judging whether there is a target transaction identifier corresponding to the target session identifier in the preset background table; If there is the target transaction identifier in the preset background table, updating the transaction execution time of the transaction corresponding to the target transaction identifier according to the operation time-consuming information corresponding to the target transaction identifier; If the target transaction identifier does not exist in the preset background table, insert the target transaction identifier into the preset background table.
7. A killing device, characterized in that, The device includes: A first determination module, configured to traverse each transaction operation information in the preset background table to determine target transaction operation information that meets the preset detection and killing conditions; A generation module, configured to generate a detection and killing statement according to the session identifier information corresponding to the target transaction operation information, including: obtaining multiple operation index information of the database server corresponding to the session identifier information according to the session identifier information corresponding to the target transaction operation information, where the operation index information includes the operation priority information and the transaction importance degree information of the transaction corresponding to the target transaction operation information; inputting the multiple operation index information into a preset detection and killing judgment algorithm to obtain a detection and killing judgment result; and generating a detection and killing statement according to the session identifier information corresponding to the target transaction operation information when the detection and killing judgment result meets the preset detection and killing feasibility conditions; A detection and killing module, configured to kill the transaction corresponding to the target transaction operation information on the database server based on the detection and killing statement.
8. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 6 are implemented.
10. A computer program product comprising a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 6 are implemented.
Citation Information
Patent Citations
Method for diagnosing large transactions and hotspot transactions of Oracle database
CN106201826A
Database deadlock detection method and device
CN112256442A