摘要：dbms_stats包问世以后，我们可通过一种新的方式来为CBO收集统计数据。目前，已经不再推荐使用老式的Analyze分析表和dbms_utility方法来生成CBO统计数据。dbms_stats能良好地估计统计数据（尤其是针对较大的分区表），并能获得更好的统计结果，最终制定出速度更快的SQL执行...
阅读全文
posted @ 2016-01-13 11:11
随笔分类 - 性能诊断
性能问题的本质就是请求响应时间超出用户的预期。
摘要：组合主键、聚集索引引发的死锁问题，还是索引字段顺序、选择性的问题，切记。 -- SPID: 61 exec sp_executesql N'DELETE FROM SYLOCKAID WHERE MKID=@param0 AND DATACAT=@param1 AND DATAID=@param2',N'@param0 varchar(max) ,@param1 varchar(...
阅读全文
posted @ 2016-01-04 14:37
摘要：如果遇到绑定窥探导致执行计划慢的情况，想要清除某条SQL的执行计划，让它硬解析，找了很久都没有找到直接操作share pool的方法（除非alter system flush shared_pool），只能通过对表ddl使SQL硬解析。现在终于找到了，使用sys.dbms_shared_pool.p
阅读全文
posted @ 2015-12-16 18:07
摘要：cache（L1，L2，L3）：1、延迟：0.5-15us2、带宽：20-60GB/s内存：1、延迟：30-100us2、带宽：2-12GB/s硬盘：一、SSD：1、延迟：10us-1ms2、带宽：50MB-2GB/s二、普通硬盘1、延迟：5-20ms2、带宽：50-200MB/s网卡：1、延迟：1
阅读全文
posted @ 2015-12-16 17:53
摘要：用户反映修改密码后程序明显变慢，查看AWR发现: ASH信息如下： 进一步验证: SQL>select event,p1 from v$session t where t.username is not null and t.status='ACTIVE'; EVENT P1 row cache l
阅读全文
posted @ 2015-12-13 15:02
摘要：sqlserver项目，因严重的阻塞造成系统宕机的问题分析
1、通过查询SQL阻塞信息，定位到阻塞源头spid、该会话的状态、等待事件及执行的SQL脚本
2、根据spid查询该会话已经持有的锁资源、数据对象
3、根据SQL脚本如果能够找到对应的程序上下文，便可以快速定位到问题源头
4、根据源头会话确定远程连接的HostName、HostProcess，抓取进程dump文件，分析线程堆栈匹配该SQL脚本
5、使用sqlserver的Profiler，开启SQL的RPC、Batch及transaction的跟踪，结合阻塞SQL时间点，分析跟踪文件
阅读全文
posted @ 2015-12-09 18:58
摘要：1. CPU time CPU time其实不是真正的等待事件。是衡量CPU是否瓶颈的一个重要指标。一般来讲，一个良好的系统，CPU TIME 应该排在TOP 5 TIME Event的最前面。 当然这也是相对的， 如果不存在显著的 latch wait 或过高的logical read 等, CP
阅读全文
posted @ 2015-11-13 20:36
摘要：近期一个项目反馈月底高峰期时系统整体性能下降，抓取对应的AWR和ASH查看，等待事件排第一位的竟然是redo日志切换。进一步看每秒的日志量是5M多，而日志文件大小仅有200M。建议项目上调整日志大小，经验证确认性能问题明显下降，现记录调整联机日志的操作。 数据初始化日志有3组，每组50M。我们建议将日志添加到6组，根据实际情况设日志大小，建议设置为1~2G，我这里设成2G； 归档...
阅读全文
posted @ 2015-11-09 10:30
摘要：最近不定期有项目反馈周期性的系统整体性能下降情况，经分析存在因数据库环境、参数配置不佳造成的。比如，sqlserver日志文件缺省按百分比增长，当日志文件已经比较大时，每次扩展时耗时较长，系统整体卡顿；另外，如果没有专门做日志备份，收缩日志和数据库时不会显著的降低日志大小，造成每次完整备份很大、备...
阅读全文
posted @ 2015-11-09 10:15
摘要：DebugDiag简介 Debug Diagnostic Tool (DebugDiag)是微软提供的工具，可以用来追踪windows平台下的程序崩溃，卡死，内存泄漏等一些疑难问题的原因，按照问题类别配置收集后，反馈给公司技术人员。下载后按缺省提示安装即可： https://www.microsof
阅读全文
posted @ 2015-10-17 10:32
摘要：问题描述： 系统中多个功能不定期出现“Unable to get error message (6107) (0).”错误，即分布式事务超时，但报出错误的部分功能根本没有使用分布式事务。原因分析： 推测是存在分布式事务未提交的情况，回到线程池后被复用造成的，例如： 系统中A功能存在分布式事务未提交的...
阅读全文
posted @ 2015-10-10 11:37
摘要：查询数据库中所有表的大小，哪些表的数据量较大create table #t(name varchar(255), rows bigint, reserved varchar(20), data varchar(20), index_size varchar(20), unused varchar(2...
阅读全文
posted @ 2015-09-17 16:15
摘要：Oracle某一数据表tkk715（数据量在一千万左右），对一个索引字段做获取最大值与最小值的聚合函数操作，响应时间较长（超过3秒）； 将SQL改写为分别取最大、最小的聚合值，IO和响应时间显著下降到常量单位。但是，同样两组脚本在SqlServer下的执行计划是完全一样的，IO和响应时间当然也是相同...
阅读全文
posted @ 2015-07-15 14:57
摘要：当某个数据库文件空间用尽，做自动增长的时候，同一时间点只能有一个用户人员可以做文件自动增长动作，其他任务必须等待，此时会出现Latch资源的等待。使用sp_helpdb查看业务数据库时发现：该数据库设置不合理，数据文件每次增长2M，日志文件每次增长10%，且分别设置了最大限制。修改为每次增长200M
阅读全文
posted @ 2015-06-27 16:51
摘要：【问题描述】： 前段时间有一项目反馈，常用的审批功能有时的响应较慢，多个管理员功能不定期的出现客户端无响应的状况，并且管理员功能一旦出现卡死，也会影响到普通的业务用户致使很多用户无法操作。该系统为混合场景，管理员功能使用的CS客户端，业务用户使用的是WEB。 【环境信息】： 应用服务器：Window
阅读全文
posted @ 2015-06-24 17:55
摘要：【问题描述】： 产品中某业务功能A，在进行“刷新”—>选择制单—>新增—>切换其他行等一系列操作后，突然发生客户端不响应的现象。 经反复测试验证发现，在单用户场景下也会发生，不过一旦客户端启用了Fiddler工具，此问题便无法重现。并且问题发生后，抓取应用服务器的dump文件进行分析，未发现running状态的线程。 【分析过程】： 根据问题描述初步...
阅读全文
posted @ 2015-06-24 15:26
摘要：经常会碰到这样的场景，自测及单单点的测试时没有任何问题，但在并发环境或生产环境下有时出现没规律的异常、报错等情况。在代码中增加日志是其中一种解决方式；抓取指定异常时的dump，通过windbg也可以快速定位问题。 Procdump命令示例：procdump -ma -e 1 –f SqlException w3wp.exe 貌似ProcDump无法抓取Crash的dum...
阅读全文
posted @ 2015-06-24 10:14
摘要：osql/sqlcmd 工具是一个 SqlServer的命令提示符工具，我们可以使用它运行 Transact-SQL 语句和脚本文件。该工具所在目录：C:\Program Files\Microsoft SQL Server\110\Tools\Binn 交互式输入 Transact-SQL 语句，如下 C:\Users\Administrator>osql -E 1> se...
阅读全文
posted @ 2015-06-20 18:43
摘要：此前遇到一个项目反馈系统宕机问题，摘要描述如下： 系统不定期出现卡死现象，在多个模块不同功能上都出现过，未发现与特定功能相关的明显规律； 当系统出现卡死现象时，新的用户无法登陆系统； 跟踪应用服务器，未发现资源不足的情况（CPU、内存使用正常） 数据库服务器资源占用也正常（CPU不高，也未发现死锁、SQL阻塞等情况） 在问题再次发生时，使用ProcDump联系...
阅读全文
posted @ 2015-06-19 14:46
