哪些使用专项使用管理总是进行难题会诊和管理

2019-10-05 作者:数据库   |   浏览(71)
我通过测试得到的结论是:对于单机单SQL Server实例,使用非默认端口时候的DAC访问跟使用默认端口1433时候完全一样。网上的一些论坛说要确保“SQL Server Browser”在运行,似乎不是必要的,至少我测试(用的SQL Server 2008 R2 SP3)过程中“SQL Server Browser”是不是在运行不影响访问。

SQL Server 为管理员提供了一种特殊的诊断连接,以供在无法与服务器建立标准连接时使用。即使在 SQL Server 不响应标准连接请求时,管理员也可以使用此诊断连接访问 SQL Server,以便执行诊断查询并解决问题。

通过DAC来访问单机多SQL Server实例的情况要复杂一些。上面的几条命令行在这种情况下都会失效。原因在两个:
a) DAC访问是实例级别的,服务端得有办法知道你要访问的是哪个实例;
b) 在单机多实例的情况下监视DAC访问的是随机端口,而不再是默认的1434(当然,具体的端口号在SQL Server启动的时候是确定的,可以在SQL Server启动的Log中找到:打开SSMS--->连接到数据库实例--->Management--->SQL Server Logs--->Current,在里面找到类似”Dedicated admin connection support was established for listening locally on port 50458.“)

--怎么破?
我们在访问数据库引擎的时候,碰到单机多实例的情况有两种办法,一种是在配置S参数的时候加上实例名,一种是加实例端口号。命令行的形式类似下面:
sqlcmd -S myServerInstanceName -U myUser -P myPassword
sqlcmd -S xxx.xxx.xxx.xxxInstanceName -U myUser -P myPassword
sqlcmd -S myServer,6xxx -U myUser -P myPassword
sqlcmd -S xxx.xxx.xxx.xxx,6xxx -U myUser -P myPassword

先从实例名着手:
sqlcmd -S myServerInstanceName -U myUser -P myPassword -A
sqlcmd -S xxx.xxx.xxx.xxxInstanceName -U myUser -P myPassword -A
sqlcmd -S ADMIN:myServerInstanceName -U myUser -P myPassword
sqlcmd -S ADMIN:xxx.xxx.xxx.xxxInstanceName -U myUser -P myPassword

经测试确认,以上4种连接方式都是OK的。注意一点,对于InstanceName的解析是服务器上的“SQL Server Browser”进行的,如果这个服务不在运行,DAC的访问是要失败的。流程是:Browser根据“myServerInstanceName”或者“xxx.xxx.xxx.xxxInstanceName”找到你要访问的实例,然后根据“-A”或者“ADMIN:”找到你要访问的端口。

既然这样可以进行DAC访问,那用类似访问数据库引擎的方式,把上面命令中的“InstanceName”改成",xxxx"格式的端口号是不是也行呢?
sqlcmd -S myServer,xxxx -U myUser -P myPassword -A
sqlcmd -S xxx.xxx.xxx.xxx,xxxx -U myUser -P myPassword -A
sqlcmd -S ADMIN:myServer,xxxx -U myUser -P myPassword
sqlcmd -S ADMIN:xxx.xxx.xxx.xxx,xxxx -U myUser -P myPassword

如果你在几个命令行中配的端口号跟访问数据库引擎时候配置的端口号是一样的话,答案是不行。原因在哪里呢?那个端口是数据库引擎的访问端口,并不是被监听的DAC端口,因为不在一个频道上DAC还不知道你想访问。我的理解,在命令行中指定了端口号的情况下,Browser认为那就是你想访问的端口,结果因为它并不是那个随机的DAC端口而导致了失败。

