有人可以阐明 SQL Server 2005 如何处理使用 ADO.NET 2.0 的客户端发出的可能请求。下面是 SQL Trace 的简短输出。我可以看到连接池正在工作(我相信只有一个连接正在池中)。我不清楚为什么我们有这么多 sp_reset_connection 调用,即一系列:审计登录、SQL:BatchStarting、RPC:Starting 和下面 for 循环中每个循环的审计注销。我可以看到 tempdb 和 master 数据库之间不断切换,这使我得出结论,当通过基于 ConectionString 参数从池中获取创建下一个连接时,我们丢失了上下文。
我可以看到每 15 毫秒我每秒可以获得 100-200 次登录/注销(由 Profiler 同时报告)。在 15 毫秒之后,我再次获得了每秒 100-200 次登录/注销的系列。
我需要澄清这可能如何影响生产环境中复杂的插入查询。我使用 Enterprise Library 2006,代码是用 VS 2005 编译的,它是一个控制台应用程序,它解析一个包含数千行分组父子行的平面文件,在应用程序服务器上运行并在远程 SQL 上运行 2 个存储过程Server 2005 插入父记录,检索标识值并使用它调用第二个存储过程 1、2 或多次(有时数千)插入子记录。子表有近 1000 万条记录,其中有 5-10 个索引,其中一些索引覆盖非集群。有一个非常复杂的插入触发器,它将插入的详细记录复制到存档表。总而言之,我每秒只有 7 次插入,这意味着 5 万条记录可能需要 2-4 小时。
所以我的问题是,是否有某种方法可以改进记录的插入,因为公司加载了 10 万条记录并进行日常计划,并且有 SLA 来满足作为平面文件订单的客户请求,并且必须处理一些大于 1 万的大文件(快速导入)。4小时导入6万应该减少到30分钟。
我正在考虑使用 DataAdapter 的 BatchSize 来发送多个存储过程调用,SQL Bulk 插入来批量从 DataReader 或 DataTable 进行多个插入,SSIS 快速加载。但我不知道如何正确分析重新索引和统计人口,也许这需要一些时间才能完成。更糟糕的是,该公司使用最大的表进行报告和其他在线处理,并且无法删除索引。我通过将字段设置为一个值来手动管理事务,并进行事务更新,将该值更改为其他应用程序用来获取已提交行的新值。
请告知如何解决这个问题。现在,我正在尝试在单独的数据库中使用最少的日志记录和没有索引的登台表,我将尝试进行批量(大量)父子插入。我相信生产数据库具有简单的恢复模型,但它可能是完全恢复。如果我的 .NET 控制台应用程序正在使用的 DB 用户具有 bulkadmin 角色,这是否意味着它的批量插入被最低限度地记录。我知道当一个表已经聚集并且许多非聚集索引插入时,仍然会为每一行记录。
连接池正在工作,但有很多登录/注销。为什么?
for (int i = 1; i <= 10000; i++){ using (SqlConnection conn = new SqlConnection("server=(local);database=master;integrated security=sspi;")) {conn.Open(); 使用 (SqlCommand cmd = conn.CreateCommand()){ cmd.CommandText = "使用 tempdb"; cmd.ExecuteNonQuery();}}}
SQL Server Profiler 跟踪:
审核登录主控 2010-01-13 23:18:45.337 1 - 非池化
SQL:BatchStarting 使用 tempdb 主控 2010-01-13 23:18:45.337
RPC:启动 exec sp_reset_conn tempdb 2010-01-13 23:18:45.337
审核注销tempdb 2010-01-13 23:18:45.337 2 - 池
审核登录 - 网络协议主控 2010-01-13 23:18:45.383 2 - 池
化 SQL:BatchStarting 使用 tempdb 主控 2010-01-13 23:18:45.383
RPC:启动 exec sp_reset_conn tempdb 2010-01-13 23:18:45.383
审核注销 tempdb 2010-01-13 23:18:45.383 2 - 池化
审核登录 -- 网络协议主控 2010-01-13 23:18:45.383 2 - 池
化 SQL:BatchStarting 使用 tempdb 主控 2010-01-13 23:18:45.383
RPC:启动 exec sp_reset_conn tempdb 2010-01-13 23:18 :45.383
审核注销 tempdb 2010-01-13 23:18:45.383 2 - 合并