Databases Reference
In-Depth Information
primarily supported read activity. The reason why use of OPS was mostly limited to
data warehousing implementations was the phenomenon known as
pinging
.
In the world of both OPS and RAC, multiple machines access the same database files
on shared disk (either physically attached or appearing as physically attached through
software), as shown in
Figure 9-6
.
Figure 9-6. RAC architecture
This architecture allows you to add more machines to a cluster of machines, which in
turn adds more overall horsepower to the system. But there was a problem with the
implementation of this architecture for OPS, stemming from the fact that a page can
contain more than a single row. If one machine in a cluster wanted to modify a row in
a page that was already being modified by another machine, that page had to be flushed
to the database file on the shared disk—a scenario that was termed a
ping
. This chain
of events caused extra disk I/O, which in turn decreased the overall performance of the
solution based on the number of writes.
The traditional way around this problem was simply to avoid it—to use OPS only when
a database would not cause pings with a lot of write operations, or to segregate writes
so that they would not require data in use on another node. This limitation required
you to carefully consider the type of application to which you would deploy OPS and
sometimes forced you to actually modify the design of your application to work around
OPS's limitations.
With Real Application Clusters, the problem caused by pings was eliminated. RAC fully
supports the technology known as Cache Fusion. Cache Fusion makes all the data in
every cache on every machine in a Real Application Cluster available to every other
machine in the cluster. If one machine needs a block that is either being used by another
machine or simply residing in the cache of another machine, the block is directly shipped
to the requesting machine, usually over a very high-speed interconnect.
