澳门新萄京官方网站-www.8455.com-澳门新萄京赌场网址

澳门新萄京官方网站:故障排查实战案例,数据

2019-10-05 作者:数据库网络   |   浏览(142)

前言

  本篇文章写在新春佳节前夕,也是给IT运维朋友一个警醒,在春节长假前请妥善体检自己的系统安心过个年。

  千里之堤毁于蚁穴,一条看似简单的语句就能拖垮整个系统,您的SQL Server很久没体检了吧? 就像一块藏着刀片的蛋糕!怎能安度春节?

  日志暴增的问题处理过很多,这只是很常规的一次,但是对于不是很熟练的运维兄弟,可能日志暴增这样的问题会被一带而过,或者解释成突发情况而不去处理,那么隐患依然存在,在春节这样的长假发生可怎么办呢?

 

  本文使用的工具:SQL专家云平台专业体检工具 :www.zhuancloud.com

前言

  很多时候数据库的TempDB、日志等文件的暴增可能导致磁盘空间被占满,如果日常配置不到位,往往会导致数据库故障,业务被迫中断。

  这种文件暴增很难排查,经验不足的一些运维人员可能更是无法排查具体原因,导致问题不能彻底解决。

前言

  很多时候数据库的TempDB、日志等文件的暴增可能导致磁盘空间被占满,如果日常配置不到位,往往会导致数据库故障,业务被迫中断。

  这种文件暴增很难排查,经验不足的一些运维人员可能更是无法排查具体原因,导致问题不能彻底解决。

写在前面

  在QQ群,微信群,论坛中经常帮助使用SQL Server数据库的朋友解决问题,但是有一些最常见最基本的问题,每天都有人问,回答多了也不想再解答了,索性把这些问题整理一下,再有人问到直接发链接。

   一时想法而写这篇文章,问题可能不全面,后续会一直更新。

场景描述

  本案例是一个很成熟的ERP厂商的产品,接到用户紧急电话,说他们日志突然暴增磁盘告警,50G的数据库日志已经达到200G。

  澳门新萄京官方网站 1

 

  看到这有的看官可能会说,肯定是没定时做日志备份导致日志不断变大!或者说才200G 一点也不大呀!

  没错,日志不备份缺失会有这样的问题,但这情景是小儿科,不会拿出来写案例的,200G 确实也不大,但要分场景,在此客户平均10个G 的场景下 200G已经是爆炸式的问题了!

  为什么会拿出来写案例,就是因为想要告诉大家排查这样问题的思路,不要让这样的暴增单纯的说成突发情况!

场景描述

  客户系统比较稳定,用了5台机器做了AlwaysOn高可用组,完全实现了读写分离。磁盘也做了规划,主库日常操作TempDB需求在20G以下,所以TempDB所在的磁盘只配置了100个G的空间。

  本案例是客户突然接到监控报警,显示TempDB磁盘空间不足,可用空间不断减小直到耗尽。

  比较戏剧的是,这个客户早上刚刚做了巡检数据库情况稳定,没有什么异常。

  那么我初步判定,这必然是一次特殊操作或应用配置出错导致的问题。

场景描述

  客户系统比较稳定,用了5台机器做了AlwaysOn高可用组,完全实现了读写分离。磁盘也做了规划,主库日常操作TempDB需求在20G以下,所以TempDB所在的磁盘只配置了100个G的空间。

  本案例是客户突然接到监控报警,显示TempDB磁盘空间不足,可用空间不断减小直到耗尽。

  比较戏剧的是,这个客户早上刚刚做了巡检数据库情况稳定,没有什么异常。

  那么我初步判定,这必然是一次特殊操作或应用配置出错导致的问题。

基础问题收集

问题分析

  拿到收集文件我直入主题,查看日志的增长情况、写入状态、问题时间点等信息

  澳门新萄京官方网站 2

 

澳门新萄京官方网站,  在日志的分配空间我们了解到日志是在11点43分左右突然暴增一直增长到13点左右达到240G

