表 1 汇总了各个选项使例程成功运行或失败的方式。请注意，如果您不设置 CommandBehavior.CloseConnection 选项，您的操作最终会失败 — 即使在使用绑定控件的情况下也是如此。即使您使用该选项，但如果您没有使用复杂的绑定控件，或者没有手工关闭 SqlDataAdapter 或 SqlConnection，该进程仍然会失败。
当我结束了这些示例应用程序的运行后，我已经生成了 1000 多个以上的池连接 — 所有连接均处于孤立状态。虽然“SQL Server 用户连接”计数为 0，但留下大约 40 个连接池。在我重新引导系统之前，孤立的池不会消失。
我用于此测试的示例应用程序包括使用 DataAdapter 来返回行的例程。除非您手工管理连接，否则，DataAdapter 将正确地打开和关闭 SqlConnection 对象，因此，您不太可能遇到孤立的池连接。不过，如果您的应用程序同时使用 DataReader 和 DataAdapter，您可能会发现，如果某个连接与一个未关闭的 DataReader 相关联，则 DataAdapter 无法针对该连接运行查询。
确定连接池何时达到最大连接数
正如我在 "Swimming in the .NET Connection Pool" 一文中讨论的那样，当连接池达到您通过 "Max Pool Size ConnectionString" 选项指定的最大连接数时，ADO.NET 将阻止任何随后打开额外连接的尝试。如果某个连接在您在 "ConnectionTimeout 选项中指定的时间之前变为可用，.NET 数据提供程序将向您的应用程序传递一个指向该连接的指针，以便将控件返回给应用程序。不过，如果没有及时释放任何连接，连接请求将引发 InvalidOperationException 异常。
现在您必须决定要采取的措施，我不建议您告诉用户您已经用完了所有连接。有些应用程序会通知用户系统正忙于帮助其他客户，并建议用户稍后进行访问。其他应用程序则播放一段动画，通知用户系统尚未死锁，而是正在忙于处理他们的请求。同时，您的代码重新尝试操作。在所有情况下，您应该记录这些故障，以便帮助诊断问题的症结所在，并记录您已经耗尽了资源。
监视连接池
您已经打开和关闭了一个连接，现在您希望知道该连接是否仍然处于打开状态。您可以使用几种方法来确定有多少连接仍然处于打开状态，以及它们正在执行何种操作：
| ? | 运行 sp_who 或 sp_who2。这些系统存储过程从 sysprocess 系统表返回信息，该系统表显示所有工作进程的状态及其有关信息。通常，您会看到每个连接有一个服务器进程 ID (SPID)。如果您是通过在连接字符串中使用 Application Name 参数来命名您的连接的，那么，您将很容易找到工作的连接。 |
| ? | 使用带有 SQLProfiler TSQL_Replay 模板的 SQL Server 事件探查器来跟踪打开的连接。如果您很熟悉事件探查器，此方法比通过使用 sp_who 进行轮询要更容易。 |
| ? | 使用性能监视器来监视池和连接。我稍后再讨论此方法。 |
| ? | 在代码中监视性能计数器。您可以通过使用例程来提取计数器或通过使用新的 .NET PerformanceCounter 控件来监视连接池的状况和已建立的连接的数量。这两种方法都包括在您可以从 http://www.sqlmag.com 进行下载的示例应用程序中。 |
现在我们将讨论如何查找连接池计数器，以及如何使用这些监视方法。
连接池计数器在哪里？要监视连接池计数器，您必须监视 ADO.NET 在其中创建和增加这些计数器的系统。如果您从远程系统进行连接，ADO.NET 并不总是在 Microsoft IIS 服务器或 SQL Server 上创建池;它在 ADO.NET 代码运行的系统上创建池。此系统可以是运行 IIS、Web 应用程序或 Web 服务的远程 Windows 或中间层系统。相反，SQL Server 性能计数器位于 SQL Server 系统上 — 而不是客户端上。
使用性能监视器来监视池。如果您使用 Microsoft 管理控制台 (MMC) Windows 2000 系统监视器管理单元，则您
