阿里云专家风移“出诊”记录:SQL Server 疑难杂症解决之道(上篇)

授人予鱼而不如授人予渔,本系列专题(上篇)为大家推荐了31篇好文,希望可以帮到大家!

“出诊”:RDS SQL Server死锁(Deadlock)

1. RDS SQL Server死锁(Deadlock)系列之一使用DBCC捕获死锁

经常会被客户问道:“应用程序被死锁报错啦?影响很大,到底是哪个进程导致了死锁发生的啊?怎么解决啊?怎么办呀?”。如何解决呢?

点击阅读详情

2. RDS SQL Server死锁(Deadlock)系列之二使用Profiler捕获死锁

不管是RDS SQL Server还是自建,死锁的确是一个非常头疼的问题。这篇文章是以死锁问题为背景,分享死锁文章系列之二使用Profiler捕获死锁。

点击阅读详情

3. RDS SQL Server死锁(Deadlock)系列之三自动部署Profiler捕获死锁

如何手动部署Profiler来捕获死锁以及对死锁发时场景重现,这篇文章是将这个手动部署的过程自动化话,实现一键部署,既快捷方便,又简单适用。

点击阅读详情

4. RDS SQL Server死锁(Deadlock)系列之四利用Service Broker事件通知捕获死锁

这篇文章介绍一个非常有意思的捕获死锁的方法:使用SQL Server Service Broker Event Notification来捕获死锁。

点击阅读详情

5. RDS SQL Server死锁(Deadlock)系列之五利用Extended Events获取死锁信息

“在事先没有任何跟踪或者监控部署的情况下,阿里云RDS SQL Server有没有办法获取到历史死锁信息,供我们分析?”。Extended Events可以。

点击阅读详情

6. MSSQL - 应用案例 - Event Notification + Service Broker构建死锁自动收集系统

如何利用Event Notification与Service Broker技术相结合来实现死锁信息自动收集系统。通过这个系统,我们可以全面把控SQL Server数据库环境中所有实例上发生的死锁详细信息。

点击阅读详情

“出诊”:高CPU使用率

1. RDS SQL Server - 最佳实践 - 高CPU使用率系列之索引缺失

CPU高使用率往往会导致SQL Server服务响应缓慢,查询超时,甚至服务挂起僵死。本系列文章之一的“索引缺失”就是CPU高使用率的最常见的原因。

点击阅读详情

2. RDS SQL Server - 最佳实践 - 高CPU使用率系列之二索引碎片

高CPU使用率的原因之一是索引缺失,而“索引碎片”是CPU高使用率的又一常见的原因。解决索引碎片问题是解决SQL Server服务响应缓慢,查询超时。

点击阅读详情

3. RDS SQL Server - 最佳实践 - 高CPU使用率系列之数据类型转换

前两篇文章讨论了导致CPU高使用率的两个重要原因是索引缺失和索引碎片,本系列文章之三讨论数据类型隐式转换话题。

点击阅读详情

4. RDS SQL Server - 最佳实践 - 高CPU使用率系列之非SARG查询

RDS SQL Server客户遇到最多的一个问题便是高CPU使用率导致导致SQL Server服务响应缓慢,查询超时,甚至服务挂起僵死。这有非SARG查询导致CPU的高利用率的解决之道。

点击阅读详情

5. SQL Server - 最佳实践 - 参数嗅探问题

这篇文章从参数嗅探是什么,如何产生,表象是什么,会带来哪些问题,如何解决这五个方面来探讨参数嗅探的来龙去脉。

点击阅读详情

列存储索引

1. SQL Server 2012列存储索引技术

MS SQL Server 2012首次引入了列存储索引(Columnstore Index)来加速数据分析(OLAP)和数据仓库(Data Warehouse)场景的查询,它主要是通过将数据按列压缩存储的方式来减少查询对磁盘IOPS开销和CPU开销,最终达到提升查询效率,降低响应时间的目的。当然,列存储索引也不是一把万能的钥匙,在SQL Server 2012版本中它有诸多非常严苛限制条件。