澳门新萄京官方网站:故障排查实战案例,数据库实战案例。  澳门新萄京官方网站 3

 

  分配空间也是同样的情况在11点43分左右暴增,后期在1点半的下降就是日志备份让使用空间被释放。

  澳门新萄京官方网站 4

  

  日志文件的写入也符合这个时间点,在11点43分左右写入达到40MB/秒,并且持续了1个多小时。

  澳门新萄京官方网站 5

 

   通过这几张图,我们很清晰的就能定位到日志暴增的时间点,下面只要找到对应时间点的语句即可!

  我的排查思路有些不同,持续1个小时的写入,必然伴随着日志文件的增长(文件增长设置固定值100MB),这里需要提一下:这就是固定增长的好处,因为当达到240G 如果按照默认10%增长,那么一次需要增24G 磁盘已经没有那么多空间,则会导致报错,系统中断!

  回到排查思路,这里我直接查看对应时间点系统的等待情况:

  澳门新萄京官方网站 6

 

  直接找到日志文件增长的等待类型,查看运行的语句确实运行时间是从11点15到13点15,和日志增长的情况吻合!!

  就这样,只花了10分钟就定位到问题,找到语句,由于存储过程加密,我无法看到里面的代码,但是暴增的语句已经找到,需要软件厂商自行处理啦!!

  就是这样简单,打完收工!所以不要放过这样的问题排查!

深入指标分析

深入指标分析

资源下载

  描述:XX版本数据库操作系统在哪里下载?

  答:  里面很多东西,有兴趣的自己看吧

后怕

  为什么说不能放过这样问题的排查!!!

  首先,这个系统正准备上集群,集群大家都知道单机变多台,必然涉及到数据的同步,同步是要有消耗的,对写入的性能会有影响,细心的小伙伴可能已经看到这个语句消耗了多少资源,逻辑读,写,影响行数有多少了

  澳门新萄京官方网站 7

 

  没错,64亿的逻辑读!为什么会产生这么大的日志,导致暴增!因为写入1亿次,影响行数19亿,并且执行的时间不是在夜间的维护期,而是在中午11点15开始,这么大的处理在集群方案部署的时候一定要高度警惕,这么大的同步量完全可能导致集群严重延迟,甚至宕机!所以这不单单是一次日志暴增问题的排查了,也是对系统功能更加细致的了解,如果这样的问题没有及早发现,就算集群后期测试也不一定会被测试到,进而导致集群上线后的悲催。

 

 

PS:继逻辑读 23亿,34亿,45亿后这个案例有刷新了我见过的最大逻辑读 64亿!

  纪念一下

 

  文件看问题

  TempDB暴增必然伴随着文件的增长,首先我们看一下TempDB文件的增长情况。

  澳门新萄京官方网站 8

 

澳门新萄京官方网站:故障排查实战案例,数据库实战案例。  可见TempDB的分配空间在14点50几分的时候开始暴增,细心的朋友会发现这是1个G到6个G的增长,这是因为客户的TempDB配置了16个数据文件:

  

  澳门新萄京官方网站 9

 

  注:为什么配置这么多TempDB文件请参见:Expert 诊断优化系列------------------给TempDB 降温

  文件看问题

  TempDB暴增必然伴随着文件的增长,首先我们看一下TempDB文件的增长情况。

  澳门新萄京官方网站 10

 

  可见TempDB的分配空间在14点50几分的时候开始暴增,细心的朋友会发现这是1个G到6个G的增长,这是因为客户的TempDB配置了16个数据文件:

  

  澳门新萄京官方网站 11

 

  注:为什么配置这么多TempDB文件请参见:Expert 诊断优化系列------------------给TempDB 降温

连接问题

  描述:数据库连接不上

  澳门新萄京官方网站 12

  答:请确认SQL服务是否启动,用户密码是否正确,连接的实例名称,端口是否正确

  澳门新萄京官方网站 13

  

 

 

