究竟是什么触发了 sys.database_files 列 is_media_read_only 的 UPDATE？

Question

愿意解决这个问题涉及到一个错误的值对is_media_read_only数据库属性我做了一些研究和试验，但最终我不能梳理一下究竟触发列的更新is_media_read_only上sys.database_files。

根据sys.database_files文档，该列is_media_read_only应具有以下两个可能值之一：

1 = 文件位于只读媒体上。

0 = 文件在读写介质上。

有了这些信息，我对两个不同版本的 SQL Server 进行了以下实验：

Microsoft SQL Server 2014 (SP3-GDR) (KB4505218) - 12.0.6108.1 (X64)
Microsoft SQL Server 2017 (RTM-CU16) (KB4508218) - 14.0.3223.3 (X64)

在我的笔记本（驱动器 E:) 中插入一个笔式驱动器并创建一个数据库，如下所示：

CREATE DATABASE [MyDB]
 ON  PRIMARY 
( NAME = N'MyDB_01', FILENAME = N'D:\DataBases\MyDB_01.mdf'), 
 FILEGROUP [SECONDARY] 
( NAME = N'MyDB_02', FILENAME = N'E:\DataBasesPendrive\MyDB_02.ndf')
 LOG ON 
( NAME = N'MyDB_log', FILENAME = N'D:\DataBases\MyDB_log.ldf')
GO

查询 sys.database_files：

USE MyDB;
GO
SELECT file_id, name, physical_name, is_media_read_only, is_read_only, state_desc  
FROM sys.database_files;
GO

这是结果：

创建数据库后，我打开 CMD 提示符并运行diskpart. 在实用程序上，我发出了以下命令：

list disk
select disk 2
attributes disk set readonly
attributes disk

磁盘 2（我的笔式驱动器）现在是只读媒体，所以我希望is_media_read_only值会改变，但是当我sys.database_files再次查询时没有任何变化：is_media_read_only 仍然是 0。所以我开始对数据库进行随机程序，看看是否任何事情都会让 SQL Server 注意到数据库现在位于只读媒体上并将值更新为 1。我可以在两种情况下实现这一点：

第一：将数据库更改为 READ_ONLY 模式并返回到READ_WRITE. （它必须是两个动作，只有其中一个不会成功）：

USE master;
GO
ALTER DATABASE MyDB SET READ_ONLY;
ALTER DATABASE MyDB SET READ_WRITE;
GO

第二：分离并再次附加数据库。

正如您在图片中看到的那样，这是我可以is_media_read_only更新的两种情况1：

现在是时候再次将笔式驱动器恢复为 read_write，所以我返回diskpart并运行：

select disk 2
attributes disk clear readonly

当我再次is_media_read_only将磁盘 2 更改为读写模式时，只会0在分离和附加过程中更新。我什至试图重新启动 SQL Server 实例，希望它能更新值，但没有运气。

直到数据库的分离和附加 SQL Server 会给我留下价值1，is_media_read_only即使磁盘不再是READ_ONLY.

因此我的问题是：究竟是什么触发UPDATE了列is_media_read_only的sys.database_files？此实验显示的行为是否可能是 SQL Server 的错误？

Answer 1

我是 SQL Server 产品团队的工程师。这种只读媒体行为并非有意为之，我们为此发布了修补程序。

为了描述行为，只读媒体检查是在打开文件时完成的（例如，数据库启动，数据库状态更改，如只读-> 读写）。SQL 然后为内存中的文件维护一个只读媒体标志，这可以持久化到元数据中（在系统目录上）。当其他文件元数据碰巧被修改或 DB 状态发生变化时，该标志可能会被持久化到元数据中。这里真正的问题是，一旦元数据（在主数据文件上）被强化，即使媒体不再是只读的，我们也没有正确重置它。可以重置标志的一种条件是附加，但它仅适用于辅助数据文件。

所需的行为是在打开文件时关闭只读媒体标志并且媒体不再是只读的。因此，当数据库重新启动、其状态发生变化、恢复或附加时，is_media_read_only应该为每个文件正确反映它。

使固定

知识库文章 4538378 中记录了此修复程序。

Answer 2

当尝试对文件本身进行更改时，该值似乎会更新，例如 LowlyDBA 建议的那样。但仅当磁盘已设置为只读时，辅助数据文件无需再进行任何修改。如果仍然需要进行更改，则会显示不同的错误。

例如，当创建一个包含一个数据文件的数据库时，F:\我们稍后会将其设置为只读。

USE MASTER
GO
CREATE DATABASE Test
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'Test1', FILENAME = N'E:\Data\Test.mdf' , SIZE = 4160KB , MAXSIZE = UNLIMITED, FILEGROWTH = 16384KB ),
( NAME = N'testreadonly', FILENAME = N'F:\ReadonlyDisk\testreadonly.ndf' , SIZE = 5120KB , MAXSIZE = UNLIMITED, FILEGROWTH = 16384KB )
 LOG ON 
( NAME = N'Test_log', FILENAME = N'E:\Data\Test_Log.ldf' , SIZE = 1040KB , MAXSIZE = 2048GB , FILEGROWTH = 16384KB )
GO

运行 diskpart 命令后，正如预期的那样，不会对is_media_read_only以下内容进行任何更改：

USE Test
GO
select name,physical_name,is_media_read_only,is_read_only
from sys.database_files;

结果

name             physical_name                      is_media_read_only  is_read_only
Test1            E:\Data\Test.mdf                   0                    0
Test_log         E:\Data\Test_Log.ldf               0                    0
testreadonly     F:\ReadonlyDisk\testreadonly.ndf   0                    0

如果我们尝试增加文件大小：

USE [master]
GO
ALTER DATABASE [Test] MODIFY FILE ( NAME = N'testreadonly', SIZE = 6144KB )
GO

我注意到它有两种方式，要么是设备未准备好的错误消息：

消息 5149，级别 16，状态 3，第 21 行 MODIFY FILE 在尝试扩展物理文件“F:\ReadonlyDisk\testreadonly.ndf”时遇到操作系统错误 21（设备未就绪。）。

这是一个糟糕的状态，数据库也将无法再次离线和在线，因为 sql server 需要在辅助数据文件处于一致状态之前对其进行修改。

磁盘被设置为 read_only 而仍然需要对辅助数据文件进行更改。

另一个错误信息显示数据库可以再次设置在线和离线，并且sql server知道磁盘的状态，但不能进行任何更改。

MODIFY FILE 在尝试扩展物理文件“F:\ReadonlyDisk\testreadonly.ndf”时遇到操作系统错误 19（媒体被写保护。）。

当出现第二条错误消息时，例如通过更改文件大小，状态将被更新。

use master  
go
ALTER DATABASE [Test] MODIFY FILE ( NAME = N'testreadonly', SIZE = 10240KB )
GO

导致is_media_read_only列被更新：

name             physical_name                      is_media_read_only  is_read_only
Test1            E:\Data\Test.mdf                   0                    0
Test_log         E:\Data\Test_Log.ldf               0                    0
testreadonly     F:\ReadonlyDisk\testreadonly.ndf   1                    0

将.mdf或.ldf文件放在只读磁盘上时，数据库将在重新启动时不再联机。由于这些文件在数据库恢复的分析步骤中被修改。

您可以通过创建另一个数据库来验证这一点，将所有 3 个文件 ( .mdf, .ndf, .ldf) 放在同一个磁盘上并将其设置为离线和在线：

ALTER DATABASE [Test] SET OFFLINE

ALTER DATABASE [Test] SET ONLINE 

自上次离线以来修改了 .mdf 和 .ldf --> 在线

因此，理论上您可以将辅助文件放在只读磁盘上，is_media_read_only当 sql server 知道它位于只读磁盘上时，该列将得到更新。

在您的情况下重新启动数据库或实例时，它无法知道这一点，因为没有对辅助数据文件进行任何修改。如果在恢复UNDO或REDO恢复过程中必须对辅助日期文件进行修改，则您的数据库将无法联机。

在.mdf或.ldf文件上尝试此操作时，您的数据库将无法联机，并且您将收到一条错误消息，例如

FixupLogTail 期间文件“文件位置”上的操作系统错误 19（媒体被写保护。）。

因为它们是在数据库启动时修改的。

因此，我们的两个实验都表明，is_media_read_only某些文件修改后会发生变化。这似乎不一致，但它在某种程度上是一种模式。有了这个结论，您是否会说这个问题超出了该标志的“正常”行为？

好吧，我会说所有实际的文件修改都可能/会触发它，但是如果必须进行文件修改或数据库未处于一致状态，那么数据库将根本无法联机/出现其他问题。如果在数据库处于一致状态时修改失败，例如手动增大文件，则会发生错误并is_media_read_only更新。

再次在这里，将磁盘更改为只读时不进行文件修改，运行

USE master;
GO
ALTER DATABASE Test SET READ_ONLY;
ALTER DATABASE Test SET READ_WRITE;
GO

然后再次将磁盘更改为读写并再次运行两个 alter database 语句：

表明is_media_read_only没有变回是由于文件没有被“测试”再次位于可写磁盘上。

是的，那个测试。是这样的：第 1 部分 - 将驱动器更改为只读；将数据库更改为只读；将数据库更改为 read_write；is_media_read_only 为 1（完美）。第 2 部分 - 将驱动器更改为 read_write；将数据库更改为只读；将数据库更改为 read_write；is_media_read_only 仍然是 1（它应该已经改回 0 以支持所有文件修改触发 is_media_read_only 更新的结论）。

将数据库更改为只读并再次返回时，不会修改辅助数据文件，如编辑中所示。所有实际尝试的文件修改仍会更改is_media_read_only状态。

该is_media_read_only状态无关，使用alter语句不修改的辅助文件，这是这些ALTER语句只是如何表现。

您可以通过将数据库设置为只读和读写并检查辅助数据文件上的最后修改日期来自己测试。

如果您想知道为什么在将磁盘设置为只读并且运行 alter database 命令而未尝试更改辅助数据文件时触发更新的原因，我无法测试该部分，在运行语句时的错误日志。这可能与该 sql server 也没有尝试删除is_media_read_only = 1数据库删除时磁盘上的辅助数据文件有关。更少的错误可能性。