这篇文章会从以下几个方面来介绍列存储索引:

  • 列存储索引所涉及到的基本概念
  • 列存储索引的结构
  • 列存储索引对查询性能的影响
  • MS SQL Server 2012上列存储索引的限制
  • 解决列存储索引表只读问题

点击阅读详情

2. SQL Server 2014聚集列存储索引

微软在SQL Server 2012引入了列存储技术,使得OLAP和Data warehouse场景性能提升10X,并且数据压缩能力超过传统表7X。这项技术包含三个方面的创新:列存储索引、Batch Mode Processing和基于Column Segment的压缩。但是,SQL Server 2012列存储索引的一个致命缺点是列存储索引表会进入只读状态,用户无法更新操作。SQL Server 2014引入了可更新聚集列存储索引技术来解决列存储索引表只读的问题,使得列存储索引表使用的范围和场景大大增加。

点击阅读详情

3. SQL Server 2016 列存储技术做实时分析

数据分析指导商业行为的价值越来越高,使得用户对数据实时分析的要求变得越来越高。使用传统RDBMS数据分析架构,遇到了前所未有的挑战,高延迟、数据处理流程复杂和成本过高。这篇文章讨论如何利用SQL Server 2016列存储技术做实时数据分析,解决传统分析方法的痛点。

点击阅读详情

4. MSSQL-应用案例-SQL Server 2016基于内存优化表的列存储索引分析Web Access Log

在日常的网站运维工作中,我们需要对网站客户端访问情况做统计、汇总、分析和报表展示,以数据来全面掌控网站运营和访问情况。当不可预知的意外情况发生时,我们可以快速发现问题以及采取相应的措施。比如:当网站受到黑客攻击时的流量陡增,又或者是网站某个资源发生意外抛异常等情况。

在提供Web服务的服务器上,比如IIS、Apache都存在访问日志记录,这篇是文章是以SQL Server 2016基于内存优化表的列存储索引来分析Apache Web Access Log为例,讲解分析网站访问情况,因此,我们需要解决以下几个问题:

  • Apache Web Access Log格式介绍
  • 列存储索引表结构的设计
  • Apache Web Access Log导入到列存储索引表
  • 网站访问流量统计
  • 客户端主机访问的分布情况
  • 客户端主机访问的资源统计
  • 异常URI访问统计
  • Response Code分布情况

点击阅读详情

5. SQL Server on Linux列存储索引

“鸟儿啊,听说微软至SQL Server 2012以来,推出了一种全新的基于列式存储的索引,你去研究看看SQL Server on Linux对这个功能的支持度如何,效率有多大的提升?”。老鸟又迫不及待的开始给菜鸟分配任务。

的确如老鸟所说,从SQL Server 2012开始推出了列存储索引,这个版本限制颇多,但是它对统计查询的效率提升又是实实在在的。所以,让我们来看看SQL Server on Linux列存储索引对统计查询的效率提升情况如何。

这里也顺便提一下SQL Server 2012 列存储索引的限制,比如:

  • 非聚集列存储索引是只读的,换句话说,基表会变成Read-Only
  • 仅支持非聚集列存储索引
  • 只能通过删除及创建索引的方式重建索引,而不可使用ALTER INDEX命令
  • 对应的表不可包含唯一性约束、主键约束或外键约束

......

点击阅读详情

“出诊”:临时表和表变量

1. SQL Server 表变量和临时表系列之概念篇

“菜鸟啊,最近我看到阿里云开发者论坛的数据库RDS中有人在提SQL Server表变量和临时表如何选择的问题,你去深入探讨下这个问题吧,解答解答他们的疑惑吧”,老鸟又开始为菜鸟找活干了。

“鸟哥啊,关于表变量和临时表使用选择的问题啊,向来行业里争论不休,我比较担心我们的观点被人家拍砖啊”。

“鸟啊,有争论才说明这个问题有价值啊,所以我们才更应该去弄清楚,道明白啊”。反正老鸟总会找到合适的理由。