--------------博客地址---------------------------------------------------------------------------------------

博客地址 

 

 欢迎转载,请注明出处,谢谢!


什么造成了增长

  造成TempDB暴增原因很多语句使用临时表、语句排序、CheckDB等,但这些都是可以在语句中反应出来。所以下面我们分析一下语句。

  注:很多使用过SQL专家云平台或工具的朋友可能不会注意里面一些细节,其实很多细节(如上面的TempDB文件增长趋势和下面的语句分配空间)的设计都是解决一些疑难的问题。

  

  首先语句中的其中两个指标用户分配空间(MB)和内部对象分配空间(MB)指的就是对TempDB的使用消耗。

  注:用户分配空间可能是临时表使用的比较多,内部对象分配空间可能是排序或者hash join等操作(其他使用的消耗可以参见前面给出的链接文章)

  澳门新萄京官方网站 14

  分配空间越大,也就说明语句越消耗TempDB资源。

  我们有两种方式找到到底是什么操作导致的TempDB暴增,可以直接找时间点的语句,也可以在TempDB资源消耗的高到低顺序中找!

  为了全面了解一下TempDB的问题,这里我们采用第二种方式。

  那么我们就分析一下语句对TempDB资源被消耗的情况:

  步骤1:首先我们按照用户对象分配空间排序:澳门新萄京官方网站 15

 

 经过排查,这里面用户空间分配比较高的都是CDC的作业,服务器上确实运行这几个库的CDC作业。其他的一些操作的用户分配空间都比较小,所以这不是造成问题的原因!

 

 步骤2:接着我们按照内部对象分配空间排序:

 澳门新萄京官方网站 16

 

 这里发现最消耗空间的是CheckDB的操作,但时间点是对应不上的,所以这也不是问题的原因。

 继续排查:

 在消耗排位在第三的这个语句中我们发现了等待资源FGCB_ADD_REMOVE(这个可以简单理解为有大量的文件自动生长发生,这里是16个TempDB文件),并且使用的内部对象空间也很高,并且我们还发现有多个会话同时执行这样的高消耗操作。澳门新萄京官方网站 17

 

 继续深入:

 澳门新萄京官方网站 18

  性能计数器的表象也与之前的种种迹象相吻合。

  澳门新萄京官方网站 19

 

什么造成了增长

  造成TempDB暴增原因很多语句使用临时表、语句排序、CheckDB等,但这些都是可以在语句中反应出来。所以下面我们分析一下语句。

  注:很多使用过SQL专家云平台或工具的朋友可能不会注意里面一些细节,其实很多细节(如上面的TempDB文件增长趋势和下面的语句分配空间)的设计都是解决一些疑难的问题。

  

  首先语句中的其中两个指标用户分配空间(MB)和内部对象分配空间(MB)指的就是对TempDB的使用消耗。

  注:用户分配空间可能是临时表使用的比较多,内部对象分配空间可能是排序或者hash join等操作(其他使用的消耗可以参见前面给出的链接文章)

  澳门新萄京官方网站 20

  分配空间越大,也就说明语句越消耗TempDB资源。

  我们有两种方式找到到底是什么操作导致的TempDB暴增,可以直接找时间点的语句,也可以在TempDB资源消耗的高到低顺序中找!

  为了全面了解一下TempDB的问题,这里我们采用第二种方式。

  那么我们就分析一下语句对TempDB资源被消耗的情况:

  步骤1:首先我们按照用户对象分配空间排序:澳门新萄京官方网站 21

 

 经过排查,这里面用户空间分配比较高的都是CDC的作业,服务器上确实运行这几个库的CDC作业。其他的一些操作的用户分配空间都比较小,所以这不是造成问题的原因!

 

 步骤2:接着我们按照内部对象分配空间排序:

 澳门新萄京官方网站 22

 

 这里发现最消耗空间的是CheckDB的操作,但时间点是对应不上的,所以这也不是问题的原因。

 继续排查:

 在消耗排位在第三的这个语句中我们发现了等待资源FGCB_ADD_REMOVE(这个可以简单理解为有大量的文件自动生长发生,这里是16个TempDB文件),并且使用的内部对象空间也很高,并且我们还发现有多个会话同时执行这样的高消耗操作。澳门新萄京官方网站 23

 

 继续深入:

 澳门新萄京官方网站 24

  性能计数器的表象也与之前的种种迹象相吻合。

  澳门新萄京官方网站 25

 

