| high
availability features |
| The
Grid: |
|
|
|
 |
The
centrepiece of the publicity surrounding Oracle 10g is the
concept of Grid Computing. Real Application Clusters (RAC),
the high availability functionality introduced in Oracle
9i, has been completely revamped to provide the backbone
for Oracle’s vision of grid computing (inevitably involving
trying to make you purchase as many Oracle licenses as possible).
By registering database applications as services within the
RAC cluster configuration, you can assign a service to one
or more nodes in RAC cluster meaning that behind the scenes
Oracle will load balance the application across the nodes,
taking advantage of idle CPU on some nodes when others start
to become overloaded. The concept extends to the Oracle Application
Server suite of products meaning you can have a complete
grid-based and fault tolerant multi-tier application. Central
to the management of all this is Grid Control, an enhanced
version of the new web-based Oracle Enterprise Manager software
that allows you to manage all aspects of your grid. |
|
| Real
Application Clusters (RAC): |
|
|
|
| RAC
has been radically altered as part of the transition to grid
computing. Although the basic concepts remain the same, the
components of the clustering software have been brought together
and renamed Cluster Ready Services, or CRS. CRS manages cluster
database functions including node membership, group services,
global resource management, and high availability. As previously
mentioned, application services are defined within CRS to
help enable grid computing. 10g also saw the introduction
of Virtual IP Addresses (VIP) to enhance the failover abilities
of RAC when nodes go down. Each server has its own VIP address
which is registered in DNS. When a node goes down, Oracle
can migrate the VIP to another node in the cluster so that
connections can still come though. The Database Configuration
Assistant (DBCA) has been considerably enhanced and Oracle
recommends using it for creating, modifying and deleting
RAC databases. |
|
| Data
Guard - Automatic Failover with Data Guard Manager: |
|
|
|
| Not
only has the syntax for this tool been greatly simplified,
it can now be used to auto-failover a database to the standby.
This is done by having a separate server with an Oracle installation
on it (and another license fee of course!) which monitors
both the live and standby nodes. In the event it loses contact
with the live database, the monitor node performs a failover
to the standby. When it becomes available again, the old
live database is automatically reconfigured to act as a new
standby. |
|
| Data
Guard – Real-time Apply Enhancements: |
|
|
|
| It’s
no longer necessary for a log switch to occur to apply data
to a standby using the SQL apply method. |
|
| Data
Guard – Flashback Support: |
|
|
|
| As
already mentioned you can use the Flashback feature to flashback
a standby database to a point before it was activated and
continue to use it as a standby. |
|
| Data
Guard – Support for Recovery through Resetlogs: |
|
|
|
| The
new %r tag in the archive log format means that a standby
database can be rolled forward even if a resetlogs has occurred
on the primary. |
|
| Data
Guard - log_archive_dest_n new “valid_for” Parameter: |
|
|
|
|
In
Oracle 9i, configuring the log_archive_dest_n init.ora parameter
to cope with switchovers and switchbacks meant many alert
log errors being produced as, for example, the standby destination
configured on the standby database tried to connect to the
live database before the roles were switched over. In Oracle
10g, the new “valid_for” parameter allows you
to configure an archive destination to only be active when
the database is playing a certain role, meaning no more confusing
and irrelevant alert log errors. |
|
|
|
|
|
| |
<<
previous page |
|
|
|
020 8465 9100 
Sales
Enquiries
Other Enquiries
