A database locking position method and device, a storage medium and a computer device

Abstract

This application relates to the field of computer technology, specifically disclosing a database lock location method and apparatus, storage medium, and computer device. The method includes: when a database lock is detected in a target database, determining the database view corresponding to the target database; obtaining first target information from the database view, and determining second target information from the first target information using a preset lock model; parsing the second target information, determining a target blocking session from the second target information, and locating the database lock based on the target blocking session. This application determines the first target information through a database view, determines the second target information based on the first target information and a preset lock model, and finally locates the database lock based on the second target information. This achieves the technical effect of accurate and rapid database lock location, improving the efficiency of database lock location and greatly enhancing the user experience for database administrators.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a database locking method and apparatus, storage medium, and computer equipment. Background Technology

[0002] A database is a repository for organizing, storing, and managing data according to data structures. There are many types of databases, ranging from the simplest databases that store various types of data in tables to large-scale database systems capable of storing massive amounts of data, and they are widely used in various fields.

[0003] When a database experiences concurrent transactions and resource contention, it is likely to generate locks. Currently, handling database locks typically relies on experienced database administrators manually checking database views. This process is cumbersome, provides a poor user experience for the database administrator, and is directly related to the administrator's experience. Insufficient experience will significantly impact the time required for the check. Summary of the Invention

[0004] In view of this, this application provides a database lock location method, apparatus, storage medium, and computer device. The method determines first target information through a database view, determines second target information based on the first target information and a preset lock model, and finally locates the database lock based on the second target information. This method can achieve the technical effect of accurately and quickly locating the database lock, improving the efficiency of database lock location and greatly enhancing the user experience of database administrators.

[0005] According to one aspect of this application, a method for locking a database bit is provided, comprising:

[0006] When a database lock is detected in the target database, the database view corresponding to the target database is determined;

[0007] First target information is obtained from the database view, and second target information is determined from the first target information through a preset lock model. The first target information includes waiting event information, running session information, and pending session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session, and the waiting time.

[0008] The second target information is parsed to determine the target blocking session, and the database lock is located based on the target blocking session.

[0009] According to another aspect of this application, a database locking bit device is provided, comprising:

[0010] The monitoring module is used to determine the database view corresponding to the target database when a database lock is detected in the target database.

[0011] The information acquisition module is used to acquire first target information from the database view and determine second target information from the first target information through a preset lock model. The first target information includes waiting event information, running session information and waiting session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session and the waiting time.

[0012] The positioning module is used to parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session.

[0013] According to another aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described database locking bit method.

[0014] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-described database locking bit method when executing the program.

[0015] By employing the above technical solutions, this application provides a database lock location method, apparatus, storage medium, and computer device. First, it can monitor the target database in real time. When a database lock is detected in the target database, the database view corresponding to the target database can be directly determined. Next, it can further query first target information from the database view. Here, the first target information may include waiting event information, running session information, and pending session information. Then, the obtained first target information can be input into a preset lock model, through which second target information can be output. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting duration corresponding to each blocked session. After determining the second target information, it can be parsed. Based on the parsing results, the target blocked sessions can be further determined, and the database lock can then be located based on the target blocked sessions. This application's embodiment determines the first target information through a database view, and determines the second target information based on the first target information and the preset lock model. Finally, it locates the database lock based on the second target information, achieving the technical effect of accurate and rapid database lock location. This improves the efficiency of database lock location and greatly enhances the user experience for database administrators.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 A schematic flowchart of a database locking bit method provided in an embodiment of this application is shown;

[0019] Figure 2 A flowchart illustrating another database locking bit method provided in an embodiment of this application is shown;

[0020] Figure 3 A flowchart illustrating another database locking bit method provided in an embodiment of this application is shown;

[0021] Figure 4 A flowchart illustrating another database locking bit method provided in an embodiment of this application is shown;

[0022] Figure 5 A schematic diagram of a database locking bit device provided in an embodiment of this application is shown. Detailed Implementation