日志问题

  描述:系统日志LDF满了 或 日志文件非常大 如何收缩?

  答:简单恢复模式下SQL Server会自动截断日志文件,完整模式下需要日志备份

  恢复模式查看

  澳门新萄京官方网站 26

  日志备份的方式

  澳门新萄京官方网站 27

  收缩日志

  澳门新萄京官方网站 28

 

  注:很多人使用简单模式习惯了,或者根本不知道自己用的什么模式,但是如果做的镜像,AlwaysOn这类方案日志必定是完整模式。

  日志不能收缩有较多的原因,常见的是没有备份和Replication 也就是使用镜像、AlwaysOn、cdc这些技术的时候日志同步中除了问题或这没有同步完成。

  一般正规军解决方式: 

  • 查看 sys.databases 里面 log_reuse_wait_desc字段 如果是nothing才能收缩 
  • log_reuse_wait_desc 为 backup 需要备份日志
  • Replication 则需要查看镜像、AlwaysOn、cdc这些技术状态是否正常,如果不正常,必须拆除或者调整为正常
  • 依次处理直到nothing才能收缩

  

 

总结

  系统运维就是保证系统平稳运行的工作,看似简单但个中奥妙和心酸只有运维人才能体会,不要放过每一个细节,一个简单突发情况处理可能引出一系列问题,而解决这些问题又是保证系统平稳运行基础,请给运维人多一些关爱吧,比如春节来个大红包,哇哈哈哈哈!!

  有的小伙伴已经开始春节休假了,祝大家新春快乐,系统平安!

 ----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

排查结论

  综合各项现象指标,可以分析出系统在下午14点57分左后开始执行TempDB高消耗操作,语句本身是一个近千行涉及大量表连接排序等操作的复杂存储过程,对TempDB造成暴增的问题负主要责任,而且雪上加霜的是从会话的标识可以看出,这不是一个语句只一次的执行,而是在特定的时间存在比较大的并发操作导致。

  与相关业务人员沟通,发现这是一个集团的类似报表的大消耗操作,因为对功能进行的调整,而程序人员的一次误操作而错误的指向了集群中的主库,而导致的问题。

 

--------------博客地址-----------------------------------------------------------------------------

原文地址: 

如有转载请保留原文地址! 

 

 ----------------------------------------------------------------------------------------------------

排查结论

  综合各项现象指标,可以分析出系统在下午14点57分左后开始执行TempDB高消耗操作,语句本身是一个近千行涉及大量表连接排序等操作的复杂存储过程,对TempDB造成暴增的问题负主要责任,而且雪上加霜的是从会话的标识可以看出,这不是一个语句只一次的执行,而是在特定的时间存在比较大的并发操作导致。

  与相关业务人员沟通,发现这是一个集团的类似报表的大消耗操作,因为对功能进行的调整,而程序人员的一次误操作而错误的指向了集群中的主库,而导致的问题。

 

--------------博客地址-----------------------------------------------------------------------------

原文地址: 

如有转载请保留原文地址! 

 

 ----------------------------------------------------------------------------------------------------

查询很久慢

  描述:查询很久都查不出数据,很慢!

  答:这样的情况出现一般是查询语句被其他语句阻塞。在查询中添加 select * from table with (nolock)如果能查出来说明阻塞

  具体的阻塞情况 可以使用sp_who2 或者 sys.dm_exec_requests 视图查询

  具体脚本(查看语句运行情况)

 1 WITH sess AS
 2 (
 3     SELECT
 4         es.session_id,
 5         database_name = DB_NAME(er.database_id),
 6         er.cpu_time,
 7         er.reads,
 8         er.writes,
 9         er.logical_reads,
10         login_name,
11         er.status,
12         blocking_session_id,
13         wait_type,
14         wait_resource,
15         wait_time,
16         individual_query = SUBSTRING (qt.text, (er.statement_start_offset/2) 1, ((CASE WHEN er.statement_end_offset = -1 THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 ELSE er.statement_end_offset END - er.statement_start_offset)/2) 1),
17         parent_query = qt.text,
18         program_name,
19         host_name,
20         nt_domain,
21         start_time,
22         DATEDIFF(MS,er.start_time,GETDATE()) as duration,
23         (SELECT query_plan FROM sys.dm_exec_query_plan(er.plan_handle)) AS query_plan
24     FROM
25         sys.dm_exec_requests er
26         INNER JOIN sys.dm_exec_sessions es ON er.session_id = es.session_id
27         CROSS APPLY sys.dm_exec_sql_text(er.sql_handle)as qt
28     WHERE
29         es.session_id > 50
30         AND es.session_Id NOT IN (@@SPID)
31 )
32 SELECT
33     *
34 FROM
35     sess
36 UNION ALL SELECT
37     es.session_id,
38     database_name = '',
39     0,
40     0,
41     0,
42     0,
43     login_name,
44     es.status,
45     0,
46     '',
47     '',
48     '',
49     qt.text,
50     parent_query = qt.text,
51     program_name,
52     host_name,
53     nt_domain,
54     es.last_request_start_time,
55     DATEDIFF(MS,es.last_request_start_time,GETDATE()) as duration,
56     NULL AS query_plan
57 FROM
58     sys.dm_exec_sessions es
59     INNER JOIN sys.dm_exec_connections ec ON es.session_id = ec.session_id
60     CROSS APPLY sys.dm_exec_sql_text(ec.most_recent_sql_handle)as qt
61 WHERE
62     ec.most_recent_session_id IN
63     (
64         SELECT blocking_session_id FROM sess WHERE blocking_session_id NOT IN(SELECT DISTINCT session_id FROM sess)
65     )
66 ORDER BY
67     1, 2

  

 总结

  问题的结果往往比较简单,也相对容易解决,但综合各项指标深入分析问题原因是值得和每一个技术人员探讨的,这也是为什么用一篇长案例来分析一个小点的原因。

  

  再思考:本案例中服务器的架构设计是比较完善的,已经做了读写分离可以轻松的把这样的大操作指向辅助服务器,并且可以做到负载均衡,那么如果你的单机服务器也有类似这样一个报表操作,你会怎么办呢?

 ----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

  

 总结

  问题的结果往往比较简单,也相对容易解决,但综合各项指标深入分析问题原因是值得和每一个技术人员探讨的,这也是为什么用一篇长案例来分析一个小点的原因。

  

  再思考:本案例中服务器的架构设计是比较完善的,已经做了读写分离可以轻松的把这样的大操作指向辅助服务器,并且可以做到负载均衡,那么如果你的单机服务器也有类似这样一个报表操作,你会怎么办呢?

 ----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

  

分区表问题

  描述:数据量千万级别了使用分区表提升性能

   答:分区表的使用场景主要是管理数据,而提升性能主要是靠IO并行,需要合理规划多块物理磁盘,大多数的场景下几千万数据单一的模式查询只需要添加正确的索引即可。

  

