WIN2008+SQL 2008,创建数据库的时候指定了4个数据文件并给出初始化大小为1024MB,在使用中想修改数据文件大小,在管理界面中在线更改初始化大小为10240MB,且更改成功,发现文件大小也发生了改变,但大约1个小时以后再看数据文件又变回了1024MB,在管理界面中看数据文件大小也同样变成了1024MB,于是通过如下语句在线修改:
ALTER DATABASE HO
MODIFY FILE
(NAME = P1D1F1,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D1F2,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D2F3,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D2F4,
SIZE = 10240MB);
GO语句执行成功后看到界面和实际文件都变为10240MB,但大约过了一个小时查看时发现数据文件又变回了初始的1024MB,日志也未记录任何相关报错信息,请问是什么原因?为什么会这样?
ALTER DATABASE HO
MODIFY FILE
(NAME = P1D1F1,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D1F2,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D2F3,
SIZE = 10240MB);
GO
ALTER DATABASE HealthOne
MODIFY FILE
(NAME = P1D2F4,
SIZE = 10240MB);
GO语句执行成功后看到界面和实际文件都变为10240MB,但大约过了一个小时查看时发现数据文件又变回了初始的1024MB,日志也未记录任何相关报错信息,请问是什么原因?为什么会这样?
name fileid filename filegroup size maxsize growth usageP1D1F1 6 M:\HISDATE\P1D1F1.ndf PRIMARY 10485760 KB Unlimited 10% data only
P1D1F2 7 M:\HISDATE\P1D1F2.ndf PRIMARY 10485760 KB Unlimited 10% data only
P1D2F3 8 N:\HISDATA\P1D2F3.ndf PRIMARY 10485760 KB Unlimited 10% data only
P1D2F4 9 N:\HISDATA\P1D2F4.ndf PRIMARY 10485760 KB Unlimited 10% data only
-----------------------------------
但一小时左右过后又变为如下结果:
name fileid filename filegroup size maxsize growth usage
P1D1F1 6 M:\HISDATE\P1D1F1.ndf PRIMARY 1048576 KB Unlimited 10% data only
P1D1F2 7 M:\HISDATE\P1D1F2.ndf PRIMARY 1048576 KB Unlimited 10% data only
P1D2F3 8 N:\HISDATA\P1D2F3.ndf PRIMARY 1048576 KB Unlimited 10% data only
P1D2F4 9 N:\HISDATA\P1D2F4.ndf PRIMARY 1048576 KB Unlimited 10% data only
------------------------------------
请问有遇到过类似情况的人没?或者ISCSI设备会有类似问题?或者有其他的原因导致这样的结果?求真相!~
在线操作未发现有问题。
针对你的修改大小后又自动还原的问题，可以用profiler来监控，查找原因。
原因如下:数据库设置了自动收缩选项,但工作在完整模式下,因此在日常的工作中并未出现截断所以未出现太大的文件大小变化,因而未曾注意.在上述描述的问题中提交了MODIFY FILE的空间请求之后在不定长的时间内发生了 AUTO_SHRINK请求,脏读导致了丢失更新:即每个事务都不知道其他事务的存在,最后的更新将覆盖由其他事务所做的更新.
询问原因得知由于该生产业务原来运行在简单模式下因此设置了自动收缩选项,但后来更改了完整工作模式却没有设置AUTO_SHRINK为OFF正式由于这种怪异的组合并未导致文件大小异常的变化而未引起注意,但事实上肯定影响了性能:一面在请求空间,在请求期间去进行自动收缩...
查询日志发现之前在数据文件(包括日志)请求空间增长的时候发生了大量的I/O错误记录:SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds...询问得知因为这些错误记录甚至联系过存储硬件厂商查找原因未果,将AUTO_SHRINK更该为OFF的情况发现并未再发生I/O错误记录,事实上证明完整工作模式下的AUTO_SHRINK ON选项也会导致I/O错误日志记录,包括微软在内的各家文档都会给出I/O错误联系硬件厂商或者更换硬件解决磁盘I/O瓶颈的建议,在此给出另外一种可能的解释,为各位查找问题提供参考.