为什么你SQL Server的数据库文件的Date modified没有变化呢?
在SQL Server数据库中,数据文件与事务日志文件的修改日期(Date Modified)是会变化的,但是有时候你会发现你的数据文件或日志文件的修改日期(Date Modified)几个月甚至是半年以上都没有变化了,如下截图所示:
为什么呢?不会是什么bug吧? 相信很多人都会有这样的反应。下面我们通过实验来看看数据库的数据文件与事务日志文件在什么情况或条件下, 修改日期(Date Modified)才会变化.首先创建一个TEST数据库,查看其数据文件或事务日志文件的修改日期如下:
USE [master];
GO
CREATE DATABASE [TEST] ON PRIMARY
(
NAME = N'TEST',
FILENAME = N'E:\SQL_DATA\test.mdf' ,
SIZE = 32MB ,
MAXSIZE = UNLIMITED, FILEGROWTH = 1MB
) LOG ON
(
NAME = N'TEST_LOG',
FILENAME = N'E:\SQL_DATA\test_log.ldf' ,
SIZE = 4MB ,
MAXSIZE = 2048GB ,
FILEGROWTH = 10%
);
GO
我们先查看一下数据库数据文件大小、空间使用情况,依此以为参照,判别数据库数据文件或事务日志的增长情况
USE TEST;
GO
SELECT DB_NAME(database_id) AS DataBaseName
,Name AS LogicalName
,type_desc AS FileTypeDesc
,Physical_Name AS PhysicalName
,CAST(size * 8.0 / 1024 AS DECIMAL(8, 4)) AS [Size(MB)]
,FILEPROPERTY(name, 'SpaceUsed') * 8.0/1024 AS [Used_Size(MB)]
,CURRENT_TIMESTAMP AS CURRENT_DATETIME
FROM sys.master_files
WHERE database_id = DB_ID('TEST');
我们通过一个大批量插入操作,使数据库的数据文件实现自增长,如下所示,当数据库的数据文件或事务日志文件增长时,其修改日期就会变化。
SET NOCOUNT ON;
GO
CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(600));
CREATE CLUSTERED INDEX PK_TEST ON TEST(OBJECT_ID)
DECLARE @Index INT =0;
WHILE @Index < 200000
BEGIN
INSERT INTO TEST
SELECT @Index, REPLICATE('it is only test', 40);
SET @Index = @Index +1;
END
GO
然后你用执行一些其他DML操作,前提是不要使数据文件增长,那么你会发现数据库数据文件与事务日志文件的修改日期是不会变化的,也就是说即使数据库的数据文件和日志文件有读写操作,它的修改日期是不会变化的,这个跟普通文件是有区别的。
DECLARE @Index INT =0;
WHILE @Index < 20
BEGIN
INSERT INTO TEST
SELECT @Index, REPLICATE('it is only test', 40);
SET @Index = @Index +1;
END
GO
所以即使你看到你的数据库里面数据文件或事务日志文件的修改日期是几天前、甚至是几个月前的日期,也不要大惊小怪,这个并不代表这这个数据库并没有任务事务操作或活动事务,而是仅仅因为数据库的数据文件和事务日志文件没有扩展而已。因为可能数据文件或事务日志文件有大量空间可用,或是最近数据增长很少的缘故。
那么还有那些操作会修改数据库的数据文件与事务日志文件的修改时间(Date Modified)呢? 总结归纳起来有下面一些操作:
1:数据文件或事务日志文件的自增长或调整大小(使用SQL语句调整数据文件大小也会改变修改时间)
2:数据文件或事务日志文件的收缩会修改数据文件的修改日期。
3:分离附加数据库或脱机联机操作会修改数据文件的修改日期。
4:重启数据库服务也会修改数据文件的修改日期(有些数据库的数据库文件的修改日期会变化,有些也不会变化)
当然,应该还有一些其他操作也有可能导致数据库数据文件或事务日志文件的修改日期变化,没法一一实验测试验证,在此略过。
PS:本文是同事想以数据文件的修改日期来判断数据库最近的活动时间,结果发现这么一个现象,所以做了一下这方面的研究和总结。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SQL Server如何固定执行计划
原文: SQL Server如何固定执行计划 SQL Server 其实从SQL Server 2005开始,也提供了类似ORACLE中固定执行计划的功能,只是好像很少人使用这个功能。当然在SQL Server中不叫"固定执行计划"这个概念,而是叫"执行计划指南"(Plan Guide 很多翻译是计划指南,个人觉得执行计划指南稍好一些)。当然两者虽然概念与命名不同,实质上它们所说的是相同的事情,当然商业包装是很常见的事情。个人还是觉得“固定执行计划”这个概念叫起来顺口,通俗易懂,执行计划指南(Plan Guide)叫起来老感觉非常拗口,不知所云(后面会在这两个概念切换,你知道我所说的是一件事情就好)。其实我以前也很少使用这些功能,直到最近在SQL Server 2014数据库中使用固定执行计划解决了几个SQL的性能问题,所以觉得还是有必要总结、归纳一下。 为什么要固定执行计划? 为什么要使用固定执行计划(Plan Guid)呢? 个人简单的从下面几个方面介绍一下,如有不足,敬请指正。个人也是在探索当中。 由于一些特殊原因(例如Parameter Sniffing、统计信息的变化...
- 下一篇
MS SQL巡检系列——检查外键字段是否缺少索引
原文: MS SQL巡检系列——检查外键字段是否缺少索引 前言感想:一时兴起,突然想写一个关于MS SQL的巡检系列方面的文章,因为我觉得这方面的知识分享是有价值,也是非常有意义的。一方面,很多经验不足的人,对于巡检有点茫然,不知道要从哪些方面巡检,另外一方面,网上关于MS SQL巡检方面的资料好像也不是特别多。写这个系列只是一个分享,自己的初衷是一个知识梳理、总结提炼过程,有些知识和脚本也不是原创,文章很多地方融入了自己的一些想法和见解的,不足和肤浅之处肯定也非常多,抛砖引玉,也希望大家提意见和建议、补充,指正其中的不足之处。Stay Hungry Stay Foolish! MS SQL巡检系列——检查重复索引 MS SQL巡检系列——检查外键字段是否缺少索引 MS SQL巡检系列——检查数据库上一次DBCC CHECKDB的时间 对于绝大部分情况,外键字段都有必要建立对应的索引(注意,外键约束并不会自动建立索引),关于外键字段为什么要建立索引?下面从几个简单的例子来分析一下。我们先准备测试环境数据。 CREATETABLE PRIMARY_TB ( PRODUCT_CD V...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS6,CentOS7官方镜像安装Oracle11G
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作