高可用的选择

  答:SQL自带的高可用或读写分离技术主要有:故障转移群集、发布订阅、镜像、日志传送、AlwaysON可用组(具体可以在进阶问题的资料中详细查看)

  一般选用读写分离需要根据不同的场景和要求,比如同步的实时性,读写分离功能的需要情况

  主要列出几个优缺点:

  故障转移群集:主备模式,单活(辅助机不可读),硬件资源浪费,主要场景是数据库的高可用。

  发布订阅:读写分离常用方式,配置灵活,副本节点可以多个,可以发布订阅部分数据(即可以对数据筛选),并提供多种发布订阅模式,缺点:维护比较麻烦,一般不能用作高可用。

  镜像:主备模式,单活(辅助机不可读),硬件资源浪费,主要场景是数据库的高可用。相对于故障转移群集镜像是数据库级别的高可用。在镜像中可以使用快照的方式实现读写分离。

  日志传送:主要用于灾备,在备用机上可读,但缺点是日志还原时不能读,读时不能还原。

  AlwaysON可用组:综合性方案,满足高可用、读写分离等需要,要求:SQL Server2012 以上版本

  第三方产品:moebius负载均衡集群,实现双活,读负载均衡、读写分离等。缺点实时同步不适合类似采集系统的大规模写入系统。

 

服务无法启动

  答:服务无法启动有很多原因,需要具体问题具体定位,如果遇到此类问题要首先查看日志定位问题,日志主要两部分,SQL启动日志和windows日志,下面给出两篇经典解析SQL启动的文章:

  你所不知道的SQL Server数据库启动过程(用户数据库加载过程的疑难杂症)

  你所不知道的SQL Server数据库启动过程,以及启动不起来的各种问题的分析及解决技巧

  

数据库设计,表设计的问题

  大多数这样的问题,在QQ群里问是根本得不到答案的,很多业务场景不是几句话可以描述清楚的。

  

SQL语句问题

  描述:SQL语句增加或者减少一个条件就变得很慢

  答:SQL语句的运行变化很微妙,需要理解执行计划,几句话或者贴个图无法解决,一些语句的习惯是需要养成的,请参见:

  SQL SERVER全面优化-------写出好语句是习惯

  SQL SERVER全面优化-------索引有多重要?

  

AlwaysOn配置问题

   AlwaysOn配置问题请参见桦仔的几篇非常细致的文章:

  从0开始搭建SQL Server AlwaysOn 第一篇(配置域控)

  从0开始搭建SQL Server AlwaysOn 第二篇(配置故障转移集群)

  从0开始搭建SQL Server AlwaysOn 第三篇(配置AlwaysOn)

  从0开始搭建SQL Server AlwaysOn 第四篇(配置异地机房节点)

  2016的AlwaysOn 搭建:SQL SERVER 2016 AlwaysOn 无域集群 负载均衡搭建与简测

 

