In this chapter, the installation of the physical standby database will be covered in three steps. The first step will be to prepare the environment for the installation, especially the preinstallation tasks on the database. Then the second step for creating a physical standby database will be covered. In the last step, the Data Guard installation will be verified to see if it is installed correctly.
In this chapter, we'll discuss the following topics:
- Planning and understanding requirements
- Preparation for the configuration
- Step-by-step instructions to create the physical standby database
- Verifying the physical standby database configuration (post-installation steps)
Before preparing the configuration, you should know the business criticality of your database, how to avoid failures, and how much data you are ready to lose.
The Data Guard configuration contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can also configure the standby database at the same location as the primary database. However, for disaster-recovery purposes and to make it highly available, it's strongly recommended to configure standby in a geographically remote location.
Before implementing a Data Guard configuration, take into account concepts such as high data availability, efficient systems utilization, and data protection.
- Availability: Outages should be tolerated transparently and should be recovered quickly in case of server failures or any network failures
- Protection: Ensure minimum data loss; standby data should be isolated from production faults such as storage failures, site failures, data corruptions, or operator errors
- Utilization: Standby resources should be utilized for productive use in case of any planned maintenance or for application access
Before implementing any high-availability solution, you need to determine the acceptable amount of data loss. Data loss should not be calculated in terms of time (for example, seconds or minutes); it should be calculated in terms of transactions. The following example is drafted from a production database. Notice how much data can be lost in 60 seconds. During the peak hours of your business, run the Stats pack or AWR snapshot at periodic intervals 2-3 times. In the report, take a look at the
Load profile section. The
Per second column of the Redo size row is the redo generation rate of your database:
|
Load profile | ||
|---|---|---|
|
Per second |
Per transaction | |
|
Redo size |
16615645.13 |
9172093.26 |
|
Instance activity stats | |||
|---|---|---|---|
|
Statistic |
Total |
Per second |
Per transaction |
|
Redo size |
16615645.13 |
16615645.13 |
9172093.26 |
In the Instance activity stats table, the redo size generated is 16615645.13 bytes per second—that is nearly 15.9 MB per second and nearly 950 MB per minute. Are you ready to lose 950 MB of data? You may want to rethink your recover plan. It must be calculated in terms of transactions.
Based on your transactions rate, calculate how much redo is generated and how much data loss is acceptable. You can configure Data Guard to have zero data loss.
We need to determine the network bandwidth required for a Data Guard physical standby implementation. Network latency is a huge factor in the amount of redo you will be able to transport from your primary site to the standby site. This value is unique to your network, and if you have a high latency network you might not be able to sustain the required rate of redo shipping. The wide area network between the primary site and standby site may be used by more than just Data Guard. So, the bandwidth requirements have to be sorted out. The formula used by Oracle, assuming a conservative TCP/IP network overhead of 30 percent, is as follows:
Required bandwidth (Mbps) = ((Redo rate bytes per sec. / 0.7) * 8) / 1,000,000
Based on this formula, according to the redo size from the preceding example, the required bandwidth is equal to 189.8930872 mbps (((16615645.13/ 0.7) * 8) / 1,000,000). Of course, according to the preceding example, bandwidth should be very high, because it's an example taken during a huge job with lot of DML activity. This means that the peak redo generation rate is a good indicator of your Data-Guard-related network requirements. Make sure that, while specifying your network requirements with your network service provider, you also consider other applications and their Service Level Agreements (SLAs) using the same network. The preceding formula indicates the network bandwidth that should be available to Data Guard; it does not indicate what the entire network bandwidth should be between your primary and DR data centers.
This topic describes Data Guard parameters and how to prepare the standby database creation and configuration. What prerequisites are mandatory to be completed before configuring the standby database? We will discuss each and every task that needs to be accomplished.
For any primary database, there are some basics you should configure. One of these is to run the primary database in the archive log mode, which is a mandatory step. You can create a database in the archive log mode or the noarchive log mode and you can change this later.
If the primary database is already in the archive log mode, you can skip this step and proceed with the next one. If this has not been done, perform the following procedure to put the primary database in the archive log mode.