阿里云数据库专家,负责SQL Server数据库产品线。SQL Server从业10年,经历过SQL 2000、SQL 2005、SQL 2008、SQL 2008R2、SQL 2012、SQL 2014、SQL 2016和SQL on Linux各个版本。
--- title: RDS CloudDBA - Performance Insights最佳实践 author: 风移 --- # Performance Insights是什么 阿里云RDS Performance Insights是RDS CloudDBA产品一项专注于用户数据库实例性能调优、负载监控和关联分析的利器,以简单直观的方式帮助用户迅速评估数据库负载,资源等待的源头
--- title: MSSQL - 最佳实践 - 使用SSL加密连接 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,往期我们已经陆续分享了:[如何使用对称密钥实现SQL Server列加密技术](http://mysql.taobao.org/monthly/2018/08/03/)、[使用非对称密钥实现SQL Server列加密](http:/
--- title: MSSQL - 最佳实践 - Always Encrypted author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,往期我们已经陆续分享了:[如何使用对称密钥实现SQL Server列加密技术](http://mysql.taobao.org/monthly/2018/08/03/)、[使用非对称密钥实现SQL Server列加密]
--- title: MSSQL-最佳实践-数据库备份加密 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,我们已经分享了:如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥实现SQL Server列加密、使用混合密钥实现SQL S.
--- title: MSSQL - 最佳实践 - 如何打码隐私数据列 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,我们已经分享了:如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥加密方式实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术、列加密技术带来的查询性能问题以及相应解决方案和行级别安全解决方
--- title: MSSQL-最佳实践-行级别安全解决方案 author: 风移 --- # 摘要 在SQL Server安全系列专题月报分享中,我们已经分享了:如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥加密方式实现SQL Server列加密、使用混合密钥实现SQL Server列加密技术和列加密技术带来的查询性能问题以及相应解决方案四篇文章。本期月报我们
--- title: MSSQL-最佳实践-使用非对称密钥实现列加密 author: 风移 --- # 摘要 上一篇月报,我们分享了SQL Server使用对称密钥实现列加密的方法。为了解决对称加密安全性低的问题,本期月报我们分享使用非对称密钥加密方式实现SQL Server列加密方法,保护用户的关键、核心隐私数据列信息。 # 场景引入 对称加密是指加密和解密过程使用同一个密钥的加密
--- title: MSSQL-最佳实践-实例级别数据库上云RDS SQL Server author: 风移 --- # 摘要 到目前,我们完成了SQL Server备份还原专题系列八篇月报分享:三种常见的数据库备份、备份策略的制定、查找备份链、数据库的三种恢复模式与备份之间的关系、利用文件组实现冷热数据隔离备份方案、如何监控备份还原进度、阿里云RDS SQL自动化迁移上云的一种
--- title: MSSQL · 最佳实践 · RDS SDK实现数据库迁移上阿里云RDS SQL Server author: 风移 --- # 摘要 至今,我们完成了SQL Server备份还原专题系列七篇月报分享:三种常见的数据库备份、备份策略的制定、查找备份链、数据库的三种恢复模式与备份之间的关系、利用文件组实现冷热数据隔离备份方案、如何监控备份还原进度、以及阿里云RD
# 摘要 至今为止我们完成了SQL Server备份还原专题系列六篇月报分享:三种常见的数据库备份、备份策略的制定、查找备份链、数据库的三种恢复模式与备份之间的关系、利用文件组实现冷热数据隔离备份方案以及如何监控备份还原进度,本期我们分享阿里云是如何基于SQL Server备份还原理论来设计RDS SQL自动化迁移上云方案的。 # 适用场景 RDS数据库迁移上云是指将用户线下数据库搬迁到阿里
--- title: MSSQL · 最佳实践 · 如何监控备份还原进度 author: 风移 --- # 摘要 本期月报是SQL Server备份还原专题分享系列的第六期,打算分享给大家如何监控SQL Server备份还原进度。 # 场景引入 由于SQL Server备份还原操作是重I/O读写操作,尤其是当数据库或数据库备份文件比较大的到时候。那么,我们就有强烈的需求去监
--- title: MSSQL-最佳实践-利用文件组实现冷热数据隔离备份方案 author: 风移 --- # 摘要 在SQL Server备份专题分享中,前四期我们分享了:三种常见的数据库备份、备份策略的制定、如何查找备份链以及数据库的三种恢复模式与备份之间的关系。本次月报我们分享SQL Server如何利用文件组技术来实现数据库冷热数据隔离备份的方案。 # 场景引入 假设某公司
--- title: MSSQL-最佳实践-数据库恢复模式与备份的关系 author: 风移 --- # 摘要 在SQL Server备份专题分享中,前三期我们分享了三种常见的数据库备份、备份策略的制定以及如何查找备份链。本期我们将分享数据库的三种恢复模式与备份之间的关系,SQL Server的三种数据库恢复模式包括: 简单恢复模式(Simple) 完全恢复模式(Full)
--- title: MSSQL-最佳实践-数据库备份链 author: 风移 --- # 摘要 在SQL Server备份专题分享中,前两期我们分享了三种常见的备份以及备份策略的制定,在第三期分享中,我们将要分享SQL Server的数据库备份链。完整的数据库备份链是保证数据库能够实现灾难恢复的基础,如果备份链条被打断或者备份链条上的文件损坏,势必会导致数据恢复不完整或者不能满
--- title: MSSQL · 最佳实践 · SQL Server备份策略 author: fengyi --- # 摘要 在上一期月报中我们分享了SQL Server三种常见的备份技术及工作方式,本期月报将分享如何充分利用三者的优点来制定SQL Server数据库的备份和还原策略以达到数据库快速灾难恢复能力。 [上期月报:MSSQL · 最佳实践 · SQL Serv
# 摘要 本期月报是SQL Server数据库备份技术系列文章的开篇,介绍三种常见的SQL Server备份方法的工作方式、使用T-SQL语句和使用SSMS IDE创建备份集三个层面,介绍SQL Server的三种常见备份的工作原理和使用方法。三种常见的备份包括: 数据库完全备份(Full Backup) 数据库日志备份(Transaction Log Backup) 数据库差异备份
--- title: MSSQL - 架构分析 - 从SQL Server 2017发布看SQL Server架构的演变 author: 风移 --- # 摘要 美国时间2017年10月2日,微软正式发布了最新一代可以运行在Linux平台的数据库SQL Server 2017。SQL Server 2017给用户带来了一系列的新功能特性的同时,也体现了微软关于自家关系型数据库平台建设
# 问题引入 SQL Server 数据库查询优化器对执行计划成本的评估是基于统计信息的,换句话说,统计信息的准确与否直接关系着查询语句是否能够高效运行。那么,在SQL Server中,表对象中统计信息的缺失是一个影响查询语句性能的风险点,我们如何能够通过非常自动化的方式来侦查,发现统计信息的缺失呢?这个问题的答案就是我们今天这篇文章要分享的内容 - 使用执行计划缓存来发现统计信息的缺失警告。
--- title: MSSQL-应用案例-日志表设计优化与实现 author: 风移 --- # 摘要 这篇文章从日志表问题引入、日志表的共有特性、日志表的设计需求、设计思路以及设计详细实现的角度,阐述了在SQL Server数据库中如何最优化设计日志表来降低系统资源的占用和提高系统吞吐量。 # 问题引入 在平时与客户服务与交流过程中,我们不止一次的被客人问及这样的场景:我们现
# 背景引入 执行计划中的Table Scan或者是Clustered Index Scan会导致非常低下的查询性能,尤其是对于大表或者超大表。执行计划缓存是SQL Server内存管理中非常重要的特性,这篇系列文章我们探讨如何从执行计划缓存的角度来发现RDS SQL数据库引擎中的Table Scan行为,以及与之相应SQL查询语句详细信息。 # 问题分析 其实,我们大家都知道,Table
# 背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇文章是巧用执行计划缓存系列文章之五,探讨如何从执行计划缓存中获取查询语句执行计划编译的性能消耗,比如: 编译时间消耗 编译CPU消耗 编译内存消耗 缓存大小消耗 等等一系列非常有价值的统计信息。 # 什么是执行计划编译 SQL查询语句在提交到SQL Server主机服务之后,数据查询访问动作发
# 背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇文章是巧用执行计划缓存系列文章之四,探讨什么是Key Lookup操作,如何从执行计划缓存中发现Key Lookup问题,以及如何解决这个问题。 # 什么是Key Lookup Key Lookup操作是指执行计划通过表的索引查找字段列的书签查找方式。Key Lookup发生在当查询语句使用Index Se
# 背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇系列文章我们探讨执行计划缓存设计中遇到的single-used plans问题,以及如何发现、如何定性和定量分析single-used plans带来的影响,最后我们使用两种方法来解决这个问题。 # 什么是Single-used Plans 要解释清楚什么是Single-used Plans,首先需要解释SQL语句
# 摘要 SQL Server数据库基表数据类型隐式转换,会导致Index Scan或者Clustered Index Scan的问题,这篇文章分享如何巧用执行计划缓存来发现数据类型隐式转换的查询语句,从而可以有针对性的优化查询,解决高CPU使用率的问题。 # 问题引入 数据类型转化是导致SQL Server高CPU使用率的又一大杀手,详情参见之前的云栖社区文章:[RDS SQL Serve
执行计划缓存是MSSQL Server内存管理十分重要的部分,同样如何巧用执行计划缓存来解决我们平时遇到的一系列问题也是一个值得深入研究的专题。这篇文章是如何巧用执行计划缓存的开篇,分享如何使用执行计划缓存来分析索引缺失(Missing Indexes)。
--- title: MSSQL - 应用案例 - Event Notification + Service Broker构建死锁自动收集系统 author: 风移 --- # 摘要 这篇文章介绍SQL Server的一个典型的应用案例,即如何利用Event Notification与Service Broker技术相结合来实现死锁信息自动收集系统。通过这个系统,我们可以全面把控SQL
# 问题引入 在日常的网站运维工作中,我们需要对网站客户端访问情况做统计、汇总、分析和报表展示,以数据来全面掌控网站运营和访问情况。当不可预知的意外情况发生时,我们可以快速发现问题以及采取相应的措施。比如:当网站受到黑客攻击时的流量陡增,又或者是网站某个资源发生意外抛异常等情况。 在提供Web服务的服务器上,比如IIS、Apache都存在访问日志记录,这篇是文章是以SQL Server 201
--- title: SQL Server 2016 列存储技术做实时分析 author: 风移 --- # 摘要 数据分析指导商业行为的价值越来越高,使得用户对数据实时分析的要求变得越来越高。使用传统RDBMS数据分析架构,遇到了前所未有的挑战,高延迟、数据处理流程复杂和成本过高。这篇文章讨论如何利用SQL Server 2016列存储技术做实时数据分析,解决传统分析方法的痛点。 #
# 问题引入 在过去很长一段时间,不断有客人会问道:“在事先没有任何跟踪或者监控部署的情况下,阿里云RDS SQL Server有没有办法获取到历史死锁信息,供我们分析?”。在写到RDS SQL Server死锁系列文章之五时,我们就可以使用Extended Events来解决这个问题。 # 分析问题 Extended Events是微软从SQL Server 2008版本开始引入的,其中有
# 问题引入 在前面三篇文章,我们分别谈到了[使用DBCC命令捕获死锁](https://yq.aliyun.com/articles/73856?spm=5176.8091938.0.0.rjljJx);[使用Profiler界面跟踪Deadlock Graph事件捕获死锁](https://yq.aliyun.com/articles/73951?spm=5176.8091938.0.0.o
# 问题引入 系列SQL Server死锁系列文章之二,讲的是如何手动部署Profiler来捕获死锁以及对死锁发时场景重现,这篇文章是将这个手动部署的过程自动化话,实现一键部署,既快捷方便,又简单适用。上一篇文章,参见:[使用Profiler捕获死锁](https://yq.aliyun.com/articles/73951?spm=5176.8091938.0.0.oDXHeW)。 # 自动
# 问题引入 不管是RDS SQL Server还是自建SQL Server数据库,死锁的确是一个非常头疼的问题,上一篇文章我们已经谈到了[使用DBCC捕获死锁](https://yq.aliyun.com/articles/73856?spm=5176.8091938.0.0.rjljJx)。这篇文章是以阿里云RDS客户遇到的死锁问题为背景,分享死锁文章系列之二使用Profiler捕获死锁。
# 问题引入 在日常运维阿里云RDS SQL Server产品过程中,经常会被客户问道:“应用程序被死锁报错啦?影响很大,到底是哪个进程导致了死锁发生的啊?怎么解决啊?怎么办呀?”。从客户一连串的问题中,我们深刻体会到了死锁问题的紧迫性和影响之大。授人予鱼而不如授人予渔,RDS SQL Server死锁系列文章就是为了帮助客人彻底解决死锁问题为初衷而诞生的。本篇文章是系列文章的开篇,主要是讨论如
针对阿里云RDS SQL Server 2008 R2版本,如何将已经开启了TDE的数据库还原到客户本地环境,是这篇文章要解决的核心问题。
# 摘要 阿里云RDS SQL Server客户遇到最多的一个问题便是高CPU使用率导致导致SQL Server服务响应缓慢,查询超时,甚至服务挂起僵死。本系列文章第四篇分析非SARG查询导致CPU的高利用率的解决之道。 # 问题引入 “鸟啊,你听说过RDBMS的非SARG查询语句吗?我还是今天第一次听说呢!”。老鸟有些不解的问菜鸟。 “哈哈,鸟哥,孤陋寡闻,土鳖了吧。它可是导致RDBMS
# 摘要 前两篇文章讨论了导致CPU高使用率的两个重要原因是索引缺失和索引碎片,本系列文章之三讨论数据类型隐式转换话题。 # 场景分析 在SQL Server中,比较运算符(大于、小于、等于或者连接)两端的数据类型需要保持一直才能进行。否则,SQL Server会按照数据类型优先级由低到高进行隐式转化,然后再进行比较。这个行为可以通过执行计划中的CONVERT_IMPLICIT关键字看出来,
# 摘要 上一篇文章分析了高CPU使用率的原因之一是索引缺失,接下来本系列文章之二的“索引碎片”是CPU高使用率的又一常见的原因。解决索引碎片问题是解决SQL Server服务响应缓慢,查询超时的又一利器。 # 问题引入 “鸟哥,我上一篇文章分享了因为索引缺失导致CPU高使用率的话题,反响不错。接下来,我打算分享索引碎片导致CPU高使用率的话题。”,菜鸟主动找到老鸟汇报工作。 上一篇文章详
CPU高使用率往往会导致SQL Server服务响应缓慢,查询超时,甚至服务挂起僵死,可以说CPU高使用率是数据库这种后台进程服务的第一大杀手。本系列文章之一的“索引缺失”就是CPU高使用率的最常见的原因之一。
本文讨论的主题是使用SSMS(SQL Server Management Studio)配合BCP命令行的方式来迁移SQL Server数据库。使用SSMS做数据库结构迁移,使用BCP命令做全量数据迁移,此方案是以本地SQL Server数据库迁移到阿里云RDS SQL Server 2012为例。
SQL Server 2012引入了列存储技术,使得OLAP场景性能提升10X,数据压缩能力7X。但是,SQL Server 2012列存储索引的一个致命缺点是列存储索引表会进入只读状态,用户无法更新操作。
在很长一段时间,我们都被一个问题困扰:如何高效的对比SQL Server执行计划的差异?这篇文章就是要来看看SSMS工具是如何解决执行计划对比功能的。
这篇文章谈到了两种将SQL Server数据库从SQL on Windows迁移到SQL on Linux Docker的方法:数据库的备份还原和数据库分离附加的方式。
这篇文章解决了Docker容器中SQL on Linux实例数据库与容器本身同生死同命运的问题,提出了当Docker容器销毁后,容器中的数据库文件得以保留的方法。
# 摘要 SQL Server 2016以及SQL on Linux版本已经支持跑在Docker容器中,也展示微软拥抱开源的决心和勇气。这篇博文就是以SQL on Linux为例,看看如何将SQL Server实例部署在Docker容器中。 # 背景 大概在两个月之前,在SQL On Linux刚发布预览版本的时候,我写过一篇文章,讲如何将SQL Server on Linux (vNext
--- title: SQL Server 2012列存储索引技术 author: 风移 --- # 摘要 MS SQL Server 2012首次引入了列存储索引(Columnstore Index)来加速数据分析(OLAP)和数据仓库(Data Warehouse)场景的查询,它主要是通过将数据按列压缩存储的方式来减少查询对磁盘IOPS开销和CPU开销,最终达到提升查询效率,降低响应
# 摘要 在面对SQL Server选择使用临时表还是表变量作为数据暂存问题时,有一个非常重要的选择标准便是性能,两者对于查询语句和DML性能表现到底如何呢?我相信,很多人的认识是片面的,或者是错误的。这里以一篇引用率很高的文章来作为反面教材来纠正那些片面和错误的认识,我暂且称之为“踢馆”。 # 背景 在研究临时表和表变量该如何选择的时候,一篇文章叫着[SQL Server Temp Tab
# 摘要 通过前面的三篇系列文章,我们对临时表和表变量的概念、对比和认知误区已经有了非常全面的认识。其实,我们的终极目的,还是今天要讨论的话题,即当我们面对具体的业务场景的时候,该选择临时表还是表变量? # 几种典型场景 以下是几种典型的场景,让我们看看到底该作何选择,以及做出最终选择的具体原因和考量。 ## 存储过程嵌套 在SQL Server中,使用存储过程的好处显而易见,往往会节约
# 摘要 关于临时表和表变量,是一个老生常谈的话题,但是,我相信很多SQL Server老司机都存在或多或少的认知误区。指出一些常见的认知误区就是写作本文的目的,希望以此来找到一些常常被我们忽略的地方。 # 认知误区 SQL Server关于临时表和表变量的常见的认知误区包含以下六点: 表变量不支持事务 表变量不能创建索引 表变量没有统计信息 表变量存驻留在内存中 表变量
# 摘要 在SQL Server代码编写过程中,经常会有需要临时“暂存”一部分数据结果集,供上下文使用,这个时候,我们有两种选择,即临时表和表变量。这篇文章从以下几个方面来对临时表和表变量进行对比: 创建和析构方式 存储方式 作用域 对事务的支持 性能影响 # 创建和析构方式 临时表和表变量在创建和析构方式上是完全不一样的,在这一节,我们会从以下几点来看看他们的不同。
# 问题引入 “菜鸟啊,最近我看到阿里云开发者论坛的数据库RDS中有人在提SQL Server表变量和临时表如何选择的问题,你去深入探讨下这个问题吧,解答解答他们的疑惑吧”,老鸟又开始为菜鸟找活干了。 “鸟哥啊,关于表变量和临时表使用选择的问题啊,向来行业里争论不休,我比较担心我们的观点被人家拍砖啊”。 “鸟啊,有争论才说明这个问题有价值啊,所以我们才更应该去弄清楚,道明白啊”。反正老鸟总会