DAC访问侦听跟数据库引擎一样,从根本上来说也是一个tcp服务(关于这一点你可以查看sys.endpoints来确认)。是服务,我们如果能知道它侦听的端口号就应该能解决问题。但不幸也在这儿,如上面b)所说,在单机多实例的情况下这个被监听的端口是随机的。视图sys.endpoints是能查到当前SQL Server实例上的tcp服务信息的,每个endpoint都有一条记录,比如你就能在这里查到用于镜像的5022,但遗憾的是对于DAC,端口那一列却显示的是0.通过端口访问的这条路我没能走通。

SQL Server 尽力使 DAC 连接成功,但在非常特殊的情况下也可能会出现连接失败。

可以使用下面的SQL:
select s.session_id,
 s.login_time,
 s.login_name,
 s.host_name,
 p.endpoint_id,
 p.protocol_desc,
 p.name
from sys.dm_exec_sessions s
inner join sys.endpoints p on s.endpoint_id = p.endpoint_id

你可以从login_time,login_name,host_name来判断出哪一个是你当前的连接session,如果是DAC连接的话,你能从name列看到“Dedicated Admin Connection”。

限制

由于 DAC 仅用于在极少数情况下诊断服务器问题,因此对连接有一些限制:

  • 为了保证有可用的连接资源,每个 SQL Server 实例只允许使用一个 DAC。如果 DAC 连接已经激活,则通过 DAC 进行连接的任何新请求都将被拒绝,并出现错误 17810。

  • 为了保留资源,SQL Server Express 不侦听 DAC 端口,除非使用跟踪标志 7806 进行启动。

  • DAC 最初尝试连接到与登录帐户关联的默认数据库。连接成功后,可以连接到 master 数据库。如果默认数据库脱机或不可用,则连接返回错误 4060。但是,如果使用以下命令覆盖默认数据库,改为连接到 master 数据库,则连接会成功:

    sqlcmd –A –d master

    由于只要启动数据库引擎实例,就能保证 master 数据库处于可用状态,因此建议使用 DAC 连接到 master 数据库。

  • SQL Server 禁止使用 DAC 运行并行查询或命令。例如,如果使用 DAC 执行下列任何语句,都会生成错误 3637。

    • RESTORE

    • BACKUP

  • DAC 只能使用有限的资源。请勿使用 DAC 运行需要消耗大量资源的查询(例如,对大型表执行复杂的联接)或可能造成阻塞的查询。这有助于防止将 DAC 与任何现有的服务器问题混淆。为了避免发生潜在的阻塞情况,如果必须执行可能会发生阻塞的查询,则尽可能在基于快照的隔离级别下运行查询;或者,将事务隔离级别设置为 READ UNCOMMITTED,将 LOCK_TIMEOUT 值设置为较短的值(如 2000 毫秒),或者同时执行这两种操作。这可以防止 DAC 会话被阻塞。但是,根据 SQL Server 所处的状态,DAC 会话可能会在闩锁上被阻塞。可以使用 CNTRL-C 终止 DAC 会话,但不能保证一定成功。如果失败,唯一的选择是重新启动 SQL Server。

  • 为保证连接成功并排除 DAC 故障,SQL Server 保留了一定的资源用于处理 DAC 上运行的命令。通常这些资源只够执行简单的诊断和故障排除功能,如下所示。