[0023] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0024] This embodiment provides a database locking bit method, such as Figure 1 As shown, the method includes:

[0025] Step 101: When a database lock is detected in the target database, determine the database view corresponding to the target database;

[0026] The database locking method provided in this application can be applied to the server side. When there is business concurrency and resource contention in the database, the database is likely to generate database locks. The database locking method provided in this application can quickly and accurately locate database locks. First, the target database can be monitored in real time. When a database lock is detected in the target database, the corresponding database view can be directly determined. The database view can then be used to obtain the current operational information of the target database.

[0027] Step 102: Obtain first target information from the database view, and determine second target information from the first target information through a preset lock model. The first target information includes waiting event information, running session information, and pending session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session, and the waiting time.

[0028] In this embodiment, after determining the database view corresponding to the target database, first target information can be further queried from the database view. Here, the first target information may include waiting event information, running session information, and pending session information. From the waiting event information, relevant information about events currently in a waiting state in the target database can be determined; from the running session information, relevant information about sessions currently running in the target database can be determined; and from the pending session information, relevant information about sessions currently in a waiting state in the target database can be determined. Next, the obtained first target information can be input into a preset lock model, through which second target information can be output. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting duration corresponding to each blocked session, wherein each session identifier is unique.

[0029] Step 103: parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session.

[0030] In this embodiment, after determining the second target information, the second target information can be parsed. Based on the parsing result, the target blocking session can be further determined. Subsequently, the database lock can be located based on the target blocking session. In this way, the resources corresponding to the target blocking session can be released, thereby eliminating the database lock and completing the database lock recovery. Here, the target blocking session is the session that caused the database lock.

[0031] By applying the technical solution of this embodiment, firstly, the target database can be monitored in real time. When a database lock is detected in the target database, the corresponding database view can be directly determined. Next, first target information can be queried from the database view. This first target information may include waiting event information, running session information, and pending session information. Then, the obtained first target information can be input into a preset lock model, which can output second target information. This second target information may include the number of blocked sessions, as well as the session identifier and waiting duration corresponding to each blocked session. After determining the second target information, it can be parsed. Based on the parsing results, the target blocked sessions can be further determined, and the database lock can then be located based on these sessions. This embodiment determines the first target information through a database view, and the second target information based on the first target information and the preset lock model. Finally, the database lock is located based on the second target information, achieving accurate and rapid database lock location. This improves the efficiency of database lock location and significantly enhances the user experience for database administrators.

[0032] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another database locking bit method is provided, such as... Figure 2 As shown, the method includes:

[0033] Step 201: When a database lock is detected in the target database, obtain the wait event view, instance view, and session view corresponding to the target database;

[0034] In this embodiment, the target database can be monitored in real time. If a database lock is detected in the target database, multiple views corresponding to the target database can be obtained, specifically including a wait event view (v$wait_chains), an instance view (v$instance), and a session view (v$session). Specifically, the wait event view can determine the event waiting status during the operation of the target database; the instance view can determine the ongoing sessions during the operation of the target database; and the session view can determine the session waiting status during the operation of the target database.

[0035] Step 202: Connect the waiting event view, the instance view, and the session view through a preset connection field to generate the database view;

[0036] In this embodiment, the obtained wait event view, instance view, and session view can then be interconnected. Specifically, preset connection fields can be used to connect these views. The connection can be established as follows: v$wait_chains.instance = v$instance.instance; v$wait_chains.sid = v$session.sid. After interconnecting the wait event view, instance view, and session view, a database view of the target database can be generated. Subsequently, the wait event view, instance view, and session view can be queried from the database view. Figure 3 This application embodiment allows for the interconnection of the waiting event view, instance view, and session view through a preset connection field, thereby quickly generating a database view. This is simple, convenient, and facilitates subsequent querying of the primary target information.

[0037] Step 203: Based on the preset query items, query the project information corresponding to each preset query item from the database view, and generate the first target information based on the project information corresponding to each preset query item;

