Server在线支持数据库,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)单机单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
    运转需求花费多量能源的查询(比方,对大型表试行复杂的连通)或恐怕引致堵塞的查询。那推进幸免将
    DAC
    与其余现存的服务器难点混淆。为了防止爆发地下的梗塞情况,如若非得推行大概会生出短路的查询,则尽量在依附快照的隔开品级下运营查询;也许,将事情隔开分离等级设置为
    READ UNCOMMITTED,将 LOCK_TIMEOUT 值设置为非常的短的值(如 3000阿秒),只怕同有的时候间推行那三种操作。那足避防止 DAC
    会话被封堵。然则,依照 SQL Server 所处的场合,DAC
    会话大概会在闩锁上被堵塞。可以运用 CNT哈弗L-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
      的职务),并甘休与其涉嫌的对话以释放工作线程。请留神,终止单个会话或许相当不足,可能须要结束八个会话。

我通过测试得到的结论是:对于单机单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 myServer\InstanceName -U myUser -P myPassword
sqlcmd -S xxx.xxx.xxx.xxx\InstanceName -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 myServer\InstanceName -U myUser -P myPassword -A
sqlcmd -S xxx.xxx.xxx.xxx\InstanceName -U myUser -P myPassword -A
sqlcmd -S ADMIN:myServer\InstanceName -U myUser -P myPassword
sqlcmd -S ADMIN:xxx.xxx.xxx.xxx\InstanceName -U myUser -P myPassword

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

发表评论

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

网站地图xml地图