标签: filegroups

如何将集群主键移动到新文件组？我已经找到了一种可能的“算法”，但它的效率非常低：

1. 删除非聚集索引（需要重新使用和重建它们）
2. 删除聚集索引（需要对整个表进行重新排序）
3. 创建新的主键约束（巨大的排序操作）
4. 创建所有非聚集索引（需要排序和写入）

有没有更有效的方法？这是非常低效的，并且需要很长时间，因为表在弱服务器上的大小为 50GB。

有没有办法跳过所有这些并在新文件组上重建？这不需要对数据进行任何排序。

如果文件组包含列存储索引，则似乎设置文件组以read_only防止dbcc checkdb整个数据库。尝试运行checkdb或checkfilegroup（对于数据库中的任何文件组，包括读写辅助文件和[PRIMARY]）时，将返回以下错误...

Msg 8921, Level 16, State 1, Line 24
Check terminated. A failure was detected while collecting facts. 
Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

是否有支持在只读文件组中存储列存储数据的方法？还是在这种情况下我无法进行完整性检查？

再现

create database check_fg_ro
go
use check_fg_ro
go
exec sp_changedbowner 'sa';
go
alter database check_fg_ro add filegroup check_fg_ro_2;
alter database check_fg_ro
    add file (
         name='check_fg_ro_2'
        ,filename='C:\check_fg_ro_2.ndf'
    ) to filegroup check_fg_ro_2;
go
create table …

我希望能够详细了解哪些数据库文件包含数据库中各种 HoBT（对齐和非对齐）的分配单元。

在我们开始为每个文件组创建多个数据文件之前，我一直使用的查询（见下文）一直对我有用，我只能弄清楚如何获得与文件组级别一样的细粒度。

select 
    SchemaName = sh.name, 
    TableName = t.name, 
    IndexName = i.name, 
    PartitionNumber = p.partition_number,
    IndexID = i.index_id,
    IndexDataspaceID = i.data_space_id,
    AllocUnitDataspaceID = au.data_space_id,
    PartitionRows = p.rows
from sys.allocation_units au
join sys.partitions p
    on au.container_id = p.partition_id
join sys.indexes i 
    on i.object_id = p.object_id
    and i.index_id = p.index_id
join sys.tables t 
    on p.object_id = t.object_id
join sys.schemas sh
    on t.schema_id = sh.schema_id
where sh.name != 'sys'
    and au.type = 2
union all 
select 
    sh.name, 
    t.name, 
    i.name, 
    p.partition_number,
    i.index_id,
    i.data_space_id, …

我们的企业标准之一是为用户表/索引使用单独的文件组/文件。这被设置为默认值，因此无需限定 CREATE TABLE 语句。

所以它看起来像这样

• fileid 1 = 系统表，MDF
• 文件 ID 2 = t-log = LDF
• fileid 3 = 用户资料 = NDF

这里的任何人都可以帮助我理解为什么强制执行此操作的原始理由吗？

我会坦白说我认为这是巫毒教。上午我错了......？

编辑：我知道如何使用文件组来分离索引/分区/存档，以及如何逐步恢复。这个问题是关于在同一卷上为系统表使用单独的文件组。

有人可以给我举一个真实世界的场景，当将多个文件组更改为只读是一个不错的选择以及何时使用它们？如果将其设置为只读有什么好处？

在具有多个文件组的数据库上，您是否必须备份整个数据库并备份该文件组的每个文件？您还可以举一个何时使用文件组备份的示例吗？当您可以备份整个数据库时，我不明白为什么备份文件组会有所帮助。希望我能获得一个真实世界的体验，这个文件组备份是理想的

我最近为旧数据库生成了脚本，发现大多数表都是用 . 创建的TEXTIMAGE_ON [PRIMARY]，但只有一个文件组。

TEXTIMAGE_ON [PRIMARY] 当只有一个文件组时是多余的，对吗？

我的数据库中有一些非常大的表，但是这些数据中有很大一部分是“旧的”。

由于我无法控制的情况，我不允许删除这些“旧”数据。另一个限制是我无法修改数据库，这意味着向其中添加文件组。现在的情况是，一切都驻留在PRIMARY文件组中。

我想将这些表分成几个分区，例如“新”、“旧”、“存档”等。我确实有一个“状态”列，我想用于此目的。

鉴于所描述的场景和限制，我想知道分区在这里是否有意义。换句话说，如果我的表以这种方式分区，但所有分区都位于同一个文件组中，SQL Server 是否足够聪明，可以在底层文件中找到我的“新”数据所在的特殊区域，而不触及具有“旧”数据的区域？

换句话说，假设我 80% 的数据是“旧的”。SQL Server 是否有一种机制可以避免访问 100% 的底层文件，而只访问 20% 包含“新”数据的内容（当然，假设我WHERE在查询子句中指定了我的分区列）。

