Kevin's Blog SQL讨论群21426959 Dynamics AX 438084988

前言作为一个数据库管理员，关注系统的性能是日常最重要的工作之一，而在所关注的各方面的性能只能IO性能却是最令人头痛的一块，面对着各种生涩的参数和令人眼花缭乱的新奇的术语，再加上存储厂商的忽悠，总是让我们有种云里雾里的感觉。本系列文章试图从基本概念开始对磁盘存储相关的各种概念进行综合归纳，让大家能够对IO性能相关的基本概念，IO性能的监控和调整有个比较全面的了解。在这一部分里我们先舍弃各种结

通常我们会遇到这样的情况，一张表中包含上百万条的数据，但是每次我们只查询一小部分的数据。 比如一列只有少部分NULL值，每次我们都需要将Null值找出来进行处理。或者我们有状态标志位，需要取Flag对数据处理。 由于数据大部分是重复的，所以对于整个列做索引代价是非常大的，而且对查询性能提升可能不大。 庆幸的是微软提供了Filtered index。Filtered index引使用

当用户告诉你数据库很慢的时候，你要怎么开始Narrowdown问题呢？SQL Server提供了sys.dm_os_wait_stats可以帮助我们查看CPU,内存或者IO的等待状况。SQL Server执行过程中中等待信息会被记录到这个View中。 通过下面的语句我们可以抓取一段时间内SQL Server等待的累积信息，通过对这些信息进行排序可以找出资源瓶颈。 先看一下各个W

