Supporting Software - Expert Consolidation in Oracle Database 12c - page 111

Exadata extends the idea of the database appliance and adds intelligent storage. Many workloads benefit from
Exadata's unique features, out of which the best-known is the offloading capability to the storage layer and the
I/O Resource Manager.
Exadata is a wonderful piece of engineering and, from an application's point of view, is another case of
RAC. Exadata does not require any changes to the applications compared to traditional Real Application Cluster
deployments. Depending on the configuration, an Exadata rack can have between two and eight cluster nodes in
addition to its own specialized and intelligent storage. From a connectivity and high availability point of view, you do
not connect any differently to Exadata than you connect to your own cluster.
Oracle is not the only hardware provider who offers such solutions. Other vendors have tightly integrated
solutions in their product portfolios. Exadata-like intelligent storage, however, does not exist outside of Oracle.
Unfortunately, most Oracle applications today are not RAC aware. However, with the new concepts of Pluggable
Databases Oracle introduced in this release, that problem is mitigated.

Disaster Recovery Considerations
You just read that Real Application Clusters are not a protection from disasters. You might hear the claim that
a stretched RAC will protect you from disasters if the data centers are far enough away from each other. Although it
is partially true, if your pockets are deep enough, there is still a fundamental problem with having only one database:
in case you have to restore, you will incur an outage. And with the trend to larger and larger databases, even the
fastest technology may not give you your database back within the service level agreement. The result is a major
embarrassment at best.
There are many ways to protect your environment from disaster, and, because of the importance of that subject,
Chapter 9 is dedicated to it. This section is just an appetizer.

■ there are more replication technologies available. this section is mainly concerned with bitwise
identical replication.

Note

In the Oracle world, you have the option to use Data Guard, which, in its standard form, is included with the
Enterprise Edition. The simple yet remarkably effective idea is to take the redo generated by the primary database,
ship it over the network, and apply it to up to 30 standby databases. The standby databases are merely mounted and
cannot be queried while they apply redo. The log shipping can be configured to be synchronous or asynchronously.
At the same time, it has many checks to ensure that the data written is not corrupt. With an additional option, called
Active Data Guard, you can even query your standby databases while they receive changes from production. Backups
from the standby database are possible as well, allowing you to offload those from your production database. Cautious
architects configure backup solutions on all data centers, allowing for flexibility should the unthinkable happen
and the primary data center blacks out. Data Guard also allows for planned role changes, it can convert a standby
to a full read-write clone of your production system to test hot fixes, and last, but not least, it can be used to fail over
from production in the event of a catastrophe. Regulatory requirements and/or standard operational procedures
often require regular DR tests, especially before a new architecture goes live. Integrating disaster recovery into the
architecture right from the start can save you from having to retrofit it later.

■ Note Chapters 9 and 10 cover Data guard in greater detail.

The alternative to Data Guard is to use block level replication on the storage array, which operates a on
a different level. Storage level replication exists for enterprise arrays, and most use a fiber channel fabric to send
blocks as they are from the production to the DR array. Other than that, the processes are quite common. The array