[0038] In this embodiment, after generating the database view corresponding to the target database, the first target information can be determined based on the database view according to preset query items. The preset query items can be manually set in advance and may specifically include waiting event items, running session items, and pending session items. The corresponding item information (waiting event information) can be retrieved from the database view based on the waiting event item; the corresponding item information (running session information) can be retrieved from the database view based on the running session item; and the corresponding item information (pending session information) can be retrieved from the database view based on the pending session item. After retrieving the item information corresponding to each preset item, the first target information can be generated based on this item information.

[0039] Step 204: Determine the second target information from the first target information using a preset lock model. The first target information includes waiting event information, running session information, and pending session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session, and the waiting time.

[0040] In this embodiment, the acquired first target information can then be input into a preset lock model, through which second target information can be output. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting time corresponding to each blocked session, wherein each session identifier is unique.

[0041] Step 205: parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session.

[0042] In this embodiment, after determining the second target information, the second target information can be parsed. Based on the parsing result, the target blocking session can be further determined, and the database lock can then be located based on the target blocking session.

[0043] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another database locking bit method is provided, such as... Figure 3 As shown, the method includes:

[0044] Step 301: When a database lock is detected in the target database, determine the database view corresponding to the target database;

[0045] In this embodiment, the target database can be monitored in real time. When a database lock is detected in the target database, the corresponding database view can be directly determined. Information about the current target database can be obtained from the database view.

[0046] Step 302: Obtain the first target information from the database view;

[0047] In this embodiment, after determining the database view corresponding to the target database, the first target information can be further queried from the database view. Here, the first target information may include waiting event information, running session information, and pending session information. From the waiting event information, relevant information about events currently in a waiting state in the target database can be determined; from the running session information, relevant information about sessions currently running in the target database can be determined; and from the pending session information, relevant information about sessions currently in a waiting state in the target database can be determined.

[0048] Step 303: Input the first target information into the preset lock model, and determine whether the first target information includes waiting events and / or sessions to be run through the preset lock model;

[0049] In this embodiment, after obtaining the first target information, the first target information can be input into a preset lock model. Then, the preset lock model can determine whether the first target information includes waiting events and / or sessions to be run, based on its judgment function. Specifically, the preset lock model can identify whether waiting events are included from waiting event information, and can identify whether sessions to be run are included from sessions to be run information.

[0050] Step 304: When included, determine the waiting duration corresponding to the waiting event and / or the session to be run, and determine the second target information based on the waiting event and / or session to be run whose waiting duration is greater than the preset duration. The first target information includes waiting event information, running session information and session to be run information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session and the waiting duration.

[0051] In this embodiment, if the preset lock model determines that there are waiting events and / or sessions waiting to be run, then the second target information can be filtered out from the waiting events and / or sessions waiting to be run according to the filtering function in the preset lock model. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting duration corresponding to each blocked session, where each session identifier is unique. The preset lock model can be any model that is pre-set and capable of performing the above-mentioned determination and filtering functions.

[0052] Step 305: parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session.

[0053] In this embodiment, after determining the second target information, the second target information can be parsed. Based on the parsing result, the target blocking session can be further determined, and the database lock can then be located based on the target blocking session.

[0054] Optionally, in this embodiment of the application, step 304, "determining the second target information based on waiting events with a waiting duration greater than a preset duration and / or waiting sessions", includes: determining the waiting sessions corresponding to waiting events with a waiting duration greater than a preset duration, and determining the blocked sessions based on the waiting sessions and the waiting sessions with a waiting duration greater than a preset duration; generating the second target information based on the number of blocked sessions, the session identifier of each blocked session, and the waiting duration.

[0055] In this embodiment, a waiting session can be determined from waiting events with a waiting duration exceeding a preset duration using a preset lock model. Generally, a longer waiting duration for a waiting event indicates the existence of a corresponding waiting session. Next, the waiting session and the pending sessions with a waiting duration exceeding the preset duration can be combined to obtain a blocked session. Duplicate sessions among the waiting sessions and the pending sessions with a waiting duration exceeding the preset duration can be deduplicated. Here, the preset duration can be manually determined based on session blocking experience; exceeding the preset duration greatly increases the likelihood of blocking.

