减少数据库管理开销方法简介

连接应用程序

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

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，你可以将应用程序快速地指向数据库的新地址。当然，你必须设计好你的应用程序连接策略来处理这种数据库变动问题。

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

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

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