多数据库环境地连接策略

由于计算机硬件功能越来越强大，价格则越来越低廉，所以很多人开始用一台机器作为多个SQL Server数据库的主机，随着时间的推移，单个机器有可能需要支持越来越多的SQL Server数据库。但是，你有可能需要替换硬件设施，你的数据库服务器有可能由于某个硬件问题而出现错误，而你的多数据库主机还有可能由于运行太多的应用程序而导致饱和，最终导致所有的应用都出现性能问题。当上述任何一种情况出现时，你应该如何应对呢?要怎样做才能够最大限度减少将应用程序重新指向一台新的数据库机器或者出于性能因素将你当前的单机环境转变成多机器环境所需要的工作量呢?本文将和大家一起探讨通过涉及数据库连接策略来简化应用程序连接变化的方法，这样就可以在需要的时候减少管理开销使数据库发挥“即插即用”的功能。

应用程序如何连接

每个应用程序都需要识别其所要连接的以便从中检索数据的数据库服务器。通过使用连接字符串可以实现应用程序和数据库服务器的连接。典型的连接字符串如下：

Server=MyServerAddress; Initial Catalog=MyDatabaseName;

Integrated Security=SSPI;

在这个例子当中，数据库服务器可以用机器名、IP连接地址、OBDC DSN名或DNS服务器别名等来进行识别。只要是可以解析为IP地址的名称就可以用。名称的解析可以用很多不同的方式进行。

如果你的SQL Server机器在一个域里，可以创建一个DNS域名注册到域里。当机器以DNS注册，那么客户端或应用程序就可以使用该机器的注册名连接到该机器。而且，用DNS注册，你可以创建一个DNS别名，这是一个代表了你的SQL Server机器的逻辑名。在连接字符串中使用DNS别名的话，当对数据库服务器进行连接时，DNS会将秘密地将该名称解析为IP地址。这样的话，你进行连接的时候，只需要记住这个看起来有意义又比较容易记住的逻辑名，而不需要记住那串难记的IP地址数字串或机器名了。当你在连接字符串中使用DNS别名的时候，你可以创建一个连接策略来隔离来自物理地址或数据库服务器机器名的应用程序。

使用DNS来识别数据库应用软件的位置

当使用DNS来识别数据库应用软件的位置时，你可以在连接字符串中使用机器的域名，但是这种方法不够灵活。想象一下当你想要改变SQL Server物理机器的名称时会发生什么事情。这种情况下，如果你使用机器名，那么你每改变一次机器名就得修改连接字符串以便引用新的机器名。如果你只有一个应用程序连接到一个数据库服务器，情况可能还不会那么糟。但是，如果你在一台机器上有很多的应用程序和很多数据库，那么这将意味着一旦你重命名你的服务器，你就需要修改很多连接字符串。因此，在连接字符串中使用机器名无法灵活应对环境的变化。

更好的做法是使用DNS别名来解析数据库所在位置。当你不再用机器名来为所有的应用程序识别数据库机器的地址时，你就应当考虑创建一个有实际意思的与别不同的DNS别名，这个别名可以解析为数据库服务器的IP地址。例如，你可以用类似于SQL2005PRO这样的DNS别名，这个在DNS中定义的名字和实际的物理机器的IP地址是一样的。使用DNS别名可以赋予名字一定的含义。这里，SQL2005PROD这个名字的意思是用于生产的 SQL Server 2005服务器。这样可以将上述的连接字符串改成：

Server=SQL2005PROD; Initial Catalog=MyDatabaseName; Integrated Security=SSPI;

那么在连接字符串中用DNS域名又有什么好处呢?有一个描述性的名称无疑是其中一个显而易见的好处，但并不是唯一的好处。假设你的数据库服务器包含了很多个不同的数据库，还要支持50个不同的应用程序。又假设你的SQL Server机器名为SSEDB01，而这台机器现在出现了某种未知的硬件错误。此外，你还有一个名为SSEDB02的备份机器，而你出于安全的考虑，已经将SSEDB01的备份传送到了这台SSEDB02中，所以你可以从SSEDB01快速恢复所有的数据库来支持这50个不同的应用程序。另外，假设你知道在SSEDB02上恢复所有SSEDB01的数据库比解决SSEDB01本身的硬件问题用时更少。在以上的前提条件下，如果你在应用程序的连接字符串中用的是机器名，那么你将不得不一个一个地修改所有的连接字符串，将SSEDB01的机器名改为SSEDB02，让这50个应用程序指向新的后备服务器SSEDB02，以便完成整个恢复过程。修改50多个连接字符串可能需要相当长一段时间，而且很容易出错。这种情况下，如果你在所有50多个连接字符串中使用的连接名是SQL2005PROD这样的逻辑名，那么你只需要进行一个修改就可以将所有的应用程序重新指向新的后备服务器SSEDB02，也就是对DNS的修改，将SQL2005PROD改为指向SSEDB02的IP地址，而不是SSEDB01的IP地址。只要你修改了DNS，那么每一个应用程序就自动地连接到SSEDB02而不再连接到SSEDB01了，也就不需要花时间修改那50多个连接字符串中的任意一个。在连接设计的时候，只要做这么一个小小的应用方面的修改，用逻辑名来代表SQL Server服务器，而不用物理服务器名或IP地址，那么在出现问题需要将所有应用程序重新指向新SQL Server服务器时，工作量就会大大减少。

