相关疑难解决方法(0)

出于故障排除目的，我希望能够检查客户端是否可以连接到 SQL Server 实例，而与可能无法连接到 SQL Server 的应用程序无关。

有没有一种简单的方法（也就是说，不必安装第 3 方软件）使用默认的 Windows 系统工具来做到这一点？也许使用脚本或网络应用程序？

我已经在 Ubuntu 16.04 机器上为 SQL Server 设置了 Microsoft ODBC Driver 13。我现在正在尝试测试一个数据库连接，其中包括服务器名称和实例名称。

以下都可以在 Windows 机器上正常工作：

sqlcmd -S "SERVERNAME\INSTANCENAME" -U User -P pwd -d DatabaseName -Q "SELECT TOP 5 Id FROM dbo.MyTable;"
sqlcmd -S SERVERNAME\INSTANCENAME -U User -P pwd -d DatabaseName -Q "SELECT TOP 5 Id FROM dbo.MyTable;"

但是，它们都不适用于 Linux - 它们都返回下面的错误消息。该错误意味着找不到服务器：

Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 13 for SQL Server : MAX_PROVS: Error Locating Server/Instance Specified [xFFFFFFFF]. . …

以前的高级 DBA 为我们整个公司的每个 SQL Server 中的所有驱动器设置了挂载点。新的高级 DBA被挂载点吓坏了想改变我们的标准（我认为主要是因为他没有使用它们的经验）。

根据大量 Internet 搜索的结果，我找不到任何（SQL Server 2000 后）不使用挂载点的理由。

有没有人知道有关此主题的 Windows 操作系统限制？

• 我最近经常听到“操作系统无法识别挂载点”的说法。（不真实，基于我对我们使用的 Windows Server 版本的研究）。

是否有任何基于证据或经验的理由不将挂载点与 SQL Server 一起使用？

• 假设用完驱动器号对我们来说不是问题。

我的理解是挂载点对于隔离工作负载非常有用。

任何人都可以确认或反驳我的理解，挂载点实际上比一个驱动器更有效地隔离/隔离不同类型的数据和日志文件（系统数据库文件、用户数据库文件、tempDB）的数据文件、日志文件和 tempdb ?