ITPub博客

数据库是信息化的基石，支撑着整个业务系统，发挥着非常重要的作用，被喻为“IT的心脏”。因此，让数据库安全、稳定、高效地运行已经成为IT管理者必须要面对的问题。数据库在底层架构层面需要满足以下几点建设要求：安全和可靠;容灾,读写分离（报表分离）;负载均衡;弹性扩展;

       自从SQL Server 2005以来，微软已经提供了多种高可用性技术来减少宕机时间和增加对业务数据的保护，而随着SQL Server 2008，SQL Server 2008 R2，SQL Server 2012的不断发布，SQL Server中已经存在了满足不同场景的多种高可用性技术。

数据库在上午10点时出现严重阻塞，阻塞源头会话在等待OLEDB，没有见过这个等待类型，请我们协助分析。

sql server数据库等待分类与解决基本流程

上午10点50分左右，客户接到SQL专家云的告警短信，数据库发生了严重的阻塞，登录到SQL专家云中发现阻塞的源头是SQL Server Management Studio，KILL掉该会话后解决。但是不理解一条简单的SQL语句为什么会造成阻塞，因此找我们分析下原因。

某医院信息科接到CIS系统磁盘空间不足告警，通过排查发现tempdb的日志文件暴增，已经涨到了130G左右，并且还在持续增长中。需要我们紧急排查原因。

某客户tempdb数据文件突然暴增，导致磁盘可用空间紧张，让我们找到暴增的原因。

客户业务系统升级后，高峰期运行缓慢，在SQL专家云上看到数据库出现严重等待，需要分析原因并紧急处理。

客户收到了SQL专家云告警邮件，在凌晨2点到3点之间带有资源等待的会话数暴增，请我们协助分析。

很多客户在对数据库做安全审计时要求配置连接加密，本文就如何配置加密以及使用证书做一个系统的整理。

客户反馈系统突然从11:10开始运行非常缓慢，在SQL专家云中看到大量的产生阻塞的活动会话，KILL掉阻塞的源头马上又出现新的源头，实在没有办法只能重启应用程序断开所有数据库连接才解决，请我们协助分析根本的原因。

客户反映HIS数据库每天22点后都会发生阻塞，阻塞的源头是一个sleeping的会话，越阻塞越多，只能通过手动KILL掉才能解决，十分不解为什么状态为sleeping的会话会造成阻塞。

磁盘的压力分析，主要使用下面几个性能计数器 （针对单独的物理盘，每个物理磁盘都会有一组）： Avg. Disk Read Queue Length 读队列（越小越好，理想值 2 以下，队列越高说明一个操作的响应时间越长） Avg. Disk Write Queue Length 写队列（越小越好，理想值 2 以下，队列越高说明一个操作的响应时间越长） Avg. Disk sec/Read　　 Avg. Disk sec/Write Disk Read Bytes/sec Disk Write Bytes/sec

背景客户反映HIS数据库每天22点后都会发生阻塞，阻塞的源头是一个sleeping的会话，越阻塞越多，只能通过手动KILL掉才能解决，十分不解为什么状态为sleeping的会话会造成阻塞。现象1在SQL专家云的活动会话中，回溯22点一个小时内的运行情况，从22点开始出现阻塞情况。转到活动会话原始数据，看到ID为2661的会话是阻塞源头，且状态为sleeping。查看2661的完整信息，发现该会话中

TempDB问题查找定位与解决

应用系统承载着大量的业务，随之而来的是复杂的业务逻辑，在数据库上的表现就是有着大量的不同种类的SQL语句。SQL语句执行的快慢又与阻塞等待有着密不可分的原因。

客户反馈今天8点钟开始进入业务高峰期后，数据库的CPU利用率非常高，基本达到了100%，前端应用也非常慢。怀疑是昨晚业务系统升级导致，请我们紧急协助分析。

客户反馈最近一段时间数据库运行缓慢，磁盘的压力很大，现在有两种不同的分析结论，存储设备性能下降和数据库压力变大，请我们进行系统的分析，给一个结论。

接到客户电话，说某系统数据库服务器CPU利用率从上午8点开始到现在基本上都是100%的情况，影响到了业务。让给看看是什么原因导致的，怎么紧急处理一下。

不合适的数据类型隐式转换会导致性能下降和并发下降，而且大多数技术人员对隐式转换的概念是陌生的，因此在生产环境中非常常见，通过本文做一个系统的梳理。