Oracle database large object migration method and device and medium

Abstract

The embodiment of the invention discloses an oracle database large object migration method and device and a medium, relates to the technical field of data migration, and is used for solving the problem that an existing oracle large object is difficult to migrate to a PostgreSQL. The method comprises the following steps: detecting a created SQL statement of a server side to determine whether a currently created table column has a large object column or not based on the created SQL statement; if yes, based on a large object secondary table structure, implicitly creating a corresponding large object secondary table, and based on the large object secondary table, generating locator information of large object data and storing the locator information in a large object primary table; returning the locator information to the client to receive large object data request information uploaded by the client; and determining current locator information of the to-be-queried large object data based on the large object data request information, positioning a data position of the large object secondary table based on the current locator information, and returning the large object data corresponding to the data position to the client.

Description

Technical Field

[0001] This specification relates to the field of large object data, and in particular to a method, device, and medium for migrating large objects in an Oracle database. Background Art

[0002] Databases are widely used in enterprise information technology development. Oracle Database, with its powerful functionality, high reliability, and wide range of application scenarios, is widely used in many large enterprises. However, as business grows and changes, database adjustments and optimizations may become necessary, necessitating the migration of large object data from Oracle databases to PostgreSQL.

[0003] In existing migration techniques, all large objects in an Oracle database are stored in a single system table. This system table can become a performance bottleneck when the number of large objects is excessive. Furthermore, migrating large objects from Oracle to PostgreSQL involves creating large object table columns, inserting and updating large objects, and other operations. However, because PostgreSQL lacks a standard SQL large object data type, table creation statements in Oracle cannot be directly applied to PostgreSQL, much less inserting data into it. This results in a complex migration of large objects from Oracle to PostgreSQL. Summary of the Invention

[0004] In order to solve the above technical problems, one or more embodiments of this specification provide a method, device, and medium for migrating large objects in an Oracle database.

[0005] One or more embodiments of this specification adopt the following technical solutions:

[0006] One or more embodiments of this specification provide a method for migrating large objects in an Oracle database, the method comprising:

[0007] Detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement;

[0008] If yes, then based on the large object secondary table structure, a corresponding large object secondary table is implicitly created, and locator information of the large object data is generated based on the large object secondary table and stored in the large object primary table;

[0009] Return the locator information to the client to receive the large object data request information uploaded by the client;

[0010] The current locator information of the large object data to be queried is determined based on the large object data request information, so as to locate the data position of the large object secondary table based on the current locator information, and return the large object data corresponding to the data position to the client.

[0011] Optionally, in one or more embodiments of this specification, detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement specifically includes:

[0012] Performing grammatical analysis on the creation SQL statement to generate an abstract syntax tree of the creation SQL statement;

[0013] Traversing the abstract syntax tree to check whether the data type of each column is a preset large object type;

[0014] If not, create a normal table based on the creation SQL statement;

[0015] If yes, determine whether the currently created table column has a large object column.

[0016] Optionally, in one or more embodiments of this specification, based on the large object secondary table structure, a corresponding large object secondary table is implicitly created to generate large object locator information based on the large object secondary table, specifically including:

[0017] Acquire a unique identifier of the large object primary table, and generate a table name of the large object secondary table based on the unique identifier of the large object primary table;

[0018] Based on the large object secondary table structure, determining the fixed fields of the large object secondary table to create a large object secondary table containing the fixed fields, and establishing a dependency association between the large object primary table and the large object secondary table based on the table name of the large object secondary table;

[0019] Determining unique identifiers corresponding to each large object data based on the large object secondary table, and binding each large object data to the large object primary table based on the dependency relationship;

[0020] Determine a corresponding paging size based on current computing resource limitation data, and add a corresponding shard identification field to the large object secondary table according to the paging size, so as to shard the large object data to achieve distributed storage;

[0021] The unique identifier corresponding to each large object, the shard identification field corresponding to the large object data, and the data shard position are encapsulated based on a preset format to obtain locator information of the large object.