虽然理论上可以运行任何不必在 DAC 上并行执行的 Transact-SQL 语句,但极力建议您限制使用下列诊断和故障排除命令:

  • 查询动态管理视图以进行基本的诊断,例如查询 sys.dm_tran_locks 以了解锁定状态,查询 sys.dm_os_memory_cache_counters 以检查缓存质量,查询 sys.dm_exec_requests 和 sys.dm_exec_sessions 以了解活动的会话和请求。避免使用需要消耗大量资源的动态管理视图(例如,sys.dm_tran_version_store 扫描整个版本存储区,并且会导致大量的 I/O)或使用了复杂联接的动态管理视图。有关性能影响的信息,请参阅特定的文档。

  • 查询目录视图。

  • 基本 DBCC 命令,例如 DBCC FREEPROCCACHE、DBCC FREESYSTEMCACHE、DBCC DROPCLEANBUFFERS, 和 DBCC SQLPERF。请勿运行需要消耗大量资源的命令,如 DBCC CHECKDB、DBCC DBREINDEX 或 DBCC SHRINKDATABASE。

  • Transact-SQL KILL <spid> 命令。根据 SQL Server 的状态,KILL 命令并非一定会成功;如果失败,则唯一的选择是重新启动 SQL Server。下面是一般的指导原则:

    • 请通过查询 SELECT * FROM sys.dm_exec_sessions WHERE session_id = <spid> 来验证 SPID 是否已被实际终止。如果没有返回任何行,则表明会话已被终止。

    • 如果会话仍在运行,则通过运行查询 SELECT * FROM sys.dm_os_tasks WHERE session_id = <spid> 来验证是否为此会话分配了任务。如果发现还有任务,则很可能当前正在终止会话。注意,此操作可能会持续很长时间,也可能根本不会成功。

    • 如果在与此会话关联的 sys.dm_os_tasks 中没有任何任务,但是在执行 KILL 命令后该会话仍然出现在 sys.dm_exec_sessions 中,则表明没有可用的工作线程。选择某个当前正在运行的任务(在 sys.dm_os_tasks 视图中列出的 sessions_id <> NULL 的任务),并终止与其关联的会话以释放工作线程。请注意,终止单个会话可能不够,可能需要终止多个会话。

DAC(Dedicated Admin Connection)是SQL Server 2005引入的一个东西,目的是在SQL Server发生严重性能问题的时候仍保留有限的资源保证管理员能够执行一些简单的命令用于问题诊断、释放资源、杀死肇事进程等。微软官方对DAC的说明:使用专用管理员连接.aspx)。对于DAC使用的一般情况,有两个不错的Blog值得推荐:

使用 DAC 连接

默认情况下,只能从服务器上运行的客户端建立连接。不允许进行网络连接,除非它们是使用带 的 sp_configure 存储过程配置的。

只有 SQL Server sysadmin 角色的成员可以使用 DAC 连接。

通过使用专用的管理员开关 (-A) 的 sqlcmd 命令提示实用工具,可以支持和使用 DAC。有关使用 sqlcmd 的详细信息,请参阅。您还可以将前缀 admin: 连接到实例名上,格式为 sqlcmd -Sadmin:*<instance_name>。还可以通过连接到 admin:<实例名*>,从 SQL Server Management Studio 查询编辑器启动 DAC。

如果有人通过我上面提到的有效的方式进行DAC访问却不幸失败了,也请不要奇怪。抛开端口劫持等特殊情况,DAC访问失败最常见的就是受到防火墙设置的拦截。对于上面提到的两种单机单实例的情况,只要确认服务端配置了允许对tcp1434端口的访问,DAC连接应该是没有问题的;复杂的情况仍然是单机多实例。

对于单机多实例的情况,由于DAC侦听的端口是随机的,不能指定,所以我们没法在防火墙上给它开口子,除非关闭防火墙。事实上,我在测试的时候就是让服务器上的Windows防火墙对域范围内的访问不起作用(关闭针对域内部访问的拦截)的。那要想从外网访问怎么办?总不能为了一个DAC连接把这台服务器赤裸裸的暴露出来(给它配外网IP)或者关掉公司的级别的防火墙吧?这倒不必,可以用VPN或者端口映射从防火墙上开个小口子,这样你就能连接到局域网,从那进行DAC访问。

DAC 端口

SQL Server 在启动数据库引擎时动态分配的专用 TCP/IP 端口上侦听 DAC。错误日志包含所侦听的 DAC 所在的端口号。默认情况下,DAC 侦听器只接受本地端口上的连接。有关激活远程管理员连接的代码示例,请参阅 。

