日期:2014-05-17  浏览次数:20568 次

SQL2008或SQL2012 如何配置, 使SQL的执行效率最高?
硬件配置:
1.双CPU,共16核32线程,每个逻辑线程的主频是2.1GHz
2.内存:48G

软件配置:
1.Win7 64位
2.SQL2012

我是使用内存表插入数据的,每次插入两千条左右数据;
表有八个字段,没有任何约束,有两千个这样的表.

现在的测试结果是32核没有4核3GHz的机器快,这是什么原因?
为什么资源监视器的资源利用率不高?

=========
我想最大范围提升执行速度(主要是插入操作),把大部分硬件资源耗在插入操作也没关系
请各位大侠建议.谢谢.

------解决方案--------------------
提升数据插入速度,主要瓶颈在io上面。
1、采用固定内存分配,如果服务器上只有SQLSERVER在运行,使用6G给系统,42G给SQLSERVER。
2、做磁盘阵列RAID10,第一个阵列放置系统,temp数据库,第二个阵列放置数据文件,第三个阵列放置日志文件。
------解决方案--------------------
LZ的问题很清晰了:
大量的日志写入时瓶颈。
1、按我之前说的做。
2、把日志大小设置为磁盘空间的80%,允许自动增长,每天按GB来增长(主要看你的日志增长速度)。
3、定时备份日志。
解释:
1、可以充分的利用磁盘,达到多个磁盘协同读写,同时日志和数据分离,可以分离数据的随机写入和日志的顺序写入,这样可以尽可能的提升磁盘读取速度。
2、设置日志的最大大小,并让日志按设置大小增长,可以让日志基本达到不自动增长的目的,因为日志文件自动增长会导致磁盘碎片和消耗磁盘的性能。
------解决方案--------------------
重点就是LOG配置上,或者优化插入批次
------解决方案--------------------
引用:
Quote: 引用:

c#并行开发的app,如循环用了Parallel.For在这里面通过内存表批量插入数据,每一次循环insert一表(2000条左右记录),有2000多次并行循环

能否把你的C#代码贴出来看看。

其实我觉得两千多次并行循环应该当作一个BATCH,然后再做Commit,这样写LOG的次数会变少,性能应该会有改进。 
------解决方案--------------------
引用:
Quote: 引用:

Quote: 引用:

c#并行开发的app,如循环用了Parallel.For在这里面通过内存表批量插入数据,每一次循环insert一表(2000条左右记录),有2000多次并行循环

能否把你的C#代码贴出来看看。

其实我觉得两千多次并行循环应该当作一个BATCH,然后再做Commit,这样写LOG的次数会变少,性能应该会有改进。 

嗯,所想略同,但是我不确实它到底是不是已经这样做了,所以想看看他的代码。
------解决方案--------------------
引用:
Quote: 引用:

Quote: 引用:

c#并行开发的app,如循环用了Parallel.For在这里面通过内存表批量插入数据,每一次循环insert一表(2000条左右记录),有2000多次并行循环

能否把你的C#代码贴出来看看。

其实我觉得两千多次并行循环应该当作一个BATCH,然后再做Commit,这样写LOG的次数会变少,性能应该会有改进。 

这里一共有两千条记录,还要做batch,一个batch 1000条吗?我感觉做batch有可能会提高性能,但效果应该不大。

CPU数目虽多,但是单个CPU的能力不一定强;而跑得慢的操作,需要消耗一定的CPU资源,同时SQLServer又是用单线程完成的。

在OLTP类型的应用里,语句相对比较简单,操作的数据量比较少,SQL
Server会选择用单个线程完成。也就是说,每个操作,SQL
Server都是用单个CPU做的。CPU数目多,可以使得SQL
Server能够在同一个时间,处理更多的并发请求。但是对于单个操作的时间长短,则是由单个CPU的能力决定的。
现在服务器上的CPU,往往一个就包含4核、32核,而且常常设置成Hyper-Threading。结果是在Windows里看上去,CPU的数目很多。但是这些CPU都是逻辑CPU。它们单个的处理能力怎么样?最好能测试一下。如果真是并行执行往2000个表里放数据的话。还应该是32盒的跑的快,你也许该看看你的代码是不是并行执行的。因为你上面说你的资源利用率不高。