AlwaysOn新建用户 

  首先要明白AlwaysOn可用组中:

  1.只有主节点是可以写入的,辅助节点只读

  2.权限分成两部分,实例级别“登录名”和数据库级别“用户”

  3.在主节点创建登录名称并选择数据库权限后,因为数据同步,所以从库上已经有了新创建用户的数据库权限,但是没有登录名。

  4.不能在辅助节点同样的方式创建登录名,这样就是“用户孤立”问题

  解决方法:  

  1.在主节点上直接添加的是“登录名”,比如创建一个登录名 KK

  澳门新萄京官方网站 29

  2.选择数据库权限及用户映射

  澳门新萄京官方网站 30

  3.查询刚才创建“登录名”的脚本(此脚本也可以用于升级或迁移数据库还原后,登录名同步的问题)

  

  1 CREATE PROCEDURE #sp_hexadecimal
  2     @binvalue varbinary(256),
  3     @hexvalue varchar (514) OUTPUT
  4 AS
  5     DECLARE @charvalue varchar (514)
  6     DECLARE @i int
  7     DECLARE @length int
  8     DECLARE @hexstring char(16)
  9 
 10     SELECT @charvalue = '0x'
 11     SELECT @i = 1
 12     SELECT @length = DATALENGTH (@binvalue)
 13     SELECT @hexstring = '0123456789ABCDEF'
 14     WHILE (@i <= @length)
 15     BEGIN
 16         DECLARE @tempint int
 17         DECLARE @firstint int
 18         DECLARE @secondint int
 19         SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
 20         SELECT @firstint = FLOOR(@tempint/16)
 21         SELECT @secondint = @tempint - (@firstint*16)
 22         SELECT @charvalue = @charvalue   SUBSTRING(@hexstring, @firstint 1, 1)   SUBSTRING(@hexstring, @secondint 1, 1)
 23         SELECT @i = @i   1
 24     END
 25     SELECT @hexvalue = @charvalue
 26 GO
 27 
 28 DECLARE @name sysname
 29 DECLARE @type varchar (1)
 30 DECLARE @hasaccess int
 31 DECLARE @denylogin int
 32 DECLARE @is_disabled int
 33 DECLARE @PWD_varbinary  varbinary (256)
 34 DECLARE @PWD_string  varchar (514)
 35 DECLARE @Principal_id int
 36 DECLARE @SID_varbinary varbinary (85)
 37 DECLARE @SID_string varchar (514)
 38 DECLARE @tmpstr  varchar (1024)
 39 DECLARE @is_policy_checked varchar (3)
 40 DECLARE @is_expiration_checked varchar (3)
 41 DECLARE @defaultdb sysname
 42 DECLARE @language sysname
 43 DECLARE @rolename sysname
 44 DECLARE login_curs CURSOR FOR SELECT 
 45     p.principal_id,
 46     p.sid, 
 47     p.name, 
 48     p.type, 
 49     p.is_disabled, 
 50     p.default_database_name, 
 51     p.default_language_name,
 52     l.hasaccess, 
 53     l.denylogin 
 54 FROM 
 55     sys.server_principals p 
 56 LEFT JOIN 
 57     sys.syslogins l ON ( l.name = p.name ) 
 58 WHERE 
 59     p.type IN ( 'S', 'G', 'U' ) AND 
 60     p.name <> 'sa'
 61 
 62 OPEN login_curs
 63 
 64 FETCH NEXT FROM login_curs INTO @Principal_id, @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @language, @hasaccess, @denylogin
 65 IF (@@fetch_status = -1)
 66 BEGIN
 67   PRINT 'No login(s) found.'
 68   CLOSE login_curs
 69   DEALLOCATE login_curs
 70   RETURN
 71 END
 72 SET @tmpstr = '** Generated '   CONVERT (varchar, GETDATE())   ' on '   @@SERVERNAME   ' */'
 73 PRINT @tmpstr
 74 PRINT ''
 75 WHILE (@@fetch_status <> -1)
 76 BEGIN
 77     IF (@@fetch_status <> -2)
 78     BEGIN
 79         PRINT ''
 80         SET @tmpstr = '-- Login: '   @name
 81         PRINT @tmpstr
 82         IF (@type IN ( 'G', 'U'))
 83         BEGIN -- NT authenticated account/group
 84             SET @tmpstr = 'CREATE LOGIN '   QUOTENAME( @name )   ' FROM WINDOWS WITH DEFAULT_DATABASE = ['   @defaultdb   '], DEFAULT_LANGUAGE = ['   @language   ']'
 85         END
 86         ELSE 
 87         BEGIN -- SQL Server authentication
 88             -- obtain password and sid
 89             SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )
 90             EXEC #sp_hexadecimal @PWD_varbinary, @PWD_string OUT
 91             EXEC #sp_hexadecimal @SID_varbinary,@SID_string OUT
 92 
 93             -- obtain password policy state
 94             SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
 95             SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
 96 
 97             SET @tmpstr = 'CREATE LOGIN '   QUOTENAME( @name )   ' WITH PASSWORD = '   @PWD_string   ' HASHED, SID = '   @SID_string   ', DEFAULT_DATABASE = ['   @defaultdb   '], DEFAULT_LANGUAGE = ['   @language   ']'
 98 
 99             IF ( @is_policy_checked IS NOT NULL )