[0056] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another database locking bit method is provided, such as... Figure 4 As shown, the method includes:

[0057] Step 401: When a database lock is detected in the target database, determine the database view corresponding to the target database;

[0058] In this embodiment, the target database can be monitored in real time. When a database lock is detected in the target database, the corresponding database view can be directly determined. Information about the current target database can be obtained from the database view.

[0059] Step 402: Obtain first target information from the database view, and determine second target information from the first target information through a preset lock model. The first target information includes waiting event information, running session information, and pending session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session, and the waiting time.

[0060] In this embodiment, after determining the database view corresponding to the target database, first target information can be further queried from the database view. Here, the first target information may include waiting event information, running session information, and pending session information. From the waiting event information, relevant information about events currently in a waiting state in the target database can be determined; from the running session information, relevant information about sessions currently running in the target database can be determined; and from the pending session information, relevant information about sessions currently in a waiting state in the target database can be determined. Next, the obtained first target information can be input into a preset lock model, through which second target information can be output. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting duration corresponding to each blocked session, wherein each session identifier is unique.

[0061] Step 403: Based on the waiting time corresponding to each blocked session, sort the blocked sessions and determine the target session identifier corresponding to the blocked session with the shortest waiting time;

[0062] In this embodiment, based on the waiting time corresponding to each blocked session in the second target information, the blocked sessions can be sorted according to their waiting time. Specifically, they can be arranged in descending order of waiting time or in ascending order of waiting time. After sorting, the blocked session with the shortest waiting time can be determined, and the target session identifier corresponding to the blocked session with the shortest waiting time can be determined. The blocked session can be uniquely identified through the target session identifier.

[0063] Step 404: Based on the target session identifier, determine the target blocking session corresponding to the target session identifier from the blocking process information;

[0064] In this embodiment, the running status of each blocked session can be seen in the blocked process information. After determining the target session identifier, the target blocked session can be determined from the blocked process information based on the target session identifier.

[0065] Step 405: Locate the database lock based on the target blocking session.

[0066] In this embodiment, the database lock can then be located based on the target blocking session.

[0067] Optionally, in this embodiment of the application, step 404 includes:

[0068] Step 404-1: Based on the target session identifier, determine whether the running session indicated by the running session information in the first target information is the previous session of the blocking session corresponding to the target session identifier;

[0069] In this embodiment, based on the running session information in the first target information, the current running session of the target database can be determined. Then, it can be determined whether the running session is the previous session of the blocking session corresponding to the target session identifier. If it is the previous session, then after the current running session of the target database finishes running, the blocking session corresponding to the target session identifier will be executed.

[0070] Step 404-2: When the result is yes, and it is determined from the blocked process information that the blocking session corresponding to the target session identifier is in a blocked state, the running session is taken as the target blocked session.

[0071] In this embodiment, if it is determined that the current running session of the target database is the previous session of the blocked session corresponding to the target session identifier, and at the same time, the blocking process information indicates that the blocked session corresponding to the target session identifier is in a blocked state, that is, the blocked session corresponding to the current target session identifier is being blocked by other sessions, then the running session can be directly used as the target blocked session.

[0072] Furthermore, if it is determined that the currently running session of the target database is not the previous session of the blocked session corresponding to the target session identifier, and the blocking process information indicates that the blocked session corresponding to the target session identifier is in a blocked state, then the investigation can be carried out sequentially based on the blocking process information. For example, if the blocked session corresponding to the target session identifier is session 6, and session 6 is in a blocked state, then it can be determined whether the previous session of session 6, i.e., session 5, is in a blocked state. If session 5 is also in a blocked state, then it can be determined whether the previous session of session 5, i.e., session 4, is in a blocked state. If session 4 is not in a blocked state, then it means that session 4 is the target blocked session.