我想要回答这个问题，需要了解分区是如何在内部实现的。我很感激任何指点。

我在 SQL Server 2017 CU3 上遇到一些奇怪的错误消息。我正在迁移数据库并重新组织文件组。“重组”是指我使用存储过程在新文件组上为对象创建分区函数和分区方案，在分区时重建索引，然后删除分区。

最后我有一些空的文件组。他们的文件被删除。文件组本身也被删除。这在大多数情况下效果很好。但是，对于两个数据库，我删除了文件...留下了一个没有关联文件的文件组，但是

ALTER DATABASE REMOVE FILEGROUP

抛出错误 5042：

无法删除文件组“xyz”，因为它不为空。

题

我怎样才能摆脱那个空的文件组......可能是什么问题？

我已经阅读了一些常见问题，但是它们在我的系统中不存在：

• 检查：

  SELECT * FROM sys.partition_schemes;
  SELECT * FROM sys.partition_functions;
  

  Run Code Online (Sandbox Code Playgroud)

  0 行...数据库中没有剩余的分区对象

• UPDATE STATISTICS 对于数据库中的所有对象

  没有效果

• 检查文件组上的索引：

  SELECT * FROM  sys.data_spaces ds
  INNER JOIN sys.indexes i
  ON ds.data_space_id = i.data_space_id
  WHERE ds.name = 'xyz'
  

  Run Code Online (Sandbox Code Playgroud)

  0 行

• 检查文件组中的对象：

  SELECT
      au.*,
      ds.name AS [data_space_name],
      ds.type AS [data_space_type],
      p.rows,
      o.name AS [object_name]
  FROM sys.allocation_units au
      INNER JOIN sys.data_spaces ds …

  Run Code Online (Sandbox Code Playgroud)

我的数据仓库中有一个非常大的数据库，我们在其中实施了分区来管理维护和备份。某个时间的记录最终会每月迁移一次到只读文件组。

有时，我们的 ETL 过程会尝试更新已迁移到存档的旧记录，但我们预计这些会失败。但是，我至少有两个最近的示例，其中测试中的记录即使在我们的测试环境（查询sys.partition_functions和sys.partition_range_values）中似乎位于只读文件组的分区中也会更新。

生产中的相同记录在尝试更新记录时会导致预期的失败。到目前为止，我们已经两次发现更新在生产中失败但在测试中成功（从来没有相反）。

相关环境事实：

• SQL Server 2012 SP3 CU3（内部版本 11.0.6537.0）
• 测试是开发版，生产是企业版
• 可以按要求提供其他人：现在严重难倒...

更新 2016-08-19

以某种方式在一夜之间更新了新记录。确认它在只读文件组中。发现我可以更新同时插入的记录（即也在只读文件组的同一分区上）。我在同一分区上识别了一条记录，并且能够多次更新该记录。尝试更新夜间更新的记录会导致预期的失败。

更新 2016-08-11

在只读分区上的测试中的夜间处理期间继续发生更新。尝试从进程更新相同的记录失败。在以之前更新记录的用户身份登录时尝试更新相同的记录失败。我也无法通过更新夜间流程尚未触及的类似记录来复制该问题。

更新 2016-08-04

今天发现它不仅限于单个表，因为我发现在使用相同分区方案的不同表上又发生了相同的行为。

更新 2016-08-03

运行该脚本这个MSDN脚本证实了我使用肯德拉小的分区助手的意见时得到ph.FilegroupDetail和ph.ObjectDetail从该演示。有问题的记录位于分区 #2（有问题的记录的分区列值为 2015-03-18）

Filegroup     Low Boundary     UpperBoundary
Archive  (RO) NULL             1900-01-01
Archive  (RO) 1900-01-01       2015-04-01
ActiveFG (RW) 2015-04-01       2015-07-01
ActiveFG (RW) 2015-07-01       2015-10-01
ActiveFG (RW) 2015-10-01       2015-01-01
ActiveFG (RW) 2016-01-01       2016-04-01
ActiveFG (RW) 2016-04-01       2016-07-01
ActiveFG (RW) 2016-07-01       2016-10-01
ActiveFG (RW) 2016-10-01       2017-01-01 …

以前，在 ServerFault 上，我问了一个关于备份和恢复 Sql Server 2008 文件组的问题。

今天，当我尝试RESTORE这些FILEGROUP备份之一时，出现以下错误：-

Processed 1895080 pages for database 'XWing', file 'XWing' on file 1.
Processed 4 pages for database 'XWing', file 'XWing_log' on file 1.
The database cannot be recovered because the log was not restored.
The database cannot be recovered because the log was not restored.
The roll forward start point is now at log sequence number (LSN) 221218000000010400001. Additional roll forward past LSN 221218000000010400001 is required to …