Database pl program generation method, device, medium and product

Abstract

This invention provides a method, device, medium, and product for generating database PL subroutines. The method for generating database PL subroutines includes: receiving a PL subroutine call request from a database session; checking if a local instance of the PL subroutine exists in the database session; if not, checking if serialized data corresponding to the PL subroutine exists; if so, obtaining the serialized data corresponding to the PL subroutine; deserializing the serialized data corresponding to the PL subroutine to obtain a basic instance structure; and constructing data for the PL subroutine, excluding the serialized data, based on the basic instance structure to obtain the required PL subroutine instance. This solution allows some sessions to generate instances by reading and deserializing serialized data without recompiling the source code, thereby significantly reducing the performance overhead of compilation operations and effectively improving the overall response performance and throughput of the database.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, apparatus, medium, and product for generating database PL subroutines. Background Technology

[0002] A PL (Procedural Language) subroutine is a named PL / SQL (Structured Query Language, SQL) block in a database that can be called repeatedly. As a crucial building block for database applications, PL subroutines are widely used in scenarios such as business logic encapsulation, data processing, and complex calculations. When the database receives a request to call a PL subroutine, it needs to create an instance of that PL subroutine in memory—its data structure in memory. Subsequent execution of the subroutine is based on this instance.

[0003] Currently, regarding the generation process of PL subroutine instances, each database session, upon its first invocation of a PL subroutine, must perform lexical analysis, syntax analysis, and compilation on the subroutine's source code to generate a corresponding instance, which is then stored in a local cache. Because each session's first invocation of a PL subroutine requires a complete lexical analysis, syntax analysis, and compilation process, and the compilation process involves significant computation and memory allocation operations, the initial invocation latency for the session is relatively high.

[0004] Especially in scenarios with a high density of short-lived sessions, each database session typically corresponds to one call request, and the session is destroyed after executing the request. In such short-session scenarios, since each session often calls the same PL subroutine only once during its lifecycle, and each call requires a complete compilation process, the overhead of the aforementioned repeated compilation is further amplified in short-session scenarios, severely impacting the overall response performance and throughput of the database. Summary of the Invention

[0005] One object of the present invention is to provide a method, apparatus, medium and product for generating database PL subroutines that can solve any of the above problems.

[0006] Specifically, the present invention provides a method for generating database PL subroutines, comprising: A call request for a PL subroutine was received from the database session; Check if a local instance of the PL subroutine exists in the database session. If not, check if serialized data corresponding to the PL subroutine exists. If so, Obtain the serialized data corresponding to the PL subroutine; The basic instance structure is obtained by deserializing the serialized data corresponding to the PL subroutine. Based on the basic instance structure, construct the PL subroutine with data other than the serialized data to obtain the required PL subroutine instance.

[0007] Optionally, if there is no serialized data corresponding to the PL subroutine, a local instance of the PL subroutine can be generated by compiling the source code. The local instance is serialized to obtain the serialized data corresponding to the PL subroutine. The serialized data corresponding to the PL subroutine is stored in the system table.

[0008] Optionally, before the step of deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure, the following steps are included: Check if the serialized data corresponding to the PL subroutine is invalid. If so, execute the step of compiling the source code to generate a local instance of the PL subroutine. If not, perform the step of deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure.

[0009] Optionally, the step of checking whether serialized data corresponding to the PL subroutine exists includes: Check if serialized data corresponding to the PL subroutine exists in the preset shared memory. If yes, determine if serialized data corresponding to the PL subroutine exists. If no, check if serialized data corresponding to the PL subroutine exists in the system table. If yes, determine if serialized data corresponding to the PL subroutine exists.

[0010] Optionally, the step of checking whether serialized data corresponding to the PL subroutine exists in the system table includes: Check if there is a load flag for the PL subroutine in the preset shared memory. The load flag is used to identify that a session is loading serialized data of the PL subroutine from the system table to the preset shared memory. If yes, the session to which the call request belongs is placed in the waiting queue corresponding to the PL subroutine, so that it can be re-executed after being woken up. If no, the step of checking whether the serialized data corresponding to the PL subroutine exists in the preset shared memory is executed.

[0011] Optionally, if the frequency of database session creation is detected to be greater than a preset threshold, a preset number of serialized data from the system table within the most recent preset time period, in descending order of the number of calls, are read into a preset shared memory.

[0012] Optionally, the step of storing the serialized data corresponding to the PL subroutine in the system table includes: Store the referenced objects corresponding to the PL subroutines in the system table; If a DDL operation on a database object is detected, check if the database object being operated on exists in the system table. If it does, mark the serialized data of the corresponding PL subroutine as invalid.

[0013] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a computer executable program stored in the memory and running on the processor, wherein the processor, when executing the computer executable program, implements a method for generating a database PL subroutine according to any of the preceding claims.

[0014] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer-executable program is stored, which, when executed by a processor, implements the method for generating a database PL subroutine according to any of the preceding claims.

[0015] According to another aspect of the present invention, a computer program product is also provided, comprising a computer executable program that, when executed by a processor, implements the method for generating a database PL subroutine according to any of the preceding claims.

[0016] The database PL subroutine generation method of the present invention checks whether a local instance of the PL subroutine exists in the database session after receiving a PL subroutine call request from a database session. If no local instance exists, it further checks whether serialized data corresponding to the PL subroutine exists. If serialized data exists, it acquires the serialized data and performs deserialization to obtain a basic instance structure. Then, based on the basic instance structure, it constructs the data of the PL subroutine excluding the serialized data to obtain the required PL subroutine instance. This scheme allows a session to reuse the serialized data of the same PL subroutine generated by other sessions when calling the PL subroutine for the first time, without recompiling the source code. Instead, it generates an instance by reading and deserializing the serialized data, thus significantly reducing the performance overhead of compilation operations and effectively improving the overall response performance and throughput of the database. In particular, by checking whether a local instance exists, the same session can directly use the already generated local instance when calling the same PL subroutine again, further avoiding repeated deserialization operations and achieving multi-level performance acceleration.

[0017] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0018] The following sections will describe some specific embodiments of the invention in a detailed manner by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a schematic flowchart of a method for generating a database PL subroutine according to an embodiment of the present invention; Figure 2 This is a schematic flowchart of a method for generating a database PL subroutine according to another embodiment of the present invention; Figure 3 This is a schematic flowchart of a method for generating a database PL subroutine according to yet another embodiment of the present invention; Figure 4 This is a schematic flowchart of a method for generating a database PL subroutine according to yet another embodiment of the present invention; Figure 5 This is a schematic diagram of a computer device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a computer program product according to an embodiment of the present invention. Detailed Implementation

[0019] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0020] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0021] The flowcharts provided in this invention are not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0022] like Figure 1 As shown, in one embodiment, the method for generating a database PL subroutine generally includes: Step S101: A call request for a PL subroutine is received from the database session.

[0023] Specifically, a database session refers to a specific connection established between a client and a database server. When a client application connects to the database, the database server creates an independent session for that connection. Each database session has its own independent private memory context (including the working area, sorting area, temporary tablespace references, variable states, and local cache, etc.), and the memory data between different sessions is isolated from each other. A PL subroutine is a named PL / SQL block in the database that can be called repeatedly. A call request refers to the execution command issued by the database session to a specific PL subroutine during task execution, such as through the CALL command in an SQL statement, a function call expression, or an execution request issued through an application programming interface (such as JDBC, ODBC).

[0024] Step S102: Check if a local instance of the PL subroutine exists in the database session. If yes, proceed to step S107. If no, proceed to step S103.

[0025] Specifically, an instance of a PL subroutine refers to the data structure of the PL subroutine, which includes the subroutine's parse tree (Abstract Syntax Tree, used to represent the expression and statement structure in the PL subroutine), parameter definitions (parameter names, data types, and passing methods), constant values ​​(such as numeric constants and string constants), variable information (including variable names, data types, and storage locations), and dependency information (unique identifiers of referenced tables, views, operators, and other subroutines in the system tables), as well as other data required for runtime.

