Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/10—File systems; File servers
  • G06F16/17—Details of further file system functions
  • G06F16/178—Techniques for file synchronisation in file systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/16—Error detection or correction of the data by redundancy in hardware
  • G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/23—Updating
  • G06F16/2308—Concurrency control
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/23—Updating
  • G06F16/2379—Updates performed during online database operations; commit processing
  • G06F16/2386—Bulk updating operations
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/23—Updating
  • G06F16/2393—Updating materialised views
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/25—Integrating or interfacing systems involving database management systems
  • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/28—Databases characterised by their database models, e.g. relational or object models
  • G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Definitions

• the present invention relates to the field of computers and in particular to a data synchronization method and system.
• the ORACLETM database includes an undo/rollback table space.
• Raw data that affects data lines is stored in the undo/rollback table space when a session performs Update and Delete operations in a Data Manipulation Language (DML) on the database.
• DML Data Manipulation Language
• the session will receive indication that the data has been modified but not yet committed and thus will retrieve the raw data from the undo/rollback table space in accordance with stored undo/rollback address information.
• the occupied rollback segment will not be released until the session in question is committed or until the rollback is finished.
• FIG. 1 is a diagram illustrating a typical data synchronization technique.
• table tl is a table residing in a frontend OLTP ORACLETM database
• the Data Warehouse (DW) is a backend data warehouse
• the Application server retrieves data from table tl.
• a typical data synchronization technique is as follows (all the following commands are executed at the frontend database): in the first step, data in a user table tl is deleted using a command such as delete from schema l.tablename and the deleted data is temporarily stored in an undo/rollback table space; in the second step, data is retrieved from a user table t2 of the backend data warehouse and inserted into the user table tl using a command such as insert into schema l.tablename select * from schema2.tablename@lnk_dw and synchronized but uncommitted data is also temporarily stored in the undo/rollback table space; in the third step, the data is committed; in the fourth step, data is rolled back if an abnormality occurs. Since the ORACLETM database is adopted for both the frontend and the data warehouse, the data can be imported/exported directly via a database link. For example, lnk_dw used in the second step of the above steps represents a database link.
• FIG. 1 is a diagram illustrating a typical data synchronization technique.
• FIG. 2 is a diagram illustrating an embodiment of a data synchronization system.
• FIG. 3 is a flowchart illustrating an embodiment of a data synchronization process for synchronizing data between a source data table and a target data table.
• FIG. 4 illustrates an example in which the application server accesses table tl, and data is synchronized from the back end data warehouse into null table t2.
• FIG. 5 illustrates an example in which an application server accesses table t2 and data is synchronized from the back end data warehouse into null table tl .
• FIGS. 6 and 7 are flowcharts illustrating embodiments of the data synchronization process for synchronizing data between a source data table (e.g., a data table in a backend data warehouse) and a target data table (e.g., a data table in a frontend ORACLETM database).
• a source data table e.g., a data table in a backend data warehouse
• a target data table e.g., a data table in a frontend ORACLETM database
• FIG. 8 is a flowchart illustrating an embodiment of a process for synchronizing the source data table and the current target data table.
• FIG. 9 is a diagram illustrating an embodiment of a storage format.
• FIG. 10 is a flowchart illustrating an embodiment of a process for synchronizing data in a segment-wise way from a source data table to a current target data table.
• FIG. 11 is a block diagram illustrating a data synchronization system.
• FIG. 12 is a block diagram illustrating a multi-process data synchronization system.
• the invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor.
• these implementations, or any other form that the invention may take, may be referred to as techniques.
• the order of the steps of disclosed processes may be altered within the scope of the invention.
• a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task.
• the term 'processor' refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
• FIG. 2 is a diagram illustrating an embodiment of a data synchronization system.
• the target data tables correspond to a source data table in which data to be synchronized is stored.
• each source data table corresponds to two target data tables, which are used alternately.
• the source data table and target data tables can reside in a backend data warehouse or in a frontend database such as ORACLETM.
• the source data table can be reside in the backend data warehouse and the target data tables can reside in the frontend database or vice versa.
• an upper view is established in advance to facilitate target data table access by the application server.
• the upper view may be established on the database server, on the application server, or on other appropriate device.
• the upper view is implemented as a pointer, a handle, or other appropriate reference to a target data table.
• the upper view is implemented as a function that returns a pointer or reference to the target data table.
• the application server accesses the target data table pointed to or referenced by the upper level. As shown in FIG. 2, for example, when the upper view points to the target data table 1, the application server can access data in the target data table 1 through the upper view.
• target data table 2 is not accessed; thus, if there is data in the source data table that should be synchronized, it can be synchronized with the target data table 2.
• the application server can access data in the target table 2 through the upper view. Since the target data table 1 is not accessed at this time, data in the source data table that needs to be synchronized can be synchronized with the target data table 1. This way, the data synchronization process and the data access process are performed on separate tables and conflicts are eliminated.
• FIG. 3 is a flowchart illustrating an embodiment of a data synchronization process for synchronizing data between a source data table and a target data table.
• the process may be implemented on a server such as a web server, a database server, or any other appropriate device that interacts with both the database and the application server.
• two or more target data tables are established based on the source data table according to the technique described above in connection with FIG. 2.
• a current target data table is determined from the previously established target data tables. In some embodiments, to determine a current target data table, the number of data records in each target data table is counted. The target data table with no records is deemed to be the current table. An arbitrary table is chosen if more than one target data table has zero records. However, if no target data table has zero records, then an abnormality has occurred and the data synchronization flow is terminated. [0031] At 306, the source data table and the determined current target data table are synchronized.
• the data when the data is synchronized from the source data table into the determined current target data table, the data can be copied or updated directly into the determined current target data table (i.e., the original null target data table).
• the original null target data table is dropped, a new target data table is recreated as the current target data table, and the data is copied into the newly recreated current target data table.
• the following command is used to create a target data table: create table t2 as select * from schema2.tablename@lnk_dw;
• the operation of the command is a compound operation.
• One operation is the
• DDL (to create a table t2) and the other operation is data synchronization.
• ORACLETM will take it as a DDL operation which occupies substantially no undo/rollback table space.
• a parallel prompt can be adopted and a specific command is as follows: create table t2 as select/*+parallel (dw_t2, 4) */ * from schema2.tablename@lnk_dw dw_t2; wherein /*+parallel (dw_t2, 4)*/ in the above command denotes a scan over the table dw_t2 with four processes.
• an application server is directed to access the current target data table upon successful completion of data table synchronization.
• the upper view is updated whenever the data synchronization successfully completes. The updated upper view points to the target data table into which the data is newly imported to ensure that the application server can smoothly access the data synchronized into the target data table.
• an operation of clearing the non-current target data table is also executed upon successful completion of data synchronization.
• a detailed example will be presented below to illustrate data synchronization between a source data table in a backend data warehouse and a target data table in a frontend ORACLETM database.
• Two data tables are established in the frontend database for the same data service, that is, the source data table in the backend data warehouse corresponds to the two target data tables (table tl and table t2) in the frontend database, which are alternately used.
• FIG 4 illustrates an example in which the application server accesses table tl, and data is synchronized from the back end data warehouse into null table t2.
• FIG 5 illustrates an example in which an application server accesses table t2 and data is synchronized from the back end data warehouse into null table tl .
• the data warehouse corresponds to a backend data warehouse
• table tl and table t2 correspond to two data tables in a frontend database.
• the tables correspond to the same data service.
• a data table in the backend data warehouse corresponds to the two data tables (tl and t2) in the frontend database.
• data can be synchronized from the table in the backend data warehouse into table tl or table t2.
• the application server determines whether to access data in table tl or table t2 based on whether the upper view points to tl or t2. Accordingly, the application server accesses the data in table tl through the upper view if the upper view points to table tl or, if the upper view points to table t2, the application server accesses table t2 through the upper view.
• a time interval (or referred to as a preset data synchronization period) that is used to periodically synchronize the data.
• some systems are configured to perform daily data synchronization from the data warehouse to the front end ORACLETM database.
• table tl and table t2 are examined to locate the null table, into which synchronized data is loaded (i.e., copied).
• the application server accesses a table tl, data is synchronized into a null table t2, and an upper view is redefined upon completion of data synchronization to point to table t2.
• the following command is executed to clear data in table tl. truncate table tl;
• Fig. 5 illustrates a case that an application server accesses a table t2 and data is synchronized into a null table tl.
• An upper view is redefined upon completion of data synchronization to point to table tl and then the following command is executed: truncate table t2; [0045] The data in table t2 is cleared.
• FIGS. 6 and 7 are flowcharts illustrating embodiments of the data synchronization process for synchronizing data between a source data table (e.g., a data table in a backend data warehouse) and a target data table (e.g., a data table in a frontend ORACLETM database).
• source data table e.g., a data table in a backend data warehouse
• target data table e.g., a data table in a frontend ORACLETM database
• the processes illustrated in the embodiments below may be executed on a web server, a database server, or other appropriate device.
• the numbers of records in the two target data tables are determined sequentially. When the number of records in one of the target data tables is determined as zero, it is not necessary to determine the number of records in the other target data table.
• the number of records in table tl is counted and the result is stored as Nl. In some embodiments, the number of records in table tl is counted and stored in a variable Nl using the following command:
• rownum denotes data records and rownum ⁇ 2 indicates that as long as at least one record is detected in the data table, presence of data can be determined without further detection of any additional data records.
• the data is synchronized and loaded from the backend data warehouse into table tl.
• the data is synchronized using various synchronization methods, such as a segment-wise commitment method supported by ORACLETM EXTENT.
• 604 it is determined whether synchronization is successful. If so, 605 is executed; otherwise, 608 is executed to handle abnormality. When an abnormality occurs, the data synchronization process is terminated. Warning and/or log messages are optionally generated.
• a new upper view is created.
• the new upper view is created to point to table tl so that an application server can access the data in table tl through the upper view.
• a clear operation is performed on table t2.
• the above command of truncate table is used when the clear operation is performed on table t2 to rapidly delete the old data and clear table t2.
• the data is synchronized and loaded from the backend data warehouse into table t2.
• the data is synchronized using various synchronization methods, such as a segment-wise commitment method supported by ORACLETM EXTENT.
• a new upper view is created.
• an upper view is recreated which points to the table that has been synchronized, i.e., table t2, so that the application server can access the data in table t2 through the upper view.
• a clear operation is performed on table tl.
• the above-mentioned truncate command is executed to rapidly delete the old data and clear table tl.
• Nl O and N2 ⁇ 0 indicates there is no data in table tl and there is data in table t2, thus the process proceeds to 703.
• the data is synchronized from the backend data warehouse into table tl.
• a new upper view is created.
• the new upper view is created to point to table tl so that an application server can access the data in table tl through the upper view.
• a clear operation is performed on table t2.
• the truncate command described above is used to implement the clear operation.
• the data is synchronized from the backend data warehouse into table t2.
• an upper view is recreated at 715 to point to the synchronized data table t2 so that an application server can access the data in table t2 through the upper view.
• a data table is selected from table tl and table t2. This can be an arbitrary selection. If table tl is selected, then 703-707 are performed. If table t2 is selected, then 713-716 and 707 are performed.
• Nl ⁇ O and N2 ⁇ 0 indicates there is data in table tl and there is data in table t2.
• FIG 8 is a flowchart illustrating an embodiment of a process for synchronizing the source data table and the current target data table. The process may be used to implement 603 and 613 of FIG 6 and 703 and 713 in FIG 7.
• the storage extents occupied by the data to be synchronized in the source data table are determined.
• a data dictionary view of the ORACLETM database is queried to obtain the storage extents occupied by the data to be synchronized in the source data table.
• the storage address information of the data to be synchronized in the above storage extents is determined, where the storage address information includes at least an address range of the data to be synchronized in the respective storage extents.
• a minimum address (e min rowid) and a maximum address (e_max_rowid) at which the data to be synchronized is stored in the respective storage extents is calculated from the storage extents occupied by the data to be synchronized in the source data table, which are derived from the data dictionary view of the ORACLETM database.
• the derived address range over is saved in an intermediate table, e.g., a table of tmp rowid.
• An example table structure of the intermediate table is as follows: create table tmp_rowid
• the address information of the data to be synchronized in the respective storage extents in the source data table is retrieved by querying the intermediate table if necessary.
• the data to be synchronized in the respective storage extents is synchronized into the current target data table in accordance with the storage address information. If synchronizing the data in a storage extent fails, then the process of synchronizing the data in the storage extent is reinitiated and will end when the number of times of being reinitiated exceeds a preset threshold.
• the data in the respective storage extents is synchronized sequentially into the current target data table in one data synchronization process in accordance with the storage address information; and in a second embodiment the determined storage extents are divided into N groups, N corresponding data synchronization processes are initiated and in each of the data synchronization processes, the data in the respective storage extents in the corresponding one of the groups is synchronized sequentially into the current target data table in accordance with the storage address information.
• the second embodiment typically requires the ORACLETM database.
• the second embodiment uses an upper view to separate the application server from specific data.
• the data table in the frontend ORACLETM database to which data is synchronized from the data warehouse is not the same as any table currently used by the system, e.g., any table in which data currently invoked by the application server is located. Since data synchronization from the data warehouse to the data table in the frontend ORACLETM database and the operation of invoking the data by the application server are not performed on the same data table, conflicting access due to these operations is eliminated.
• a data table in the ORACLETM database includes numerous storage extents, each including consecutive blocks with a fixed size in which data is stored.
• An extent is the minimum unit of the data table space and one extent and another extent may not be continuous in terms of their physical locations. However, inside each extent there are a series of blocks which have continuous physical addresses.
• the storage format thereof is as illustrated in FIG 9.
• data to be synchronized can be segment-wise committed, that is, the data synchronization procedure can be enabled in the second embodiment, without any influence on accuracy of data accessed by the service system and with an improved speed of data synchronization.
• FIG 10 is a flowchart illustrating an embodiment of a process for synchronizing data in a segment-wise way from a source data table (e.g., a backend data warehouse) to a current target data table (e.g., a frontend table tl or t2).
• a source data table e.g., a backend data warehouse
• a current target data table e.g., a frontend table tl or t2
• a query is made about storage extents occupied by the data to be synchronized.
• a data dictionary view of the backend data warehouse in which the source data table is located is queried to derive the storage extents occupied by the data to be synchronized in the source data table.
• an address range of the data to be synchronized in each storage extent in the source data table is determined.
• the address range is determined by querying a stored intermediate table, e.g., a table of tmp rowid.
• the storage extents in which the data to be synchronized is stored are divided into N groups.
• the data in the table of tmp rowid can be grouped in numerous ways, for example, divided into N groups by identifier (ID) modulus. The data is then processed by group.
• ID identifier
• N data synchronization processes are initiated to synchronize the data in the respective N divided-into groups of storage extents into the current target data table.
• the data is processed in parallel in the N data synchronization processes, where the respective processes correspond to the respective groups of storage extents.
• the synchronization processes simultaneously execute without conflicts.
• the use of parallel processing for synchronization of the data in the respective storage extents improves the efficiency of data synchronization.
• the data to be synchronized in the respective storage extents in the present group (e.g., the first group) is sequentially processed.
• the data to be synchronized in one of the storage extents in the present group is processed and upon reception of a message acknowledging successful synchronization, a process of synchronizing the data in the next storage extent in the present group is initiated.
• 1006a it is determined whether synchronization is successful. In some embodiments, it is determined whether the data to be synchronized in the present storage extent is synchronized successfully. If so, then 1008a is executed; otherwise, a rollback is required to execute again the procedure of synchronizing the data in the storage extent and 1007a is executed.
• a threshold for the number of rollbacks i.e., retries
• the number of retries is preset and the number of retries is counted. If the number of retries is greater than the preset threshold, then no further retry will be made and the loop exits while an indication is generated to indicate the failure of synchronizing the data in the storage extent.
• the retry policy is adopted in the data synchronization procedure to improve error tolerance of data synchronization. If the number of retries is less than the preset threshold, then the flow returns to execute again 1005a of resynchronizing the data in the storage extent into the target data table; otherwise, 1009a is executed and the failure indication is generated if necessary.
• the synchronized data is committed to the target data table.
• At 1009a It is determined whether processing is finished, that is, it is determined whether all the storage extents in the present group have been processed. If so, then it indicates that the corresponding data in all the storage extents in the group is synchronized and the process terminates. Failure indication is generated if needed. If the processing is not finished, in other words, the corresponding data in all the storage extents in the group has not been synchronized, then the flow returns to execute 1005a of synchronizing the data in the next storage extent in the group.
• a counter variable v done num can be set for each of the groups during parallel processing to indicate correspondingly the number of storage extents in the group for which data synchronization is finished to thereby facilitate calculation of a speed at which each process synchronizes the data and of an overall speed of data synchronization.
• the efficiency of data synchronization can also be monitored conveniently based upon the above statistics.
• the steps 1005b-1009b are a procedure of synchronizing sequentially the data in the respective storage extents in the second group.
• the steps 1005x-1009x are a procedure of synchronizing sequentially the data in the respective storage extents in the N* group. Additional steps may exist in the flowchart for intermediate groups.
• a data synchronization device can be constructed as illustrated in Fig. 11, which includes a data table creating module 10, a determination module 20, a data synchronization module 30 and an access and update module 40.
• the modules can be implemented as software components executing on one or more general purpose processors, as hardware such as programmable logic devices and/or Application Specific Integrated Circuits designed to perform certain functions or a combination thereof.
• the modules can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as optical disk, flash storage device, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, network equipments, etc.) implement the methods described in the embodiments of the present invention.
• a nonvolatile storage medium such as optical disk, flash storage device, mobile hard disk, etc.
• the modules may be implemented on a single device or distributed across multiple devices. The functions of the modules may be merged into one another or further split into multiple sub-modules.
• the data table creating module 10 is adapted to create in advance two target data tables corresponding to a source data table in which data to be synchronized is stored.
• the determination module 20 is adapted to determine a current target data table from the two target data tables.
• the determination module 20 can further include a counting unit
• the counting unit 201 is adapted to count respective data records in the two target data tables.
• the determination unit 202 is adapted to determine one of the target data tables with the number of data records counted by the counting unit 201 being zero as the current target data table.
• the determination unit 202 is further adapted to show an abnormality and end the data synchronization flow when neither of the numbers of data records in the two target data tables counted by the counting unit 201 is zero.
• the data synchronization module 30 is adapted to synchronize the data from the source data table into the current target data table determined by the determination module 20.
• the data synchronization module can further include a storage extent determination unit 301, an address information determination unit 302, and a data synchronization unit 303.
• the storage extent determination unit 301 is adapted to determine several storage extents occupied by the data to be synchronized in the source data table.
• the address information determination unit 302 is adapted to determine storage address information of the data to be synchronized in the respective storage extents.
• the data synchronization unit 303 is adapted to synchronize the data to be synchronized in the respective storage extents into the current target data table in accordance with the storage address information determined by the address information determination unit 302.
• the data synchronization unit 303 can further include a first data synchronization sub-unit 3031 and a second data synchronization sub-unit 3032.
• the first data synchronization sub-unit 3031 is adapted to synchronize sequentially the data in the respective storage extents into the current target data table in one data synchronization process in accordance with the storage address information determined by the address information determination unit 302.
• the second data synchronization sub-unit 3032 is adapted to divide the storage extents into N groups, to initiate N corresponding data synchronization processes, and to synchronize sequentially in each of the data synchronization processes the data in the respective storage extents in the corresponding one of the groups into the current target data table in accordance with the storage address information determined by the address information determination unit 302.
• the data synchronization unit 303 further includes a reinitiating sub-unit 3033 adapted to reinitiate the procedure of synchronizing the data in a storage extent when the synchronizing failed and to end the procedure of synchronizing the data in the storage extent when the number of times of being reinitiated exceeds a preset threshold.
• the access and update module 40 is adapted to enable an application server to turn to access the current target data table determined by the determination module 20 when the data synchronization module 30 synchronizes the data successfully.
• the access and update module 40 is particularly adapted to create in advance an upper view so that the application server can access through the upper view one of the target data tables to which the upper view points and to update the upper view to enable the upper view to point to the current target data table upon completion of data synchronization.
• the above data synchronization device further includes a data table clear module 50 adapted to clear the other of the two target data tables which is not subject to data synchronization when the data synchronization module 30 synchronizes the data successfully.
• the data synchronization module 30 in the above data synchronization device can be arranged as a separate means for data synchronization and can be separately used in any data transfer procedure.
• a multi-process data synchronization device as illustrated in Fig. 12 can be constructed, which includes a grouping unit 121 and a data synchronization unit 122.
• the units can be implemented as software components executing on one or more general purpose processors, as hardware such as programmable logic devices and/or Application Specific Integrated Circuits designed to perform certain functions or a combination thereof.
• the units can be embodied by a form of software products which can be stored in a nonvolatile storage medium (such as optical disk, flash storage device, mobile hard disk, etc.), including a number of instructions for making a computer device (such as personal computers, servers, network equipments, etc.) implement the methods described in the embodiments of the present invention.
• a nonvolatile storage medium such as optical disk, flash storage device, mobile hard disk, etc.
• a computer device such as personal computers, servers, network equipments, etc.
• the units are shown to be in a single device in this example, in other embodiments they may distributed across multiple devices.
• the functions of the units may be merged into one another or further split into multiple sub-units.
• the grouping unit 121 is adapted to divide storage extents occupied by data to be synchronized in a source data table into several groups.
• the data synchronization unit 122 is adapted to initiate in parallel the corresponding data synchronization processes and to synchronize in each of the data synchronization processes the data to be synchronized in the respective storage extents in the corresponding one of the groups into a current target data table.
• the data synchronization unit 122 can further include a control execution sub-unit 1221 and a determination sub-unit 1222.
• the control execution sub-unit 1221 is adapted to control each of the data synchronization processes to process the data to be synchronized in one of the storage extents in the corresponding one of the groups and to initiate the procedure of processing the data to be synchronized in the next storage extent in the corresponding group when the determination sub-unit determines that not all the storage extents in the corresponding group are processed.
• the determination sub-unit 1222 is adapted to determine whether all the storage extents in the corresponding group are processed after the data to be synchronized in the one storage extent is synchronized and successfully committed.
• the data synchronization unit 122 further includes an reinitiating sub-unit
• the above data synchronization device further include:
• a storage extent determination unit 123 adapted to determine the storage extents occupied by the data to be synchronized in the source data table, and an address information determination unit 124 adapted to determine storage address information of the data to be synchronized in the respective storage extents.
• target data tables are created in advance, which correspond to a source data table in which data to be synchronized is stored and the application server accesses through an upper view created in advance one of the target data tables to which the upper view points so that the application layer will not give any attention to which table the data originates particularly from to thereby reduce the complexity of an application implementation.
• the data is synchronized from the source data table into the target data table, firstly one of the two target data tables, which is null, is determined as a current target data table, then the data is synchronized from the source data table into the current target data table, and the upper view is updated to point to the current target data table upon success of data synchronization.
• the two target data tables are alternately used and the data table accessed by the application server and that accessed by the data synchronization program have no conflicts so that a large amount of data can be prevented from being transferred into an undo/rollback table space to thereby avoid effectively a queuing and congestion phenomena arising after the undo/rollback table space is fully occupied and also improve the speed and efficiency of data synchronization.
• the inherent storage mechanism of an ORACLETM data table can be utilized in combination with the space allocation and storage principle of the ORACLETM table to synchronize data in respective storage extents into a target data table, to perform data migration on the respective storage extents, and to synchronize and commit the data in parallel by storage extent so that it is possible in the procedure of data synchronization to reduce a long term occupancy of an undo/rollback table space in the frontend ORACLETM database, to reduce greatly an overall utilization ratio of the undo/rollback table space, to reduce greatly a possibility that the undo/rollback table space is fully occupied, and to assure security of a production database.
• the storage extents can also be grouped so that the data can be migrated in parallel to further improve the efficiency of data migration.
• a rollback mechanism When synchronizing the data in a storage extent failed, a rollback mechanism can be adopted to thereby improve greatly error tolerance of the system, and a number-of- rollbacks control mechanism can prevent occurrence of an endless loop, e.g., an infinite number of rollbacks, etc. Since operations are performed on the respective storage extents without any conflicts with a table space accessed by the application server and the used current data table is null in an initial status and thus contains no conflict data, therefore synchronization of an unsynchronized part of data can be continued upon interruption of data synchronization, which makes it possible to resume a broken transfer of the data to be synchronized.
• a counter variable can be arranged to count the storage extents for which data synchronization is finished to thereby monitor the progress, speed, and efficiency of data synchronization.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Data Mining & Analysis (AREA)
• Quality & Reliability (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (2)

Applications Claiming Priority (4)

Publications (1)

Family

ID=40630405

Family Applications (1)

Country Status (5)

Families Citing this family (52)

Citations (3)

Family Cites Families (34)

• 2008
  • 2008-12-10 CN CNA2008101793946A patent/CN101419616A/zh active Pending
• 2009
  • 2009-12-08 US US12/653,091 patent/US8949178B2/en active Active
  • 2009-12-09 EP EP09832231.6A patent/EP2368178A4/en not_active Ceased
  • 2009-12-09 WO PCT/US2009/006457 patent/WO2010068260A1/en not_active Ceased
  • 2009-12-09 JP JP2011540691A patent/JP5577350B2/ja not_active Expired - Fee Related
• 2014
  • 2014-12-15 US US14/570,837 patent/US9727576B2/en active Active

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events