问题标签 [defragmentation]

我们在多个表中使用聚集列存储索引。要确定碎片，

1. 当我使用 sys.dm_db_column_store_row_group_physical_stats 时，我看到 0% 的碎片，
2. 当我查询 sys.dm_db_index_physical_stats 时，我看到 90.10% 的碎片也索引属性显示页面完整度为 62.5%，总碎片为 90.10%。

哪个碎片应该被视为我的表的实际碎片。我可以通过重建索引或重建列存储分区来删除碎片吗？

请建议。

我们正在运行 MariaDB v 10.1.30，测试一个脚本来运行数据库维护脚本，以使用 OPTIMIZE TABLE 命令通过设置 innodb_defragment = 1 的新 10.1.1 补丁来对表进行碎片整理和重建索引。

我已经使用 Alogorithm = INPLACE 测试了 Alter Table，工作正常，但我正在尝试使用 innodb_defragment 并使用优化来避免在按照 Alter table INPLACE 算法重建表时创建临时文件。

在使用 Optimize 时，没有创建临时表，但是该表被锁定，不允许并发连接，这与 Alter Table with Alogorithm = INPLACE 的情况不同，但是文档提到优化是使用 INPLACE 算法完成的。

https://mariadb.org/defragmenting-unused-space-on-innodb-tablespace/

这是一个错误还是我在这里遗漏了什么，请告知。

我正在试验FSCTL_MOVE_FILE. 大多数情况下，一切都按预期工作。但是，有时如果我尝试重新读取（通过FSCTL_GET_NTFS_FILE_RECORD）我刚刚移动的 Mft 记录，我会得到一些错误的数据。

具体来说，如果文件记录说 $ATTRIBUTE_LIST 属性是非常驻的，我使用我的卷句柄从磁盘读取数据，我发现那里的数据内部不一致（记录长度大于数据的实际长度） .

我一看到这种情况，原因就很清楚了：我在 Ntfs 驱动程序完成写入之前读取记录。调试支持这一理论。但是知道这并不能帮助我解决它。我正在使用同步方法进行FSCTL_MOVE_FILE调用，但显然文件系统仍然可以在后台更新内容。唔。

在普通文件中，我会考虑LockFileEx使用共享锁（因为我只是在阅读）。但我不确定这对音量句柄有什么意义？而且我更不确定 Ntfs 在内部使用这种机制来确保一致性。

不过，这似乎是一个开始的地方。但是我LockFileEx对音量句柄的调用正在返回ERROR_INVALID_PARAMETER。我没有看到哪个参数可能出错，除非它是音量句柄本身。也许他们只是不支持锁？CreateFile或者也许在打开音量手柄时我应该设置一些特殊的标志？我尝试启用SE_BACKUP_NAMEand FILE_FLAG_BACKUP_SEMANTICS，但错误保持不变。

展望未来，我可以在这里看到一些替代方案：

1. 弄清楚如何使用卷句柄锁定部分（并希望 Ntfs 驱动程序也这样做）。在这一点上似乎很可疑。
2. 弄清楚如何刷新我刚刚移动的文件的元数据（nb：MOVE_FILE_DATA.FileHandle 的 FlushFileBuffers 没有帮助。也许刷新卷句柄？）。
3. 是否有一些“官方”方法可以读取不涉及ReadFile卷句柄的非常驻数据？我没有找到，但也许我错过了。
4. 移动数据后稍等片刻，让驱动程序完成更新所有内容。呸。

FWIW，这是一些针对卷句柄执行 LockFileEx 的测试代码。请注意，您必须以管理员身份运行才能锁定卷句柄。我正在使用J:，因为那是我的闪存驱动器。50000 是随机挑选的，但应该小于闪存驱动器的大小。

查看坏数据的代码……相当复杂。然而，它很容易重现。当它失败时，我最终尝试读取长度为“0”的可变长度 $ATTRIBUTE_LIST 条目，这会导致无限循环，因为看起来我从未完成读取整个缓冲区。如果长度为零，我正在通过退出来解决它，但我担心缓冲区中的“剩余垃圾”而不是干净的零。检测到这是不可能的，所以我希望有更好的解决方案。

毫不奇怪，关于这方面的信息并不多。因此，如果有人在这里有一些经验，我可以使用一些见解。

编辑1：

更多不太有效的事情：

