为什么在Partition'SWITCH'语句中，source＆target必须位于同一个文件组中？

我知道分区之间的切换需要两个分区都驻留在同一个文件组中。但我无法找到任何合适的位置来知道其中/原因背后的原因。为什么在Partition'SWITCH'语句中，source＆target必须位于同一个文件组中？

源表和目标表必须共享相同的文件组。 ALTER TABLE ... SWITCH语句的源表和目标表必须驻留在同一个文件组中，并且它们的大值列必须存储在同一个文件组中。任何相应的索引，索引分区或索引视图分区也必须位于同一个文件组中。但是，文件组可能与相应的表或其他相应的索引不同。 http://technet.microsoft.com/en-us/library/ms191160(v=sql.105).aspx

在我的分区执行的一个：

我把我的档案表中同一文件组，执行开关，然后删除并重新创建聚集索引将数据移动到不同的filegroup.This耗资我很多！

我想将旧数据移动到不同的表，即archivaltable（用于分析目的）居住在不同的文件组（不同的驱动器），但由于这种限制，我已经实现提到

我理解这个概念其次（数据没有实际移动）。但为什么？期待的答案，如“由于sql-server页面大小限制或分页概念重叠等”等那样。

请帮我看看或理解这个！

来源

2014-10-08 Recursive

正如它在页面上所说的那样链接到“数据没有实际移动” – 2014-10-08 13:34:24

我已更新我的问题，并带有预期的答案 – Recursive 2014-10-09 12:13:08

switch声明是有效的，因为它基本上只是替换磁盘上的地址而不是移动数据。因此，这两组数据都需要位于同一个文件组中，以便于实现这个“技巧”。

来源

2014-10-08 13:03:12 Mureinik

但是，如果没有错，我们主要使用的开关是将旧数据存档到其他表。是不是我的档案表会驻留在另一个存储区域的另一个文件组中。 – Recursive 2014-10-08 13:06:57

SWITCH也可以替换存储的文件组信息以便切换分区。它应该仍然是可能的。 – usr 2014-10-09 07:47:55

@usr请分享我的链接或解释您的评论。我无法完全理解您的评论。 – Recursive 2014-10-09 08:28:36

考虑以下设置

 FG1     FG2 
     |      | 
------------   ------------ 
|   |   |   | 
F1   F2   F3   F4

凡FG s为文件组和下方的F s为单个文件。

我们有一个分区，其数据偶然发生在F1之内。在我们执行开关后，其所有数据仍将在F1之内。尽管限制只限于文件组，但限制实际上是“数据必须保留在同一文件中”。

为什么？因为这就是我们能够有效地做到这一点的全部原因。我们无法在F1范围内取得范围（甚至是单个数据页），并突然将它们变为F2（或F3或F4）的一部分，因为这些其他文件可能位于其他磁盘上。你不能说“这个磁盘的这个页面现在是该文件的一部分，位于另一个磁盘上” - 这不是（大多数传统的）文件系统的工作方式 - 当然是SQL Server的工作方式。

而且在想跨文件组移动的情况下，你不能突然说F1（或它的一部分）现在是FG2组成部分，也是的，或相反，它属于FG1。文件只属于一个文件组，因为File Groups是几个功能的管理级别。

如果我们想移动一组两个表之间的行，但我们希望把它写在不具有数据移动的限制的方式，我们已经有工具来做到这一点 - INSERT和DELETE（可能将它写为一个可爱的组合语句，使用来自DELETE的OUTPUT作为INSERT的行的来源。

微软的某人可以坐下来写下ALTER TABLE ... SWITCH的实现，它确实允许数据移动发生 - 但他们没有看到需要实现这一点。相反，他们已经记录了目前的限制。

（我会注意到，我还没有链接到任何“官方消息人士”还是真的增添了新来的，不能从了解什么是真正文件组，其中我希望有人收集在遇到实际上试图在它们之间移动数据的情况之前，至少会有一些熟悉）

来源

2014-10-15 11:00:46

假设表格1在FG1上，表格2是空的，在FG2上。我们现在切换Table1和Table2。我们不能只是将Table1的元数据更改为空，而将Table2的元数据更改为位于FG1上？是的，这会将Table2移动到不同的FG，但这可能是好的。（并且在这些声明中我可以互换使用表和分区）。 – usr 2014-10-15 15:01:54

@usr - 除了实际数据的实际字节仍然位于磁盘1上，作为'F1'文件的一部分。它违背了*具有*独立文件组并且能够控制*数据放置位置的目的。我希望我能在上面说明，但显然不是。 – 2014-10-15 16:04:12

我的观点是交换机可以在这种情况下工作并产生有用的结果。当然，它不能移动数据。但是逻辑数据的变化可以起作用。或者，也许我只是没有想到这里。 – usr 2014-10-15 16:17:27

一个文件组可以存储多个表的数据。该声明将表格引用到文件组。当一个文件组存储多个表的数据，并且您试图只移动一个表的数据（只将一个表切换到另一个表）时，原始文件组应该被拆分，这需要大量资源来执行操作（物理移动数据）。在这种情况下，操作与将索引或群集键移动到另一个文件组时类似。

编辑此外，源和目标FG及相关的分区方案和功能不必相同，你正在尝试移动没有必要千篇一律的分区定义在新文件组中的数据。

从下面

评论它为什么就不可能更新存储文件组的信息，就像SQL Server中的元数据更新存储到B树的根元数据？在这个答案中，我没有找到交换机无法在文件组之间切换的原因。

这并非不可能，但一个物理文件不能成为多个FG的一部分。如果您只将元数据更改为另一个FG，并且原始FG存储多个表格数据（这意味着物理文件存储多个表格数据），则需要进行文件分割，或者如果数据未移动，则文件将成为多个FGs。

来源

2014-10-15 11:14:25 Pred

SWITCH的用例不是将数据重新定位到不同的存储区，而是将数据移动到另一个表中作为元数据操作。这是设计。没有任何技术上的原因可以阻止SQL Server将分区移动到不同的文件组，但不再只是元数据，并且由于大量的数据移动，操作可能非常耗时。这基本上与您目前手动进行的昂贵操作相同。

这引发了一个问题，你为什么要将数据移动到不同的表中。我想你只想将分区移动到不同的文件组，但将它保留在原始表中。

来源

2014-10-16 02:38:47

我希望它移动到不同的表（用于分析目的）居住在不同的文件组（不同的驱动器）。但由于这个限制，我已经实现了我提到的问题。 – Recursive 2014-10-16 10:50:55

为什么归档数据需要用于分析的不同表格/文件组？无法使用分区列中的WHERE子句对原始表中的数据执行分析？ – 2014-10-16 13:12:14

它可以完成，但有一个不同的应用程序完全等待潜入此数据。我明白的是，如果我可以将其移动到不同的文件组，使生活易于分开管理数据。 – Recursive 2014-10-17 05:19:04

为什么在Partition'SWITCH'语句中，source＆target必须位于同一个文件组中？

回答

相关问题