Introducing DAN - A New Database Architecture

Oracle Tips by Burleson Consulting

August 16, 2002

Database management systems generally run on only one server at a time. Without sophisticated solutions such as Oracle's Real Application Clusters, databases must be manually moved between servers. This limitation has led to a situation in which huge amounts of computer resources are wasted because it's difficult to balance server load at the database level.

From SAN to DAN

While SAN (Storage Area Networks) and dynamic application servers have been highly successful for Web and application server load balancing, the database layer is still a serious system bottleneck. SAN has made it easy to move disk storage from server to server, allowing the IT staff to dynamically relocate disk storage as needed (Figure A).

Figure A

The current flexible architecture

SAN technology allows single-threaded sharing of data by many computers, but a problem remains: how to intelligently relocate databases to different servers when processing demands change. This is where DAN (Database Area Network) technology enters the picture.

The DAN architecture uses a database switch with the underlying SAN to allow databases to move from server to server without affecting availability. Figure B shows both architectures.

Figure B

SAN and DAN architecture

Database server load balancing is complex and problematic, and many companies waste millions of dollars each year by overallocating database server resources. Worse yet, many shops underallocate server resources, forcing end users to endure unacceptable response times until the database administrator (DBA) can manually relocate the database to a larger server. In order to address this inefficient use of database server resources, researchers are exploring DAN techniques to allow for the dynamic relocation of databases when the processing demands exceed the processing capacity of the server.

How DAN technology works

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.

The benefits of DAN

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 the server.

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 Figure C.

Figure C

Sample configuration

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 technology going?

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.

��