[0022] Optionally, in one or more embodiments of the present specification, a corresponding paging size is determined based on current computing resource limitation data, and a corresponding shard identification field is added to the large object secondary table according to the paging size, so as to shard the large object data to achieve distributed storage, specifically including:

[0023] Based on the current computing resource limitation data, determine the current Oracle large object migration scenario; wherein the migration scenario includes: high memory and low transmission scenario and low memory and high concurrency scenario;

[0024] Determining a paging size that matches the current computing resource limitation data within a paging range value corresponding to the migration scenario;

[0025] Determining a fragmentation rule based on the page size and the page number, determining a fragmentation position of the large object secondary table based on the fragmentation rule, and adding a corresponding fragmentation identification field to the large object secondary table according to the fragmentation position;

[0026] The large object data located in the same shard identification field in the large object secondary table is stored in the distributed storage physical table, and the mapping relationship between the data shard position and the large object data is recorded.

[0027] Optionally, in one or more embodiments of the present specification, based on the large object secondary table structure, a corresponding large object secondary table is implicitly created, and after locator information of large object data is generated based on the large object secondary table and stored in the large object primary table, the method further includes:

[0028] receiving update data of the large object primary table, and determining whether to trigger a large object data insertion process based on the update data;

[0029] If the large object data insertion process is triggered, the locator information is inserted into the large object primary table, and the designated large object column corresponding to the updated data is determined;

[0030] According to the locator information and the designated large object column, directly adding the updated data to the large object secondary table corresponding to the designated large object column;

[0031] After determining whether to trigger the large object data insertion process based on the update data, the method further includes:

[0032] If the large object data insertion process is triggered, the preset interface is called to determine the large object secondary table corresponding to the updated data based on the locator information and update it.

[0033] Optionally, in one or more embodiments of this specification, returning the large object locator information to the client to receive the large object data request information uploaded by the client specifically includes:

[0034] The large object locator information is returned to the client, so that the client generates large object data request information based on a preset remote function call protocol and receives the large object data request information uploaded by the client; wherein the preset remote function call protocol is a preset remote FuncCall.

[0035] Optionally, in one or more embodiments of the present specification, determining current locator information of the large object to be queried based on the large object data request information, locating the data location of the large object secondary table based on the current locator information, and returning the large object data corresponding to the data location to the client specifically includes:

[0036] Determining current locator information of the large object to be queried based on the large object data request information to verify validity of the current locator information;

[0037] If the verification result is determined to be valid, then the dependency relationship between the large object primary table and the large object secondary table is associated based on the unique identifier corresponding to the large object in the current locator information, and the large object secondary table to be queried is determined based on the dependency relationship;

[0038] Based on the shard identification field and data shard position of the current locator information, the distributed storage physical table of the large object secondary table to be queried is sequentially retrieved to determine the data location corresponding to the large object data to be queried, so as to return the large object data corresponding to the data location to the client.

[0039] Optionally, in one or more embodiments of this specification, returning the large object data corresponding to the data location to the client specifically includes:

[0040] Determining the return type of the large object data based on the client's operating environment data and network data; wherein the return type includes: block transmission type and compression processing type;

[0041] If the return type is a block transfer type, slicing the large object data based on the paging size to obtain each large object data to be transferred;

[0042] If the return type is a compression processing type, screening an existing compression algorithm based on the operating environment data, and compressing the large object data according to the existing compression algorithm to obtain the large object data to be transmitted;

[0043] The large object data to be transmitted is encapsulated based on a preset remote function call protocol to return the data to the client.

[0044] One or more embodiments of this specification provide an Oracle database large object migration device, the device including:

[0045] at least one processor; and,

[0046] a memory communicatively connected to the at least one processor; wherein,

[0047] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: perform any of the above methods.

[0048] One or more embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute any of the above-described methods.

[0049] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects: BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some of the embodiments described in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0051] Figure 1 A flowchart of a method for migrating large objects in an Oracle database provided in an embodiment of this specification;

[0052] Figure 2 A schematic diagram of a scenario of a large object migration method for an Oracle database provided in an embodiment of this specification;

[0053] Figure 3 A schematic diagram of a process for implicitly creating a large object secondary table provided in an embodiment of this specification;

[0054] Figure 4 A schematic diagram of the structure of an Oracle database large object migration device provided in an embodiment of this specification;

[0055] Figure 5 A schematic diagram of the structure of a non-volatile storage medium provided in an embodiment of this specification. DETAILED DESCRIPTION

[0056] The embodiments of this specification provide a method, device, and medium for migrating large objects in an Oracle database.

[0057] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0058] like Figure 1 As shown, the embodiment of this specification provides a flow chart of a migration method of a large object in an Oracle database. Figure 1 It can be seen that in one or more embodiments of this specification, a method for migrating large objects in an Oracle database includes:

[0059] S101: Detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement.

[0060] The large object data type can store a large amount of data and can directly perform insert and update operations on large object columns. And large object data can be modified, queried, and other operations can be performed through the interface. However, due to the lack of a standard SQL large object data type in the PostgreSQL database system, it is very difficult to migrate Oracle large objects to PostgreSQL. Therefore, in order to be able to detect the migration bottleneck of the Oracle database, namely large object data, the embodiment of this specification will detect the creation SQL statement on the server side, and thus determine whether the current creation table column has a large object column based on the creation SQL statement. In this process, by detecting the creation SQL statement on the server side to determine whether there is a large object column, the key factor that may cause migration difficulties, namely large object data, can be accurately identified in the early stage of database migration, thereby facilitating the subsequent implicit creation of corresponding large object secondary tables for large object data, generating locator information, etc., to achieve reasonable storage and access of large object data in the new database, and ensure the availability and manageability of large object data after migration.

[0061] Specifically, in one or more embodiments of this specification, detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement specifically includes the following process:

[0062] First, you can use a pre-set SQL parser such as ANTLR, JavaCC, etc. to parse the SQL statement, decompose it into nodes, and generate an abstract syntax tree for the SQL statement. Then, traverse the abstract syntax tree to check whether the data type of each column is the preset large object type. If not, Figure 3 The following example shows how to create a regular table based on a SQL statement. If the default large object type is set, the table column being created is determined to have a large object column. This process automatically discovers large object columns by parsing SQL, enabling automated identification of Oracle large object columns and laying the foundation for subsequent large object data migration. By separating large object data from regular data, this solves the problem of PostgreSQL's lack of a standard large object type and ensures the feasibility and efficiency of Oracle-to-PostgreSQL migration.

[0063] S102: If yes, then based on the large object secondary table structure, implicitly create a corresponding large object secondary table, and generate locator information of the large object data based on the large object secondary table and store it in the large object primary table.

[0064] Based on the above step S101, if it is determined that the currently created table column has a large object column, then a corresponding large object secondary table can be implicitly created based on the large object secondary table structure. Then, the locator information of the large object data is generated based on the large object secondary table and stored in the large object primary table. By introducing the large object secondary table structure, this process can simulate Oracle's large object storage through the secondary table, so that the upper-level application does not need to be aware of the differences in the underlying database, and a smooth migration can be achieved. By generating locator information and storing it in the large object primary table, the large object data is split into independent secondary tables, and the main table only stores the locator information, thereby effectively reducing the IO overhead of the main table. Therefore, by introducing the large object secondary table and locator information, the problem of PostgreSQL's lack of standard large object types is effectively solved. In addition, the large object secondary table in this process adopts a distributed solution, that is, each table containing large object columns has a unique secondary large object table, while the native system adopts a centralized storage method to store all large objects in the system table. The distributed secondary table large object solution significantly improves the large object data processing performance in high concurrency scenarios.

[0065] Specifically, in one or more embodiments of this specification, based on the large object secondary table structure, a corresponding large object secondary table is implicitly created to generate large object locator information based on the large object secondary table, specifically including:

[0066] First, in order to quickly identify the secondary table corresponding to the large object in subsequent operations, the unique identifier of the large object's primary table is obtained, and the table name of the large object's secondary table is generated based on the unique identifier of the large object's primary table. Then, based on the large object's secondary table structure, the fixed fields of the large object's secondary table are determined to create a large object's secondary table containing the fixed fields, and a dependency association is established between the large object's primary table and the large object's secondary table based on the table name of the large object's secondary table. It should be noted that the large object's secondary table structure contains three fixed fields: lobid, pageno, and data columns. Lobid is the large object's unique identifier column, pageno is the data slice page number, and data is the slice data of pageno page.

[0067] Then, in order to ensure that each large object data can have a clear corresponding relationship in the secondary table, it is necessary to determine the unique identifier corresponding to each large object data based on the large object secondary table, and bind each large object data to the large object primary table based on the dependency relationship, so that the large object can be accurately associated and identified in both the primary table and the secondary table. Then, in order to balance storage efficiency and computing performance, the embodiment of this specification will determine the corresponding paging size based on the current computing resource limitation data, and add the corresponding shard identification field to the large object secondary table according to the paging size, shard the large object data, and realize distributed storage. The unique identifier corresponding to each large object, the shard identification field corresponding to the large object data, and the data shard location are encapsulated based on the preset format to obtain the locator information of the large object.

[0068] Furthermore, in one or more embodiments of the present specification, a corresponding paging size is determined based on current computing resource limitation data, and a corresponding shard identification field is added to the large object secondary table according to the paging size, so as to shard the large object data and implement distributed storage, specifically including the following process:

[0069] Based on the current computing resource limitation data, the current Oracle large object migration scenario is determined; wherein the migration scenarios include: a high-memory, low-transmission scenario and a low-memory, high-concurrency scenario. A paging size that matches the current computing resource limitation data is determined within the paging range value corresponding to the migration scenario. For example, in a high-memory, low-transmission scenario, due to relatively abundant memory resources and limited transmission capacity, a larger paging size is selected to reduce the number of transmissions and fully utilize the advantages of high memory. In a low-memory, high-concurrency scenario, memory resources are limited but concurrency requirements are high, so a smaller paging size is selected to accommodate the low memory limitations and support more concurrent operations. Then, a sharding rule is determined based on the paging size and the paging number, thereby determining the sharding location of the large object secondary table based on the sharding rule, and adding a corresponding sharding identification field to the large object secondary table based on the sharding location. Then, the large object data located in the same sharding identification field in the large object secondary table is stored in a distributed storage physical table, and the mapping relationship between the data sharding location and the large object data is recorded. That is, compared with the traditional process of inserting all large objects into the system table, this process uses distributed storage in high-concurrency scenarios. Through data sharding, large objects are divided into multiple physical tables according to user tables, allowing query requests to be processed in parallel, thereby breaking through the original single-table resource limitations and improving the overall system throughput.

[0070] Furthermore, in one or more embodiments of the present specification, based on the large object secondary table structure, a corresponding large object secondary table is implicitly created. After locator information of large object data is generated based on the large object secondary table and stored in the large object primary table, in order to solve the problem that it is difficult to freely insert or update data into a specified large object column in the existing method, the method further includes:

[0071] Receive the update data of the large object level table to determine whether to trigger the large object data insertion process based on the updated data; if the large object data insertion process is triggered, insert the locator information into the large object level table and determine the designated large object column corresponding to the updated data. Figure 2 As shown, based on the locator information and the specified large object column, the updated data is directly added to the large object secondary table corresponding to the specified large object column. After determining whether to trigger the large object data insertion process based on the updated data, the method further includes: if the large object data insertion process is triggered, then calling the preset interface such as Figure 2As shown, based on the locator information, the large object secondary table corresponding to the updated data is determined and updated. There are two methods for inserting data into a large object table. One method is direct data insertion, which directly specifies that data be inserted into the table. This method generates large object locator information before inserting data into the table. Since large object data can be located in the secondary table simply by using the large object secondary table OID and the large object unique identifier OID when querying large object data, the large object secondary table OID and the large object OID constitute the locator information. The locator structure is (16628, 888), where 16628 represents the large object secondary table OID and 888 represents the large object OID. The generated locator is inserted into the large object primary table column, specifying that the inserted data fragment be stored in the secondary table. The second method uses the interface to modify and append to large object data using the large object locator.