[0073] Furthermore, as Figure 1 To specifically implement the method, this application provides a database locking bit device, such as... Figure 5 As shown, the device includes:

[0074] The monitoring module is used to determine the database view corresponding to the target database when a database lock is detected in the target database.

[0075] The information acquisition module is used to acquire first target information from the database view and determine second target information from the first target information through a preset lock model. The first target information includes waiting event information, running session information and waiting session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session and the waiting time.

[0076] The positioning module is used to parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session.

[0077] Optionally, the monitoring module includes:

[0078] The view acquisition unit is used to acquire the wait event view, instance view, and session view corresponding to the target database.

[0079] The view connection unit is used to connect the waiting event view, the instance view, and the session view through a preset connection field to generate the database view.

[0080] Optionally, the information acquisition module includes:

[0081] The query unit is used to query the project information corresponding to each preset query item from the database view based on preset query items, and generate the first target information based on the project information corresponding to each preset query item.

[0082] Optionally, the information acquisition module further includes:

[0083] An information input unit is used to input the first target information into the preset lock model, and determine whether the first target information includes a waiting event and / or a session to be run through the preset lock model;

[0084] An information determination unit is configured to, when included, determine the waiting duration corresponding to the waiting event and / or the session to be run, and determine the second target information based on the waiting event and / or the session to be run whose waiting duration is greater than a preset duration.

[0085] Optionally, the information determining unit is configured to:

[0086] Identify the waiting session corresponding to the waiting event with a waiting duration longer than a preset duration, and determine the blocked session based on the waiting session and the pending session with a waiting duration longer than the preset duration; generate the second target information based on the number of blocked sessions, the session identifier of each blocked session, and the waiting duration.

[0087] Optionally, the positioning module includes:

[0088] The sorting unit is used to sort the blocking sessions based on the waiting time corresponding to each blocking session, and to determine the target session identifier corresponding to the blocking session with the shortest waiting time.

[0089] The target blocking session determination unit is used to determine the target blocking session corresponding to the target session identifier from the blocking process information based on the target session identifier.

[0090] Optionally, the target blocking session determination unit is configured to:

[0091] Based on the target session identifier, determine whether the running session indicated by the running session information in the first target information is the previous session of the blocked session corresponding to the target session identifier; when the result is yes, and based on the blocked process information it is determined that the blocked session corresponding to the target session identifier is in a blocked state, the running session is taken as the target blocked session.

[0092] It should be noted that other corresponding descriptions of the functional units involved in the database locking bit device provided in this application embodiment can be found in the following references. Figures 1 to 4 The corresponding descriptions in the method will not be repeated here.

[0093] Based on the above, Figures 1 to 4Accordingly, this application also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-described method. Figures 1 to 4 The database locking bit method shown.

[0094] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This software product can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), and includes several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0095] Based on the above, Figures 1 to 4 The method shown, and Figure 5 To achieve the above objectives, the present application also provides a computer device, specifically a personal computer, server, network device, etc., as shown in the virtual device embodiment. This computer device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to achieve the above-described objectives. Figures 1 to 4 The database locking bit method shown.

[0096] Optionally, the computer device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), etc.

[0097] Those skilled in the art will understand that the computer device structure provided in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0098] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages and stores the hardware and software resources of a computer device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software within the physical device.

[0099] Through the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. First, the target database can be monitored in real time. When a database lock is detected in the target database, the database view corresponding to the target database can be directly determined. Next, first target information can be queried from the database view. Here, the first target information may include waiting event information, running session information, and also pending session information. Then, the obtained first target information can be input into a preset lock model, through which second target information can be output. Here, the second target information may include the number of blocked sessions, and may also include the session identifier and waiting duration corresponding to each blocked session. After determining the second target information, it can be parsed. Based on the parsing results, the target blocked sessions can be further determined, and subsequently, the database lock can be located based on the target blocked sessions. This application embodiment determines the first target information through a database view, and determines the second target information based on the first target information and a preset lock model. Finally, it locates the database lock based on the second target information, which can achieve the technical effect of accurately and quickly locating the database lock. While improving the efficiency of database lock location, it can also greatly improve the user experience of database administrators.

