On the design scheme of the Oracle standby Database

On the design scheme of the Oracle standby Database

Oracle's ADG is needless to say. In terms of storage circles, the storage is changing from passive to active, but in general it is being snatched by software and RAID is snatched by ASM, snapshots are snatched by Flashback and DR is snatched by ADG.

What will happen if these solutions are combined. This involves the design of a slave database.

I am also an expert. The environment is based on 11 GB of dg.

First of all, a master database and a slave database are the standby database design methods used by many systems. If the database is critical, what are the disadvantages of this solution.

The 11g slave database is now given more responsibilities.

Disaster Tolerance: If the master database fails, the slave database can perform failover. This is no problem, so the 11g slave database is now given more responsibilities.

Batch query. There may be some tasks for batch query and REPORT query. Then, these functions can be stored in the slave database.

Human operation prevention. In case of misoperations and human operations, is it possible to prevent them in a timely and reasonable manner.

Therefore, the one-master-one-slave solution has several drawbacks,

First, batch query. If the batchcompute task is under high pressure, it consumes a lot of CPU resources. If it takes longer than a month, the actual hardware consumption cannot be ignored, if something goes wrong, you may not be able to get any insurance.

In case of human misoperation, how can we say this? If the delay is afraid of losing too much data without delay, it is inevitable to avoid human misoperation. If this happens once a year, it will be enough for us to have a good time.

So we design one master, two slave?

If this design is done, it will be good for key businesses. However, there are several things to consider. We still need to meet the needs of the previous few, such as disaster recovery, support for large queries, and prevent human error.

Standby 1 can be designed to be in the same adjacent region, while standby2 can be considered as remote disaster recovery. Remote Disaster Recovery is also an important consideration. If the data center loses power, several slave databases are in one data center, which is likely to be implicated.

Therefore, Remote Disaster Recovery is also important. So how can we meet the above three requirements.

First, disaster recovery, one master, two backups, taking into account remote disaster recovery, this is a good solution in itself.

If large queries are supported, you can split the big query characters and run them on two slave databases, for example, 60% or 40%. Do not let the slave database be completely idle. At the same time, the pressure is reduced a lot.

Then human error occurs. How can we prevent this problem? There are also several solutions based on the current one-master-two-slave environment. One is to enable delayed application archiving for another slave database.

For example, for standby2 in remote disaster recovery, if the delay is set to 2 hours, human error occurs in this case. For example, truncate may also recover the deleted data. However, it is only possible, because no one can make it clear for a few hours. In the event of misoperations three hours ago, we finally found that this was caused by misoperations, so this solution also had to be broken down.

Some may say that if 20 archives are switched within two hours, the truncate operation is in the final archive, that is, the operation in the 20th archive, the data changes in the 20th archive may be in the following format.

Transaction 1

Transaction 2

Transaction 3

Transaction 4

....

Transaction 10

Truncate, How can you ensure that you will be able to recover it strictly? Some friends may say that you can use logminer, well, or you can, but it still takes some effort. And it cannot be guaranteed by 100%.

What other solutions can be improved. You can try to flash back to the database.

In fact, flash back to the database is no longer a new feature in 11 GB. So how can he fulfill the above three requirements.

Disaster recovery does not need to be said, and large queries can also be supported, so human error occurs. The Green Arrow is shown below.

Flash back on Remote Disaster Recovery 2, get the required data after traversing, export exp, and deploy the data to the master database. Then the slave database continues to enable the log application.

It seems that this method can meet these needs.

Then let's sort out these requirements. In this case, the large query can be shared, and the standby database 1 can be shared more, and the standby database 2 can be shared less. In addition, the remote disaster recovery requires additional space for storing flash logs.

If two machines in the same city data center crash, and more seriously, one minute before the crash, some manual deletion operations occur, will remote disaster recovery be awesome.

In this case, you need to first flash back to the database, export the required data, then perform failover, then turn off the function of flash back to the database, and then re-deploy the disaster recovery environment, therefore, it can still be ensured that a flash may flash back, but if the table is large, it may take some time to export data.

Therefore, the one-master-two-slave mode can be used in a variety of ways. As long as the stability of the solution is ensured, the flashback database can still be considered in the case of one-master-two-slave mode.