[0072] During this process, locator information for the large object data is generated and stored in the large object primary table. Locator information plays a key positioning role, containing the necessary information pointing to the large object secondary table and its sharded data location, facilitating subsequent access and management of the large object data. When the large object data insertion process is triggered, the locator information is first inserted into the large object primary table. This step is to record the location information related to the large object data in the primary table. The designated large object column corresponding to the updated data is determined, clarifying the specific location in the primary table where the data should be inserted. Then, based on the locator information previously stored in the primary table and the designated large object column, the system will directly add the updated data to the large object secondary table corresponding to the designated large object column, achieving accurate writing of data from the primary table to the secondary table and ensuring correct data storage and management. Adding data to the secondary table based on the locator and calling the preset interface for update enables flexible insertion and update operations on large object data, improving the efficiency and convenience of data management.

[0073] S103: Return the locator information to the client to receive the large object data request information uploaded by the client.

[0074] In order to facilitate the client's query on the large object column, in the embodiment of this specification, after obtaining the locator information based on the above steps, as shown in FIG. Figure 2 As shown, the locator information will be returned to the client to receive the large object data request information uploaded by the client. This will allow the client to subsequently obtain the large object data through remote FuncCall.

[0075] Specifically, in one or more embodiments of this specification, returning the large object locator information to the client to receive the large object data request information uploaded by the client specifically includes:

[0076] The server returns the large object locator information to the client, allowing the client to generate large object data request information based on the pre-configured remote function call protocol and receive the large object data request information uploaded by the client. The pre-configured remote function call protocol is the pre-configured remote FuncCall protocol. The server returns the locator information to the client, clarifying the storage location and related mapping relationships of the large object data. When receiving data requests uploaded by the client, the server can quickly locate the corresponding large object secondary table and shard location based on the locator information for storage, avoiding data confusion and duplicate processing, and improving the accuracy and efficiency of data management.

[0077] S104: Determine current locator information of the large object data to be queried based on the large object data request information, locate the data location of the large object secondary table based on the current locator information, and return the large object data corresponding to the data location to the client.

[0078] After determining the current locator information of the large object data to be queried based on the large object data request information, the server in the embodiment of this specification locates the data position of the large object secondary table based on the current locator information to return the large object data corresponding to the data position to the client. For example, in a certain scenario, when the server receives a remote FuncCall from the client to query large object data, it will locate the position of the large object in the secondary table based on the locator information, and then obtain all the large object data and return it to the client. That is, the insertion and query of large objects are inextricably linked to the secondary table. When inserting data into a large object, the secondary table stores the specific inserted large object data. When querying, the locator information stored in the primary table is used to locate the data item of the large object in the secondary table, and then the large object data obtained from the secondary table is returned to the query end. Among them, the locator plays a vital role. The locator information generated when the large object is inserted is stored in the primary table. When querying the table, the large object data is obtained through the obtained locator locator.

[0079] Specifically, in one or more embodiments of the present specification, determining the current locator information of the large object to be queried based on the large object data request information, locating the data location of the large object secondary table based on the current locator information, and returning the large object data corresponding to the data location to the client specifically includes the following process:

[0080] Based on the large object data request information, the current locator information of the large object to be queried is determined to verify the validity of the current locator information. If the verification result is determined to be valid, then the dependency relationship between the large object primary table and the large object secondary table is associated based on the unique identifier corresponding to the large object based on the current locator information, and the large object secondary table to be queried is determined based on the dependency relationship. Then, based on the shard identification field and data shard location of the current locator information, the distributed storage physical table of the large object secondary table to be queried is sequentially retrieved to determine the data location corresponding to the large object data to be queried, and the large object data corresponding to the data location is returned to the client. In this process, the large object data is processed according to the locator. The locator design not only solves the problem that traditional data types in the PostgreSQL database cannot exceed 1GB of data volume. It also solves the problem that traditional large object data cannot be directly inserted and cannot be directly queried.

[0081] Specifically, in one or more embodiments of this specification, returning the large object data corresponding to the data location to the client specifically includes:

[0082] First, the return type of the large object data is determined based on the client's operating environment data and network data. Return types include block transfer and compression processing types. For example, the return type of the large object data is determined based on thresholds corresponding to the operating environment data and network data, respectively. If the return type is determined to be block transfer, the large object data is sliced ​​according to the page size to obtain the individual large object data to be transmitted. If the return type is compression processing, existing compression algorithms are selected based on the operating environment data and compressed according to the existing compression algorithms to obtain the large object data to be transmitted. The large object data to be transmitted is then encapsulated based on the preset remote function call protocol and returned to the client. This process determines the return type based on the client's operating environment and network conditions, allowing for flexible adaptation to different conditions. For example, compressed transmission is enabled in weak network conditions, while block transmission is used when client storage is limited, improving data transmission efficiency and availability. Encapsulating data using the preset remote function call protocol ensures transmission standardization and compatibility, facilitating client parsing and processing.

[0083] like Figure 4 As shown in FIG, the embodiment of this specification provides a schematic diagram of the structure of a migration device for Oracle database large objects. Figure 4 It can be seen that in one or more embodiments of this specification, a large object migration device for an Oracle database includes:

[0084] at least one processor; and,

[0085] a memory communicatively connected to the at least one processor; wherein,

[0086] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: perform any of the above methods.

[0087] like Figure 5 As shown in FIG, the embodiment of this specification provides a structural diagram of a non-volatile storage medium. Figure 5 It can be seen that in one or more embodiments of this specification, a non-volatile storage medium stores computer-executable instructions 501, and the computer-executable instructions 501 can: execute any of the methods described above.

[0088] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0089] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0090] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A method for migrating large objects in an Oracle database, characterized in that: The method comprises: Detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement; If yes, then based on the large object secondary table structure, a corresponding large object secondary table is implicitly created, and locator information of the large object data is generated based on the large object secondary table and stored in the large object primary table; Return the locator information to the client to receive the large object data request information uploaded by the client; The current locator information of the large object data to be queried is determined based on the large object data request information, so as to locate the data position of the large object secondary table based on the current locator information, and return the large object data corresponding to the data position to the client.

2. The method for migrating large objects in an Oracle database according to claim 1, wherein: Detecting a creation SQL statement on the server side to determine whether a currently created table column has a large object column based on the creation SQL statement, specifically including: Performing grammatical analysis on the creation SQL statement to generate an abstract syntax tree of the creation SQL statement; Traversing the abstract syntax tree to check whether the data type of each column is a preset large object type; If not, create a normal table based on the creation SQL statement; If yes, determine whether the currently created table column has a large object column.

3. The method for migrating large objects in an Oracle database according to claim 1, wherein: Based on the large object secondary table structure, a corresponding large object secondary table is implicitly created to generate the locator information of the large object based on the large object secondary table, specifically including: Acquire a unique identifier of the large object primary table, and generate a table name of the large object secondary table based on the unique identifier of the large object primary table; Based on the large object secondary table structure, determining the fixed fields of the large object secondary table to create a large object secondary table containing the fixed fields, and establishing a dependency association between the large object primary table and the large object secondary table based on the table name of the large object secondary table; Determining unique identifiers corresponding to each large object data based on the large object secondary table, and binding each large object data to the large object primary table based on the dependency relationship; Determine a corresponding paging size based on current computing resource limitation data, and add a corresponding shard identification field to the large object secondary table according to the paging size, so as to shard the large object data to achieve distributed storage; The unique identifier corresponding to each large object, the shard identification field corresponding to the large object data, and the data shard position are encapsulated based on a preset format to obtain locator information of the large object.

