The internal mechanism of DAN technology is quite
simple. In a SAN environment, the relocation of a
database involves the following steps:
- Shut down the database and use a software
mechanism to redirect in-flight transactions.
- Redirect the data file access to the target
server using SAN.
- Restart the database on the new server.
Using built-in products like Oracle's Transparent
Application Failover (TAF), no transactions will be
lost during the relocation, and the end users will not
be aware that the database has changed servers.
This type of load balancing has important
ramifications for the IT manager. With tens of
millions of dollars spent in hardware, the IT
manager's job is to maximize the utilization of the
expensive server resources while maintaining
acceptable response time for the end users. Using a
DAN to relocate databases based on processing allows
IT management to consolidate servers, potentially
saving millions of dollars each year in hardware costs
and software licensing fees.
There's also the benefit of reduced DBA
maintenance. By consolidating server resources, the
DBA has fewer servers to manage and need never worry
about outgrowing a server.
DANs also make databases behave like "black boxes."
This means that the OS architecture is not important
because the database is independent of the OS. For
example, Oracle databases can be relocated to AIX,
Linux, Solaris, or HP/UX in a seamless fashion because
Oracle is supported in each of these platforms.
Because the DAN hides the OS internals, the DAN can
relocate databases based solely upon the horsepower of
As this technology matures, DANs will evolve to use
proactive historical metrics to predict when the
database will experience stress and relocate it to a
larger server, just in time to accommodate the
increased processing need. All savvy database
professionals know that database servers develop
well-known stress "signatures." These signatures
develop because of the periodic nature of end users
processing and can be seen when server stress is
plotted by hour of the day or day of the week.
If historical metrics on CPU and RAM usage are
available, a DAN should be able to predict when the
database should be moved to a more powerful server.
The DAN can anticipate the impending processing spike
and relocate each database to the larger server when
maximum horsepower is required.
Let's take a closer look at how DAN technology
accomplishes this task. Assume that we have two
databases with the CPU consumption signatures shown in
In Figure C, System A experiences 100% utilization on
Tuesday, while System B experiences peak loads on
Wednesday through Friday. Without DAN technology, the
IT manager is forced to place these databases on two
$40,000 servers. Using DAN technology, the IT manager
can relocate the database and replace the second
server with a cheaper $10,000 Linux server. The DAN
relocates the databases when processing demands
change. This results in a $30,000 savings.
Where is DAN
Any database with a SAN can be moved easily from
server to server with just a few minutes of system
downtime. With DAN technology, the relocation manager
provides seamless database relocation without losing
in-flight transactions, and intelligent agents direct
the database relocation. It will be interesting to see
how this exciting new technology evolves and how large
database shops will leverage DAN technology to perform
dynamic database load balancing—and if DAN can match
the huge market appeal enjoyed by SAN.