• 全部
  • 基础类
  • 应用实例
  • 新技术前沿

求救:为什么在win2003上安装了sql 2k(sp3)后无法修改tempdb的日志增长参数?

spoky 2006-12-01 10:10:47
在win2003上安装了sql 2k(sp3)后,在执行一些大数据量的插入操作时,由于使用到临时表,发现一个普通的操作也需要耗费好久,然后检查tempdb的日志增长参数时,发现系统自动设置为每次自动增长1M,于是修改为每次增加10%之后,速度立刻快了很多。

但是在重启服务器后tempdb的log文件又还原为1M,而且自动增长设置参数又重新变回每次1M,之后就再怎么改都无法修改了。不知道为什么呢?救命啊~~~
...全文
144 点赞 收藏 6
写回复
6 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
spoky 2006-12-08
但是现在是每次重启他都说自动变回“每次自动增加1M”,这样太奇怪了,因为我已经把参数设置为“每次自动增长10%”啊?help!!
回复
gc_ding 2006-12-08
提醒楼主,如果硬盘空间不够也有可能引起你的问题!
回复
gc_ding 2006-12-08
转:happydreamer
如果系统运行过程中 tempdb因需要自动增长了,SQL Serve不会记住增长后的大小,重启服务后仍然恢复到初始大小,但如果用户使用了手工调整tempdb的大小,重启服务SQL Server会把tempdb重建为用户指定大小

测试示例

tempdb初始化大小为8MB

1)使tempdb自动增长
select b.* into #t from sysprocesses a,sysobjects b
重启后使用sp_helpdb 'tempdb'
可以看到tempdb又恢复到8MB
2) 用户使用Alter Database调整为100MB,

USE master
GO
ALTER DATABASE tempdb
MODIFY FILE
(NAME = tempdev,SIZE = 100MB)

重启服务后使用查看tempdb大小就为100MB

以下查询可以看到tempdb的变化
select a.filename,a.name,a.size*8.0/1024.0 as originalsize_MB,
f.size*8.0/1024.0 as currentsize_MB
from master..sysaltfiles a join tempdb..sysfiles f on a.fileid=f.fileid
where dbid=db_id('tempdb')
and a.size<>f.size

总结:
当系统自动调整tempdb大小时,对文件的读写将暂时的阻塞
所以如果我们预知tempdb将会增加到某个大小时,可以自行调整,从而避免性能下降
回复
qw12cn 2006-12-08
Up
回复
gc_ding 2006-12-08
try,转:
任意设置日志文件的大小。
SET NOCOUNT ON
DECLARE @LogicaFILENAME SYSNAME,
@MAXMINUTES INT,
@NEWSIZE INI
USE MARIAS---要操作的数据库
SELECT @LOGICALFILENAME = 'MARIAS_LOG',---日志文件名
@MAXMINUTES = 10,---LIMIT ON TIME ALLOWED TO WRAP LOG.
@NEWSIZE = 100---你想设定的日志文件大小(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 INI,
@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,@STARTIME,GETDATE()) --TIME HAS NOE EXPIRED
AND @ORIGINALSIZE =(SELECT SIZE FROM SYSFILE WHERE NAME = @LOGICALFILENAME)
AND (@ORIGINALSIZE*8/1024)>@NEWSIZE
BEGIN --OUTER LOOP.
SELECT @COUNT = 0
WHILE((@COUNT<@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'+
CONVER(VARCHAR(30,(SIZE*8/1024))+'MB'
FROM SYSFILES
WHERE NAME = @LOGICALFILENAME
DROP TABLE DUMMYTRANS
SET NOCUNT OFF
回复
zzxiaoma 2006-12-02
把分配空间调大点
回复
相关推荐
综教楼后的那个坑用双向链表实现 描述   在 LIT 综教楼后有一个深坑,关于这个坑的来历,有很多种不同的说法。其中一种说法是,在很多年以前,这个坑就已经在那里了。这种说法也被大多数人认可,这是因为该坑有一种特别的结构,想要人工建造是有相当困难的。   从横截面图来看,坑底成阶梯状,由从左至右的 1..N 个的平面构成(其中 1 ≤ N ≤ 100,000),如图:    *            * :    *            * :    *            * 8    *    **      * 7    *    **      * 6    *    **      * 5    *    ********* 4 <- 高度    *    ********* 3    ************** 2    ************** 1 平面 |  1  |2|   3    | 每个平面 i 可以用两个数字来描述,即它的宽度 Wi 和高度 Hi,其中 1 ≤ Wi ≤ 1,000、1 ≤ Hi ≤ 1,000,000,而这个坑最特别的地方在于坑底每个平面的高度都是不同的。每到夏天,雨水会把坑填满,而在其它的季节,则需要通过人工灌水的方式把坑填满。灌水点设在坑底位置最低的那个平面,每分钟灌水量为一个单位(即高度和宽度均为 1)。随着水位的增长,水自然会向其它平面扩散,当水将某平面覆盖且水高达到一个单位时,就认为该平面被水覆盖了。   请你计算每个平面被水覆盖的时间。    灌水 水满后自动扩散 | | * | * * | * * * * V * * V * * * * * * .... * *~~~~~~~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~** : * *~~~~**~~~~~~* * ** * *~~~~**~~~~~~* *~~~~**~~~~~~* * ********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* *~~~~********* ************** ************** ************** ************** ************** **************    4 分钟后    26 分钟后        50 分钟后    平面 1 被水覆盖     平面 3 被水覆盖    平面 2 被水覆盖输入   输入的第一行是一个整数 N,表示平面的数量。从第二行开始的 N 行上分别有两个整数,分别表示平面的宽度和高度。 输出   输出每个平面被水覆盖的时间。
发帖
MS-SQL Server
创建于2007-09-28

3.3w+

社区成员

MS-SQL Server相关内容讨论专区
申请成为版主
帖子事件
创建了帖子
2006-12-01 10:10
社区公告
暂无公告