4. The method for migrating large objects in an Oracle database according to claim 3, wherein: Determining a corresponding paging size based on current computing resource limitation data, and adding a corresponding shard identification field to the large object secondary table according to the paging size, so as to shard the large object data and implement distributed storage, specifically including: Based on the current computing resource limitation data, determine the current Oracle large object migration scenario; wherein the migration scenario includes: high memory and low transmission scenario and low memory and high concurrency scenario; Determining a paging size that matches the current computing resource limitation data within a paging range value corresponding to the migration scenario; Determining a fragmentation rule based on the page size and the page number, determining a fragmentation position of the large object secondary table based on the fragmentation rule, and adding a corresponding fragmentation identification field to the large object secondary table according to the fragmentation position; The large object data located in the same shard identification field in the large object secondary table is stored in the distributed storage physical table, and the mapping relationship between the data shard position and the large object data is recorded.

5. The method for migrating large objects in an Oracle database according to claim 1, wherein: Based on the large object secondary table structure, a corresponding large object secondary table is implicitly created, and after locator information of large object data is generated based on the large object secondary table and stored in the large object primary table, the method further includes: receiving update data of the large object primary table, and determining whether to trigger a large object data insertion process based on the update data; If the large object data insertion process is triggered, the locator information is inserted into the large object primary table, and the designated large object column corresponding to the updated data is determined; According to the locator information and the designated large object column, directly adding the updated data to the large object secondary table corresponding to the designated large object column; After determining whether to trigger the large object data insertion process based on the update data, the method further includes: If the large object data insertion process is triggered, the preset interface is called to determine the large object secondary table corresponding to the updated data based on the locator information and update it.

6. The method for migrating large objects in an Oracle database according to claim 1, wherein: Returning the large object locator information to the client to receive the large object data request information uploaded by the client specifically includes: The large object locator information is returned to the client, so that the client generates large object data request information based on a preset remote function call protocol and receives the large object data request information uploaded by the client; wherein the preset remote function call protocol is a preset remote FuncCall.

7. The method for migrating large objects in an Oracle database according to claim 4, characterized in that: Determining current locator information of the large object to be queried based on the large object data request information, locating a data location of the large object secondary table based on the current locator information, and returning the large object data corresponding to the data location to the client, specifically comprising: Determining current locator information of the large object to be queried based on the large object data request information to verify validity of the current locator information; If the verification result is determined to be valid, then the dependency relationship between the large object primary table and the large object secondary table is associated based on the unique identifier corresponding to the large object in the current locator information, and the large object secondary table to be queried is determined based on the dependency relationship; Based on the shard identification field and data shard position of the current locator information, the distributed storage physical table of the large object secondary table to be queried is sequentially retrieved to determine the data location corresponding to the large object data to be queried, so as to return the large object data corresponding to the data location to the client.

8. The method for migrating large objects in an Oracle database according to claim 3, wherein: Returning the large object data corresponding to the data location to the client specifically includes: Determining the return type of the large object data based on the client's operating environment data and network data; wherein the return type includes: block transmission type and compression processing type; If the return type is a block transfer type, slicing the large object data based on the paging size to obtain each large object data to be transferred; If the return type is a compression processing type, screening an existing compression algorithm based on the operating environment data, and compressing the large object data according to the existing compression algorithm to obtain the large object data to be transmitted; The large object data to be transmitted is encapsulated based on a preset remote function call protocol to return the data to the client.

9. A migration device for large objects in an Oracle database, characterized in that: The device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: execute the method according to any one of claims 1 to 8.

10. A non-volatile storage medium storing computer-executable instructions, characterized in that: The computer executable instructions can execute the method according to any one of claims 1 to 8.

Images