CN107766502B - Oracle RAC database disaster recovery switching drilling method - Google Patents
Oracle RAC database disaster recovery switching drilling method Download PDFInfo
- Publication number
- CN107766502B CN107766502B CN201710982422.7A CN201710982422A CN107766502B CN 107766502 B CN107766502 B CN 107766502B CN 201710982422 A CN201710982422 A CN 201710982422A CN 107766502 B CN107766502 B CN 107766502B
- Authority
- CN
- China
- Prior art keywords
- database
- switching
- disaster recovery
- library
- service
- 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.)
- Active
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 87
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000005553 drilling Methods 0.000 title claims abstract description 38
- 238000004519 manufacturing process Methods 0.000 claims abstract description 56
- 238000012544 monitoring process Methods 0.000 claims abstract description 17
- 238000002360 preparation method Methods 0.000 claims abstract description 15
- 238000012360 testing method Methods 0.000 claims abstract description 5
- 238000004140 cleaning Methods 0.000 claims description 7
- 238000007689 inspection Methods 0.000 claims description 7
- 230000002159 abnormal effect Effects 0.000 claims description 6
- 238000013515 script Methods 0.000 claims description 6
- 238000011112 process operation Methods 0.000 claims description 3
- 230000006870 function Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000007405 data analysis Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/1458—Management of the backup or restore process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/82—Solving problems relating to consistency
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)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
The invention discloses an Oracle RAC database disaster recovery switching drilling method, which comprises the following steps: s1) firstly, carrying out early-stage preparation check on the data synchronization condition between production and disaster recovery databases, the database backup execution condition, the key parameters of the databases related to switching, the database monitoring ports and the disaster recovery network state; s2), checking preparation before switching, and terminating subsequent planning if the switching condition cannot be met; s3) executing role switching between the production library and the disaster recovery library; s4) service checking and operation after switching; s5), providing service through disaster recovery system, if need to do switch-back test, continuing to prepare before switch-back, judging to meet switch-back condition, then making database role switch-back, and making service check and operation after switch-back. The invention can ensure that the production and disaster recovery databases can be normally switched during the disaster recovery drilling, reduce the service interruption time and avoid various error problems which are easy to occur in the disaster recovery drilling process.
Description
Technical Field
The invention relates to a database disaster tolerance drilling method, in particular to an Oracle RAC (Real Application Cluster) database disaster tolerance switching drilling method.
Background
Disaster recovery drilling refers to a process of simulating various emergency situations by using some specific methods and organizing IT personnel to handle various system service recovery. After the disaster recovery system is constructed, the disaster recovery drill is required to be performed immediately to test the effectiveness of the disaster recovery system. In an environment using an Oracle RAC architecture database as an enterprise core business system, an Oracle Active DataGuard (ADG) technology is mostly used as an implementation method of a disaster recovery system. The ADG can realize automatic synchronization and application of data from the production database to the disaster recovery database, and when a disaster event occurs in the production database (primary database) or disaster recovery switching drilling is performed, roles of production and the disaster recovery database (backup database) can be exchanged manually or by a script or the like.
The existing general treatment method is as follows:
1. and directly switching between the production of the business system and the disaster tolerance database by using an Oracle Active Dataguard command line or a DG browser component for switching.
2. The database service function and the disaster recovery function share a network port.
3. Before the drill, the business department is required to stop the application connection in a matching way.
The method is generally suitable for the conditions of low business busy degree and single business type, but the switching process between production and a disaster tolerance database during disaster tolerance drilling cannot be ensured to be smoothly carried out under the business scene of high data volume and high business pressure at the level above TB and the mixed business type of simultaneous online transaction processing and data analysis, and even the original normal business processing can be influenced.
The main disadvantages of the prior art are as follows:
once, the database role switching is performed directly, operation failure often occurs.
The overall process of the Oracle Active Dataguard command line or DG browser component for producing and switching the roles of the disaster tolerance database is as follows: 1. the remote connection on the production system is interrupted, 2, the ongoing affairs on the production database are terminated and rolled back, 3, all logs of the production database are transmitted to the disaster recovery database, 4, the production system database is closed, 5, the logs of the production system are applied to the disaster recovery system database, 6, the role conversion is carried out, and the original disaster recovery system database is converted into a new production system. In a database environment with high load and heavy traffic, the database of the production system cannot be normally closed due to various factors such as the fact that the traffic connection cannot be interrupted and the transaction cannot be finished in a short time, and the like, so that the processing of the steps 1, 2 and 4 is directly influenced, and the role switching process cannot be smoothly completed. In some cases, the production database is suspended or even automatically restarted, and then a lot of time is spent on repairing, so that the drilling operation cannot be completed within the specified time.
And secondly, sharing a network port by the database service function and the disaster recovery function.
The default is that the network monitoring port of the Oracle database providing external service is 1521, and the Oracle Active Dataguard also uses the port to perform data synchronization operation between the production and disaster recovery databases. In this case, the newly generated database connection during the switching cannot be blocked by closing the port, and the new connection generated continuously will affect the normal closing of the database.
And thirdly, the business department before the drill cooperates with the shortage of stopping the application.
Generally, in order to perform a drilling smoothly, a coordination business department first stops business in the early stage of the drilling, so that the stopping and switching of database services are facilitated. However, the method has the following disadvantages: 1. due to the numerous application modules, the application servers may be very numerous and distributed, it is difficult to terminate the application connection completely, and it is difficult to predict which portion of the traffic has not been stopped. 2. The purpose of this operation is only to enable the database role to be smoothly switched, but the database role does not necessarily conform to the real scene requiring role switching, and the role of switching the drilling work cannot be really played.
Disclosure of Invention
The invention aims to solve the technical problem of providing an Oracle RAC database disaster recovery switching drilling method, which can ensure that production and a disaster recovery database can be normally switched during the disaster recovery drilling process, and avoid various error problems easy to occur in the disaster recovery drilling process; meanwhile, the interruption time of the service is reduced, and the continuity of the service is improved.
The technical scheme adopted by the invention for solving the technical problems is to provide an Oracle RAC database disaster recovery switching drilling method, which comprises the following steps: s1) firstly, carrying out early-stage preparation check on the data synchronization condition between production and disaster recovery databases, the database backup execution condition, the key parameters of the databases related to switching, the database monitoring ports and the disaster recovery network state; s2), checking preparation before switching, if abnormal, judging whether the rectification can be completed within a specified time, if the switching condition can not be met, terminating the subsequent plan; s3) executing role switching between the production library and the disaster recovery library; s4) service checking and operation after switching; s5) providing service for the outside through the disaster recovery system, if the back switching is not needed, the drilling work is finished; if the switchback test is needed, preparation before switchback is continuously carried out, database role switchback is carried out after the switchback condition is judged to be met, and operation is carried out after service inspection and switching.
In the above Oracle RAC database disaster recovery switching drilling method, step S2 checks the remote connection, two-stage transaction, database operation and background task existing in the production database before switching; when external service connections of all databases need to be shielded, a monitoring port responsible for service connections is closed, and an independent monitoring port is used for data synchronization between production and disaster recovery databases; meanwhile, the checking and killing conversation process operation is executed in batch in a mode of storing the process or SQL scripts.
In the method for practicing disaster recovery switching in the Oracle RAC database, the step S2 sequentially checks the following steps according to the time sequence: checking data consistency according to ADG and present network time difference, monitoring state check, main and standby library log group quantity, parameter check required to restart, rollback state check, main library check log application status, standby library check log application status, database filing configuration check, stopping database statistics collection service, database password file comparison, checking whether Temp files are matched, whether data files are online, confirming that sum of filing path quantity and thread quantity/example quantity of production database is set to be 4 or more, checking whether parameter dg _ broker _ start is closed, confirming whether current ADG is configured to be maximum performance mode, confirming main library ADG role/state, confirming standby library ADG role/state, whether database is in force logging state, whether alter log is abnormal, checking before system resource switching, checking correlation database/memory database and before middleware switching, checking whether the ADG is configured to be maximum performance mode, checking whether the ADG role/state of main library is in force logging state, checking whether alter log is abnormal, checking system resource switching resource before switching, checking correlation database/memory database and middleware switching, Stopping batch service, stopping background service, stopping other non-critical service, starting a database trigger, checking whether a master database and a backup database have gap before switching, starting by using spfile, stopping a database example, checking a large transaction and modifying the number of JOB to be 0, disabling database service, stopping monitoring external service of the database, cleaning session connection of a remote database example, cleaning two-stage transaction, detecting rollback, stopping database example 2 and checking data consistency again.
In the above Oracle RAC database disaster recovery switching drilling method, the step S3 is only executed on one node of the RAC production library and the disaster recovery library, and the specific process is as follows: the production library example 1 converts the role of the master library into the standby library, the disaster recovery library example 1 converts the role of the standby library into the master library, a new master library example 1 is opened, database service is registered, the state of the database is confirmed, and the jobs number is modified to the original state.
The method for practicing disaster recovery switching of the Oracle RAC database, wherein the operation after switching in step S4 includes: the disaster tolerance library example 2 starts a new main library example 2, checks the state of the new main library example 2 and performs registration service; the disaster tolerance bank example 1 initiates service switching, and performs service connection check and monitoring state check together with the disaster tolerance bank example 2, and performs check after switching system resources; the production library example 1 changes the original master library into the standby library mode, starts the database, then performs status check and starts data synchronization.
Compared with the prior art, the invention has the following beneficial effects: the Oracle RAC database disaster recovery switching drilling method provided by the invention fully considers the safety of disaster recovery drilling, ensures the data safety of a production system to the maximum extent, and cannot influence the data consistency due to the operation of stopping, switching and the like of the database in the disaster recovery drilling, thereby solving various errors and avoiding risks easily occurring in the existing drilling process, and ensuring that the disaster recovery drilling work is safer, more reliable and more efficient.
Drawings
FIG. 1 is a schematic diagram of the disaster recovery handover process of the Oracle RAC database of the present invention.
Detailed Description
The invention is further described below with reference to the figures and examples.
FIG. 1 is a schematic diagram of the disaster recovery handover process of the Oracle RAC database of the present invention.
Referring to fig. 1, the method for performing disaster recovery handover of Oracle RAC database according to the present invention is optimized for a general operation process and operation method, so as to form a complete, general and safe handover method. The invention relates to a disaster tolerance drilling process of a business system based on an Oracle RAC database (including switching and back switching between roles of a production database and a disaster tolerance data), which mainly comprises seven links: the method comprises the steps of early preparation, preparation before switching, database role switching, service inspection and work after switching, preparation before back switching, database role back switching, and service inspection and work after back switching. The whole flow is shown in figure 1.
The following information needs to be planned or recorded in detail in each link: task number, sub-number, server to which the task belongs, task content, start time, duration (minutes), group to which the task belongs, executor, inspector, business impact, one-touch script or operation content, inspection script, expected result, actual result, exception handling, timeout/exception reporting, start time, end time, operator, inspector, completion status.
The concrete implementation of each link is described as follows
Step S1: early preparation
The early preparation stage refers to the day before disaster recovery switching exercise, and checks and prepares for key points, and if abnormality is found, correction can be performed. It is mainly checked whether the following aspects are normal: data synchronization between production and disaster recovery databases, database backup execution, database key parameters related to switching, database listening port and disaster recovery network status, etc.
Step S2: preparation before handover
And the preparation stage before switching refers to 8 hours before switching the database, checking key points, judging whether the rectification can be completed within a specified time if the abnormity is found, and terminating the subsequent plan if the rectification cannot be completed. According to the time sequence, the following checking work is carried out:
serial number | Work content |
1 | Data consistency check (ADG time difference with the current network) |
2 | Snoop status checking |
3 | Number of master and slave library log groups |
4 | Restart required parameter checking |
5 | Rollback state detection |
6 | Master library audit log application status |
7 | Application of backup database checking log |
8 | Database archive configuration checking |
9 | Stopping database statistics collection services |
10 | Database password file comparison |
11 | Checking whether the Temp files are matched and whether the data files are online |
12 | Confirming that LOG _ ARCHIVE _ MAX _ PROCESSES is set to a value of 4 or more |
13 | Checking the parameter dg _ broker _ start (off) |
14 | Confirming whether current ADG is configured as maximum performance mode |
15 | Validating master library ADG roles/states |
16 | Validating backup ADG roles/states |
17 | Whether the database is in the force logging state |
18 | Whether the alter log has exceptions |
19 | System resource pre-handoff checks |
20 | Pre-switch checks of relational databases, in-memory databases, middleware, and the like |
21 | Stopping bulk traffic |
22 | Stopping background traffic |
23 | Stopping other non-critical traffic |
24 | Starting a database trigger to ensure that no data file is added under the running condition of the standby database |
25 | Checking whether there is gap in main and standby databases before switching |
26 | Whether spfile startup is used |
27 | Halting a database instance (including performing subsequent 28-36 processes) |
28 | Checking large transactions |
29 | Modifying the number of JOBs to 0 (operating in parallel with the previous step) |
30 | Disable database services (prevent pulling service in backup after startup) |
31 | Stopping database services |
32 | Stopping monitoring external service of database, and reserving ADG communication monitoring |
33 | Cleaning remote database instance Session connections (batch cleaning, not all at once) |
34 | Cleaning two-phase transactions |
35 | Rollback detection |
36 | Stopping other database instances |
37 | Data consistency check (ADG time difference with the current network) |
The step 1 shows that the disaster recovery library (ADG library) can be consistent with the data of the current time point of the production library after the time difference, that is, how long the disaster recovery library takes to catch up the current state of the production library. Generally, the number of seconds is several seconds, and if the local inspection finds that the number of minutes exceeds one minute or more, it is generally said that data synchronization is abnormal, and at this time, the data consistency cannot be guaranteed by performing the switching operation, and the inspection is required.
The calculation method of LOG _ ARCHIVE _ MAX _ PROCESSES in the step 12 is as follows: the number of archive paths + number of threads/number of instances of the production database. Taking the most common production database as an example, the production library has 2 nodes, and the disaster recovery library has 2 nodes, then the archive path of the production library is 3, the thread is 2, the number of instances is 2, and the calculation result is 3+ 2/2-4. However, the default value of this parameter will be greater than 4, where only minimal safeguards are made.
Step 27 "stop a database instance" is not a separate step and refers to the process from 28-36.
Step S3: performing role switching between production library and disaster recovery library
The operation of the process is only executed on one node of the RAC production library and the disaster recovery library, and the database can be opened for external service without operating all the nodes, so that the service interruption time is reduced.
Serial number | Main unit | Content of operation |
1 | Production library example 1 | Converting a master role to a PHYSICAL STANDBY |
2 | Disaster recovery warehouse example 1 | Converting the role of the backup library into PRIMARY |
3 | Disaster recovery warehouse example 1 | Opening a New Master library instance 1 |
4 | Disaster recovery warehouse example 1 | Registration database service |
5 | Disaster recovery warehouse example 1 | Validating database state |
6 | Disaster recovery warehouse example 1 | Modifying the jobnumber to the original state |
Step S4: business checking and post-switch operation
And performing 2-11 substeps of operation while performing service verification to complete subsequent work after the role of the database is switched.
Serial number | Main unit | Content of operation |
1 | (none) | Key business verification (business department responsible for processing) |
2 | Disaster recovery warehouse example 2 | Start New Master library instance 2 |
3 | Disaster recovery warehouse example 2 | Checking new master library instance 2 status |
4 | Disaster recovery warehouse example 2 | Registration service |
5 | Disaster recovery warehouse example 1 | Service switching |
6 | Disaster recovery repository instance 1/2 | Service connection checking |
7 | Disaster recovery repository instance 1/2 | Snoop status checking |
8 | Disaster recovery repository instance 1/2 | Post system resource switch checking |
9 | Production library example 1 | Changing original main library into standby library mode and opening database |
10 | Production library example 1 | State checking |
11 | Production library example 1 | Enabling data synchronization |
Steps S5, S6, and S7:
after the above operations are completed, the disaster recovery system can already provide business services to the outside, if the back-cut is not needed, the drilling work is ended, and if the back-cut test needs to be continued, the steps S5, S6 and S7 are continued. Steps S5, S6, S7 are the same as steps S2, S3, S4, respectively, and the description thereof is not repeated here.
The Oracle RAC database disaster recovery switching drilling method provided by the invention sequentially executes the operations in the step S2, and can ensure that the role switching between production and disaster recovery database can be smoothly carried out. The normal closing and role switching process of the production database instance is influenced by a large number of remote connections, two-stage transactions, database operations, background tasks and the like in the production database. In particular:
the operation of the serial number 32 in step S2 uses an independent listening port to perform data synchronization between the production and disaster recovery databases. For example: the listening port for the synchronization process between production and disaster recovery databases is used 1526 and the listening port for the operations (responsible for traffic connections) with the other databases is used 1521. When all external service connections of the database need to be shielded, the monitoring port responsible for the service connections can be closed first, and the data synchronization operation cannot be influenced.
In the operation of the serial number 33 in step S2, in a busy database system having thousands of remote connections at the same time, an operation of "enter system kill session" should be executed in batch in a manner of storing a procedure or an SQL script to perform a killing session process operation, which cannot be used: all processes are cleared at one time in a 'kill-9 + remote connection process number' mode, and database instance exception is prevented from occurring in the operation process.
The database role switching operation of step S2 is performed only on one node of the RAC production library and the disaster recovery library, and the external service of the database can be opened without performing operations on all nodes, thereby reducing service interruption time.
After the operation of step S3 is completed, the operation of step S4 may be performed at a subsequent scheduled time, and the step operation may not take the drilling time.
The Oracle RAC database disaster recovery switching drilling method provided by the invention has the following specific advantages:
1) universality: the invention does not depend on any third-party software, can finish all operations by using the own command of the Oracle database/operating system, and can be used in the disaster-tolerant environment with any Oracle Active DataGuard.
2) Safety: the invention fully considers the safety of disaster tolerance drilling, ensures the data safety of the production system to the maximum extent, and can not influence the data consistency due to the operations of database stopping, switching and the like in the disaster tolerance drilling.
3) Reliability: the invention is suitable for disaster recovery switching drilling work of a system with large data volume and busy service, and solves factors influencing switching operation item by item through various operations in the step II, thereby ensuring that the system with high service load can be smoothly switched.
4) Controllability: the invention refines all the operation steps into independent operation instructions, and can find and process clear corresponding relation if abnormity occurs. On the other hand, the invention has small dependence on the cooperation of the application side, and can replace the cooperation work of the service side through database level operation, such as: stop application connection, etc.
Although the present invention has been described with respect to the preferred embodiments, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (3)
1. An Oracle RAC database disaster recovery switching drilling method is characterized by comprising the following steps:
s1) firstly, carrying out early-stage preparation check on the data synchronization condition between production and disaster recovery databases, the database backup execution condition, the key parameters of the databases related to switching, the database monitoring ports and the disaster recovery network state;
s2), checking preparation before switching, if abnormal, judging whether the rectification can be completed within a specified time, if the switching condition can not be met, terminating the subsequent plan;
s3) executing role switching between the production library and the disaster recovery library;
s4) service checking and operation after switching;
s5) providing service for the outside through the disaster recovery system, if the back switching is not needed, the drilling work is finished; if the switchback test is needed, preparation before switchback is continuously carried out, the database role switchback is carried out after the switchback condition is judged to be met, and operation after service inspection and switching is carried out;
the step S2 checks for remote connections, two-phase transactions, database operations, and background tasks existing in the production database before switching; when external service connections of all databases need to be shielded, a monitoring port responsible for service connections is closed, and an independent monitoring port is used for data synchronization between production and disaster recovery databases; meanwhile, the checking and killing conversation process operation is executed in batch in a mode of storing the process or SQL scripts;
the step S2 sequentially performs the following checks according to the chronological order:
checking data consistency according to ADG and present network time difference, monitoring state check, main and standby library log group quantity, parameter check required to restart, rollback state check, main library check log application status, standby library check log application status, database filing configuration check, stopping database statistics collection service, database password file comparison, checking whether Temp files are matched, whether data files are online, confirming that sum of filing path quantity and thread quantity/example quantity of production database is set to be more than 4, checking whether parameter dg _ broker _ start is closed, confirming whether current ADG is configured to be maximum performance mode, confirming main library ADG role/state, confirming standby library ADG role/state, whether database is in force logging state, whether alter log is abnormal, checking before system resource switching, checking correlation database/memory database and before middleware switching, checking whether resource is required to restart, checking whether or not all the ADG is in a state, checking whether the database is in a state of being monitored, checking system resource switching resource before switching, checking whether or not all, Stopping batch service, stopping background service, stopping other non-critical service, starting a database trigger, checking whether a master database and a backup database have gap before switching, starting by using spfile, stopping a first database example, checking a large transaction and modifying the number of JOBs to be 0, forbidding database service, stopping monitoring external service of the database, cleaning session connection of a remote database example, cleaning two-stage transaction, detecting rollback, stopping a second database example and checking data consistency again.
2. The Oracle RAC database disaster recovery handover drilling method according to claim 1, wherein said step S3 is performed only on one node of the RAC production library and the disaster recovery library, and the specific procedure is as follows: the first production library instance converts the role of the master library into the standby library, the first disaster tolerance library instance converts the role of the standby library into the master library, the first new master library instance is opened, the database service is registered, the database state is confirmed, and the jobb number is modified to the original state.
3. The Oracle RAC database disaster recovery handover drilling method as claimed in claim 2, wherein the post-handover operation in step S4 comprises:
the second disaster tolerance library instance starts a second new main library instance, checks the state of the second new main library instance and performs registration service;
the first disaster recovery library instance initiates service switching, and performs service connection check and monitoring state check together with the second disaster recovery library instance, and performs check after switching system resources;
the first production library instance changes the original main library into a standby library mode, starts the database, then performs state check and starts data synchronization.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710982422.7A CN107766502B (en) | 2017-10-20 | 2017-10-20 | Oracle RAC database disaster recovery switching drilling method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710982422.7A CN107766502B (en) | 2017-10-20 | 2017-10-20 | Oracle RAC database disaster recovery switching drilling method |
Publications (2)
Publication Number | Publication Date |
---|---|
CN107766502A CN107766502A (en) | 2018-03-06 |
CN107766502B true CN107766502B (en) | 2021-03-23 |
Family
ID=61268887
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710982422.7A Active CN107766502B (en) | 2017-10-20 | 2017-10-20 | Oracle RAC database disaster recovery switching drilling method |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107766502B (en) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108667652A (en) * | 2018-04-12 | 2018-10-16 | 国网天津市电力公司 | A safe switching module and switching method for the main and standby machines of the remote machine |
CN109189864B (en) * | 2018-08-09 | 2021-03-16 | 联动优势电子商务有限公司 | Method, device and equipment for determining data synchronization delay |
CN109726046B (en) * | 2018-11-23 | 2021-01-08 | 网联清算有限公司 | Machine room switching method and device |
CN109885344A (en) * | 2019-02-27 | 2019-06-14 | 四川航空股份有限公司 | Operating system switching method and device |
CN112948484A (en) * | 2019-12-11 | 2021-06-11 | 中兴通讯股份有限公司 | Distributed database system and data disaster recovery drilling method |
CN113132177A (en) * | 2020-01-10 | 2021-07-16 | 中国移动通信集团山西有限公司 | Emergency drilling automation realization method, device, equipment and medium |
CN112347175A (en) * | 2020-11-11 | 2021-02-09 | 欧冶云商股份有限公司 | Cross-database remote measurement self-healing method and system |
CN114650214B (en) * | 2020-12-21 | 2024-09-27 | 顺丰科技有限公司 | Disaster recovery switching method and device, computer equipment and storage medium |
CN112764967B (en) * | 2020-12-29 | 2023-11-14 | 中国人寿保险股份有限公司上海数据中心 | ORACLE database system, database environment deployment method and database switching method |
CN113495811B (en) * | 2021-06-22 | 2024-08-06 | 交控科技股份有限公司 | Automatic recovery method, device, equipment and storage medium for main and standby reverse cutting of database |
CN114238284B (en) * | 2021-12-24 | 2025-06-27 | 中国建设银行股份有限公司 | Database disaster recovery system construction method and device |
CN114650216B (en) * | 2022-03-22 | 2024-07-19 | 阿里云计算有限公司 | Safety protection method and device |
CN114676118B (en) * | 2022-05-30 | 2022-08-12 | 深圳市科力锐科技有限公司 | Database switching method, device, equipment and storage medium |
CN114827080B (en) * | 2022-06-06 | 2022-09-23 | 武汉四通信息服务有限公司 | IP switching method and system |
CN118012676B (en) * | 2024-04-10 | 2024-07-30 | 深圳市科力锐科技有限公司 | Disaster recovery exercise method, equipment, storage medium and device |
CN119377012A (en) * | 2024-12-26 | 2025-01-28 | 杭州美创数智科技有限公司 | Application disaster recovery switching drill method, device, computer equipment and storage medium |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7827136B1 (en) * | 2001-09-20 | 2010-11-02 | Emc Corporation | Management for replication of data stored in a data storage environment including a system and method for failover protection of software agents operating in the environment |
CN103530735A (en) * | 2013-10-23 | 2014-01-22 | 北京邮电大学 | Assessment method for daily operation and maintenance management capacity of disaster recovery center |
CN103984309A (en) * | 2014-05-09 | 2014-08-13 | 浙江中烟工业有限责任公司 | Cigarette production system with disaster tolerance function and disaster tolerance exercise method thereof |
CN106095614A (en) * | 2016-05-27 | 2016-11-09 | 上海新炬网络信息技术有限公司 | A kind of data base's DR test managing and control system |
-
2017
- 2017-10-20 CN CN201710982422.7A patent/CN107766502B/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7827136B1 (en) * | 2001-09-20 | 2010-11-02 | Emc Corporation | Management for replication of data stored in a data storage environment including a system and method for failover protection of software agents operating in the environment |
CN103530735A (en) * | 2013-10-23 | 2014-01-22 | 北京邮电大学 | Assessment method for daily operation and maintenance management capacity of disaster recovery center |
CN103984309A (en) * | 2014-05-09 | 2014-08-13 | 浙江中烟工业有限责任公司 | Cigarette production system with disaster tolerance function and disaster tolerance exercise method thereof |
CN106095614A (en) * | 2016-05-27 | 2016-11-09 | 上海新炬网络信息技术有限公司 | A kind of data base's DR test managing and control system |
Non-Patent Citations (1)
Title |
---|
IT系统基础架构的容灾分析与设计;高若飞;《中国优秀硕士学位论文全文数据库 信息科技辑》;20110215(第2期);第I138-14页 * |
Also Published As
Publication number | Publication date |
---|---|
CN107766502A (en) | 2018-03-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107766502B (en) | Oracle RAC database disaster recovery switching drilling method | |
CN110262972B (en) | A failure testing tool and method for microservice applications | |
US20220321440A1 (en) | Interface Service Function Monitoring Method and System Based on Data Acquisition | |
CN107634860B (en) | Method for automatically upgrading weblogic cluster patches in batches | |
CN110088744B (en) | A database maintenance method and system thereof | |
CN106789141B (en) | A kind of gateway equipment fault handling method and device | |
CN113162808B (en) | Storage link fault processing method and device, electronic equipment and storage medium | |
CN111563002B (en) | Transaction fault processing method and device, electronic equipment and storage medium | |
CN102833120B (en) | The abnormal method and system of NM server are processed in a kind of rapid automatized test | |
CN103645985B (en) | Source code macro-pairing detection method | |
CN106897779A (en) | A kind of processing method of data center's operational system event | |
CN108880873B (en) | Transaction compensation method and device applied to heterogeneous system | |
CN119668916A (en) | Cluster system fault handling method, system, device, equipment, medium and program | |
CN113065001B (en) | Fault stop loss method and device | |
CN119311318A (en) | Intent-based server management method, device, medium and product | |
Zhang et al. | Application business information interaction bus based on micro frontend framework | |
CN109377167A (en) | A kind of inspection field operation method | |
CN107590647A (en) | The servo supervisory systems of ship-handling system | |
CN114257495A (en) | Automatic processing system for abnormity of cloud platform computing node | |
CN112711508A (en) | Intelligent operation and maintenance service system facing large-scale client system | |
CN116450417B (en) | Bank payment system disaster backup switching platform and method based on DevOps | |
CN100518100C (en) | Device and method for automatically testing the compression resistance of a communication system | |
CN109634777A (en) | A kind of sales service system O&M emergency disposal and quick recovery method | |
CN114348071B (en) | On-site upgrading method and system for rail transit operation scene | |
CN118820011A (en) | Functional safety monitoring system, functional safety monitoring method and vehicle-mounted terminal |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |