WO2021184679A1 - 持续数据保护系统及方法 - Google Patents

持续数据保护系统及方法 Download PDF

Info

Publication number
WO2021184679A1
WO2021184679A1 PCT/CN2020/110500 CN2020110500W WO2021184679A1 WO 2021184679 A1 WO2021184679 A1 WO 2021184679A1 CN 2020110500 W CN2020110500 W CN 2020110500W WO 2021184679 A1 WO2021184679 A1 WO 2021184679A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
source
log
database
task
Prior art date
Application number
PCT/CN2020/110500
Other languages
English (en)
French (fr)
Inventor
黄开德
苟露
Original Assignee
上海爱数信息技术股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 上海爱数信息技术股份有限公司 filed Critical 上海爱数信息技术股份有限公司
Publication of WO2021184679A1 publication Critical patent/WO2021184679A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2365Ensuring data consistency and integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1464Management of the backup or restore process for networked environments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2433Query languages
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273Asynchronous replication or reconciliation

Definitions

  • This application relates to the field of data protection technology, for example, to a continuous data protection system and method.
  • Oracle database backup is offline backup, also known as cold backup. Before the backup starts, the database must be shut down completely, and every file used by the database needs to be backed up.
  • Oracle Database Version 6 introduced the concept of hot backup. This means that the database can remain open and process transactions while performing backups, but each tablespace must be placed in a special backup mode before the OS files can be copied. Therefore, the DBA modifies its script to connect to the database, obtains a list of table spaces, puts each table space in backup mode, performs a copy of the OS file, and finally removes the table space from the backup mode.
  • RMAN Oracle Recovery Manager
  • the common data protection mode of the Oracle database is scheduled backup, that is, the data in the Oracle database is periodically backed up to the storage medium, and most of them use RMAN backup.
  • RMAN backup For regular backups, periodic full backups, incremental backups, and archive log backups are required to form corresponding time points for data recovery, which can restore data to a certain historical state.
  • This backup method is only suitable for data protection scenarios that do not require high requirements for RPO (Recovery Point Object) and RTO (Recovery Time Objective). For other scenarios, it will cause the RPO and RTO of Oracle's scheduled backup to be biased. Major problems, and thus cannot guarantee the real-time consistency and availability of Oracle database data.
  • part of the Oracle database data protection mode uses disk volume replication. However, this method protects the entire data volume. Only the data placed on the disk is copied, and the cached data cannot be processed, and problems such as poor database consistency will occur.
  • This application provides a continuous data protection system and method, which can make RPO and RTO approach zero and ensure the real-time consistency and availability of Oracle database data.
  • a continuous data protection system which includes a server, a client, a source, a target, an actual data storage unit, a redo log, and an archive log;
  • the server serves as a console of real-time replication software, configured to take on the task of interacting with users, and at the same time coordinate and manage all resources including the client;
  • the client as a proxy client of the source and target in real-time replication software, is configured to interact with the server, receive the real-time replication task command issued by the server, and respond to the command Make corresponding processing, and return the execution result to the server;
  • the source end serves as the user's production environment end and is configured to read the redo log or the archive log in the source end database in real time when the real-time replication task is running, and obtain the log with data changes through processing After that, parse the log and generate SQL statements;
  • the target end as the user's disaster recovery environment end, is configured to receive SQL statements from the source end and generate SQL files, and execute the SQL statements in the database of the target end by invoking OCI;
  • the actual data storage unit is used as the actual data storage unit of the database of the source and the target, and the actual data storage unit is configured to perform full copy when the task is initiated for the first time, and directly transfer all the data through the data pump.
  • the data in the database at the source end is synchronized to the database at the target end;
  • the redo log or the archive log is configured to store all operation records and changed data of changes to the database.
  • a continuous data protection method used in the continuous data protection system as described above, the continuous data protection method includes:
  • a real-time replication task is deployed, and a production environment end is set as the source end, and a disaster recovery environment end is set as the target end.
  • Figure 1 is a structural diagram of each role and the relationship between the roles in the application for data protection
  • Figure 2 is a flowchart of the application for initiating real-time replication tasks and task execution.
  • This application proposes a continuous data protection technology based on parsing Oracle logs.
  • the logs with data changes are captured and analyzed to generate SQL (Structured Query Language) statements. It is transmitted to the disaster recovery environment through the network, and the disaster recovery environment loads and executes after receiving the SQL statement. Due to the real-time capture, analysis and synchronization of logs, the RPO and RTO are close to zero, ensuring the real-time consistency and availability of Oracle database data.
  • SQL Structured Query Language
  • this application relates to a continuous data protection system based on parsing Oracle logs, which can be used to protect Oracle data and meet the needs of customers for low RPO and database consistency.
  • the system replicates the data in the production environment to the disaster recovery environment in real time, so as to protect the data in the Oracle database.
  • Source is the source in the real-time replication process
  • Target is the target in the real-time replication process.
  • the Agent client is responsible for interacting with the server, receiving commands from the server, and processing the commands accordingly, and returning the execution results to the server.
  • the Server in this application serves as the console of the real-time replication software, and is the management unit of the real-time replication software, responsible for the task of interacting with users.
  • the server is responsible for sending instructions for real-time replication tasks to the corresponding agent, and at the same time, receiving the execution results returned by the agent and monitoring the execution of the tasks.
  • Source in this application represents the user's production environment.
  • the source reads the redo log or archive log of the database in real time, and obtains a log with data changes through analysis, which is based on the transaction as the basic unit. After obtaining the log with data changes, parse the log and generate SQL statements.
  • Target in this application represents the user's disaster recovery environment.
  • the target side receives the SQL statement from the source side and generates a SQL file, and executes the SQL statement in the database (Database) of the target side by calling OCI.
  • the actual data storage unit is the actual data storage unit of the source and target databases.
  • a task is initiated for the first time, a full copy is first performed, and the data in the source database (Database) is directly synchronized to the target database (Database) through the data pump technology.
  • redo log and archive log are redo logs and archive logs in the database, which are responsible for storing all the operations and data of changes to the database.
  • the number and size of redo logs are specified by the database, and data is written in circular replication.
  • the SQL statement generated by the source end will be transmitted to the target end through the TCP/IP network protocol, and the target end will generate the SQL file in the cache directory of the target end after receiving the SQL statement.
  • the operator can deploy real-time replication tasks.
  • This task requires a production environment, which is the source end of the instance, and a disaster recovery environment, which is the target end of the instance.
  • the operator initiates a task, perform the backup operation according to the following steps:
  • Figure 2 is a schematic diagram of the task flow when a data protection task is initiated. Actually, when the task is initiated, the source end captures the log, parses the log, and generates SQL statements concurrently by multiple threads, and the target end receives and executes SQL statements concurrently.
  • the process in Figure 2 can be:
  • Step 1 The operator selects the data source and objects to be protected, establishes a real-time replication task, initiates the task, and executes step 2. It should be noted that the operator can choose to protect the user or table when creating a task. And when the operator creates a task, both the source and the target need to select a cache directory to store the files that need to be recorded.
  • Step 2 After the task is started, the source terminal checks whether the running conditions are met according to the task options configured when the task is created. If it is satisfied, that is, the status is normal, go to step 3. If the status is abnormal, repeat step 2.
  • the options that need to be tested include:
  • Step 3 The source sends the parameters required by the target to the target, and connects to the target. If the target is successfully connected and the environment meets the operating requirements, perform step 4, otherwise restart step 2.
  • the options that need to detect whether the environment meets the operating requirements include:
  • the source sends parameters to the target and connects with the target. If the connection between the source and the target fails, return to step 2; otherwise, proceed to the next step.
  • the target side checks whether the database status of the selected instance is open. If the status is not open, go back to step 2; otherwise, go to the next step.
  • the target side detects whether the target side cache directory has read and write file permissions. If not, go back to step 2; otherwise, go to the next step.
  • Step 4 The target side obtains the serial number and SCN number recorded before the last task exit, and the target side sends the obtained information to the source side. If the configuration of recording the serial number and SCN number is not found in the cache directory of the target side File, then the target end returns 0 to the source end. The source judges whether to perform the full amount according to the obtained serial number. If the source end receives the data returned by the target end is not 0, and can use the serial number to query the log, then the task does not need to perform full copy, go to step 6, otherwise go to step 5.
  • Step 5 The source side synchronizes the data to the target side through full replication. Create a database link from the target end to the source end on the target end, and then receive the data in the source end database at the target end and load it into the target end database. After the migration is complete, go to step 6.
  • Step 6 The source side obtains the redo log or archive log of the database, and judges whether there is a data change in the log by analyzing part of the structure of the log. If there is a data change, perform step 7; otherwise, continue to obtain the log.
  • Step 7 The source terminal obtains a log with data changes, and the log uses a transaction as the basic unit. Analyze the log to obtain the information of the changed data, query the table name and user name in the data dictionary according to the obj number in the obtained change information, compare the queried table name and user name with the object selected when creating the task, and determine whether it is true Objects that need to be protected. If the changed data belongs to the object that needs to be protected, go to step 8. Otherwise, continue to step 6 to obtain new logs for analysis.
  • Step 8 The source obtains the changed data, and generates corresponding DDL (Data Definition Language) statements and DML (Data Manipulation Language) statements, and writes SQL statements into the cache in transaction units , And record the SCN number when the transaction was submitted, and go to step 9.
  • DDL Data Definition Language
  • DML Data Manipulation Language
  • Step 9 The source side obtains the SQL statement and SCN number from the cache, and sends the SQL statement and SCN number to the target side through the network, and step 10 is executed.
  • Step 10 The target receives the SQL statement and the SCN number sent by the source via the network, writes the SQL statement into the cache directory, and executes step 11.
  • Step 11 The target side executes the SQL statement through the OCI (Oracle Call Interface) interface, synchronizes the data to the database of the target side, and executes step 12.
  • OCI Organic Call Interface
  • Step 12 After executing the SQL statement, the target end writes the SCN number into the configuration file.
  • the source side detects whether the operator issues an instruction to stop the task. If the stop command is not received, go to step 6. If the operator issues a stop command, go to step 13.
  • Step 13 The source detects the instruction to end the task initiated by the operator, and the source sends a message to end the task to the target. After receiving the message to end the task, the target ends the task and sends the end of the target to the source. Message, the source ends the task.
  • Change vector represents a change made to a certain data block in the database. Contains the transaction operation code, the address of the changed subordinate data block, and the updated data.
  • Redo record It is composed of a set of change vectors, which is a set of change vectors, which represents a database change (insert, update, delete, etc. operations), and constitutes the minimum recovery unit for database changes.
  • Transaction is a group of logical units containing one or more statements, and each transaction is an atomic unit.
  • a transaction contains multiple redo records.
  • the Oracle log file is a binary format file composed of several data blocks of a specified size. On different operating systems, the block size is different, it can be 512bytes, it can be 1K, 2K, etc.
  • the first block of the log file is the file header.
  • the data block size and the number of data blocks of the log file are stored in the file header.
  • the second block of the redo log header of the log file stores database-related information, including database ID, database name, thread number and other information.
  • each data block has a 16-byte data header, including the number of the current data block, the serial number and offset of the current log. It is the first redo record in the current data block. ) The starting position.
  • the Record header includes LEN, VLD, RBA and other parameters.
  • LEN is the length of the record structure.
  • the VLD parameter determines the length of the record header, and the corresponding length can be parsed through the meaning of the existing VLD.
  • RBA is the redo record address, which is composed of log sequence number, data block number, and offset in the data block. RBA can quickly locate the position of the recode in the log.
  • Change is divided into change header, change length list and change body.
  • the length of the Change header is 24 bytes.
  • the change header includes OP, SCN and other parameters.
  • OP is the operation code of change, representing different data operations of Oracle.
  • SCN is the system change number, which is a time stamp that defines the submitted version of the database at a certain point in time.
  • the change body has a different structure according to the OP in the change header.
  • the common opcode OP5.2 is to modify the header of the rollback segment, which is the beginning of a transaction.
  • OP5.1 is to store the old data before the database operation.
  • OP11.2 records the detailed information of the insert data.
  • OP11.3 records the detailed information of delete data.
  • OP11.5 records the detailed information of the update data.
  • OP24.1 records DDL statements.
  • OP5.4 records transaction commit information, which is the end of a transaction.
  • This application monitors the data changes of the logs in the production environment in real time, captures the logs with data changes, analyzes and generates SQL statements, and transmits them to the disaster recovery environment through the network, that is, synchronizes to the target end in real time, and the disaster recovery environment receives the SQL statements
  • the RPO and RTO are close to 0, ensuring the real-time consistency and availability of Oracle database data, and effectively reducing the RPO to close to 0.
  • This application provides a continuous data protection system based on parsing Oracle logs.
  • the method is used to protect Oracle data while meeting the needs of customers with low RPO and database consistency.
  • the method may include:
  • the server server as the console of real-time replication software, is used to undertake the task of interacting with users, and at the same time coordinate and manage all resources including the client agent.
  • the server is mainly responsible for sending instructions for real-time replication tasks to the corresponding client Agent, and at the same time receiving execution results returned by the Agent, and monitoring the execution of tasks.
  • Client Agent as the proxy client of the source and target in real-time replication software, is responsible for interacting with the server, receiving the real-time replication task commands issued by the server, and processing the commands accordingly, and executing the results Return to Server.
  • Source as the user's production environment, is used to read the redo log file or archive log of the database in real time when the real-time replication task is running. After the log with data changes is obtained through processing, the log is parsed and the SQL statement is generated ; The log with data changes obtained by the source end Source is a log with transaction as the basic unit.
  • the SQL statement generated by the source is transmitted to the target target through the TCP/IP network protocol. After the target receives the SQL statement, the SQL file is generated in the target cache directory of the target.
  • Target as the user's disaster recovery environment, is used to receive SQL statements from Source and generate SQL files, and execute SQL statements in Target's Database by calling OCI.
  • the actual data storage unit of the database as the actual data storage unit of the source-side Source and target-side Target databases, is used to perform full replication when the task is initiated for the first time, and directly transfer the data in the database Database of the source-side Source through the data pump Synchronize to the database of the target target.
  • Redo log files or archive logs are used to store all changes to the database operation records and changed data.
  • the number and size of redo log files are specified by the database, and data is written in circular replication.
  • the database opens the archive mode, when a redo log file is full, it will be archived and an archived log file will be generated.
  • the source-side Source captures the log, parses the log, and generates SQL statements for multi-threaded concurrent execution, and the target-side Target receives and executes SQL statements for concurrent execution.
  • This application also provides a continuous data protection method, the main content of which is:
  • the real-time replication task executes the backup operation according to the following steps:
  • the source-side Source detects whether the operating conditions are met according to the task options configured when the task is created, and if it is met, execute the next step, otherwise, repeat this step;
  • the source-side Source sends the parameters required by the target-side Target to the target-side Target, and connects to the target-side Target. If the target-side Target is successfully connected and the environment meets the operating requirements, perform step S4, otherwise restart step S2;
  • the target on the target side obtains the serial number and SCN number recorded before the last task exit, and sends the obtained information to the source side. If the configuration file recording the serial number and SCN number is not found in the target cache directory on the target side , The target end Target returns a result of 0 to the source end Source, and the source end Source judges whether to perform the full amount according to the obtained serial number. If the source end Source receives the data returned by the target end Target is not 0, and the serial number can be used to query the log , The task does not need to be copied in full, and step S6 is executed, otherwise, step S5 is executed;
  • the source-side Source synchronizes data to the target-side Target through full copying. After the target-side Target creates a database link between the target-side Target and the source-side Source, the target-side Target receives the data in the source-side Source database and loads it to the target-side Target. Database, after the migration is completed, step S6 is executed;
  • the source source obtains the redo log file or archive log of the database, processes part of the structure of the data acquisition log, and judges whether there is a data change in the log, if there is any data change, execute step S7, otherwise continue to obtain the log;
  • the source end Source obtains the log with data changes based on the transaction as the basic unit, and then analyzes the log, obtains the information of the changed data, and determines whether it is an object that needs to be protected. If it is, perform step S8, otherwise continue to perform step S6. Get new logs for analysis;
  • the source source obtains the changed data, generates corresponding DDL statements and DML statements, writes SQL statements into the cache in transaction units, records the SCN number when the transaction is committed, and executes step S9;
  • the source side Source obtains the SQL statement and SCN number from the cached data, and sends the SQL statement and SCN number to the target side Target through the network, and step S10 is executed;
  • the target receives the SQL statement and SCN number sent by the source through the network, writes the SQL statement into the cache directory, and executes step S11;
  • the target end Target executes the SQL statement through the OCI interface, synchronizes the data to the target end Target's database, and executes step S12;
  • the target end Target After the target end Target executes the SQL statement, it writes the SCN number into the configuration file.
  • the source side Source detects whether the instruction to stop the task is issued, if the stop instruction is not received , Then execute step S6, if a stop instruction is detected, execute step S13;
  • the source-side Source detects the instruction to end the task and sends it to the target-side Target.
  • the target-side Target ends the task after receiving the message, and sends a message that the target-side Target task ends to the source-side Source, and the source-side Source ends the task.
  • step S2 the source-side Source detects whether the running condition is satisfied according to the task options configured when the task is created, which may be:
  • step S3 the need to detect whether the environment meets the operating requirements may be:
  • the source-side Source sends parameters to the target-side Target and connects with the target-side Target. If the connection between the source-side Source and the target-side Target fails, return to step S2; otherwise, proceed to the next step;
  • the target side Target checks whether the selected database status is open, if the status is not open, then return to step S2, otherwise, proceed to the next step;
  • the target side Target detects whether the target side Target cache directory has read and write file permissions, and if not, returns to step S2, otherwise, proceeds to the next step.
  • the log parsing process mainly includes the following steps:
  • This application monitors the data changes of the logs in the production environment in real time, captures the logs with data changes, parses and generates SQL statements, and transmits them to the disaster recovery environment through the network, that is, synchronizes to the target end in real time, and the disaster recovery environment receives After SQL statements are loaded and executed, due to the real-time capture, analysis and synchronization of logs, the RPO and RTO are close to zero, ensuring the real-time consistency and availability of Oracle database data, and effectively reducing the RPO to close to zero.
  • both the production and disaster recovery databases are in an open state, and the disaster recovery data can be queried, and the validity of the data can be verified immediately; in addition, under normal circumstances, real-time replication is real-time capture Redo log, after executing the SQL statement on the target side, record the log sequence number and SCN number in the cache directory.
  • real-time replication stops or other reasons need to read the archive log, you can follow the recorded sequence number And SCN number to obtain archived logs, through the log serial number and SCN can further ensure the accuracy of the data.
  • the user can set the time period for the real-time replication task to run from the interface configuration.
  • the real-time replication software will synchronize the production data to the disaster recovery side within the specified time period.
  • the user independently designs the synchronization period.
  • real-time replication tasks are long-term monitoring tasks. When a task is abnormal, it can automatically try to restore the task to a normal state without human intervention; in addition, the console manages customers in the production environment and disaster recovery environment Terminal, the interface-based operation of the client makes it more convenient for users to operate real-time replication tasks; at the same time, the console can monitor the running status of tasks in real time, and users can understand the current execution of tasks through the console.
  • the source end occupies low CPU resources and memory resources, which will not affect the business of the source end production environment; while the real-time replication software can analyze and process about 1T logs per day, which can meet business needs. Will cause the accumulation of logs.
  • This application system sets the source end of the production environment and serves as the target end of the disaster recovery environment.
  • the disaster recovery environment can be used to replace the production environment, which can minimize data loss and economic loss And the reduction in productivity.
  • the real-time replication of this application supports two replication methods: user-level replication and table-level replication.
  • User-level replication refers to all the data objects such as tables, views, indexes, procedures, functions, packages, sequences, etc. contained in the specified user of the source database are replicated
  • table-level replication refers to copying a single table under the specified user of the source database to a single table under the specified user of the target database. It is suitable for various data such as disk placement data and cache data.

