合 MSSQL中的等待事件OLEDB说明
Tags: MSSQLSQL Server等待事件
简介
OLEDB等待类型是SQL SERVER 数据库中最常见的几种等待类型之一。它意味着某个会话(SPID)通过SQL Server Native Client OLEDB Provider发生了调用请求并等待数据库返回所需的数据。它出现在远程系统(remote system )或网络连接速度不够快,因此调用服务器必须等待要返回结果的情况下。
OLEDB等待事件一般是由那些活动造成呢?它一般由下面一些事件引起:
- 远程过程调用(Remote procedure calls)
- 链接服务器查询(Linked server queries)
- BULK INSERT commands
- Full-search queries 或外部数据源处理,例如Excel
- 客户端的Profiler跟踪(Client-side Profiler traces)
- DMV, log reader and DBCC CHECKDB
DBCC CHECKDB出现OLEDB等待事件
看到DBCC CHECKDB会引起OLEDB等待事件,你是否觉得很奇怪,其实刚开始的时候我也觉得很奇怪,我们的DPA(Database Performance Analyzer)监控工具发现SQL 2012、SQL 2014数据库的DBCC CHECKDB引起的OLEDB等待事件占据了等待类型柱状图很大的比例。这个引起了我的好奇心,后面查证后发现DBCC CHECKDB它使用 OLEDB 行集在查询处理器和存储引擎的子系统之间交换信息。
下面演示一下DBCC CHECKDB出现OLEDB等待事件的例子:
1 2 3 4 5 6 7 8 9 10 | --SESSION 1 DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR); GO DBCC CHECKDB('AdventureWorks2014'); --SESSION 2 SELECT * FROM sys.dm_os_wait_stats WHERE wait_type='OLEDB' |
在DBCC CHECKDB还在执行时,你在会话2中,会看到OLEDB等待类型的waiting_tasks_count、wait_time_ms会一直增加。关于DBCC CHECKDB产生的OLEDB等待事件,我从DPA里面观察,发现SQL Server 2012、SQL Server 2014明显要比SQL Server 2005、 SQL Server 2008要多,暂时不清楚具体原因,在SQL SERVER 2012/2014中DBCC CHECKDB出现了几个Bug,具体可以参考官方文档SQL Server 2014 Service Pack 1 release information 。我们可以看到官方已经Fix掉了三个关于DBCC CHECKDB的Bug。但是我更新了这些补丁,依然发现DBCC CHECKDB引起的OLEDB等待事件较多。
另外关于DMV会引起OLEDB等待事件,是因为DMV内部使用了OLEDB,因此一些监测工具频繁调用DMV也会导致出现较多OLEDB等待事件。
OLEDB等待事件解决
1:从应用层面考虑,只返回必要的字段和数据。减少网络传输内容和时间。从而减少OLEDB等待事件。例如分页控件的按页获取数据。
2:如果使用Linked Server获取的数据是静态数据,可以考虑将这些静态数据复制到本地数据库,减少没有必要的链接服务器查询。如果数据是动态变化,也可以考虑使用使用复制(发布订阅)将数据同步到本地数据库。
3:从业务角度出发审查你的数据分布,链接服务器查询是否绝对有必要?那些是可以减少、那些不必要的?另外 ,可以从架构层面考虑解决,例如将那些数据集中起来。
4:如果有些数据源是Excel文件,可以先将其通过FTP或文件共享上传到本机,然后处理数据。
5: 优化链接服务器查询的SQL,检查其是否缺少索引、统计信息是否过时;是否可以将某些业务逻辑放置到远程服务器上去处理(存储过程),然后只返回需要的数据。例如下面这种需求。
1 2 3 4 5 | SELECT * FROM linked_server.dbo.table_a inner join .. linked_server.dbo.table_b inner join .. linked_server.dbo.table_c inner join .. ....................... |
6:找系统管理员或网络管理员了解专线带宽等情况。有时候网络带宽资源不足时也是引起OLEDB等待事件增多的原因。
修改插入方向
1、之前一个案例下来,单个SQL需要2小时,大概有12个SQL,就是需要1天才能跑完,按照这种方式优化后大概1条SQL3分钟搞定,12条SQL大概30分钟搞定。
2、在SQL Server中,SELECT INTO 的性能要比INSERT INTO 快出不少。参考:https://www.dbaup.com/zaimssqlzhongdeselect-intoheinsert-into-selectnagexingnenggenghao.html
在A库执行insert语句,将数据插入远程B库很慢。。。
1 | insert into linked_server.dbo.tttt select * from tt; |
优化:直接在B库做insert插入。。。 很快。。。。