[0026] A local instance refers to a PL subroutine instance stored in the private local cache of the current session. Each database session has an independent private memory space that stores various runtime data generated during the execution of the session, including local instances of PL subroutines. The existence of a local instance can be checked by searching the current session's local cache (e.g., a hash table or linked list) for an entry with the unique identifier of the PL subroutine (such as an object ID, or OID) as the key. If a matching entry is found, a local instance is determined to exist; otherwise, it is determined not to exist. If a local instance exists, proceed to step S107 (obtain the instance, end the process). If no local instance exists, proceed to step S103.

[0027] Step S103: Check if there is serialized data corresponding to the PL subroutine. If yes, proceed to step S104; otherwise, proceed to step S108.

[0028] Specifically, serialization refers to the process of converting a complex data structure into a data format that can be stored or transmitted. In the context of this invention, serialized data refers to the data obtained after converting the static parts of a PL subroutine instance (such as parse trees, parameter definitions, constant values, dependency information, etc.) into a binary byte stream. Deserialization refers to the process of converting a stored or transmitted data stream back into a data structure; it is the reverse process of serialization. The serialized data corresponding to the PL subroutine can be stored in a system table, i.e., an internal table in the database used to store metadata (such as table structure, index information, subroutine definitions, etc.), or in shared memory. If serialized data corresponding to the PL subroutine exists, step S104 is executed; otherwise, step S108 is executed.

[0029] In one embodiment of the present invention, the step of checking whether serialized data corresponding to a PL subroutine exists may include: first checking whether serialized data corresponding to a PL subroutine exists in a preset shared memory; if it exists, then it is determined that serialized data corresponding to a PL subroutine exists; if it does not exist, then checking whether serialized data corresponding to a PL subroutine exists in a system table; if it exists, then it is determined that serialized data corresponding to a PL subroutine exists. If neither the preset shared memory nor the system table contains serialized data corresponding to a PL subroutine, then it is determined that serialized data corresponding to a PL subroutine does not exist.

[0030] The pre-configured shared memory is a public memory area allocated when the database starts, accessible to all sessions. It is used to cache frequently accessed data to improve access speed. Reading data from shared memory is a pure memory operation, which is much faster than reading data from system tables (disk). By setting shared memory as a second-level cache, a faster read path can be provided above system tables, improving system processing efficiency.

[0031] It should be noted that the sources of serialized data in the pre-configured shared memory include: After compiling a local instance of a PL subroutine from the source code, the local instance is serialized to obtain the serialized data corresponding to the PL subroutine. This serialized data is first stored in a pre-configured shared memory, and then stored in a system table.

[0032] Alternatively, whenever serialized data is hit from a system table, the serialized data is read into a pre-configured shared memory.

[0033] Alternatively, if the frequency of database session creation is detected to be greater than a preset threshold, a preset number of serialized data from the system table within the most recent preset time period, ranked from most to least frequent, will be read into a preset shared memory.

[0034] Specifically, session creation frequency refers to the number of new database sessions created per unit of time. The database can maintain a counter to record the number of new sessions created within a recent time window (e.g., the last second). Session creation frequency can be monitored periodically by a background monitoring thread on the database.

[0035] Specifically, the preset threshold can be set by the database administrator according to business characteristics, such as 50 sessions / second, 100 sessions / second, or 200 sessions / second. When the session creation frequency exceeds this threshold, it indicates that the database is about to experience or is experiencing a high-concurrency connection storm.

[0036] At this point, the background thread queries the system table for the PL subroutines that have been called the most times in the most recent preset time period (e.g., the last 3 minutes) and the preset number (e.g., 10, 20, or 50). The serialized data corresponding to these subroutines is then read from the system table and written into the preset shared memory.

[0037] This preloading mechanism can warm up the serialized data of popular subroutines before a large number of new sessions flood in, so that when a new session calls these popular subroutines for the first time, it can directly obtain serialized data from shared memory, avoiding cache penetration and disk I / O bottlenecks in high-concurrency scenarios.

[0038] Step S104: Obtain the serialized data corresponding to the PL subroutine.

[0039] Specifically, if it is determined in step S103 that there is serialized data corresponding to the PL subroutine, then the binary byte stream of the serialized data is read from the storage location (shared memory or system table).

