c# - 如何实现类似 Exchange 的内部 SQL Server 可用性监控

Question

我们有一个依赖中央 SQL 服务器的内部应用程序(胖客户端)。该应用程序是一个桌面应用程序，允许用户在“离线”模式下工作(例如 Outlook)。我需要完成的是一种准确判断 SQL 是否可用的方法。

我目前拥有的:

我目前使用的是下面的方法-->

 internal static void CheckSQLAvailability()
    {
        using (TcpClient tcpc = new TcpClient())
        {
            try
            {
                tcpc.Connect(Settings.Default.LiveSQLServer, Settings.Default.LiveSQLServerPort);
                IsSQLAvailable = true;                    
            }
            catch
            {
                IsSQLAvailable = false;
            }
        }
    }

由于以下原因，我对这种方法并不着迷。

• 容易出现假阴性
• 需要“手动”调用
• 看起来“很臭”(try/catch)

我曾想过使用计时器，每 X(3??) 分钟调用一次，如果结果为阴性，则再次尝试以减少假阴性。

这里有一个类似的问题--> Detecting if SQL server is running但它在这些方面与我的不同:

• 我只检查 1 个服务器
• 我正在寻找一种被动的方式而不是主动的方式

那么到底有没有更优雅的方式来实现呢？这都是“网络内”检测。

附言按照以下答案的要求提供一些背景知识:我的应用程序是一个基本的 CRUD 应用程序，可以连接到我们的中央 SQL Server 或本地 SQLExpress 服务器。我有一个使它们保持同步的合并复制模块，并且 DAL 绑定(bind)到 User.Setting 值。我已经可以手动将它们从 Central 切换到 Local 并返回。我只想实现一种让它自动执行此操作的方法。我有一个运行良好的 NetworkChangeDetection 类，但很明显，它没有检测到远程 SQL。

Answer 1

考虑 Windows 集群监视器对 SQL Server 集群资源的作用:它实际上连接并运行虚拟查询 (SELECT @@version)。这表明 SQL 正在运行，正在主动监听请求，并且能够运行请求并返回结果。对于集群监视器，对此查询的响应是服务器的“心跳”，如果它未能获得响应，无论出于何种原因，它都可能启动集群故障转移。

在我看来，仅连接到 TCP 有几个缺点:

• 它省略了非 TCP 协议(protocol)，例如本地共享内存 (LPC) 或远程网络管道 (SMB)
• 它需要硬编码的 TCP 端口号，而不是让实例端口监听自动发现来完成它的工作(SQL 浏览器和 friend )
• 它只确定可以建立操作系统级别的套接字，它不验证 SQL Server 本身是否处于可运行状态(非生成调度程序可能会阻止网络 IO 请求接受，调度程序过载和工作人员饥饿可能会做同样的事情，内存资源耗尽等)。

不幸的是，没有办法从 SQL Server 本身获得通知说“嘿，我很活跃，你不发送一些请求吗？”。我不知道您的胖客户端(“胖应用程序”)的所有详细信息，但也许您应该研究一个不同的比喻:客户端所有都在本地工作，在 SQL Express 实例上，并且这些实例同步服务器可用时的数据。 Service Broker专为这种连接重试模式而设计，由于其异步松耦合编程 API，它会隐藏服务器可用性。