“那好吧,要把这个问题要刨根问底,我们需要分四篇文章来把这个问题理清楚。”,菜鸟掰着手指头就数了出来:

  • 表变量和临时表基本概念
  • 表变量和临时表的对比
  • 表变量和临时表认知误区
  • 表变量和临时表的选择

点击阅读详情

2. SQL Server 临时表和表变量系列之认知误区篇

关于临时表和表变量,是一个老生常谈的话题,但是很多SQL Server老司机都存在或多或少的认知误区。指出一些常见的认知误区就是写作本文的目的。

点击阅读详情

3. SQL Server 临时表和表变量系列之选择篇

前三篇文章,大家对临时表和表变量的概念、对比和认知误区已经有了非常全面的认识。其实,终极目的,是本文要讨论的话题:即当面对具体的业务场景的时候,该选择临时表还是表变量?

点击阅读详情

4. SQL Server 临时表和表变量系列之踢馆篇

在面对SQL Server选择使用临时表还是表变量作为数据暂存问题时,有一个非常重要的选择标准便是性能,两者对于查询语句和DML性能表现到底如何呢?我相信,很多人的认识是片面的,或者是错误的。这里以一篇引用率很高的文章来作为反面教材来纠正那些片面和错误的认识,我暂且称之为“踢馆”。

点击阅读详情

云上实践

1. SQL Server - 最佳实践 - SSMS配合BCP迁移SQL Server数据库上阿里云

本文讨论的主题是使用SSMS(SQL Server Management Studio)配合BCP命令行的方式来迁移SQL Server数据库。使用SSMS做数据库结构迁移,使用BCP命令做全量数据迁移,此方案是以本地SQL Server数据库迁移到阿里云RDS SQL Server 2012为例。

点击阅读详情

2. 开启TDE的RDS SQL Server还原到本地环境

阿里云RDS SQL Server 2008 R2版本,客户在前端控制台可以自行启用透明数据加密(TDE),来避免客户数据库备份文件被非法盗取而引起拖库风险。最近,客户咨询如何将开启了TDE的数据库还原到本地环境,这篇文章的目的就是为了解决这个问题。

点击阅读详情

3. RDS SQL SERVER 解决中文乱码问题

这天老鸟又开始纠缠着菜鸟:“菜鸟啊,我们最近遇到一个RDS SQL Server 2008 R2的奇怪的问题,我们的生僻字写入到RDS SQL Server中,查询结果展示出来是乱码呀?你去解决下这个问题吧。”。

“可是,鸟哥,我最近在做关于SQLTest的系列文章啊,暂时抽不出。。。。。。”。

“那个暂时先放放,这个比较紧急,尽快,立刻,马上去复盘并解决掉,Understand?”。还没等菜鸟说完,老鸟已经迫不及待的发号施令了。

点击阅读详情

4. SQL Server FullText解决Like字句性能问题

这天老鸟火急火燎的冲到菜鸟座位:“还记得你在云栖社区发表的一篇名为‘SQL Server利用HashKey计算列解决宽字段查询的性能问题’的文章吗?被人踢馆啦,人家觉得你这个限制条件太苛刻,只能解决完全等于的问题条件下的性能问题,没有太大的现实意义。”

菜鸟烧脑的调动大脑的每一个细胞:“哦,你说的是这篇文章啊?”。

菜鸟反思着,的确,需要完全匹配这个条件限制太严格了,SQL Server有没有一种方法来代替LIKE字句的功能而又可以大大提高查询效率的呢?因为,我们知道,LIKE左模糊匹配是可以使用到索引,而右模糊和完全模糊匹配是完全无法使用到索引的。G哥告诉菜鸟有解决方法,用FullText搜索啊。

点击阅读详情

5. SQL Server使用视图做权限控制

