大批量导入数据到SQL Server中log文件太大,效率低

时间:2022-03-16 06:39:32
看了相关资料,SQL Server在导入数时就是要生成log的,
我使用Bulk Insert一次导入的记录数量超过20万,
那么导入时的log文件就超过500M,
首先,是低效!
其次,本场合不需要log!
  数据是程序生成的,计算程序一定是在与数据库在一起(物理位置),连接保证率高,数据完整性有保证,没有rollback的需要

请教各位大侠,
有没有提升效能的措施?
或者这样的场合就不适合应用SQL Server?而应该使用其它数据库产品,如MySQL?

10 个解决方案

#1


知足吧  好象没有

#2


好象沒有其它辦法

#3


如果你保证正确的话.log文件可以删除的.不过以后执行还是会有的.

#4


我就是导入一次,清除一次log文件.
但是SQL Server写数据库的效率较低.
  测试中向空数据库写20万条记录,SQL Server的时间效率还不及Access.
  (不过Access写入后续数据,越来越慢.)
没有想到,传说中NB的数据库管理系统,就这能力,有点失望.
  (当然我的应用比较偏)

#5


--写一次数据,如果LOG没用的话,清除它.

清除日志:

 
DECLARE @LogicalFileName sysname,
        @MaxMinutes INT,
        @NewSize INT
USE     szwzcheck             -- 要操作的数据库名
SELECT  @LogicalFileName = 'szwzcheck_Log',  -- 日志文件名
@MaxMinutes = 10,               -- Limit on time allowed to wrap log.
        @NewSize = 20                  -- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size 
  FROM sysfiles
  WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' + 
        CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
  FROM sysfiles
  WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
  (DummyColumn char (8000) not null)
DECLARE @Counter   INT,
        @StartTime DATETIME,
        @TruncLog  VARCHAR(255)
SELECT  @StartTime = GETDATE(),
        @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time 
      AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = 
@LogicalFileName)  
      AND (@OriginalSize * 8 /1024) > @NewSize  
  BEGIN -- Outer loop.
    SELECT @Counter = 0
    WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
      BEGIN -- update
        INSERT DummyTrans VALUES ('Fill Log')  
        DELETE DummyTrans
        SELECT @Counter = @Counter + 1
      END   
    EXEC (@TruncLog)  
  END   
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
        CONVERT(VARCHAR(30),size) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
  FROM sysfiles 
  WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
 
把szwzcheck换成你数据库的名字即可,在查询分析器里面运行。 
有全角的空格(为了显示好看),你自己把他换一下. 


收缩日志:

企业管理器--所有任务--收缩数据库--文件--选日志文件收缩

#6


如果操作速度慢.检查主键,索引等是否正确?

如果不做判断,只导入数据,应该没问题的.
如果做了判断,如ID存在,UPDATE,不存在,INSERT,看看判断语句写得是否正确.建议不用in等内容.

#7


Try:

将数据库的故障恢复模型改为大容量日志记录恢复模型。

在大容量日志记录恢复模型下,将在介质错误保护程度与某些大规模或大容量操作的最优性能及日志存储空间最少占用量之间进行权衡。这些操作包括 SELECT INTO、大容量装载操作(bcp 和 BULK INSERT)、CREATE INDEX 以及文本和图象操作(WRITETEXT 和 UPDATETEXT)。

在大容量日志记录恢复模型下,对整个类只做最少的日志记录,并且无法逐个操作地控制日志记录行为。

#8


正在试验中,感谢各位大侠的关注。
谢谢!

#9


感谢各位大侠的热情参与!谢谢!

#10


Log文件大小和导入数据的时间,在上面的基础上需要在Bulk Insert命令的基础上加上With TableLock参数,对于我的实例,提高效能(导入时间)在十倍左右。

对该问题有兴趣的,可以参看下面的帖子:
http://www.microsoft.com/china/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx
个人觉得有所帮助。

#1


知足吧  好象没有

#2


好象沒有其它辦法

#3


如果你保证正确的话.log文件可以删除的.不过以后执行还是会有的.

#4


我就是导入一次,清除一次log文件.
但是SQL Server写数据库的效率较低.
  测试中向空数据库写20万条记录,SQL Server的时间效率还不及Access.
  (不过Access写入后续数据,越来越慢.)
没有想到,传说中NB的数据库管理系统,就这能力,有点失望.
  (当然我的应用比较偏)

#5


--写一次数据,如果LOG没用的话,清除它.

清除日志:

 
DECLARE @LogicalFileName sysname,
        @MaxMinutes INT,
        @NewSize INT
USE     szwzcheck             -- 要操作的数据库名
SELECT  @LogicalFileName = 'szwzcheck_Log',  -- 日志文件名
@MaxMinutes = 10,               -- Limit on time allowed to wrap log.
        @NewSize = 20                  -- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size 
  FROM sysfiles
  WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' + 
        CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
  FROM sysfiles
  WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
  (DummyColumn char (8000) not null)
DECLARE @Counter   INT,
        @StartTime DATETIME,
        @TruncLog  VARCHAR(255)
SELECT  @StartTime = GETDATE(),
        @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time 
      AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = 
@LogicalFileName)  
      AND (@OriginalSize * 8 /1024) > @NewSize  
  BEGIN -- Outer loop.
    SELECT @Counter = 0
    WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
      BEGIN -- update
        INSERT DummyTrans VALUES ('Fill Log')  
        DELETE DummyTrans
        SELECT @Counter = @Counter + 1
      END   
    EXEC (@TruncLog)  
  END   
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
        CONVERT(VARCHAR(30),size) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
  FROM sysfiles 
  WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
 
把szwzcheck换成你数据库的名字即可,在查询分析器里面运行。 
有全角的空格(为了显示好看),你自己把他换一下. 


收缩日志:

企业管理器--所有任务--收缩数据库--文件--选日志文件收缩

#6


如果操作速度慢.检查主键,索引等是否正确?

如果不做判断,只导入数据,应该没问题的.
如果做了判断,如ID存在,UPDATE,不存在,INSERT,看看判断语句写得是否正确.建议不用in等内容.

#7


Try:

将数据库的故障恢复模型改为大容量日志记录恢复模型。

在大容量日志记录恢复模型下,将在介质错误保护程度与某些大规模或大容量操作的最优性能及日志存储空间最少占用量之间进行权衡。这些操作包括 SELECT INTO、大容量装载操作(bcp 和 BULK INSERT)、CREATE INDEX 以及文本和图象操作(WRITETEXT 和 UPDATETEXT)。

在大容量日志记录恢复模型下,对整个类只做最少的日志记录,并且无法逐个操作地控制日志记录行为。

#8


正在试验中,感谢各位大侠的关注。
谢谢!

#9


感谢各位大侠的热情参与!谢谢!

#10


Log文件大小和导入数据的时间,在上面的基础上需要在Bulk Insert命令的基础上加上With TableLock参数,对于我的实例,提高效能(导入时间)在十倍左右。

对该问题有兴趣的,可以参看下面的帖子:
http://www.microsoft.com/china/technet/prodtechnol/sql/2000/maintain/incbulkload.mspx
个人觉得有所帮助。