• LockFileEx 仍然没有运气。
• 我尝试冲洗音量手柄（如保罗建议的那样）。虽然这有效，但它使我的执行时间增加了一倍以上。而且，严格来说，它仍然不能解决问题。仍然不能保证 Ntfs 不会在 FlushFileBuffers 和 FSCTL_GET_NTFS_FILE_RECORD / ReadFile 之间做出更多改变。
• 我想知道 $STANDARD_INFORMATION 属性的“RecordChanged”时间戳。但是，由于对 ATTRIBUTE_LIST 的这些更改，它没有被更改。
• 对文件进行分段最终会导致添加一个 ATTRIBUTE_LIST，并且随着分段的不断增加，更多的 DATA 记录将添加到该列表中。添加 DATA 记录后，UpdateSequenceNumber（不是 MFT_SEGMENT_REFERENCE 的一部分，另一个）会更新。不幸的是，有一系列事件可以执行此更新。显然，ATTRIBUTE_LIST 缓冲区“长度”在“UpdateSequenceNumber”之前更新。因此，查看“UpdateSequenceNumber”是否已更改无助于避免读取（可能）错误信息。

我的下一个最佳想法是看看 Ntfs 是否总是在更新记录长度之前将新字节归零（或者可能每当记录长度缩小时？）。如果我可以依赖记录长度为零（而不是任何剩余数据可能占用这些字节），我可以假装称之为固定。

我已在本地计算机中使用以下查询在数据库表上重建 INDEX。之后，我创建了一个.bak文件以将数据库移动到服务器。我不确定重建索引是否反映到.bak文件中，或者它只是本地硬盘上的碎片整理过程？

我应该再次在服务器上重复此查询吗？

使用 EXECUTES 从碎片整理 SP 重建和排除索引时，我收到以下错误：

消息 50000，级别 16，状态 1，过程 IndexOptimize，第 918 行 不支持参数 @Indexes 的值。

消息 50000，级别 16，状态 1，过程 IndexOptimize，第 1009 行该文档可在https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html获得。

据我所知，我的语法是正确的，并且遵循 Ola 对 T 的文档。有什么想法吗？

示例代码：

我在这里找到了我们如何在 SQL Server 中解决这个问题- 但我如何在 PostgreSQL 中解决这个问题？

我们需要每年从一个巨大的表中删除一次旧数据。表的行相当紧凑（大约 40 个字节），表上只有一个聚集索引。

该数据库总共约 750 GB，处理的表大小为 640 GB，在清理之前包含 87 亿行。删除后，只剩下 37 亿行，数据大小降至 500 GB 左右。

这些数字看起来很奇怪，但它们很好：每一页都删除了一些行。一些页面被清空和丢弃，一些没有改变，仍然 100% 满，但现在大部分页面都被部分填满了，每个页面上都有很多无人认领的空间。

为了回收这个空间，我需要重建索引。我的问题是：如何对与索引本身大小差不多的数据库中的索引进行碎片整理？

如果我没记错的话，INDEX DEFRAG REBUILD 需要的可用空间是其工作大小的 1.3 倍，因为它以排序方式复制数据。数据库将增长近 1 TB，一旦碎片整理完成，就不需要这个新空间。

碎片整理后收缩并没有帮助，因为它会引入新的（大量）碎片。

我知道“SORT_IN_TEMPDB”设置。是否估计此设置需要多少数据库中的可用空间？

作为替代方案，我可以删除并重新创建聚集索引，但我不确定该操作的空间要求是什么。

重新组织索引不会回收每个页面上的空间（？），所以这个操作也不是我想要的。

感谢您的任何想法！拉尔夫

我正在编写一个 C 代码来求解欧拉方程。我的代码在集群上工作得很好，但在我的电脑上却不行。似乎是 malloc() 的问题。它无法分配请求的内存并失败。

我如何使它工作？它与碎片整理有关吗？但系统设置显示（0% 碎片整理）。

仅在此处包含一部分 malloc() 代码。

我一直在寻找一个脚本，它可以对 HDD 进行碎片整理，但也可以通过os.walk(). 但我什么也没找到。

我们有一个内部 .NET 应用程序，它通过网络镜像文件目录。在客户端，我们使用 .NET 文件观察器类来监控目录。

在我们的 6 个客户端服务器之一上，我们注意到集成的 Windows 碎片整理程序有时会在运行碎片整理作业时触发文件上的文件观察程序删除事件。这些文件要么保留在源目录中，要么在源目录中重新创建，但会触发删除事件，因此我们的应用程序会删除目标端的文件。我们已经多次看到这种情况，但仅在该 1 台服务器上（从未在其他 5 台服务器上）。

任何人有任何想法或想法为什么会触发删除事件，或者有任何碎片整理设置来检查与其他服务器的差异？

任何想法或想法将不胜感激。

谢谢，

编辑：我假设的原因：

• 它发生在没有人使用服务器的半夜，
• 总是在同一天/同一时间（周一凌晨 3 点左右）
• 碎片整理作业开始，事件查看器显示碎片整理大约在同一时间开始。
• 自从我们在这台服务器上安装软件以来，过去 2 个月内这种情况发生了大约 3-4 次。
• 该软件已在其他服务器上安装了大约 6 个月以上，我们以前从未见过此问题。