这天老鸟火急火燎的跑到菜鸟旁边,想必是遇到什么难题了:“现在有这么一个场景,假如有三种角色,并且存在层级关系,他们需要访问同一个数据源表,但是需要做权限控制,使得每种角色只能看到自己及以下层级的数据。比如:公司有CEO,Manger和普通的employee三种角色,CEO可以查看CEO、Manager和employee层级的数据;Manger只能查看Manger和employee的数据,不能查看CEO层级;而employee只能查看employee的数据,不能查看CEO和Manager级别的数据。这个在SQL Server有比较简单清爽的实现方法吗?”。老鸟这个问题的确问得非常有水准,这个场景也非常普遍,菜鸟顿时陷入了无边的困境。

在关系型数据库SQL Server中,权限的确不能达到行列级别这么细粒度的控制,这也是菜鸟为什么陷入困境的原因。但是,突然菜鸟灵魂出窍,灵光一现,像是被雷劈中一般的感觉:虽然SQL Server基于表无法达到那么细粒度的权限控制,但是我们可以建立视图(VIEW),用视图来建立正式表的行、列过滤,然后在视图对象上做权限控制,最终达到对三个层级的权限控制的目的,想到这里菜鸟立马赫然开朗。

点击阅读详情

6. 巧用COLUMNS_UPDATED获取数据变更

在平时与数据库打交道的过程中,我们经常会有这样的疑惑:如何快速的获取数据变更记录呢?举个例子,搜索引擎要为外部客人提供快速准确的商品信息搜索功能,那么当有新的商品数据变更后,搜索引擎如何快速的发现这些新的变更数据呢?

点击阅读详情

7. SQL Server利用HashKey计算列解决宽字段查询的性能问题

某年某月某日,某MSSQL菜鸟满脸愁容的跑到老鸟跟前,心灰意懒的对老鸟说“我最近遇到一个问题,很大的问题,对,非常大的问题”。老鸟不急不慢的推了推2000度超级近视眼镜框,慢吞吞的说:“说来听听”。

“我有一个100万数据量的表,有一个宽度为7500字段,不幸的是现在我需要根据这个字段的值来查询表数据,而且最为可恨的是MSSQL Server不允许我在这个字段上建立Index,所以,我的查询语句爆慢,应用程序直接超时,肿么办呀,肿么办?”。

点击阅读详情

8. 如何侦查SQL执行状态

随着菜鸟一点点的成熟,现在老鸟已经开始慢慢的将一些问题抛给他:“菜鸟,你去研究下如何有效而快捷的侦查SQL执行状态?”。

“鸟哥,你交代的任务,我分分钟就去办。”,菜鸟领了任务赶紧忙碌起来。

“其实这个场景经常遇到,比如:我们想知道某个进程的SQL查询执行到哪一步了?当前执行多久了?查询是从哪个登录用户哪一个机器过来的?跑的是什么业务?甚至执行计划是什么样子?老鸟就是老鸟,总想的比我们远”。菜鸟一边寻思着,一边又马不停蹄的问G哥,终于功夫不负有心人,总算有了点眉目。

点击阅读详情

9. 谁占用了我的Buffer Pool

双十一后,老鸟接二连三的狂轰滥炸着菜鸟:“你读过一本叫《谁动了我的奶酪》的书吗?正好,你研究下谁动了SQL Server的Buffer Pool吧?”。

菜鸟又是满脸懵逼茫然状:“这谁跟谁啊?有半毛钱关系吗?”。没办法,老鸟交代的任务,菜鸟还是要一丝不苟的竭尽全力。

点击阅读详情

10. sys.master_files不能准确展示Tempdb数据库大小

老鸟这两周一直没有找到机会略菜鸟,因为菜鸟最近一直在参加百阿培训。这不,刚好菜鸟过完买买买的双十一回来,老鸟逮着机会劈头盖脸问道:“菜鸟啊,你去研究下为什么MSSQL Server系统视图sys.master_files不能准确展示Tempdb数据库数据文件大小啊?”。

点击阅读详情

11. SQL Server - 最佳实践 - 参数嗅探问题

这篇文章从参数嗅探是什么,如何产生,表象是什么,会带来哪些问题,如何解决这五个方面来探讨参数嗅探的来龙去脉,期望能够将SQL Server参数嗅探问题理清楚,道明白。

点击阅读详情