如何使用专用管理连接进行问题诊断和处理,Server中DAC连接及其它

DAC(Dedicated Admin Connection卡塔尔国是SQL Server
二〇〇五引进的二个东西,指标是在SQL
Server产生严重品质难点的时候仍保留少数的能源保障管理员可以施行一些简易的吩咐用于难点确诊、释放财富、杀死肇事进度等。微软官方对DAC的注解:太阳集团游戏官方网站,动用专项使用管理员连接.aspx)。对于DAC使用的雷同情况,有多个不错的Blog值得推荐介绍:

SQL Server
为组织者提供了风流倜傥种奇特的确诊连接,以供在不或者与服务器构造建设专门的学问连接时使用。尽管在
SQL Server 不响应规范连接乞求时,管理员也能够利用此诊断连接访问 SQL
Server,以便实施确诊查询并消除难点。

地点的两篇blog涉及到的中坚是DAC访谈单机单实例的情事。本文试图对DAC访谈单机多实例的事态也做个研讨。

此专项使用助理馆员连接 (DAC) 扶植 SQL Server 的加密功能和其他安全效用。DAC
只允许将客户上下文切换来别的管理顾客。

1卡塔 尔(阿拉伯语:قطر‎单机单SQL Server实例,且SQL Server实例使用默许端口(1433卡塔 尔(阿拉伯语:قطر‎

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)。

使用 DAC 连接

暗许景况下,只可以从服务器上运转的客户端建构连接。不一样意实行互联网连接,除非它们是利用带
sp_configure 存款和储蓄进度配置的。

只有 SQL Server sysadmin 角色的积极分子可以使用 DAC 连接。

因此运用专项使用的助理馆员按钮 (-A) 的 sqlcmd
命令提醒实用工具,可以支撑和应用 DAC。有关使用 sqlcmd
的详细新闻,请参阅。您还能将前缀 admin: 连接到实例名上,格式为
sqlcmd -Sadmin:*<instance_name>。还是能透过连续几日到
admin:<
实例名*>,从 SQL Server Management Studio
查询编辑器运维 DAC。

2卡塔 尔(英语:State of Qatar)单机单SQL Server实例,SQL Server实例使用非暗中认可端口

限制

由于 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
    运营须求开支大批量财富的查询(比方,对大型表施行复杂的交接卡塔 尔(英语:State of Qatar)或大概变成窒碍的询问。那有利于防守将
    DAC
    与任何现存的服务器难题混淆。为了防止产生地下的短路情状,假若非得试行恐怕会生出短路的查询,则尽量在借助快速照相的隔绝等级下运营查询;或许,将事情隔绝等级设置为
    READ UNCOMMITTED,将 LOCK_TIMEOUT 值设置为超级短的值(如 2003皮秒卡塔 尔(阿拉伯语:قطر‎,大概同有的时候候实行那三种操作。这足以幸免 DAC
    会话被打断。可是,依据 SQL Server 所处的意况,DAC
    会话只怕会在闩锁上被窒碍。能够使用 CNT中华VL-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卡塔 尔(英语:State of Qatar)或行使了复杂连接的动态处理视图。有关质量影响的信息,请参阅特定的文书档案。

  • 询问目录视图。

  • 基本 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
      的天职卡塔尔,并终止与其关系的对话以释放专业线程。请在意,终止单个会话恐怕远远不足,恐怕要求结束八个会话。

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

DAC 端口

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

陈设远程管理连接之后,会马上启用 DAC 侦听器而不用再次起动 SQL
Server,而且客商端能够立刻远程连接到 DAC。通过先在本地利用 DAC 连接到
SQL Server,然后再实行 sp_configure 存款和储蓄进程接收远程连接,则就是SQL Server 甘休响应,DAC 侦听器如故能够选用远程连接。

对此集结配置,DAC 在私下认可情状下是剥夺的。客户能够施行 sp_configure
remote 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

3)单机多SQL Server实例

示例

在这里示例中,管理员开掘服务器 URAN123
不响应,由此要确诊该难题。为此,客商激活 sqlcmd
命令提醒实用工具,并应用 -A 指明 DAC 连接到服务器 URAN123

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

明日,管理员能够实践查询来确诊难点,何况能够告生机勃勃段落截至响应的对话。

通过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.通过端口访问的这条路我没能走通。

4卡塔尔国DAC访谈与防火墙

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

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

5卡塔 尔(阿拉伯语:قطر‎怎么样确认当前是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”。

发表评论

电子邮件地址不会被公开。 必填项已用*标注