CN113468144A - Database migration method and migration device thereof - Google Patents
Database migration method and migration device thereof Download PDFInfo
- Publication number
- CN113468144A CN113468144A CN202110833567.7A CN202110833567A CN113468144A CN 113468144 A CN113468144 A CN 113468144A CN 202110833567 A CN202110833567 A CN 202110833567A CN 113468144 A CN113468144 A CN 113468144A
- Authority
- CN
- China
- Prior art keywords
- file
- database
- backup
- target
- migration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/214—Database migration support
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
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)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a database migration method and a migration device thereof, wherein the migration method comprises the following steps: performing initialization backup on a database file of a source end to form an initialization backup file; modifying the content of the res configuration file generated after the initialization backup; restoring the initialized backup file into a database file at the target end; continuously migrating the new database file generated by the source end to the target end in a backup mode; after the new database file is migrated, exporting metadata of the source end and importing the metadata into the target end; the method is improved aiming at a database migration method, and the content of the configuration file generated in the backup process is inquired and modified, so that the data files before and after migration correspond one to one, the defect of poor accuracy existing in the original high-efficiency migration is overcome, and the migration with high accuracy and matching degree is realized on the basis of high-efficiency and safe migration.
Description
Technical Field
The invention belongs to the technical field of database migration, and particularly relates to an efficient database migration method and a migration device thereof.
Background
Management of data is important in current enterprise database systems. The data volume of the database is increased continuously over time to a T level or a P level, and then the server hardware is aged, and the database software needs to be updated. Meanwhile, the efficient, safe and zero-data-loss migration of data of more than 10T of the enterprise in a controllable time needs to be guaranteed.
In the current practice, data can be migrated in exp \ imp or expdp \ impdp manner. However, in order to ensure that data is not lost during the migration process, the migration process needs to stop the application running, so as to ensure the consistency of all the service tables. The migration in this way is the simplest, and the applicable scenario is usually that the data size is small (the data is probably below 1T), and the use of a data pump is much more convenient. However, for libraries with large LOB field data volume, such as 5T LOB fields, GoldenGate is generally selected for migration, but the disadvantage is that the time of the data initialization stage is long, and only after the data of the target end is leveled, the business is formally cut off, the application connection string is switched, and the application connection string is cut off to a new library.
Therefore, the developed incremental backup mode such as XTTS realizes cross-platform data migration, data synchronization is realized through incremental data backup and recovery, the Oracle database can be migrated quickly, efficiently, stably and safely, and the migration time is relatively short.
ZL201510065707.5 discloses an Oracle database migration tool for migrating from an AIX platform to a K-UX platform, and the migration of the Oracle database from the AIX platform to the K-UX platform is realized by applying the database migration tool combined with a migration algorithm, so that the working time is shortened, and the working efficiency is improved. However, the method is easy to cause disorder of the data files in the migration process, and the condition that the data files in the table spaces of the target end and the source end do not correspond after migration occurs, so that the application of the subsequent database is influenced.
How to realize high-accuracy migration of data with large data volume based on efficient and safe migration in controllable time is a problem which needs to be solved urgently in the field at present.
Disclosure of Invention
The method aims to solve the problems that efficient and safe migration within controllable time is realized in the database migration process, but the matching degree and the corresponding degree of the data file and the source end are not high after the data file is migrated to the target end.
In one aspect, the present invention provides a database migration method, including the following steps:
step S1: performing initialization backup on a database file of a source end to form an initialization backup file;
step S2: modifying the content of the res configuration file generated after the initialization backup;
step S3: restoring the initialized backup file into the database file at the target end;
step S4: continuously migrating the new database file generated by the source end to the target end in a backup mode;
step S5: after the new database file is migrated, exporting the metadata of the source end and importing the metadata into the target end;
step S6: and completing the migration of the database.
Further, the res configuration file content includes the number of the data file, the name of the second data file, the name of the tablespace, and the name of the first data file;
the second data file name refers to the data file name after the initialization backup, and the first data file name refers to the data file name before the initialization backup;
the name of the table space is the name of the table space where the data file is located.
Further, the step S2 of modifying the res configuration file content generated after the initial backup specifically includes:
step S21: confirming the number of the data file needing to be modified in the res configuration file content;
step S22: inquiring the data file in a database of the source end according to the serial number of the data file, and outputting the name of the original data file;
step S23: and changing the first data file name in the res configuration file content into the output original data file name.
Further, in step S2, before modifying the res configuration file content generated after the initialization backup and transmitting the initialization backup file to the target end, the source end modifies the first data file name in the res configuration file content.
Further, in step S2, after the content of the res configuration file generated after the initialization backup is modified and the initialization backup file is transmitted to the target end, the first data file name in the content of the res configuration file is modified at the target end.
Further, the step S4 of continuing to migrate the new database file generated by the source end to the target end in a backup manner specifically includes:
step S41: performing incremental backup at the source end, and transmitting the incremental backup file to the target end;
the first incremental backup is to backup the newly added database file from the initial backup in step S1 to the first incremental backup; the subsequent incremental backup is to backup a newly added database file in a time period from the previous incremental backup to the current incremental backup;
step S42: restoring the incremental backup file to the new database file at the target end;
step S43: and judging whether the database of the source end is set to be in a read-only mode, if so, repeating the step S41 and the step S42 once to complete the new database file migration process, and if not, returning to the step S41.
Further, before the step S1, setting parameters of the source end and the target end through a script file specifically includes:
uploading an original script file to the source end;
modifying the xtt configuration file in the original script to form a new script file;
the modification comprises creating a database table space name of the source end and a directory for performing backup files in the xtt configuration file, and creating the directory of the backup files restored by the target end and a storage directory of the database files at the target end;
copying the new script file to the target end;
and setting environment variables for the source end and the target end at the same time.
Further, verifying the database file and the metadata of the target end and setting the database of the target end to a read-write mode are further included between the step S5 and the step S6.
Further, the verifying the database file and the metadata of the target end includes synchronizing storage processes, JOBs, packages, views, and sequence synonyms of the source end to the target end.
In another aspect, the present invention provides a database migration apparatus for executing the database migration method according to any one of claims 1 to 9, where the database migration apparatus includes a source server and a target server, and is characterized in that:
the source server can back up and transmit database files, modify the content of res configuration files and export metadata;
the target end server can receive and restore the backup file transmitted by the source end server, and modify the content of the res configuration file and import the metadata.
The invention improves the database migration method, inquires and modifies the content of the configuration file generated in the backup process, so that the data files before and after migration correspond one to one, overcomes the defect of poor accuracy in the original high-efficiency migration, and realizes the migration with high accuracy and matching degree on the basis of high-efficiency and safe migration.
Drawings
The above and other objects, features and advantages of exemplary embodiments of the present disclosure will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or corresponding parts and in which:
FIG. 1 is a schematic flow chart diagram of a database migration method according to an embodiment of the present invention;
FIG. 2 is a flow diagram illustrating res profile content modification according to an embodiment of the present invention;
FIG. 3 is a schematic flow chart of migration of a new database file by means of backup according to an embodiment of the present invention;
fig. 4 is a schematic flowchart of parameter setting by a script file according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the examples of the present invention and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise, and "a plurality" typically includes at least two.
It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that an article or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such article or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in the article or device in which the element is included.
Alternative embodiments of the present invention are described in detail below with reference to the accompanying drawings.
Example one
Referring to fig. 1, the present invention provides a database migration method, including the following steps:
step S1: performing initialization backup on a database file of a source end to form an initialization backup file;
step S2: modifying the content of the res configuration file generated after the initialization backup;
step S3: restoring the initialized backup file into a database file at the target end;
step S4: continuously migrating the new database file generated by the source end to the target end in a backup mode;
step S5: after the new database file is migrated, exporting metadata of the source end and importing the metadata into the target end;
step S6: and completing the migration of the database.
An Oracle database has at least one tablespace, one tablespace corresponds to a plurality of physical data files, and one data file can only be associated with one tablespace, and the data file provides real physical storage for database information.
When the database is migrated, in order to solve the problem of long downtime caused by excessive migration data volume, the incremental backup + XTTS mode is adopted, the database of the source end can be normally applied, and only when the last incremental backup is carried out to the target end, the tablespace in the database of the source end needs to be set to be in a read-only mode, so that the downtime is reduced to the maximum extent. When the source side performs initialization backup, a configuration file of res.txt is generated under a directory of the environment variable, and the configuration file is copied and transmitted to the target side, so that the database file can be recovered.
However, in the actual database transmission process, in order to take account of factors such as the efficiency of backup of a source-end database file, the diversity of applicable scenes, and the like, the res configuration file generated by the source-end backup often has the problem of inaccurate mapping information, and if the res configuration file is directly transmitted to a target end, no processing is performed (the content of the res.
Example two
On the basis of the first embodiment, the present embodiment may further include the following:
the res configuration file content comprises a data file number, a second data file name, a tablespace name and a first data file name;
the second data file name refers to a data file name after the initial backup, and the first data file name refers to a data file name before the initial backup;
the tablespace name is the name of the tablespace in which the data file is located.
Referring to fig. 2, the step S2 of modifying the res configuration file content generated after the initial backup specifically includes:
step S21: confirming the number of the data file to be modified in the res configuration file content;
step S22: inquiring the data file in a source end database according to the serial number of the data file, and outputting the name of the original data file;
step S23: and changing the first data file name in the res configuration file content into the output original data file name.
Txt's configuration file will be generated after the source database is initialized and backed up, and the contents of the configuration file mainly include backup type, data file number, second data file name, SCN number of the database during backup, tablespace name, first data file name, and the like. For example, the specific content of the res. (#0:: 5,13, SHWZH _ TAB _5_0d008ssv _1.bkp,0,1934044,0,0,0, SHWZH _ TAB, SHWZH _ TAB _5. dbf).
The detailed explanation for the content is as follows: #0: the representative is initialization full standby; 5: the representative data file number is 5; SHWZH _ TAB _5_0d008ssv _1_1. bkp: is the name of the second data file; 1934044: database SCN number when backup; SHWZH _ TAB: is a table space name; SHWZH _ TAB _5. dbf: is the first data file name. Wherein, the data file number and the table space name are consistent before and after backup.
And modifying the content of the res configuration file generated after the initialization backup, wherein the modification is mainly performed on the name of the end of the suffix in the first data file in the res. In one embodiment, when the content of the res configuration file is modified, the number of the data file to be modified before backup is first determined, for example, the number of the data file is 5; then, the data file No. 5 is searched in the database, for example, the original data file name may be output by an instruction of "select file _ name from dba _ data _ files where file _ id ═ data _ file _ Serial _ number" (where data file _ Serial _ number indicates the data file number); and finally, changing the first data file name in the res configuration file content into the output original data file name. The changing mode may be set by setting a mapping relationship, for example, after the data FILE in the database is found, the path of the data FILE is recorded, and then the NAME of the first data FILE in the res configuration FILE content is changed through a similar instruction of select FILE _ ID, FILE _ NAME, packet space _ NAME from dba _ data _ FILEs FILE _ ID ═ 5, or the like.
By adopting the modification steps, the content of the res configuration file which is subsequently transmitted to the target end is modified in the data migration process, so that the problem that the names of the data files before and after the migration are inconsistent is solved. The modification method is easy to operate, unification of data files before and after backup is achieved in the database file migration process, data consistency before and after data migration is improved, meanwhile, the backup and recovery processes of the database files are not affected, and high-accuracy migration of large data volume is achieved on the basis of efficient and safe migration within controllable time.
EXAMPLE III
On the basis of the above embodiment, the present embodiment may further include the following:
in order to make the information such as the name types of the database files of the source end and the target end consistent, the following two schemes can be adopted.
One is as follows: after the source performs the initial backup, the res configuration file is modified before being transmitted to the target.
The benefit of this approach is that source-side modification of the configuration file before transmission need only be performed once throughout the migration process. That is, in the subsequent step S4, the new database file is migrated in the backup manner without repeated modification, and the information of the res configuration file modified after the initial backup is directly read when the target performs recovery, so as to automatically modify and correct the res configuration file.
However, in some scenarios, for example, when the whole migration process is checked after the database migration is completed, it is necessary to ensure the original state of the backup file of the source database as much as possible. Modifying the res configuration file content at the source end destroys the original state of the backup file, and only the res configuration file can be directly transmitted to the target end, and another modification scheme is selected.
Secondly, after the res configuration file is transmitted to the target end, the res configuration file is inquired in the database, and the content of the res configuration file is modified.
This solution not only requires the res configuration file content migrated after the initial backup to be modified, but also requires repeated modification after the new database file is migrated in the backup manner in the subsequent step S4. Although the method is more complicated than the first method, the method meets the scene requirement that some source ends are not suitable for modifying the content of the configuration file, and also achieves the effect of consistency of the data files before and after migration.
Example four
On the basis of the above embodiment, the present embodiment may further include the following:
referring to fig. 3, the step S4 of continuing to migrate the new database file generated by the source end to the target end in the backup manner specifically includes:
step S41: performing incremental backup at a source end, and transmitting an incremental backup file to a target end;
wherein, the first incremental backup is to backup the newly added database file from the initial backup in step S1 to the first incremental backup; the subsequent incremental backup is to backup the newly added database file in the time period from the previous incremental backup to the current incremental backup;
step S42: restoring the incremental backup file into a new database file at the target end;
step S43: and judging whether the database of the source end is set to be in a read-only mode, if so, repeating the step S41 and the step S42 once to complete the new database file migration process, otherwise, returning to the step S41.
After data initialization, the data is subsequently used as an incremental recovery, incremental backup and recovery are used for the newly added and changed database files after initialization, and the last small increment is supplemented back again when the last application is switched through the forward rolling database files. Thus ensuring that the cutting time is short.
In the migration process of the database, incremental backup is implemented only by backing up files which are added or modified compared with the previous time, synchronization of incremental data backup and data recovery is achieved, the Oracle database can be migrated quickly, efficiently, stably and safely, and migration time is relatively short.
EXAMPLE five
On the basis of the above embodiment, the present embodiment may further include the following:
referring to fig. 4, before step S1, setting parameters of the source peer and the target peer through a script file specifically includes:
uploading an original script file to a source end;
modifying xtt configuration files in the original script to form a new script file;
the modification comprises creating a database table space name of a source end and a directory for carrying out backup files in xtt configuration files, and creating a directory of backup files restored by a target end and a storage directory of database files at the target end; copying the new script file to a target end;
and setting environment variables for the source end and the target end.
Properties parameter file, defining all parameters needed in the migration process, such as:
tablespaces-tablespace names are capitalized,
Platformed--select PLATFORM_ID from v$database，
src _ scratch _ location-source backup directory,
dest _ scratch _ location-target backup directory,
dest _ datafile _ location-target end data file storage directory;
setting environment variables at a source end and a target end:
the source end export TMPDIR ═ bak/xtt/tmp,
target end export TMPDIR ═ backhaul/xtt/tmp.
EXAMPLE six
On the basis of the above embodiment, the present embodiment may further include the following:
the method also comprises the steps of verifying the database file and the metadata of the target end between the step S5 and the step S6, and setting the database of the target end to be in a read-write mode.
Validating the database file and metadata of the target peer includes synchronizing the store process, JOB, package, view, and sequence synonyms of the source peer to the target peer.
And (3) checking the physical and logical block damage condition at the target end, and verifying the test data, for example, in an RMAN backup mode:
RMAN is run to check for physical and logical block corruption by running VALIDE TABLESSPACE, RMAN > valid TABLESPACE TS1, TS2 check local.
After the metadata is exported and imported, the storage process, the JOB, the package, the view and the agreement word of the source end user cannot be synchronized to the target end, and the target end user loses the storage process, the JOB, the package, the view and the sequence synonym, so that the influence on the whole database is very large, data can be lost, and certain functions of the application program cannot be used.
Therefore, store processes, JOBs, packages, views, sequence synonyms of the source peer need to be synchronized to the target peer manually.
EXAMPLE seven
The present embodiment provides a database migration apparatus for executing a database migration method, where the database migration apparatus includes a source server and a target server:
the source server can back up and transmit the database file, modify the content of the res configuration file and export the metadata;
the target end server can receive and restore the backup file transmitted by the source end server, and modify the content of the res configuration file and import the metadata.
The foregoing describes preferred embodiments of the present invention, and is intended to provide a clear and concise description of the spirit and scope of the invention, and not to limit the same, but to include all modifications, substitutions, and alterations falling within the spirit and scope of the invention as defined by the appended claims.
Claims (10)
1. A database migration method, comprising the steps of:
step S1: performing initialization backup on a database file of a source end to form an initialization backup file;
step S2: modifying the content of the res configuration file generated after the initialization backup;
step S3: restoring the initialized backup file into the database file at the target end;
step S4: continuously migrating the new database file generated by the source end to the target end in a backup mode;
step S5: after the new database file is migrated, exporting the metadata of the source end and importing the metadata into the target end;
step S6: and completing the migration of the database.
2. The database migration method according to claim 1, wherein the res-profile contents include a number of a data file, a second data file name, a tablespace name, and a first data file name;
the second data file name refers to the data file name after the initialization backup, and the first data file name refers to the data file name before the initialization backup;
the name of the table space is the name of the table space where the data file is located.
3. The database migration method according to claim 2, wherein the step S2 of modifying the res configuration file content generated after the initial backup specifically comprises:
step S21: confirming the number of the data file needing to be modified in the res configuration file content;
step S22: inquiring the data file in a database of the source end according to the serial number of the data file, and outputting the name of the original data file;
step S23: and changing the first data file name in the res configuration file content into the output original data file name.
4. The database migration method according to claim 3, wherein the step S2 modifies the res configuration file content generated after the initial backup into the first data file name modified in the res configuration file content at the source end before the initial backup file is transmitted to the target end.
5. The database migration method according to claim 3, wherein in step S2, after the res configuration file content generated after the initial backup is modified and the initial backup file is transmitted to the target end, the first data file name in the res configuration file content is modified at the target end.
6. The database migration method according to claim 1, wherein the step S4 of continuing to migrate the new database file generated by the source end to the target end in a backup manner specifically includes:
step S41: performing incremental backup at the source end, and transmitting the incremental backup file to the target end;
the first incremental backup is to backup the newly added database file from the initial backup in step S1 to the first incremental backup; the subsequent incremental backup is to backup a newly added database file in a time period from the previous incremental backup to the current incremental backup;
step S42: restoring the incremental backup file to the new database file at the target end;
step S43: and judging whether the database of the source end is set to be in a read-only mode, if so, repeating the step S41 and the step S42 once to complete the new database file migration process, and if not, returning to the step S41.
7. The database migration method according to claim 1, wherein before the step S1, setting parameters of the source peer and the target peer through a script file specifically includes:
uploading an original script file to the source end;
modifying the xtt configuration file in the original script to form a new script file;
the modification comprises creating a database table space name of the source end and a directory for performing backup files in the xtt configuration file, and creating the directory of the backup files restored by the target end and a storage directory of the database files at the target end;
copying the new script file to the target end;
and setting environment variables for the source end and the target end at the same time.
8. The database migration method according to claim 1, further comprising, between the step S5 and the step S6, verifying the database file and the metadata of the target, and setting the database of the target to a read-write mode.
9. The database migration method of claim 8, wherein said validating said database file and said metadata of said target peer comprises synchronizing a stored procedure, a JOB, a package, a view, and a sequence synonym of said source peer to said target peer.
10. A database migration apparatus for performing the database migration method according to any one of claims 1 to 9, wherein the database migration apparatus includes a source server and a target server, and the database migration apparatus is characterized in that:
the source server can back up and transmit database files, modify the content of res configuration files and export metadata;
the target end server can receive and restore the backup file transmitted by the source end server, and modify the content of the res configuration file and import the metadata.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110833567.7A CN113468144A (en) | 2021-07-23 | 2021-07-23 | Database migration method and migration device thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110833567.7A CN113468144A (en) | 2021-07-23 | 2021-07-23 | Database migration method and migration device thereof |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113468144A true CN113468144A (en) | 2021-10-01 |
Family
ID=77882013
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110833567.7A Pending CN113468144A (en) | 2021-07-23 | 2021-07-23 | Database migration method and migration device thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113468144A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115129661A (en) * | 2022-08-30 | 2022-09-30 | 东方电气风电股份有限公司 | Data migration method and system after power-off restart of wind field monitoring system server |
| CN117171130A (en) * | 2023-08-31 | 2023-12-05 | 中银金融科技(苏州)有限公司 | Data migration method between heterogeneous databases and related equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107315763A (en) * | 2017-04-26 | 2017-11-03 | 杭州沃趣科技股份有限公司 | One kind is directed to oracle database Platform-cross Data Migration method |
| CN110019138A (en) * | 2017-12-29 | 2019-07-16 | 中国移动通信集团公司 | A kind of transmission table space Autonomic Migration Framework method and system based on Zabbix |
| CN111367886A (en) * | 2020-03-02 | 2020-07-03 | 中国邮政储蓄银行股份有限公司 | Method and device for data migration in database |
| US20200349133A1 (en) * | 2019-04-30 | 2020-11-05 | Commvault Systems, Inc. | Automated log-based remediation of an information management system |
| CN112231303A (en) * | 2020-12-10 | 2021-01-15 | 北京蒙帕信创科技有限公司 | Data migration system and method |
| CN112632035A (en) * | 2020-12-24 | 2021-04-09 | 广州辰创科技发展有限公司 | Autonomous controllable database migration method and storage medium |
-
2021
- 2021-07-23 CN CN202110833567.7A patent/CN113468144A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107315763A (en) * | 2017-04-26 | 2017-11-03 | 杭州沃趣科技股份有限公司 | One kind is directed to oracle database Platform-cross Data Migration method |
| CN110019138A (en) * | 2017-12-29 | 2019-07-16 | 中国移动通信集团公司 | A kind of transmission table space Autonomic Migration Framework method and system based on Zabbix |
| US20200349133A1 (en) * | 2019-04-30 | 2020-11-05 | Commvault Systems, Inc. | Automated log-based remediation of an information management system |
| CN111367886A (en) * | 2020-03-02 | 2020-07-03 | 中国邮政储蓄银行股份有限公司 | Method and device for data migration in database |
| CN112231303A (en) * | 2020-12-10 | 2021-01-15 | 北京蒙帕信创科技有限公司 | Data migration system and method |
| CN112632035A (en) * | 2020-12-24 | 2021-04-09 | 广州辰创科技发展有限公司 | Autonomous controllable database migration method and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115129661A (en) * | 2022-08-30 | 2022-09-30 | 东方电气风电股份有限公司 | Data migration method and system after power-off restart of wind field monitoring system server |
| CN117171130A (en) * | 2023-08-31 | 2023-12-05 | 中银金融科技(苏州)有限公司 | Data migration method between heterogeneous databases and related equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US12147305B2 (en) | Restoring a database using a fully hydrated backup | |
| US10254996B1 (en) | Fast migration of metadata | |
| US10705919B2 (en) | Data backup using metadata mapping | |
| US8341460B2 (en) | Verification of computer backup data | |
| EP3796174B1 (en) | Restoring a database using a fully hydrated backup | |
| US8234475B2 (en) | Save set bundling for staging | |
| US7925856B1 (en) | Method and apparatus for maintaining an amount of reserve space using virtual placeholders | |
| EP3895033B1 (en) | Efficient database migration using an intermediary secondary storage system | |
| US20180203942A1 (en) | Method for reading and writing data and distributed storage system | |
| US10261865B1 (en) | Fast and optimized restore using delta information | |
| CN114490677B (en) | Data synchronization method and system in data analysis system | |
| CN105302675A (en) | Method and device for data backup | |
| US20170308420A1 (en) | System and method of validating data for incremental format of backup archive | |
| CN107256182A (en) | A kind of method and apparatus of database restoration | |
| US20190227710A1 (en) | Incremental data restoration method and apparatus | |
| CN113468144A (en) | Database migration method and migration device thereof | |
| CN103838645A (en) | Remote difference synthesis backup method based on Hash | |
| US8738577B1 (en) | Change tracking for multiphase deduplication | |
| US8433864B1 (en) | Method and apparatus for providing point-in-time backup images | |
| US11392868B1 (en) | Data retention cost control for data written directly to object storage | |
| US20210055996A1 (en) | Migration of backup data | |
| EP3245589B1 (en) | Change tracking using redundency in logical time | |
| US8838545B2 (en) | Incremental and prioritized restoration of blocks | |
| US8595271B1 (en) | Systems and methods for performing file system checks | |
| CN106484312A (en) | A kind of magnetic disk of virtual machine data migration method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20211001 |
|
| RJ01 | Rejection of invention patent application after publication |