[0040] Step S105: Deserialize the serialized data corresponding to the PL subroutine to obtain the basic instance structure.

[0041] Specifically, the basic instance structure refers to the portion of a PL subroutine instance that can be directly recovered from the serialized data through deserialization. This portion includes the static information of the PL subroutine, such as the parse tree, parameter definitions, constant values, and dependency information mentioned earlier. Deserialization reads each field sequentially from the binary byte stream according to a preset data format and fills it into the instance structure allocated in memory, thus obtaining the basic instance structure. The preset data format can be a custom binary format or a common serialization protocol.

[0042] Step S106: Based on the basic instance structure, construct the data of the PL subroutine excluding serialized data to obtain the required PL subroutine instance.

[0043] Specifically, data other than serialized data refers to data in a PL subroutine instance that cannot be directly recovered from serialized data through deserialization and needs to be regenerated in the current session environment. This data mainly includes dynamic runtime pointers, such as: function entry addresses (pointing to the starting location of the machine code in the current session's memory), memory context pointers (pointing to the current session's private memory manager), the current execution stack frame pointer, and local cache pointers (pointing to the cache addresses of resolved dependent objects in the current session). Because different sessions have independent virtual memory spaces, the memory addresses of the same PL subroutine are completely different in different sessions; therefore, these pointers cannot be copied across sessions and must be regenerated in the current session.

[0044] For example, the specific content of the construction includes: pointing the function's entry address to the machine code start position of the PL subroutine in the current session; and pointing the memory context pointer to the private memory manager of the current session.

[0045] After completing the construction of the PL subroutine based on the basic instance structure, excluding the serialized data, you will obtain a PL subroutine instance that can be directly executed in the current session.

[0046] Step S107: Obtain the instance and end the process.

[0047] Specifically, if a local instance is detected in step S102, or if the instance is built in step S106, then the current session has a usable instance of the PL subroutine, and the PL generation process ends.

[0048] Step S108: Generate a local instance of the PL subroutine by compiling the source code.

[0049] Specifically, if it is determined in step S103 that there is no serialized data corresponding to the PL subroutine, then the process reverts to the traditional instance generation method, that is, by performing lexical analysis, syntax analysis and compilation on the source code of the PL subroutine, a local instance of the PL subroutine is generated.

[0050] Step S109: Serialize the local instance to obtain the serialized data corresponding to the PL subroutine.

[0051] Specifically, the portion of the local instance generated by compiling the source code in step S108 that can be reused across sessions, namely the static information portion mentioned above, is converted into a binary byte stream according to a preset data format.

[0052] Step S110: Store the serialized data corresponding to the PL subroutine in the system table.

[0053] Specifically, the serialized data (binary byte stream) obtained in step S109 is written as a record into the corresponding field of the system table. The system table can store the mapping relationship between the unique identifier (OID) of the PL subroutine and the serialized data, so that subsequent sessions can quickly look it up using the OID. By storing the serialized data in the system table, the first session that completes compilation can provide reusable serialized data for all subsequent sessions, achieving the effect of "compile once, reuse many times".

[0054] In this embodiment, after receiving a call request for a PL subroutine from a database session, the system checks whether a local instance of the PL subroutine exists in the database session. If no local instance exists, it further checks whether serialized data corresponding to the PL subroutine exists. If serialized data exists, it acquires the serialized data and performs deserialization to obtain a basic instance structure. Then, based on the basic instance structure, it constructs the data of the PL subroutine excluding the serialized data to obtain the required PL subroutine instance. This approach allows a session to reuse the serialized data of the same PL subroutine generated by other sessions when calling the PL subroutine for the first time, without recompiling the source code. Instead, it generates an instance by reading and deserializing the serialized data, significantly reducing the performance overhead of compilation operations and effectively improving the overall response performance and throughput of the database. In particular, by checking for the existence of a local instance, the same session can directly use the already generated local instance when calling the same PL subroutine again, further avoiding repeated deserialization operations and achieving multi-level performance acceleration.

[0055] like Figure 2 As shown, in one embodiment of the present invention, before deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure, the method further includes: Check if the serialized data corresponding to the PL subroutine is invalid. If so, execute the step of compiling the source code to generate a local instance of the PL subroutine; if not, execute the step of deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure.

[0056] Specifically, the method for generating database PL subroutines in this embodiment generally includes: Step S201: A call request for a PL subroutine is received from the database session.

[0057] Step S202: Check if a local instance of the PL subroutine exists in the database session. If yes, proceed to step S208. If no, proceed to step S203.

[0058] Step S203: Check if there is serialized data corresponding to the PL subroutine. If yes, proceed to step S204; otherwise, proceed to step S209.

[0059] Step S204: Check if the serialized data corresponding to the PL subroutine is invalid. If yes, proceed to step S209; otherwise, proceed to step S205.

[0060] Specifically, serialization data failure refers to a change in the state of the database object upon which the serialized data is based, causing the serialized data to no longer correctly reflect the semantics of the PL subroutine. Typical scenarios for serialization data failure include: DDL (Data Definition Language) operations (such as ALTER TABLE to modify the table structure, DROP TABLE to delete the table) performed on the table referenced by the PL subroutine.

[0061] The method to check whether the serialized data is invalid can be as follows: store the version number of the PL subroutine or a combination of version numbers of dependent objects in the system table, compare the current version number with the version number recorded in the serialized data, and if they do not match, it is determined to be invalid. If the serialized data is invalid, proceed to step S209; if it is not invalid, proceed to step S205.

[0062] Step S205: Obtain the serialized data corresponding to the PL subroutine.

[0063] Step S206: Deserialize the serialized data corresponding to the PL subroutine to obtain the basic instance structure.

[0064] Step S207: Based on the basic instance structure, construct the data of the PL subroutine excluding serialized data to obtain the required PL subroutine instance.

[0065] Step S208: Obtain the instance and end the process.

[0066] Step S209: Generate a local instance of the PL subroutine by compiling the source code.

[0067] Specifically, if it is determined that there is no serialized data corresponding to the PL subroutine, or that the serialized data of the existing PL subroutine has expired, then the process reverts to the traditional instance generation method, that is, by performing lexical analysis, syntax analysis and compilation on the source code of the PL subroutine, a local instance of the PL subroutine is generated.

[0068] Step S210: Serialize the local instance to obtain the serialized data corresponding to the PL subroutine.

[0069] Step S211: Store the serialized data corresponding to the PL subroutine in the system table.

[0070] In this embodiment, when serialized data corresponding to the PL subroutine exists, the serialized data is checked for invalidity, and if invalidity is detected, the process reverts to the source code compilation path. This ensures the consistency between the serialized data and the database object state, and avoids execution errors caused by changes in dependent objects.

[0071] It should be noted that steps not detailed in this embodiment are described with reference to the steps of the same name in the previous embodiment.

[0072] like Figure 3 As shown, in one embodiment, the method for generating a database PL subroutine generally includes: After storing the serialized data corresponding to the PL subroutine in the system table, the following is included: Step S301: Store the reference objects corresponding to the PL subroutine in the system table.

[0073] Specifically, a referenced object refers to other database objects that the PL subroutine depends on during compilation, including but not limited to tables, views, operators, data types, or other subroutines referenced by the subroutine. Each referenced object can be represented by its unique identifier (OID) in the system table. By storing the mapping relationship between the OID of the PL subroutine and the OIDs of all its referenced objects in the system table, a dependency graph of the PL subroutine can be constructed.

[0074] Step S302: If a DDL operation on a database object is detected, check whether the database object being operated on exists in the system table.

[0075] Specifically, when the database executes DDL operations (such as ALTER, DROP, CREATE OR REPLACE, etc.), it obtains the OID of the object being operated on and queries the reference object mapping table stored in step S301 to see if the OID appears as a reference object of a certain PL subroutine.

[0076] Step S303: If yes, mark the serialized data of the corresponding PL subroutine as invalid.

