Question

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

到目前为止我所拥有的：

我目前使用以下方法 - ＆gt;

 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 ??）分钟调用一次，如果是否定结果，请再次尝试减少误报。

这里有一个类似的问题 - ＆gt; Detecting if SQL server is running 但它在这方面与我的不同：

我只检查1台服务器
我正在寻找一种反应性方式而不是主动

所以最后，有更优雅的方式来做到这一点吗？这都将是“网内”检测。

P.S。在下面的答案中提供一些背景请求：我的应用程序是一个基本的CRUD应用程序，可以连接到我们的中央SQL Server或本地SQLExpress服务器。我有一个合并复制模块，使它们保持同步，并且DAL绑定到User.Setting值。我已经可以手动将它们从中央翻转到本地并返回。我只是想实现一种让它自动执行此操作的方法。我有一个NetworkChangeDetection类，它运行得很好，但很明显，它没有检测到远程SQL。

Answer 1

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

在我看来，只有连接到TCP有几个drawbaks：

它省略了非TCP协议，如本地共享内存（LPC）或远程网络管道（SMB）
它需要硬编码的TCP端口号，而不是让实例端口监听自动发现工作（SQL浏览器和朋友）
它只确定可以建立OS级别套接字，它不验证SQL Server本身是否处于可运行状态（非屈服调度程序可能会阻止网络IO请求接受，调度程序过载和工作者饥饿可能会这样做，内存资源耗尽等）。

不幸的是，没有办法从SQL Server本身那里得到一个通知，说'嘿，我很活跃，你不会发送一些请求吗？'。我不知道胖客户端的所有细节（“厚应用程序”），但也许您应该研究一个不同的比喻：客户端所有在SQL Express实例上本地工作，并且这些实例同步服务器可用时的数据。 Service Broker是专门针对此连接重试模式设计的，由于其异步松散耦合编程API，它将隐藏服务器可用性。

如何实现Exchange，如内部SQL Server的可用性监视

到目前为止我所拥有的：

1 个答案: