本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 接上文:理解性能的奥秘--应用程序中慢,SSMS中快(5)--案例:如何应对参数嗅探 我们抛开参数嗅探的话题,回到了本系列的最初关注点中:为什么语句在应用程序中慢,但是在SSMS中快?到目前为止,都是在说存储过程的情况.而存储过程的问题通常是因为SET ARITHABORT的不同设置项的原因.如果你的应用不使用存储过程,而是通过中间层提交客户端的查询,那么也有几个原因可能让你的查询因为不同的缓存条目从而使得在SSMS和应用程序中的运…

本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 接上文:理解性能的奥秘--应用程序中慢,SSMS中快(4)--收集解决参数嗅探问题的信息 首先我们需要明白,参数嗅探本身不是问题,而是一个特性,避免SQL Server做出盲目的假设,从而产生次优查询计划.但是有些情况下,参数嗅探却会带来负面影响.通常有下面三种典型的情况: 查询使用的参数嗅探完全不合适.也就是说,查询计划对于这次执行是合适的,但是对于下一次执行就可能不合适. 应用程序中存在特定的调用模式,而且与其他大部分调用模式差…

本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 在工作中发现有不少类似的现象,有幸看到国外大牛写的一篇文章,由于已经完善得不能再添油加醋,所以决定直接翻译,原文出处:http://www.sommarskog.se/query-plan-mysteries.html#defaultsettings  本人水平有限,如果读者觉得自己英语过得去,建议阅读原文.在翻译过程中,不排除会对某些部分进行修改,但不会影响最终效果. 由于内容较多,所以把文章拆为多篇发布,本系列文章结构: 简介…

本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 接上文:理解性能的奥秘--应用程序中慢,SSMS中快(3)--不总是参数嗅探的错 前面已经提到过关于存储过程在SSMS中运行很快,但在应用程序中运行很慢的可能原因:因为ARITHABORT的不同选项会导致不同的缓存词目,另外由于SQL Server使用了参数嗅探导致获得了不同的执行计划. 虽然已经说明了这个现象的原因,但是还没解释:如何定位和解决这个问题?到目前为止,大家都知道了如何快速处理,如果这个问题很紧急,可以直接使用: EX…

本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 接上文:理解性能的奥秘--应用程序中慢,SSMS中快(2)--SQL Server如何编译存储过程 在我们开始深入研究如何处理参数嗅探相关的性能问题之前,由于这个课题过于广泛,所以首先先介绍一些跟参数嗅探没有直接关系的内容,但是又会导致语句在SSMS和应用程序中存在性能差异的情况. 替换变量和参数: 前面已经接触过,但是在这里对其进行扩展.有时会看到论坛上有人说,某个存储过程很慢,但是把相同的语句提取出来单独执行就很快.真相就是:语…

本文属于<理解性能的奥秘--应用程序中慢,SSMS中快>系列 接上文:理解性能的奥秘--应用程序中慢,SSMS中快(1)--简介 本文介绍SQL Server如何编译存储过程并使用计划缓存.如果你的应用程序完全没有用到存储过程,而是直接使用SQL语句提交请求,那么本文大部分内容也是有效的.但是关于动态SQL的编译会在后面章节介绍,这里重点关注让人头痛的存储过程问题. 什么是存储过程? 虽然这个问题有点愚蠢,但是实际的问题是:什么对象有自己的查询计划?SQL Server为下面四类对象创建查询计…

---从计划缓存中直接获取查询计划和参数: ), ) SELECT @dbname = 'hydee_连锁', @procname = 'dbo.p_select_ware'; WITH basedata AS ( AS stmt_start, qs.statement_end_offset AS stmt_end, est.encrypted AS isencrypted, est.TEXT AS sqltext, epa.value AS set_options, qp.query_plan…

现象描述: (1).数据库通过调用透明网络实现分布式事务,但透明网关停用后,失败的分布式事务并未清理. (2).数据库 alert 日志 Thu Sep 06 06:53:00 2018 Errors in file /u01/app/oracle/diag/rdbms/zszdb/ZSZDB/trace/ZSZDB_reco_12245.trc: ORA-01017: invalid username/password; logon denied [Oracle][ODBC SQL Serve…

为什么说JAVA中要慎重使用继承   这篇文章的主题并非鼓励不使用继承,而是仅从使用继承带来的问题出发,讨论继承机制不太好的地方,从而在使用时慎重选择,避开可能遇到的坑. JAVA中使用到继承就会有两个无法回避的缺点: 打破了封装性,子类依赖于超类的实现细节,和超类耦合. 超类更新后可能会导致错误. 继承打破了封装性 关于这一点,下面是一个详细的例子(来源于Effective Java第16条) public class MyHashSet<E> extends HashSet<E>…

日常的OLTP环境中,有时会涉及到一些统计方面的SQL语句,这些语句可能消耗巨大,进而影响整体运行环境,这里我为大家介绍如何利用SQL Server中的”类MapReduce”方式,在特定的统计情形中不牺牲响应速度的情形下减少资源消耗. 我们可能经常会利用开窗函数对巨大的数据集进行分组统计排序.比如下面的例子: 脚本环境 /* This script creates two new tables in AdventureWorks: dbo.bigProduct dbo.bigTransacti…