[0077] Specifically, if in step S302 the database object being operated on is found to be a reference object of a PL subroutine, then the serialized data corresponding to that PL subroutine in the system table is marked as invalid. The invalidation can be achieved by setting the validity flag field in the serialized data record to "invalid," or by updating the record's version number to be inconsistent with the current version number.

[0078] The above solution enables proactive failure management of serialized data. When a dependent object changes, the relevant serialized data is promptly marked as invalid. Subsequent sessions can directly obtain the status of the serialized data by checking whether an invalidation mark exists, without having to check each reference object of the PL subroutine during the subroutine instance generation process, thereby improving generation efficiency.

[0079] like Figure 4 As shown, in one embodiment, before the step of checking whether serialized data corresponding to a PL subroutine exists in the system table, the following steps are included: Step S401: Check if there is a load flag corresponding to the PL subroutine in the preset shared memory. If yes, proceed to step S402; otherwise, proceed to step S403.

[0080] Specifically, a load flag is a flag stored in shared memory used to indicate whether a session is currently loading serialized data of a PL subroutine from the system table into shared memory. Each PL subroutine can correspond to an independent load flag. When a session begins reading serialized data from the system table to load into shared memory, it first sets the load flag for that PL subroutine in shared memory; once loading is complete, the load flag is cleared.

[0081] Step S402: Place the session to which the call request belongs into the waiting queue corresponding to the PL subroutine, so that it can be re-executed after being woken up to check whether the serialized data corresponding to the PL subroutine exists in the preset shared memory.

[0082] Specifically, the wait queue is a queue in shared memory used to store session identifiers waiting for the serialized data of a specific PL subroutine to finish loading. When multiple sessions simultaneously request the unloaded serialized data of the same PL subroutine, all sessions except the first one to execute the loading enter the wait queue corresponding to that PL subroutine. After the serialized data is successfully loaded into the preset shared memory, the sessions in the wait queue are awakened, and the preset shared memory is checked again to see if the serialized data corresponding to the PL subroutine exists. At this point, the required serialized data already exists in the preset shared memory, and the session can directly obtain it from the preset shared memory without needing to access the system table again.

[0083] Step S403: Check if serialized data corresponding to the PL subroutine exists in the system table.

[0084] In this embodiment, by configuring a loading flag and a waiting queue mechanism, when multiple sessions simultaneously request the same serialized data that has not yet been fully loaded, only the first session is allowed to perform the loading operation from the system table. Subsequent sessions enter the waiting queue and are woken up uniformly after loading is complete. This mechanism can effectively avoid the waste of IO resources and lock contention caused by multiple sessions reading the same serialized data from the system table at the same time, and significantly improve the system efficiency in high-concurrency scenarios.

[0085] This embodiment also provides a computer device and a computer-readable storage medium. Figure 5 This is a schematic diagram of a computer device 10 according to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention.

[0086] The computer device 10 may include a memory 110, a processor 120, and a computer-executable program 11 stored on the memory 110 and running on the processor 120. When the processor 120 executes the computer-executable program 11, it implements the database PL subroutine generation method of any of the above embodiments.

[0087] The computer-readable storage medium 20 stores a computer-executable program 11 thereon, which, when executed by a processor, implements the database PL subroutine generation method of any of the above embodiments.

[0088] This embodiment also provides a computer program product. Figure 7 This is a schematic diagram of a computer program product 30 according to an embodiment of the present invention. The computer program product 30 includes a computer executable program 11, which, when executed by a processor 120, implements any of the database PL subroutine generation methods described above.

[0089] Specifically, the computer executable program 11 used to perform the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, computer instructions, computer-related instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages.

[0090] For the purposes of this embodiment, the computer-readable storage medium 20 can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, the computer-readable storage medium 20 can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0091] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0092] Computer device 10 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 10 can be a cloud acquisition node. Computer device 10 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 10 can be implemented in a distributed cloud acquisition environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud acquisition environment, program modules can reside on local or remote acquisition system storage media, including storage devices.