Landscapes

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

Abstract

一种持续数据保护系统及方法,所述系统包括服务端、客户端、源端、目标端、实际数据存储单元、重做日志和归档日志。所述服务端作为实时复制软件的控制台;所述客户端作为所述源端和所述目标端在实时复制软件的代理客户端;所述源端作为用户的生产环境端;所述目标端作为用户的灾备环境端;所述实际数据存储单元作为所述源端和所述目标端的数据库的实际数据存储单元;所述重做日志文件或所述归档日志,被配置为存放所有对所述数据库更改的操作记录及更改的数据。

Description

持续数据保护系统及方法
本公开要求在2020年03月16日提交中国专利局、申请号为202010182675.8的中国专利申请的优先权,以上申请的全部内容通过引用结合在本公开中。
技术领域
本申请涉及数据保护技术领域,例如涉及一种持续数据保护系统及方法。
背景技术
相关技术中,Oracle数据库备份为脱机备份,又被称为冷备份。在备份开始前,数据库必须彻底关闭,并且需要将数据库使用的每个文件都备份下来。Oracle数据库第6版推出了热备份的概念。这意味着数据库可以在执行备份的同时保持打开状态并处理事务,但必须将每个表空间放在特殊的备份模式中,然后才能复制OS文件。因此,DBA修改其脚本以连接到数据库,获取表空间列表,将每个表空间放在备份模式中,执行OS文件副本备份,最后从备份模式中取出表空间。
Oracle数据库的第8版推出了Oracle Recovery Manager,即RMAN,作为Oracle数据库的推荐备份方式。RMAN是随Oracle服务器一同安装的,可以用来备份和恢复数据库文件、归档日志和控制文件的工具,用来执行完全或不完全的数据库恢复。RMAN采用备份级别实现增量备份,在一个完整的备份基础上采用增量备份减少备份的数量。
相关技术中,常见的Oracle数据库的数据保护模式为定时备份,即周期性地将Oracle数据库中的数据备份到存储介质中,大部分采用RMAN备份。对于定时备份,需要周期性的全量备份,增量备份,归档日志备份,形成对应的时间点用于数据恢复,可以将数据恢复到历史的某个状态。该备份方式仅适用于对RPO(Recovery Point Object,复原点目标)和RTO(Recovery Time Objective,复原时间目标)要求不高的数据保护场景,对于其他场景则会导致Oracle定时备份的RPO和RTO偏大问题,进而无法保证Oracle数据库数据的实时一致性与可用性。此外,部分对Oracle数据库的数据保护模式采用磁盘卷复制的方式,然而这种方式是对整个数据卷保护,只复制落盘数据,无法处理缓存数据,会出现数据库一致性差等问题。
发明内容
本申请提供一种持续数据保护系统及方法,可以使RPO和RTO趋近于零,保证Oracle数据库数据的实时一致性与可用性。
本申请可以通过以下技术方案来实现:
一种持续数据保护系统,所述持续数据保护系统包括服务端、客户端、源端、目标端、实际数据存储单元、重做日志和归档日志;
其中,所述服务端作为实时复制软件的控制台,被配置为担负与用户交互的任务,同时统筹管理包括所述客户端在内的所有的资源;
所述客户端作为所述源端和所述目标端在实时复制软件的代理客户端,被配置为与所述服务端进行交互,接收所述服务端下达的实时复制任务的命令,并针对命令做出相应的处理,并将执行结果返回给所述服务端;
所述源端作为用户的生产环境端,被配置为在实时复制任务运行时,实时读取所述源端的数据库中的所述重做日志或所述归档日志,通过处理获取有数据变化的日志后,解析日志并生成SQL语句;
所述目标端作为用户的灾备环境端,被配置为接收来自所述源端的SQL语句并生成SQL文件,通过调用OCI在所述目标端的数据库中执行SQL语句;
所述实际数据存储单元作为所述源端和所述目标端的数据库的实际数据存储单元,所述实际数据存储单元被配置为在第一次发起任务时进行全量复制,并通过数据泵直接将所述源端的数据库中的数据同步到所述目标端的数据库中;
所述重做日志或所述归档日志被配置为存放所有对所述数据库更改的操作记录及更改的数据。
一种持续数据保护方法,用于如上所述的持续数据保护系统,所述持续数据保护方法包括:
当保护的生产环境需要达成RPO趋近于零的效果时,部署实时复制任务,设置一个生产环境端作为所述源端,设置一个灾备环境端作为所述目标端。
附图说明
图1为本申请在数据保护时各个角色及角色间关系的结构图;
图2为本申请发起实时复制任务及任务执行的流程图。
具体实施方式
下面结合附图和具体实施例对本申请进行详细说明。显然,所描述的实施例是本申请的一部分实施例,而不是全部实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都应属于本申请保护的范围。
本申请提出了一种基于解析Oracle日志的持续数据保护技术,通过实时监测生产环境中日志的数据变化情况,捕获有数据变化的日志并解析生成SQL(Structured Query Language,结构化查询语言)语句,通过网络传输到灾备环境中,灾备环境在接收到SQL语句后装载执行。由于对日志的实时捕获解析以及同步,使得RPO和RTO趋近于0,保证Oracle数据库数据的实时一致性与可用性。
如图1所示,本申请涉及一种基于解析Oracle日志的持续数据保护系统,可用于进行Oracle数据的保护,并满足客户低RPO及数据库一致的需求。该系统将生产环境上的数据实时复制到灾备环境中,从而达到Oracle数据库中数据的保护。其中,Source是实时复制过程中的源端,Target是实时复制过程中的目标端。
在本申请中,需要在源端和目标端分别安装Agent代理客户端。客户端Agent作为实时复制软件在源端和目标端的代理,负责与服务端Server进行交互,接收Server下达的命令,并针对命令做出相应的处理,并将执行结果返回给Server。
本申请中的Server作为实时复制软件的控制台,是实时复制软件的管理单元,担负和用户交互的任务。在Server中管理所有的资源,包括对Agent的管理。Server负责发送实时复制的任务的指令给对应的Agent,同时,接收Agent返回的执行结果,监控任务的执行情况。
本申请中的Source代表用户的生产环境。在实时复制任务运行时,源端实时读取数据库(Database)的重做日志(redo log)或归档日志(archive log),通过分析得到有数据变化的日志,该日志是以事务为基本单位。获取到有数据变化的日志后,解析日志并生成SQL语句。
本申请中的Target代表用户的灾备环境。目标端接收来自源端的SQL语句并生成SQL文件,通过调用OCI在目标端的数据库(Database)中执行SQL语句。
在本申请中,实际数据存储单元是源端和目标端数据库的实际数据存储单元。在第一次发起任务时,首先会进行全量复制,通过数据泵技术直接将源端 的数据库(Database)中的数据同步到目标端的数据库(Database)中。
在本申请中,redo log和archive log为数据库中的重做日志和归档日志,负责存放所有对数据库更改的操作和更改的数据。重做日志的个数和大小由数据库指定,采用循环复写的方式写入数据,当数据库开启归档模式时,在一个重做日志写满时,会进行归档,产生一个归档日志。
在本申请中,源端产生的SQL语句会经过TCP/IP网络协议传送到目标端,目标端接收到SQL语句后在目标端缓存目录中生成SQL文件。
在本申请中,当保护的生产环境需要达到RPO趋近于0的效果时,操作员可部署实时复制任务。该任务中需要一个生产环境,即为实例中的源端,还需要一个灾备环境,即为实例中的目标端。操作员发起任务时,按照以下步骤执行备份操作:
图2为发起数据保护任务时的任务流程示意图,实际当发起任务时,源端捕获日志,解析日志,生成SQL语句是多线程并发进行的,目标端接收SQL语句和执行SQL语句也是并发执行。图2中的流程可以为:
步骤1、操作员选择需要保护的数据源及对象,建立实时复制任务,并发起任务,执行步骤2。需要注意的是:操作员创建任务时可选择对用户或者表进行保护。且操作员创建任务时源端和目标端都需要选择缓存目录,用来存放需要记录的文件。
步骤2、任务启动后,源端根据创建任务时配置的任务选项检测是否满足运行条件。如果满足,即状态正常,则执行步骤3,如果状态异常,重复执行步骤2。
需要检测的选项包括:
检测需要保护实例的数据库状态是否为打开状态(即,open状态)。如果状态为非打开状态(非open状态),则重试;否则,进行下一步。
检测需要保护实例的数据库的模式是否为归档模式。如果状态为非归档模式,则重试;否则,进行下一步。
检测需要保护实例的数据库中的日志模式是否为强制记录模式,并且是否开启日志补全。如果不是,则重试;否则,进行下一步。
检测源端缓存目录是否有读写文件权限。如果没有,则重试;否则,进行下一步。
获取源端当前序列号及SCN号(系统修订号,System Change Number)。如 果获取失败,则重试;否则,进行下一步。
步骤3、源端将目标端所需要的参数发送至目标端,并且连接目标端,如果目标端连接成功,并且环境符合运行要求,则执行步骤4,否则重新开始执行步骤2。
在一实施例中,需要检测环境是否符合运行要求的选项包括:
源端向目标端发送参数,并与目标端连接。如果源端与目标端连接失败,则返回步骤2;否则,进行下一步。
目标端检查选择实例的数据库状态是否为open。如果状态为非open状态,则返回步骤2;否则,进行下一步。
目标端检测目标端缓存目录是否有读写文件权限。如果没有,则返回步骤2;否则,进行下一步。
步骤4、目标端获取上一次任务退出前记录的序列号及SCN号,且目标端将获取到的信息发送至源端,如果在目标端缓存目录中找不到记录序列号和SCN号的配置文件,那么目标端就向源端返回0。源端根据获取到的序列号判断是否进行全量。如果源端接收到目标端返回的数据不为0,并且能够使用序列号查询到日志,那么任务不需要进行全量复制,执行步骤6,否则执行步骤5。
步骤5、源端通过全量复制将数据同步至目标端。在目标端创建目标端到源端的数据库链接,然后在目标端接收源端数据库中的数据并装载至目标端数据库。迁移完成后,执行步骤6。
步骤6、源端获取数据库的重做日志或归档日志,通过分析日志的部分结构,判断该日志是否有数据变化,如果有数据变化则执行步骤7,否则继续获取日志。
步骤7、源端获取到有数据变化的日志,该日志以事务为基本单位。解析日志,获取变化数据的信息,根据获取到变化信息中的obj号在数据字典中查询表名及用户名,将查询到的表名和用户名与创建任务时选择的对象进行对比,判断是否是需要保护的对象。如果变化的数据属于需要被保护的对象,执行步骤8,否则继续执行步骤6,获取新的日志进行解析。
步骤8、源端获取到变化的数据,生成对应的DDL(库数据模式定义语言,Data Definition Language)语句和DML(数据操纵语言,Data Manipulation Language)语句,以事务为单位将SQL语句写入缓存中,并且记录事务提交时的SCN号,执行步骤9。
步骤9、源端从缓存中获取到SQL语句以及SCN号,将SQL语句和SCN 号通过网络发送到目标端,执行步骤10。
步骤10、目标端通过网络接收到源端发送的SQL语句以及SCN号,并将SQL语句写入缓存目录中,执行步骤11。
步骤11、目标端通过OCI(Oracle调用接口,Oracle Call Interface)接口执行SQL语句,将数据同步到目标端的数据库中,执行步骤12。
步骤12、目标端在执行完SQL语句后,将SCN号写入配置文件中,当任务异常停止或者手动停止后,下一次重新发起任务的时候,源端如果还存在该事务所在的日志时,解析可以直接从该事务的下一个事务处进行解析,无需进行全量复制。当完成将SCN号写入配置文件的操作后,源端检测操作员是否发出停止任务的指令。如果未接收到停止指令,执行步骤6,如果操作员发出停止指令,执行步骤13。
步骤13、源端检测到操作员发起的结束任务的指令,源端向目标端发送结束任务的消息,目标端接收到结束任务的消息后,结束任务,并向源端发出目标端任务结束的消息,源端结束任务。
需要说明的是,本申请中的日志的解析技术主要的内容如下:
1、众所周知,日志的逻辑结构包括以下三个部分:
a.改变向量(change vector):表示对数据库内某一个数据块所做的一次变更。包含了事务操作代码、变更从属数据块的地址以及更新后的数据。
b.重做记录(redo record):由一组改变向量组成,是一个改变向量的集合,代表一个数据库的变更(insert、update、delete等操作),构成数据库变更的最小恢复单位。
c.事务:是一组包含一条或多条语句的逻辑单元,每个事务都是一个原子单元。一个事务中包含多个重做记录。
Oracle日志文件是二进制格式文件,是由若干个指定大小的数据块组成的。在不同的操作系统上,块的大小是不同的,可以是512bytes,也可以是1K、2K等。日志文件的第一块是文件头,文件头中存储日志文件的数据块大小以及数据块的数量。日志文件的第二块重做日志头,该块中存储的是数据库相关信息,其中包括数据库ID,数据库名称,线程号等信息。
从第二块起,每个数据块都有16字节数据头,包括当前数据块的编号,当前日志的序列号及偏移量,是当前数据块中,第一个重做记录(redo record)开始的位置。
从第三个数据块开始,使用record结构记录Oracle的操作信息。Record包括record header和若干个change组成。
Record header中包括了LEN,VLD,RBA等参数。LEN是record结构的长度。VLD参数决定了record header的长度,可以通过已有的VLD含义来解析出对应的长度。RBA是重做记录地址,由日志序列号,数据块号,在数据块内的偏移量组成,通过RBA可以快速定位recode在日志内的位置。
Change又分为change header,change length list和change body。
Change header的长度为24字节。Change header中包括OP,SCN等参数。OP是change的操作码,表示Oracle不同的数据操作。SCN是系统改变号,是在某个时间点定义数据库已提交版本的时间戳标记。
Change body根据change header中OP的不同拥有不同的结构。常见的操作码OP5.2是修改回滚段的头,是一个事务的开始。OP5.1为存储数据库操作前的旧数据。OP11.2记录插入(insert)数据的详细信息。OP11.3记录删除(delete)数据的详细信息。OP11.5记录更改(update)数据的详细信息。OP24.1记录DDL语句。OP5.4记录事务提交信息,是一个事务的结束。每个Change body中均存在XID字段,XID是事务的标识符。
2、对于日志的解析,本申请采用以下方法实现:
以事务为基本单位获取有数据变化的日志,获取时使用XID参数区分。事务中需存在OP5.2,OP5.1,OP5.4,OP11.*或OP24.1。以update操作为例分析解析过程:
a.在change参数OP=5.1的日志中获取OBJ参数,根据OBJ在数据字典中查询表所属的用户,表名以及表的列信息。
b.在change参数OP=5.1的日志中获取修改之前的列号以及二进制数据。数据在日志中按照顺序存储,可通过列号判断改数据所属的列。
c.在change参数OP=11.5的日志中获取修改之后的列号以及二进制数据。
d.将获取到的二进制数据根据列类型解析为该类型的数据。
e.将解析出的数据,用户名,表名等信息拼接成SQL语句。
本申请通过实时监测生产环境中日志的数据变化情况,捕获有数据变化的日志并解析生成SQL语句,通过网络传输到灾备环境中,即实时同步至目标端,灾备环境在接收到SQL语句后装载执行,由于对日志的实时捕获解析以及同步,使得RPO和RTO趋近于0,保证Oracle数据库数据的实时一致性与可用性,有 效降低RPO至趋近于0的效果。
本申请提供一种基于解析Oracle日志的持续数据保护系统,该方法用于实现Oracle数据的保护,同时满足客户低RPO及数据库一致的需求场景,可以包括:
服务端Server,作为实时复制软件的控制台,用于担负与用户交互的任务,同时统筹管理包括客户端Agent在内的所有的资源。所述的服务端Server主要负责发送实时复制的任务的指令给对应的客户端Agent,同时负责接收Agent返回的执行结果,监控任务的执行情况。
客户端Agent,作为源端和目标端在实时复制软件的代理客户端,用于负责与Server进行交互,接收Server下达的实时复制任务的命令,并针对命令做出相应的处理,并将执行结果返回给Server。
源端Source,作为用户的生产环境端,用于在实时复制任务运行时,实时读取其Database的重做日志文件或归档日志,通过处理获取有数据变化的日志后,解析日志并生成SQL语句;所述的源端Source所获取的有数据变化的日志为以事务为基本单位的日志。源端Source产生的SQL语句通过TCP/IP网络协议传送到目标端Target,目标端Target接收到SQL语句后在目标端Target缓存目录中生成SQL文件。
目标端Target,作为用户的灾备环境端,用于接收来自源端Source的SQL语句并生成SQL文件,通过调用OCI在目标端Target的Database中执行SQL语句。
数据库的实际数据存储单元,作为源端Source和目标端Target数据库的实际数据存储单元,用于在第一次发起任务时进行全量复制,并通过数据泵直接将源端Source的数据库Database中的数据同步到目标端Target的数据库Database中。
重做日志文件或归档日志,用于负责存放所有对数据库更改的操作记录及更改的数据。重做日志文件的个数和大小由数据库指定,采用循环复写的方式写入数据,当数据库开启归档模式时,在一个重做日志文件写满时则进行归档,产生一个归档日志文件。
当发起任务时,源端Source捕获日志,解析日志,生成SQL语句为多线程并发进行,目标端Target接收SQL语句及执行SQL语句为并发执行。
本申请还提供了一种持续数据保护方法,该方法的主要内容为:
当保护的生产环境需要达成RPO趋近于0的效果时,部署实时复制任务,设置一个生产环境端作为源端Source,设置一个灾备环境端作为目标端Target。
所述实时复制任务按照如下步骤执行备份操作:
S1、选择需要保护的数据源及对象,建立实时复制任务,并发起任务,执行下一步;
S2、任务启动后,源端Source根据创建任务时配置的任务选项检测是否满足运行条件,若满足,则执行下一步,否则,重复执行本步骤;
S3、源端Source将目标端Target所需的参数发送至目标端Target,并连接目标端Target,若目标端Target连接成功,且环境符合运行要求,则执行步骤S4,否则重新开始执行步骤S2;
S4、目标端Target获取上一次任务退出前记录的序列号及SCN号,并将获取的信息发送至源端Source,若在目标端Target缓存目录中找不到记录序列号和SCN号的配置文件,则目标端Target向源端Source返回结果0,源端Source根据获取的序列号判断是否进行全量,若源端Source接收到目标端Target返回的数据不为0,且能够利用序列号查询到日志,则任务不需要进行全量复制,执行步骤S6,否则执行步骤S5;
S5、源端Source通过全量复制将数据同步至目标端Target,在目标端Target创建目标端Target到源端Source的数据库链接后,目标端Target接收源端Source数据库中的数据并装载至目标端Target数据库,迁移完成后,执行步骤S6;
S6、源端Source获取数据库的重做日志文件或归档日志,处理数据获取日志的部分结构,并判断该日志是否有数据变化,若有,则执行步骤S7,否则继续获取日志;
S7、源端Source获取以事务为基本单位的有数据变化的日志后进行日志解析,获取变化数据的信息,判断其是否是需要保护的对象,若是,则执行步骤S8,否则继续执行步骤S6,获取新的日志进行解析;
S8、源端Source获取到变化的数据,生成对应的DDL语句和DML语句,以事务为单位将SQL语句写入缓存中,并记录事务提交时的SCN号,执行步骤S9;
S9、源端Source从缓存数据中获取SQL语句及SCN号,将SQL语句和SCN号通过网络发送至目标端Target,执行步骤S10;
S10、目标端Target通过网络接收到源端Source发送的SQL语句以及SCN号,并将SQL语句写入缓存目录中,执行步骤S11;
S11、目标端Target通过OCI接口执行SQL语句,将数据同步到目标端Target的数据库中,执行步骤S12;
S12、目标端Target在执行完SQL语句后,将SCN号写入配置文件中,当任务异常停止或手动停止后,下一次重新发起任务时,源端Source若还存在该事务所在的日志时,则直接从该事务的下一个事务处进行解析,无需进行全量复制,当完成将SCN号写入配置文件的操作后,源端Source检测是否停止任务的指令是否发出,若未接收到停止指令,则执行步骤S6,若检测出停止指令,执行步骤S13;
S13、源端Source检测到结束任务的指令后发送至目标端Target,目标端Target接收消息后结束任务,并向源端Source发出目标端Target任务结束的消息,源端Source结束任务。
在一实施例中,步骤S2中,源端Source根据创建任务时配置的任务选项检测是否满足运行条件可以为:
检测需要保护的数据库状态是否为open,若否,则重试;否则,进行下一步;
检测需要保护的数据库的模式是否为归档模式,若不是,则重试;否则,进行下一步;
检测需要保护的数据库中的日志模式是否为强制记录模式,并且是否开启日志补全,若不是,则重试;否则,进行下一步;
检测源端Source缓存目录是否有读写文件权限,若没有,则重试;否则,进行下一步;
获取源端Source当前序列号及SCN号,若获取失败,则重试;否则,进行下一步。
在一实施例中,步骤S3中,需要检测环境是否符合运行要求可以为:
源端Source向目标端Target发送参数,并与目标端Target连接,若源端Source与目标端Target连接失败,则返回步骤S2;否则,进行下一步;
目标端Target检查选择的数据库状态是否为open,若状态为非open状态,则返回步骤S2,否则,进行下一步;
目标端Target检测目标端Target缓存目录是否有读写文件权限,若没有, 则返回步骤S2,否则,进行下一步。
在一实施例中,日志的解析过程主要包括如下步骤:
以事务为基本单位获取有数据变化的日志,获取时使用XID参数区分。事务中需存在OP5.2,OP5.1,OP5.4,OP11.*或OP24.1。以update操作为例分析解析过程:
a.在change参数OP=5.1的日志中获取OBJ参数,根据OBJ在数据字典中查询表所属的用户,表名以及表的列信息。
b.在change参数OP=5.1的日志中获取修改之前的列号以及二进制数据。数据在日志中按照顺序存储,可通过列号判断改数据所属的列。
c.在change参数OP=11.5的日志中获取修改之后的列号以及二进制数据。
d.将获取到的二进制数据根据列类型解析为该类型的数据。
e.将解析出的数据,用户名,表名等信息拼接成SQL语句。
与相关技术相比,本申请具有以下优点:
1)本申请通过实时监测生产环境中日志的数据变化情况,捕获有数据变化的日志并解析生成SQL语句,通过网络传输到灾备环境中,即实时同步至目标端,灾备环境在接收到SQL语句后装载执行,由于对日志的实时捕获解析以及同步,使得RPO和RTO趋近于0,保证Oracle数据库数据的实时一致性与可用性,有效降低RPO至趋近于0的效果。
2)本申请在实时复制时,对日志的整合和传输以事务为单位,无需处理复杂的回滚机制,在拥有高性能的同时还能够更好的保证数据复制的一致性和完整性;此外,实时复制不需要等待重做日志文件归档后再进行日志读取等操作,而是直接读取日志的数据块内容,捕获日志和Oracle数据库写日志是并行操作而不互相影响。
3)在实时复制任务运行期间,生产端与灾备端数据库均处于open状态,灾备端数据能够实现查询,即时验证数据的有效性;此外,在正常情况下,实时复制都是实时的捕获重做日志,在目标端执行完SQL语句后,在缓存目录中记录日志序列号及SCN号,在日常运行过程中,实时复制停止或其它原因需要读取归档日志时,可根据记录的序列号及SCN号获取归档日志,通过日志序列号和SCN可进一步保证数据的准确性。
4)对于本申请的实时复制任务,用户可以从界面配置中设置实时复制任务运行的时间段,实时复制软件会在指定时间段内将生产端数据同步至灾备端, 用户自主设计同步时段,达到避开业务高峰期;实时复制任务是长期监控的任务,当任务出现异常时,无需人为干预,可自动尝试将任务恢复至正常状态;此外,控制台管理生产环境和灾备环境上的客户端,界面化操作客户端的方式,使用户操作实时复制任务更加便捷;同时,控制台可以实时监控任务的运行状态,用户可通过控制台了解任务当前执行情况。
5)本申请在增量复制过程中,源端占用CPU资源及内存资源低,不会影响源端生产环境的业务;而实时复制软件每天大约可分析处理1T左右日志,可满足业务需求,不会造成日志的累积。
6)本申请系统设置了生产环境的源端,以及作为灾备环境的目标端,源端生产环境出现宕机时,可以使用灾备环境替代生产环境,能够最大限度地减少数据丢失、经济损失以及生产力的降低。
7)本申请在实时复制过程中,可过滤掉生产环境删除用户或者删除表的操作,当遇到这些操作时,目标端不会执行删除操作,而是将表或者用户进行重命名操作,进而防止当用户误操作删除用户或者表时,用户和表无法恢复,有利于保证数据的完整性和安全性。
8)本申请的实时复制支持用户级复制和表级复制两种复制方式,用户级复制指源端数据库指定用户所包含的表、视图、索引、过程、函数、包、序列等数据对象全部复制到目标端数据库指定的用户下,同时,用户级复制支持源端用户名和目标端用户名不同;表级复制指源端数据库指定用户下的单个表复制到目标端数据库指定用户下的单个表,适用于落盘数据、缓存数据等各种数据。