[0100] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application. Those skilled in the art will understand that the modules in the apparatus of the embodiment can be distributed within the apparatus of the embodiment as described, or can be modified to be located in one or more apparatuses different from this embodiment. The modules of the above-described embodiment can be combined into one module, or further divided into multiple sub-modules.

[0101] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of any particular implementation scenario. The above disclosures are merely a few specific implementation scenarios of this application; however, this application is not limited thereto, and any variations conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A method for locking a database bit, characterized in that, include: When a database lock is detected in the target database, the database view corresponding to the target database is determined. The database view corresponding to the target database is generated by connecting and linking the wait event view, instance view, and session view. First target information is obtained from the database view, and second target information is determined from the first target information through a preset lock model. The first target information includes waiting event information, running session information, and pending session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session, and the waiting time. The second target information is parsed to determine the target blocking session, and the database lock is located based on the target blocking session. The step of determining the second target information from the first target information using a preset lock model includes: The first target information is input into the preset lock model, and the preset lock model determines whether the first target information includes waiting events and / or sessions to be run. When included, determine the waiting duration corresponding to the waiting event and / or the waiting session to be run, determine the waiting session corresponding to the waiting event with a waiting duration greater than a preset duration, and determine the blocking session based on the waiting session and the waiting session to be run with a waiting duration greater than the preset duration; The second target information is generated based on the number of blocked sessions, the session identifier of each blocked session, and the waiting time.

2. The method according to claim 1, characterized in that, Determining the database view corresponding to the target database includes: Obtain the wait event view, instance view, and session view corresponding to the target database; The database view is generated by connecting the waiting event view, the instance view, and the session view through a preset connection field.

3. The method according to claim 1, characterized in that, The step of obtaining the first target information from the database view includes: Based on the preset query items, the project information corresponding to each preset query item is queried from the database view, and the first target information is generated based on the project information corresponding to each preset query item.

4. The method according to claim 1, characterized in that, The step of parsing the second target information and determining the target blocking session from the second target information includes: Based on the waiting duration corresponding to each blocked session, the blocked sessions are sorted, and the target session identifier corresponding to the blocked session with the shortest waiting duration is determined. Based on the target session identifier, the target blocking session corresponding to the target session identifier is determined from the blocking process information.

5. The method according to claim 4, characterized in that, The step of determining the target blocked session corresponding to the target session identifier from the blocked process information based on the target session identifier includes: Based on the target session identifier, determine whether the running session indicated by the running session information in the first target information is the previous session of the blocking session corresponding to the target session identifier; When the result is yes, and it is determined from the blocked process information that the blocked session corresponding to the target session identifier is in a blocked state, the running session is taken as the target blocked session.

6. A database locking bit device, characterized in that, include: The monitoring module is used to determine the database view corresponding to the target database when a database lock is detected in the target database. The database view corresponding to the target database is generated based on the connection and integration of the wait event view, instance view, and session view. The information acquisition module is used to acquire first target information from the database view and determine second target information from the first target information through a preset lock model. The first target information includes waiting event information, running session information and waiting session information. The second target information includes the number of blocked sessions, the session identifier corresponding to each blocked session and the waiting time. The positioning module is used to parse the second target information, determine the target blocking session from the second target information, and locate the database lock based on the target blocking session; The information acquisition module further includes: An information input unit is used to input the first target information into the preset lock model, and determine whether the first target information includes a waiting event and / or a session to be run through the preset lock model; An information determination unit is configured to, when included, determine the waiting duration corresponding to the waiting event and / or the session to be run, determine the waiting session corresponding to the waiting event with a waiting duration greater than a preset duration, and determine the blocked session based on the waiting session and the session to be run with a waiting duration greater than the preset duration; and generate the second target information based on the number of blocked sessions, the session identifier of each blocked session, and the waiting duration.

7. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 5.

8. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 5.

Images