配置远程管理连接之后,会立即启用 DAC 侦听器而不必重新启动 SQL Server,并且客户端可以立即远程连接到 DAC。通过先在本地使用 DAC 连接到 SQL Server,然后再执行 sp_configure 存储过程接受远程连接,则即使 SQL Server 停止响应,DAC 侦听器仍然可以接受远程连接。

对于群集配置,DAC 在默认情况下是禁用的。用户可以执行 sp_configureremote admin connection 选项,使 DAC 侦听器能够访问远程连接。如果 SQL Server 停止响应并且未启用 DAC 侦听器,则可能必须重新启动 SQL Server 来连接 DAC。因此,建议在群集系统上启用 remote admin connections 配置选项。

DAC 端口由 SQL Server 在启动时动态分配。当连接到默认实例时,DAC 会避免在连接时对 使用 SQL Server 解决协议 (SSRP) 请求。它先通过 TCP 端口 1434 进行连接。如果失败,则通过 SSRP 调用来获取端口。如果 SQL Server 浏览器没有侦听 SSRP 请求,则连接请求将返回错误。若要了解 DAC 所侦听的端口号,请参阅错误日志。如果将 SQL Server 配置为接受远程管理连接,则必须使用显式端口号启动 DAC:

sqlcmd –Stcp:*<server>,<port>*

SQL Server 错误日志列出了 DAC 的端口号,默认情况下为 1434。如果将 SQL Server 配置为只接受本地 DAC 连接,请使用以下命令和环回适配器进行连接:

sqlcmd –S127.0.0.1,1434

5)如何确认当前是DAC连接还是普通连接

示例

在此示例中,管理员发现服务器 URAN123 不响应,因此要诊断该问题。为此,用户激活 sqlcmd 命令提示实用工具,并使用 -A 指明 DAC 连接到服务器 URAN123

sqlcmd -S URAN123 -U sa -P <xxx> –A

现在,管理员可以执行查询来诊断问题,并且可以终止停止响应的会话。

4)DAC访问与防火墙

此专用管理员连接 (DAC) 支持 SQL Server 的加密功能和其他安全功能。DAC 只允许将用户上下文切换到其他管理用户。

--以下的形式都可以访问
sqlcmd -S myServer -U myUser -P myPassword -A
sqlcmd -S ADMIN:myServer -U myUser -P myPassword
sqlcmd -S myServer,1434 -U myUser -P myPassword
sqlcmd -S xxx.xxx.xxx.xxx -U myUser -P myPassword -A
sqlcmd -S xxx.xxx.xxx.xxx,1434 -U myUser -P myPassword

说明:
a) sqlcmd命令行中参数与参数值之间可以有空格也可以没有;如果你的密码中有空格,你可以用双引号把你的密码引起来;
b) sqlcmd命令中的“-S”其实也可以用"/S",其它参数也一样;
c) 1434是SQL Server连接的默认端口号;
d) 在服务器前加"ADMIN:"也是为了指定进行DAC连接;
e) “-A”是在sqlcmd命令行中指定DAC连接的参数;
f) "-A","ADMIN:",",1434"不能在一条命令中出现两个或以上,否则会报错;
g) 不在命令行中加入这3个参数("-A","ADMIN:",",1434")的任何一个,登录也能成功,差别在于你使用的连接是普通连接,不是DAC连接。一般来说,普通连接能用的资源更多,但是当系统性能出现严重问题的时候普通连接可能没法建立,这也是引入DAC的初衷;再就是DAC连接下能看到一些有助于诊断的秘密视图(参见上面推荐的第一个blog)。

2)单机单SQL Server实例,SQL Server实例使用非默认端口

3)单机多SQL Server实例

上面的两篇blog涉及到的基本是DAC访问单机单实例的情况。本文试图对DAC访问单机多实例的情况也做个探讨。

1)单机单SQL Server实例,且SQL Server实例使用默认端口(1433)

本文由www.bifa365365.com发布于数据库,转载请注明出处:哪些使用专项使用管理总是进行难题会诊和管理

关键词: www.bifa3653