100             BEGIN
101                 SET @tmpstr = @tmpstr   ', CHECK_POLICY = '   @is_policy_checked
102             END
103             IF ( @is_expiration_checked IS NOT NULL )
104             BEGIN
105                 SET @tmpstr = @tmpstr   ', CHECK_EXPIRATION = '   @is_expiration_checked
106             END
107         END
108         IF (@denylogin = 1)
109         BEGIN -- login is denied access
110             SET @tmpstr = @tmpstr   '; DENY CONNECT SQL TO '   QUOTENAME( @name )
111         END
112         ELSE IF (@hasaccess = 0)
113         BEGIN -- login exists but does not have access
114             SET @tmpstr = @tmpstr   '; REVOKE CONNECT SQL TO '   QUOTENAME( @name )
115         END
116         IF (@is_disabled = 1)
117         BEGIN -- login is disabled
118             SET @tmpstr = @tmpstr   '; ALTER LOGIN '   QUOTENAME( @name )   ' DISABLE'
119         END
120         PRINT @tmpstr
121         PRINT 'GO'
122         DECLARE server_role_members_curs CURSOR FOR 
123             SELECT 
124                 (SELECT [name] FROM sys.server_principals WHERE principal_id = role_principal_id) AS rolename
125             FROM 
126                 sys.server_role_members 
127             WHERE 
128                 member_principal_id = @Principal_id
129         OPEN server_role_members_curs
130 
131         FETCH NEXT FROM server_role_members_curs INTO @rolename
132         WHILE (@@fetch_status <> -1)
133         BEGIN
134             SELECT @tmpstr = 'EXEC master..sp_addsrvrolemember @loginame = N'''   @name   ''', @rolename = N'''   @rolename   ''''
135             PRINT @tmpstr
136             PRINT 'GO'
137             FETCH NEXT FROM server_role_members_curs INTO @rolename
138         END
139         CLOSE server_role_members_curs
140         DEALLOCATE server_role_members_curs        
141     END
142     FETCH NEXT FROM login_curs INTO @Principal_id, @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @language, @hasaccess, @denylogin
143 END
144 CLOSE login_curs
145 DEALLOCATE login_curs
146 GO
147 
148 DROP PROCEDURE #sp_hexadecimal
149 GO

 

  4.找到查询出的脚本,在辅助节点运行(其中主要的就是SID)

  澳门新萄京官方网站 31

 

   

进阶问题

  进阶问题中需要对数据库知识有一定的积累,无法几句话概括,所以下面给出一些经典文章的链接:

数据库优化问题

   整体思路:SQL SERVER全面优化-------Expert for SQL Server 诊断系列

   具体细节:SQL Server性能调优系列

  

数据库巡检及指标

  巡检系列:轻松精通数据库管理之道——运维巡检系列

  

澳门新萄京官方网站 32

 高可用技术

  如何规划、建设你的数据库架构

   数据库集群技术漫谈

  SQL Server中的高可用性(1)----高可用性概览

 

负载均衡集群

  大数据时代下的SQL Server第三方负载均衡方案----Moebius测试

  SQL SERVER 2016 AlwaysOn 无域集群 负载均衡搭建与简测

 

常用优化工具平台

  SQL专家云平台 : 30分钟带你熟练性能优化的那点儿事儿(案例说明)   

  profiler与性能计数器:性能计数器与profiler的组合性能诊断

  语句的分析工具:一款好用且免费的语句分析工具

 

运维脚本

  数据库的运维策略(内附脚本,无私分享)

  SQL Server自动化运维系列——监控性能指标脚本(Power Shell)

 

--------------博客地址---------------------------------------------------------------------------------------

博客地址 

 

 欢迎转载,请注明出处,谢谢


  总结 : 遇到的问题很多,一时间很多想不起来,我会慢慢整理,慢慢补充,争取让此篇变成对看官们很有帮助的一边总结。

   

  遇到的常见问题,希望大家给予补充,一起完善这篇文章。

 ----------------------------------------------------------------------------------------------------

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

 

本文由澳门新萄京官方网站发布于数据库网络,转载请注明出处:澳门新萄京官方网站:故障排查实战案例,数据

关键词: