Database Reference
In-Depth Information
Chapter 9
Learning About Data Guard
This chapter is dedicated to helping you make informed choices to protect your site from disaster. One cannot think of a
hosting solution to be used by potentially hundreds or more databases without proper, standardized planning for what
to do when disaster strikes. In order to be prepared for the disaster situation, practice and documentation are crucial to
successful handling of the crisis situation. In the Oracle world there are broadly speaking two different ways to achieve
the goal of ensuring that your business applications can continue if the lights on your primary data center go out. The
first one is the more obvious one to the Oracle database professional: application level replication. The most common
representative of this approach is Oracle Data Guard. The second option available is to use application-agnostic storage
array replication. The latter is very popular with large organizations that have long-term relations with the established
storage vendors. Please note that the chapter you are about to read deals with Data Guard only.
WhY YOU NeeD a DISaSter reCOVerY StrateGY
Most regulators, external and internal, will require your applications to be resilient to data center failures. That
does not mean that your application has to be continuously available, although that could be specified too. Rather,
it implies that your application must have some sort of standard operating procedure written down and practiced
explaining the correct steps to undertake in case an application component irrevocably fails. Usually you will find
service level agreements (SLA) with more or less strict obligations signed by the business continuity department
and the hosting platform's product management. The intention of the SLA is to limit the time for unplanned
outages. The most important aspects you will find covered are:
•
The maximum amount of data lost, usually expressed in a time frame
•
The maximum amount of time until the service must be restored
In the language of the business-continuity specialist, the first of the two is termed
Recovery Point Object
or RPO.
The second bullet point is known as the
Recovery Time Object
, or RTO. Applications which are really critical for
the survival of a company are often described as having an RPO and RTO of zero. In other words, there must be
no data loss, and the service must be restored instantly. Such a configuration is very difficult and very expensive
to implement.
It is not expected that a database hosted on the consolidation platform has these strict requirements. All services
planned to be part of the consolidation platform should however have approval from the Business Continuity
department from within your organization as a milestone on the project plan. The earlier you have involvement
and sign-off from the right team the easier it is to implement your solution around the requirements. Before
discussing your options to keep the light on in more detail let's have a look at the offering by Oracle: Data Guard.
Search WWH ::
Custom Search