利用DNS来协助容量管理

在连接字符串中使用DNS别名可以帮助你进行容量管理。假设你的环境中又很多不同的SQL Server生产服务器。每一台机器都要支持很多应用程序。又假设某些应用的数据库基本上呈线性增长，但也有相当一部分应用数据库没有表现出一个可预见的增长速率。这些数据库的增长速度在不同的时段表现的很不一样，有时候一点都不增长，有时候呈指数递增或递减。由于有一部分这样的增长率波动很大的数据库，导致有一些服务器几乎没有什么可用空间，甚至经常性出现可用空间用完的情况，而同时另外有一部分服务器却还有大量可用空间。那么怎样利用DNS来帮助你管理这些磁盘空间，解决容量问题呢?

当数据库已经快挤满服务器的硬盘空间时，再向往数据库服务器增加更多的磁盘空间并不一定总是一件轻松的事情。可能需要花费几个月的时间来获取额外的硬件，并为增加服务器的硬盘空间容量磁盘设计一个时间进度计划。因此，如果你的磁盘空间容量有问题，你就需要找到一个方法使你的数据库具有即插即用的能力，以便管理这种容量问题。“即插即用”在这里的意思是你需要一种方法，让你可以将数据库从一个服务器快速复制到另外一个服务器，并能够同时花费最少的精力就可以修改应用程序获取数据所需要的IP地址。通过使用DNS，你可以将应用程序快速地指向数据库的新地址。当然，你必须设计好你的应用程序连接策略来处理这种数据库变动问题。

在上文中所述的如何使用DNS的例子中，我们探讨了与SQL Server的物理服务器IP地址有逻辑关系的单个DNS域名。如果你只是因为磁盘空间容量问题而想将一个数据库从一台服务器转移到另一台服务器，那么这种策略就没有什么作用了。这时候，你需要开发一个能够让每一个应用程序都拥有一个与别不同的名字的逻辑DNS命名策略，而不是让同一台服务器上所有的数据库都使用同一个DNS域名。

假设你有一个数据库服务器，里面包含了与订单、财会、人事和结算这四个系统有关的数据库。由以下四个数据库分别负责这四个方面的应用：Order、REV、HR和Billing。在这种情况下，你应当为每个不同的应用定义不同的DNS域名，可以使用像ORDER、REV、HR和 BILLING这样的DNS域名。让每个数据库应用的连接字符串使用合适的DNS域名，以确保应用程序指向各自的数据库所在的当前物理服务器。当你因为容量问题而需要将其中某个数据库从当前服务器转移到另外一个服务器时，你只需要将该数据库的DNS域名指向新的数据库服务器即可。

你可以还利用逻辑DNS命名法来处理其他问题。假设对于上述的每一种应用，你都分别有一个开发环境，一个质量保证环境和一个生产环境。在这种情况下，你可以给所有的DNS域名附加一个环境后缀。例如，对于BILLING，可以把开发环境下的DNS域名改为BILLINGDV，质量保证环境下的为BILLINGQA，而生产环境下的为BILLINGDV。

假设你有某个数据库服务器的CPU使用率特别高，那么通过使用DNS，你可以将一个或多个数据库快速地从这个不堪重负的服务器中转移到尚未饱和的服务器，然后将其DNS地址重新指向新服务器。这给你提供了一个低技术含量的解决方案来平衡数据库服务器的CPU使用情况。

通过设计进行管理

中国有句老话叫“因地制宜”，用在这里也挺合适，因为每一台服务器的环境都有其独特的需求。如果你的环境中，单个服务器上涉及到用多个数据库来处理多种不同的应用，那么设计好连接策略来尽量减少随着时间推移可能会遇到的问题是很有用的。如果你有机会购置一台新的机器，并要将你的应用程序移植到这台机器上的话，可以考虑一下是否需要使用逻辑DNS域名来解决与环境管理相关的问题。