今天,我在我管理的一个 SQL Server 上遇到了以下错误。
无法为数据库 '%.*ls' 中的对象 '%.*ls'%.*ls 分配空间,因为 '%.*ls' 文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。
它发生在索引重组操作期间。经过调查,我发现我的数据库被分成 3 个文件组,其中有多个文件。他们都至少有一个启用了自动增长的文件,并且托管它们的磁盘有足够的可用空间。那么为什么我的索引维护失败了呢?我的研究使我找到了这篇 MS 文章https://msdn.microsoft.com/en-us/library/aa337441.aspx,其中说:
当一个索引位于多个文件时,当其中一个文件已满时,ALTER INDEX REORGANIZE 会返回错误 1105。当进程尝试将行移动到完整文件时,重组进程被阻止。要解决此限制,请执行 ALTER INDEX REBUILD 而不是 ALTER INDEX REORGANIZE 或增加任何已满文件的文件增长限制。
好的。所以解决方案是重建索引,使其移动到新文件。但是,如果我想继续将索引保存在同一个文件中,以便我的重组可以继续,该怎么办?那可能吗?另外,是否可以找出我的数据库对象驻留在哪个文件中?大多数博客都有脚本来查找驻留在文件组中的对象,但我想在该文件组中查找文件,以便我可以手动增长它们并查看是否可以修复它。
作为我从一个 SAN 迁移到另一个 SAN 的持续传奇的一部分,新的 SAN 供应商说我需要将索引数据文件与我的主数据文件放在同一个驱动器中。否则,考虑到 SAN 附带的工具,我需要为此数据库创建一个新的 LUN 并将其创建为自己的卷。
无论如何,这是一种可以接受的做法吗……将索引文件组 (.ndf) 与数据文件放在同一个驱动器上?
谢谢
我有一个 SQL Server 数据库,其中包含两个表 -Acks和Logs.
这两个表在逻辑上是相关的,但不是关系数据库的方式。基本上,传入的每条消息都会保存在Log表中,如果我们的服务器确认了它,那么该确认就会存储在Ack表中。
我们每天存储大约 500 万个确认和 300 万个日志。我试图在每日边界上对这两个表进行分区,以便我们可以轻松地从表中删除旧分区,并提高查询性能。
我之前没有做过表分区,所以我一直在阅读一些在线教程,但是我被一件事困住了。我遵循的所有教程似乎都手动添加文件组并手动添加边界。
我希望 SQL Server 每天都以某种方式执行此操作,这就是我的问题所在。我需要它来为第二天创建新的文件组,例如每天 22:00。然后在 24:00 插入应该开始填满新的一天的分区。
谁能指出我如何实现这一目标的正确方向?综合教程或一些好的旧建议也可以。
我的第二个问题:我可以以某种方式将相同的分区函数应用于两个不同的表吗?
他们都有一个datetime(2)我想在其上分区的列,并且将应用相同的规则。
那如何适应我的文件组?我一天需要一个文件组吗?每个表在该文件组中都有一个文件,还是两个表都保存到文件组中的同一个文件中?
我是否必须为每个文件组创建一个.mdf和.ldf?还是整个数据库还有一个日志文件?
我很快将迁移到 SQL Server 2017,因此我正在努力美化我们数据库中一些被忽视的方面。一方面是文件组:我的 DBA 前任创建了多个文件组,但是没有人真正被告知大多数对象只是转到默认文件组 (PRIMARY)。
现在我想强制人们创建表和索引实际上命名他们的对象应该驻留的文件组。含义:没有“ON [Filegroup]”的 CREATE TABLE 或 CREATE INDEX 应该回滚,并显示文件组丢失的错误。有什么方法可以做到这一点,您会建议继续采用这种方法吗?我刚刚发现基于策略的管理无法阻止在默认文件组上创建对象。
这样做的要点是,someboy 应该首先为对象选择文件组,而不是在默认文件组中创建它们,然后必须根据 DBA 的咆哮移动对象:-)。
我想过两种技术......但是由于缺少知识而无法开始使用它们中的任何一种:
非常感谢您的帮助
马丁
我想知道在特定数据库中创建的对称密钥是否存储在主文件组中?
或者它们存储在用户无法与之交互的某些特殊文件组中?
例如,如果我对文件组(主要或次要)执行部分备份,我可以确定备份不包含对称密钥吗?
我发现我们只能通过 t-sql 使文件组脱机,但要使该文件组联机,我们需要恢复整个数据库。
假设我在 SQL Server 中创建了一个带有文件组 FG1 的新数据库,并将其标记为默认值。我所有的用户表等现在都在 FG1 中创建。但是,我还创建了一个属于 PRIMARY 文件组的文件。显然系统对象存储在这个主文件中。我想知道
这些是什么类型的系统对象?我可以检查他们吗?它们是否出现在“系统”数据库中?
显然,以这种方式做事会获得一些可靠性。假设我的主文件组中的文件损坏了,我还能恢复我的数据库吗?
在不同文件组上为操作系统创建数据库的优缺点是什么?我知道如果您想让数据库的静态部分在其他部分(位于不同的文件组)可以恢复时保持在线状态,这很有用。然而,这种情况对我们没有用(根据系统的性质)。
根据您的经验,如果在不同的文件组上创建数据库,我们还能获得其他好处吗?如果是这样,分配文件组的最佳做法是什么?
非常感谢。
我手头有一项任务是移动重建一个大表,以将 LOB 页面移动到 SQL Server 2017 Enterprise Edition 上的不同文件组。
我正在概念验证环境中测试脚本,我可以看到总共大约CREATE INDEX .. DROP_EXISTING=ON需要 6 小时。
CREATE UNIQUE CLUSTERED INDEX [PK_TABLE1]
ON [dbo].[TABLE1] ([Id] ASC)
WITH (DROP_EXISTING = ON , FILLFACTOR = 100, PAD_INDEX = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, IGNORE_DUP_KEY = OFF, DATA_COMPRESSION = NONE, STATISTICS_NORECOMPUTE = OFF, ONLINE = ON, MAXDOP=2)
ON PS_MOVE_HELPER_D59E24BC73414AA8A5FB2E5D8F93C3D8([Id] );
CREATE UNIQUE CLUSTERED INDEX [PK_TABLE1]
ON [dbo].[TABLE1] ([Id] ASC)
WITH (DROP_EXISTING = ON , FILLFACTOR = 100, PAD_INDEX = OFF, ALLOW_ROW_LOCKS …Run Code Online (Sandbox Code Playgroud) 将数据库放在一个服务器实例上的一个常见问题是它们都共享相同的 tempdb。是否可以为单独的数据库分配 tempdb 文件/和文件组。资源调控器允许这样做吗?
数据库 1,只能访问 tempdb 中的一个文件/文件组 1。
数据库 2,只能访问 tempdb 中的一个文件/文件组 2。