[0093] Computer device 10 may include a processor 120 adapted to execute stored instructions and a memory 110 that provides temporary storage space for the operation of said instructions during operation. Processor 120 may be a single-core processor, a multi-core processor, an acquisition cluster, or any other configuration. Memory 110 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0094] The processor 120 can be connected via a system interconnect (e.g., PCI, PCI-Express, etc.) to an I / O interface (input / output interface) suitable for connecting the computer device 10 to one or more I / O devices (input / output devices). I / O devices may include, for example, a keyboard and indicating devices, where indicating devices may include a touchpad or touchscreen, etc. I / O devices may be built into the computer device 10 or may be external devices connected to the acquisition device.

[0095] The processor 120 may also be linked via a system interconnect to a display interface suitable for connecting the computer device 10 to a display device. The display device may include a display screen that is a built-in component of the computer device 10. The display device may also include an external computer monitor, television, or projector connected to the computer device 10. Furthermore, a network interface controller (NIC) may be adapted to connect the computer device 10 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Minicomputer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices may connect to the computer device via the network.

[0096] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A method for generating database PL subroutines, comprising: A call request for a PL subroutine was received from the database session; Check if a local instance of the PL subroutine exists in the database session. If not, check if serialized data corresponding to the PL subroutine exists. If yes, Obtain the serialized data corresponding to the PL subroutine; The serialized data corresponding to the PL subroutine is deserialized to obtain the basic instance structure; Based on the basic instance structure, the data of the PL subroutine, excluding the serialized data, is constructed to obtain the required PL subroutine instance.

2. The method for generating database PL subroutines according to claim 1, wherein... If no serialized data corresponding to the PL subroutine exists, a local instance of the PL subroutine is generated by compiling the source code. The local instance is serialized to obtain the serialized data corresponding to the PL subroutine; The serialized data corresponding to the PL subroutine is stored in the system table.

3. The method for generating database PL subroutines according to claim 2, wherein... Before the step of deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure, the following steps are included: Check if the serialized data corresponding to the PL subroutine is invalid. If so, execute the step of generating a local instance of the PL subroutine by compiling from the source code. If not, perform the step of deserializing the serialized data corresponding to the PL subroutine to obtain the basic instance structure.

4. The method for generating database PL subroutines according to claim 1, wherein... The step of checking whether serialized data corresponding to the PL subroutine exists includes: Check if the serialized data corresponding to the PL subroutine exists in the preset shared memory. If yes, determine that the serialized data corresponding to the PL subroutine exists. If no, check if the serialized data corresponding to the PL subroutine exists in the system table. If yes, determine that the serialized data corresponding to the PL subroutine exists.

5. The method for generating database PL subroutines according to claim 4, wherein... Before the step of checking whether the serialized data corresponding to the PL subroutine exists in the system table, the following steps are included: Detect whether the preset shared memory contains a load flag corresponding to the PL subroutine. The load flag is used to indicate that a session is loading the serialized data of the PL subroutine from the system table into the preset shared memory. If yes, the session to which the call request belongs is placed in the waiting queue corresponding to the PL subroutine, so that it can be re-executed after being woken up. If no, the step of checking whether the serialized data corresponding to the PL subroutine exists in the preset shared memory is executed.

6. The method for generating database PL subroutines according to claim 1, wherein... If the frequency of database session creation is detected to be greater than a preset threshold, a preset number of serialized data from the system table within the most recent preset time period, in descending order of the number of calls, will be read into the preset shared memory.

7. The method for generating database PL subroutines according to claim 1, wherein, The step of storing the serialized data corresponding to the PL subroutine in the system table includes: The reference objects corresponding to the PL subroutines are stored together in the system table; If a DDL operation targeting a database object is detected, check if the database object being operated on exists in the system table. If it does, mark the serialized data of the corresponding PL subroutine as invalid.

8. A computer device comprising a memory, a processor, and a computer-executable program stored in the memory and running on the processor, wherein the processor, when executing the computer-executable program, implements the method for generating a database PL subroutine according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer-executable program stored thereon, wherein the computer-executable program, when executed by a processor, implements the method for generating a database PL subroutine according to any one of claims 1 to 7.

10. A computer program product comprising a computer executable program, wherein the computer executable program, when executed by a processor, implements the method for generating a database PL subroutine according to any one of claims 1 to 7.

Images