Claims (10)

  1. 一种持续数据保护系统,所述持续数据保护系统包括服务端、客户端、源端、目标端、实际数据存储单元、重做日志和归档日志;
    其中,所述服务端作为实时复制软件的控制台,被配置为担负与用户交互的任务,同时统筹管理包括所述客户端在内的所有的资源;
    所述客户端作为所述源端和所述目标端在实时复制软件的代理客户端,被配置为与所述服务端进行交互,接收所述服务端下达的实时复制任务的命令,并针对命令做出相应的处理,并将执行结果返回给所述服务端;
    所述源端作为用户的生产环境端,被配置为在实时复制任务运行时,实时读取所述源端的数据库中的所述重做日志或所述归档日志,通过处理获取有数据变化的日志后,解析日志并生成SQL语句;
    所述目标端作为用户的灾备环境端,被配置为接收来自所述源端的SQL语句并生成SQL文件,通过调用OCI在所述目标端的数据库中执行SQL语句;
    所述实际数据存储单元作为所述源端和所述目标端的数据库的实际数据存储单元,所述实际数据存储单元被配置为在第一次发起任务时进行全量复制,并通过数据泵直接将所述源端的数据库中的数据同步到所述目标端的数据库中;
    所述重做日志或所述归档日志被配置为存放所有对所述数据库更改的操作记录及更改的数据。
  2. 根据权利要求1所述的持续数据保护系统,其中,所述源端所获取的有数据变化的日志为以事务为基本单位的日志。
  3. 根据权利要求1所述的持续数据保护系统,其中,所述源端产生的SQL语句为通过TCP/IP网络协议传送到所述目标端,所述目标端接收到所述SQL语句后在所述目标端的缓存目录中生成SQL文件。
  4. 根据权利要求1所述的持续数据保护系统,其中,所述服务端被配置为发送实时复制的任务的指令给对应的所述客户端,同时接收所述客户端返回的执行结果,监控任务的执行情况。
  5. 根据权利要求1所述的持续数据保护系统,其中,所述重做日志的个数和大小由所述数据库指定,所述重做日志为采用循环复写的方式写入数据,当所述数据库开启归档模式时,基于一个所述重做日志写满的判断结果,进行归档并产生一个归档日志。
  6. 根据权利要求3所述的持续数据保护系统,其中,当发起任务时,所述源端捕获日志,解析日志,生成SQL语句为多线程并发进行,所述目标端接收 SQL语句及执行SQL语句为并发执行。
  7. 一种持续数据保护方法,用于如权利要求1~6任一项所述的持续数据保护系统,所述持续数据保护方法包括:
    当保护的生产环境需要达成RPO趋近于零的效果时,部署实时复制任务,设置一个生产环境端作为所述源端,设置一个灾备环境端作为所述目标端。
  8. 根据权利要求7所述的持续数据保护方法,其中,所述实时复制任务为按照如下步骤执行备份操作:
    1)选择需要保护的数据源及对象,建立实时复制任务,并发起任务,执行下一步;
    2)任务启动后,所述源端根据创建任务时配置的任务选项检测是否满足运行条件,基于满足运行条件的检测结果,执行下一步,基于不满足运行条件的检测结果,重复执行本步骤;
    3)所述源端将所述目标端所需的参数发送至所述目标端,并连接所述目标端,基于所述源端与所述目标端连接成功,且环境符合运行要求的判断结果,执行步骤4),基于所述源端与所述目标端连接失败,或环境不符合运行要求的判断结果,重新开始执行步骤2);
    4)所述目标端获取上一次任务退出前记录的序列号及SCN号,并将获取的信息发送至所述源端,基于在所述目标端缓存目录中找不到记录序列号和SCN号的配置文件的判断结果,所述目标端向所述源端返回结果0,所述源端根据获取的序列号判断是否进行全量,基于所述源端接收到所述目标端返回的数据不为0,且能够利用序列号查询到日志的判断结果,任务不需要进行全量复制,执行步骤6),基于所述源端接收到所述目标端返回的数据为0,或不能够利用序列号查询到日志的判断结果,执行步骤5);
    5)所述源端通过全量复制将数据同步至所述目标端,在所述目标端创建所述目标端到所述源端的数据库链接后,所述目标端接收所述源端数据库中的数据并装载至所述目标端数据库,迁移完成后,执行步骤6);
    6)所述源端获取所述数据库的重做日志或归档日志,处理所述数据获取日志的部分结构,并判断该日志是否有数据变化,基于该日志有数据变化的判断结果,执行步骤7),基于该日志没有数据变化的判断结果,继续获取日志;
    7)所述源端获取以事务为基本单位的有数据变化的日志后进行日志解析,获取变化数据的信息,判断变化数据是否是需要保护的对象,基于变化数据是 需要保护的对象的判断结果,执行步骤8),基于变化数据不是需要保护的对象的判断结果,继续执行步骤6),获取新的日志进行解析;
    8)所述源端获取到变化的数据,生成对应的DDL语句和DML语句,以事务为单位将SQL语句写入缓存中,并记录事务提交时的SCN号,执行步骤9);
    9)所述源端从缓存数据中获取SQL语句及SCN号,将SQL语句和SCN号通过网络发送至所述目标端,执行步骤10);
    10)所述目标端通过网络接收到所述源端发送的SQL语句以及SCN号,并将SQL语句写入缓存目录中,执行步骤11);
    11)所述目标端通过OCI接口执行SQL语句,将数据同步到所述目标端的数据库中,执行步骤12);
    12)所述目标端在执行完SQL语句后,将SCN号写入配置文件中,当任务异常停止或手动停止后,下一次重新发起任务时,基于所述源端还存在异常停止或手动停止的任务对应的事务所在的日志的判断结果,所述源端直接从该事务的下一个事务处进行解析,无需进行全量复制,当完成将SCN号写入配置文件的操作后,所述源端检测停止任务的指令是否发出,基于未接收到停止指令的检测结果,执行步骤6),基于检测出停止指令的检测结果,执行步骤13);
    13)所述源端检测到结束任务的指令后发送至所述目标端,所述目标端接收消息后结束任务,并向所述源端发出所述目标端任务结束的消息,所述源端结束任务。
  9. 根据权利要求8所述的持续数据保护方法,其中,步骤2)中,所述源端根据创建任务时配置的任务选项检测是否满足运行条件为:
    检测需要保护的数据库状态是否为打开状态,基于需要保护的数据库状态不为打开状态的检测结果,进行重试;基于需要保护的数据库状态为打开状态的检测结果,进行下一步;
    检测需要保护的数据库的模式是否为归档模式,基于需要保护的数据库的模式不为归档模式的检测结果,进行重试;基于需要保护的数据库的模式为归档模式的检测结果,进行下一步;
    检测需要保护的数据库中的日志模式是否为强制记录模式,并且是否开启日志补全,基于需要保护的数据库中的日志模式不为强制记录模式,或者未开启日志补全的检测结果,进行重试;基于需要保护的数据库中的日志模式为强制记录模式,并且开启日志补全的检测结果,进行下一步;
    检测所述源端缓存目录是否有读写文件权限,基于所述源端缓存目录没有读写文件权限的检测结果,进行重试;基于所述源端缓存目录有读写文件权限的检测结果,进行下一步;
    获取所述源端当前序列号及SCN号,基于获取失败的判断结果,进行重试;基于获取成功的判断结果,进行下一步。
  10. 根据权利要求8所述的持续数据保护方法,其中,步骤3)中,需要检测环境是否符合运行要求为:
    所述源端向所述目标端发送参数,并与所述目标端连接,基于所述源端与所述目标端连接失败的判断结果,返回步骤2);基于所述源端与所述目标端连接成功的判断结果,进行下一步;
    所述目标端检查选择的数据库状态是否为打开状态,基于选择的数据库状态为非打开状态状态的检查结果,返回步骤2),基于选择的数据库状态为打开状态状态的检查结果,进行下一步;
    所述目标端检测所述目标端缓存目录是否有读写文件权限,基于所述目标端缓存目录没有读写文件权限的检测结果,返回步骤2),基于所述目标端缓存目录有读写文件权限的检测结果,进行下一步。
