数据库治理系统一次通常只能运行在一台服务器上。在不采用高级解决方案的前提下（比如Oracle公司的Real application Clusters）数据库则只能在服务器之间手工迁移。由于难以在数据库级别上平衡服务器负载，所以这一局限性导致大量计算机资源被白白浪费了。
从SAN到DAN
虽然SAN （存储区域网）和动态应用服务器在Web和应用服务器负载均衡领域取得了巨大的成功，但是，数据库层却仍然是系统性能的瓶颈。利用SAN能够很方便地在服务器之间搬移磁盘，从而令IT治理职员可以根据需要对磁盘存储动态地重新部署，如图A所示。
图A
当前的灵活体系
SAN技术实现了多计算机之间的单线程数据共享，但问题也随之而来：在处理能力需求发生改变的情况下该如何智能地重新部署数据库呢。这就是DAN（数据库区域网：Database Area Network）技术的用武之地了。
DAN架构用到了数据库交换机，其下的SAN则实现了数据库在不影响可用性的情况下在服务器之间的搬移。图B所示就是两种架构。
图 B
SAN 和DAN架构
数据库服务器负载均衡是一个复杂而又问题丛生的技术话题。许多公司年复一年耗费了大量的资金重新部署数据库服务器资源。更糟糕的是，由于资源分配的不足和不合理，最终用户不得不容忍漫长的服务响应时间，直到数据库治理员（DBA）通过手工操作的方式把数据库再度分配到更大的服务器上，研究人员利用DAN技术就可以在处理要求超出服务器处理能力的时候动态分配数据库。
DAN技术的工作原理
DAN技术的内部机制可谓相当简单。在SAN环境下，数据库的重新部署涉及到以下的步骤：
关闭数据库，采用软件方法立即重定向交易。
把数据文件重定向到使用SAN的目标服务器。
在新服务器上重新启动数据库。
用Oracle的Transparent Application Failover (TAF)之类的内建产品进行处理不会在重新部署期间丢失任何交易，最终用户也不会察觉到数据库已经变更了服务器。
DAN的优点
这种类型的负载均衡对IT治理人员来说具有不一般的影响。由于在硬件上投入了巨资，IT治理人员的工作就是实现昂贵的服务器资源利用率的最大化，同时维持最终用户可以接受的响应时间。根据处理要求采用DAN重新部署数据库就可以巩固和强化对服务器的IT治理，从而为企业在硬件和软件许可证费用方面节约大量资金创造了条件。
同时，采用DAN之后DBA维护的工作量也会大大降低。由于服务器资源的整合，DBA直接治理的服务器数量显著减少，几乎不再担心服务器的处理能力扩充问题。
DAN还实现了数据库行为的“黑盒”化。这就是说，由于数据库独立于操作之外而令操作系统架构失去了以往的重要性。比如说，Oracle数据库就可以无缝地重新部署在AIX、linux、Solaris或者HP/UX等系统之上，原因就在于以上这些平台都支持Oracle数据库系统。因为DAN隐藏了操作系统的内部结构，所以DAN尽可根据服务器的处理能力重新部署数据库。
随着DAN技术日益走向成熟，DAN最终可以根据先验的历史测量数据来猜测数据库遭遇处理压力而必须重新部署到更大型服务器的时间，从而满足日益增长的处理要求。所有理智的数据库专业人士都知道，数据库服务器有规律地表现出一些众所周知的处理压力“信号”。出现这些信号是因为最终用户处理能力要求的周期性，而且我们可以每周、日、小时为度量单元描绘出服务器受到的处理压力，从而观察这些“信号”的出现情况。
假如CPU和内存使用情况的历史测量可用，那么DAN就应当能猜测数据库搬移到更强大服务器的时间。DAN可以猜测迫近的处理高峰，在需要最大处理能力的时候重新部署数据库。
下面我们就看看DAN技术是如何完成以上任务的。假设我们拥有两个数据库，其CPU利用情况如图C所示。
图C
配置示例
在图C中，系统A于周二达到了100%的使用率，而系统B则在周三到周五都达到了峰值负载。在没有用到DAN技术的情况下，IT管人员只能被迫把这些数据库放到两台价值4万美元的服务器上。而采用DAN技术后，IT治理人员就可以重新部署数据库并用更便宜的、价值1万美元的Linux服务器取代第2台服务器。DAN则在处理要求发生变动的情况下重新部署数据库。而系统则节约了3万美元。
DAN技术向何处去？
任何采用SAN的数据库都可以在几分钟的系统关机时间内方便地从一台服务器移到另一台服务器。
而在采用DAN技术的场合下，负责数据库重新部署的治理人员可以在不丢失即时交易的情况下提供无缝的数据库重新部署，智能代理则直接负责数据库的重新部署。假如DAN真能满足以往SAN定位的市场要求，那么大型数据库应用商会如何利用DAN技术实施动态数据库负载均衡呢？我们对这种新技术的未来发展趋势拭目以待。