SELECT DTST.[session_id], DES.[login_name]AS[Login Name], DB_NAME(DTDT.database_id)AS [Database], DTDT.[database_transaction_begin_time]AS [Begin Time], --DATEDIFF(ms,DTDT.[database_transa

sys.dm_exec_procedure_stats返回缓存存储过程的聚合性能统计信息，所以用这个函数我们可以查询缓存的存储过程性能，然后针对耗资源的部分进行优化。 SELECT DB_NAME(database_id) DBName,OBJECT_NAME(object_id) SPName, datediff(second, last_execution_time,get

很多开发都喜欢用Subquery而不喜欢用Join,对于他们来讲Subquery更容易实现。但是很多情况下用Join性能要比用Subquery好。 首先我们看一下Subquery: 子查询也称为内部查询或内部选择，而包含子查询的语句也称为外部查询或外部选择。许多包含子查询的Transact-SQL语句都可以改用联接表示。其他问题只能通过子查询提出。在 Transact-SQL 中，

sys.dm_exec_query_plan以 XML格式返回计划句柄指定的批查询的显示计划，下面的语句就是通过查询XML获得并行计划信息。 SELECT TOP 10 p.*, q.*, qs.*, cp.plan_handle FROM sys.dm_exec_cached_planscp CROSS apply sys.dm_exec_query_

我们都知道SQL Server访问的数据会放到Buffer Pool中，但是你知道Buffer Pool中使用的数据密度吗？ 如果Buffer Pool中我们要查询数据的密度小，说明很多无用的内存被占用了，导致内存的浪费。  那么如何查看buffer pool中数据的密度呢？ SQL Server2005版本中提供了sys.dm_os_buffer_descriptors  DMV，使用这

随着数据的越来越大，数据库也越来越大，同时伴随着磁盘空间的增长以及性能的下降。使用SQLServer 2008的数据压缩功能可以大大的减小数据量提高查询性能，尤其对于数据仓库非常有用。（BestPractices for Data Warehousing with SQL Server 2008：http://msdn.microsoft.com/en-us/library/cc719165.as

默认情况下在日志复制中如果新增加Article那么需要产生一个包含所有Article的Snapshot。由于产生Snapshot会加锁，同时会产生IO操作，所以对于大的数据库性能影响是很大的。 可以通过下面的办法让SQL Server针对增加的Article产生Snapshot。 1.      Disable 'immediate_sync'  'allow_anonymous'

今天测试数据库的并行计划，对数据库做了一些调整。将MAXDOP的数量更改为1。但是发现还是有很多SQL语句有超过5个Thread.后来查到一篇文章说根本的原因在于MAXDOP的限制只会作用在执行计划的每个operator上，而不会作用在整个执行计划上。于各种各样的原因，我们可能需要通过sp_configure来设置最大并行度，也就是Max Degree of Parallelism (MA

SQL Server Profiler中提供了一个Blocked Process Report 事件，这个事件可以记录阻塞超过指定的时间的任务，使用这个事件我们可以记录数据库的阻塞信息。 下面我们来看一下如何使用Blocked ProcessReport： 使用Blocked Process Report需要配置阈值和报告生成频率，使用sp_configure 命令配置 block

SELECT SPID=p.spid,       DBName = convert(CHAR(20),d.name),       ProgramName = program_name,        LoginName = convert(CHAR(20),l.name),       HostName = convert(CHAR(20),host

当创建大数据库时，为了减少碎片，我们一般都会安装最终的使用大小创建，但是初始化数据和日志文件时会覆盖以前删除的文件遗留在磁盘上的任何现有数据，花费很多的时间。  不过SQL Server 提供了即时文件初始化功能，借助这个功能可以在瞬间对数据文件进行初始化即时文件初始化功能仅在向 SQL Server (MSSQLSERVER) 服务帐户授予了 SE_MANAGE_VOLUME_N

近发现系统运行比较慢，查执行计划发现花时间的基本上是Remote cost，然后在网上找到了下面这篇文章讲解了如果做优化，可以借鉴。标题：Best Performer: Distributed query (Four-part) or OPENQUERY when executing linked server queries in SQL Server文章正文：wanted

通常我们都需要查询一个表的总行数，很多人都喜欢用select count(*) from Table.如果表数据非常大的话，这样的查询是很耗费时间和资源的。 其实有两个办法可以快速的查询到SQL Server的表数据。1. sp_spaceused:其中有一列是rows，如果输入的表对象的话，那么就会获得这个表的行数，速度非常快。 rowschar(11

今天突然接到用户电话反映程序很慢。打开电脑登陆到数据库服务器发现CPU使用率达到100%。而平时CPU最高也就50%，持续时间不会超过2分钟，这个是很不正常的。查看了一下运行的SQL，确实用户比平时要多。但是很多语句明显运行时间要比平时长了很多。查了一下内存和IO都没问题，然后看查看当前执行语句的执行计划，发现都少了一个索引。 这个索引以前是我建的，建完之后效率提升了很多，怎么就没有了呢？

Good articles to troubleshooting deadlock issue in SQL Server:deadlock is defined in the dictionary as "a standstill resulting from the action of equal and opposed forces," and this turns out to be

一般在写SQL的时候应该避免在条件中使用函数，因为这样就不能有效的使用索引，从而无法生成高效的执行计划。 SQL Server提供了计算列可以帮助我们解决这个问题。 我们举个普通的例子。有很多公司使用SQL Server Collcation为大小写敏感的，因为没有办法控制用户的输入（当然在程序中进行转化也是可以的，比如全部转为大写，但是当时设计的时候很多程序员都没有考虑到），所以再做查询的时

因为sys.dm_io_virtual_file_stats返回数据和日志文件的 I/O 统计信息，包括对文件发出的读取/写入次数以及总字节数，所以这个函数既可以看到IOPS也可以看到吞吐量，还可以计算出单个IO的大小。另外也可以看到IO的等待时间。能够帮助我们很好的了解数据库的IO状况。配合Perfmon一起使用可以很快的找到IO瓶颈。下面的文章来自微软的以为高级工程师：http

今天在MSDN查询优化建议中看到这样一条信息：SQL Server 会自动考虑索引交集并可以在同一查询中对同一个表使用多个索引（可能跟大家的理解有偏差）。 在解释之前我们先看一个例子： useAdventureWorksgoselect soh.*from sales.SalesOrderHeaderASsohWHERE soh.SalesPersonID= 276

在执行计划中我们经常会看到KeyLookup和RIDLookup操作，而且Cost很大，具体什么是Key Lookup和RID Lookup： RIDLookup是在使用提供的行标识符(RID) 在堆上进行的书签查找 KeyLookup运算符是在具有聚集索引的表上进行的书签查找 区别是 Key Lookup通过聚集索引键值进行查找，RID Lookup是通过堆的行标识符（F

这个是朋友让我帮忙看的，一个查询跑的很慢，运行一次要超过1分钟。我看了一下执行计划：  这里面两张大表的Join竟然选择了Nested Loop Join(一张表返回170W另外一张返回40W数据).一般Nested Loop Join试用在外部表数据比较小，而内部表又有索引的情况下，性能好。但是这里两张表的数据都很大，这里用Nested Loop Join有点不合适。我尝试更新过