PCT/CN2020/110500 2020-03-16 2020-08-21 持续数据保护系统及方法 WO2021184679A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010182675.8A CN111427898A (zh) 2020-03-16 2020-03-16 一种基于解析Oracle日志的持续数据保护系统及方法
CN202010182675.8 2020-03-16

Publications (1)

Publication Number Publication Date
WO2021184679A1 true WO2021184679A1 (zh) 2021-09-23

Family

ID=71553559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/110500 WO2021184679A1 (zh) 2020-03-16 2020-08-21 持续数据保护系统及方法

Country Status (2)

Country Link
CN (1) CN111427898A (zh)
WO (1) WO2021184679A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115437881A (zh) * 2022-08-25 2022-12-06 北京万里开源软件有限公司 一种基于用户态文件系统的数据库进程异常处理方法
CN115712582A (zh) * 2023-01-06 2023-02-24 大熊集团有限公司 一种数据缓存的方法及装置
CN116821100A (zh) * 2023-07-20 2023-09-29 广州云臻数据科技有限公司 一种基于双态协同的数据库高保真迁移方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111427898A (zh) * 2020-03-16 2020-07-17 上海爱数信息技术股份有限公司 一种基于解析Oracle日志的持续数据保护系统及方法
CN112181992A (zh) * 2020-10-27 2021-01-05 浪潮云信息技术股份公司 一种oracle数据库增量数据采集实现方法
CN113515573B (zh) * 2021-05-08 2023-01-17 上海英方软件股份有限公司 一种oracle数据库一对多协商复制断点的方法及系统
CN113704213A (zh) * 2021-08-20 2021-11-26 辽宁振兴银行股份有限公司 一种基于sqlldr2和ogg数据同步的实现方法
CN116701063B (zh) * 2023-08-07 2023-10-20 北京大学 数联网数据语用内存状态数据的持久化方法、装置及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102710752A (zh) * 2012-05-13 2012-10-03 徐州易存信息技术有限公司 灾备存储系统
CN103455557A (zh) * 2013-08-08 2013-12-18 上海新炬网络技术有限公司 一种基于日志的结构化数据同步方法
CN107368505A (zh) * 2016-05-11 2017-11-21 邓方 一种数据库实时增量复制软件中利用Apriori算法对并行入库进行智能分组优化的技术
CN110704242A (zh) * 2019-09-24 2020-01-17 上海爱数信息技术股份有限公司 一种基于Oracle日志捕获的连续数据保护系统及方法
CN111427898A (zh) * 2020-03-16 2020-07-17 上海爱数信息技术股份有限公司 一种基于解析Oracle日志的持续数据保护系统及方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104346454B (zh) * 2014-10-30 2017-12-05 上海新炬网络技术有限公司 基于Oracle数据库的数据一致性校验方法
CN110543513B (zh) * 2018-05-29 2024-03-15 金篆信科有限责任公司 分布式数据库增量数据同步方法、设备及存储介质
CN110727548B (zh) * 2019-09-29 2022-03-04 上海英方软件股份有限公司 一种基于数据库dml同步的持续数据保护方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102710752A (zh) * 2012-05-13 2012-10-03 徐州易存信息技术有限公司 灾备存储系统
CN103455557A (zh) * 2013-08-08 2013-12-18 上海新炬网络技术有限公司 一种基于日志的结构化数据同步方法
CN107368505A (zh) * 2016-05-11 2017-11-21 邓方 一种数据库实时增量复制软件中利用Apriori算法对并行入库进行智能分组优化的技术
CN110704242A (zh) * 2019-09-24 2020-01-17 上海爱数信息技术股份有限公司 一种基于Oracle日志捕获的连续数据保护系统及方法
CN111427898A (zh) * 2020-03-16 2020-07-17 上海爱数信息技术股份有限公司 一种基于解析Oracle日志的持续数据保护系统及方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115437881A (zh) * 2022-08-25 2022-12-06 北京万里开源软件有限公司 一种基于用户态文件系统的数据库进程异常处理方法
CN115437881B (zh) * 2022-08-25 2023-03-28 北京万里开源软件有限公司 一种基于用户态文件系统的数据库进程异常处理方法
CN115712582A (zh) * 2023-01-06 2023-02-24 大熊集团有限公司 一种数据缓存的方法及装置
CN116821100A (zh) * 2023-07-20 2023-09-29 广州云臻数据科技有限公司 一种基于双态协同的数据库高保真迁移方法
CN116821100B (zh) * 2023-07-20 2023-12-22 广州云臻数据科技有限公司 一种基于双态协同的数据库高保真迁移方法

Also Published As

Publication number Publication date
CN111427898A (zh) 2020-07-17

Similar Documents

Publication Publication Date Title
WO2021184679A1 (zh) 持续数据保护系统及方法
US7636741B2 (en) Online page restore from a database mirror
US7996363B2 (en) Real-time apply mechanism in standby database environments
US10120767B2 (en) System, method, and computer program product for creating a virtual database
JP4598821B2 (ja) データベース復旧中のスナップショットクエリのためのシステムおよび方法
US7103619B1 (en) System and method for automatic audit data archiving within a remote database backup system
US7822726B1 (en) Encapsulation of storage object extensibility records for backup and restore
US7933872B2 (en) Database backup, refresh and cloning system and method
US7596713B2 (en) Fast backup storage and fast recovery of data (FBSRD)
US6983295B1 (en) System and method for database recovery using a mirrored snapshot of an online database
US20170322993A1 (en) Controlling a multi-database system
US20060129618A1 (en) Method and a computer system for synchronising backups of objects and of meta data about the objects
CN110727548B (zh) 一种基于数据库dml同步的持续数据保护方法及装置
US20090024674A1 (en) Automatic file versioning
CN110704242B (zh) 一种连续数据保护系统及方法
JP7108782B2 (ja) データリカバリー方法、装置、サーバ及びコンピュータ・プログラム
US7058662B2 (en) Maintenance of data integrity during transfer among computer networks
EP3822794B1 (en) Data backup method and apparatus, server and computer readable storage medium
US11704335B2 (en) Data synchronization in a data analysis system
US20230401128A1 (en) Backup recovery system and method for oracle database
US20040098394A1 (en) Localized intelligent data management for a storage system
CN115729749A (zh) 一种数据备份方法及系统
US9811542B1 (en) Method for performing targeted backup
US11301341B2 (en) Replication system takeover with handshake
WO2022135690A1 (en) Method and device for backing up file system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20925298

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20925298

Country of ref document: EP

Kind code of ref document: A1