我知道在分区之间切换需要两个分区都驻留在同一个文件组中。但是我无法找到任何合适的地方知道在哪里/可能是这个概念背后的原因。
源表和目标表必须共享同一文件组。 ALTER TABLE ... SWITCH语句的源表和目标表必须位于同一文件组中，并且它们的大值列必须存储在同一文件组中。任何相应的索引，索引分区或索引视图分区也必须位于同一文件组中。但是，文件组可以与相应表或其他相应索引的文件组不同。 http://technet.microsoft.com/en-us/library/ms191160(v=sql.105).aspx
在我的一个分区实现中：
我将我的档案表保存在同一个文件组中，执行SWITCH，然后删除 并重新创建聚集索引以将数据移动到不同的文件组。这花费了我很多！
我希望旧数据移动到不同的表，即存档于不同文件组（用于分析目的）的档案表（不同的驱动器）。但是由于这个限制，我实现了如上所述
我理解所遵循的概念（数据没有实际移动）。但为什么？ 期待答案，如＆＃34;由于sql-server pagesize限制或分页概念重叠等等＃34; 就像那样。
请帮我找到或理解这个！
答案 0 :(得分：1)
switch语句非常有效，因为它实际上只是替换磁盘上的地址而不是移动数据。因此，两组数据都需要在同一个文件组中才能促成这种“技巧”。
答案 1 :(得分：0)
考虑以下设置
FG1 FG2
| |
------------ ------------
| | | |
F1 F2 F3 F4
FG是文件组，下面的F是个别文件。
我们有一个分区，其数据偶然发生在F1内。在我们执行切换后，其所有数据仍将在F1之内。尽管仅限制了文件组的限制，但限制实际上是＃34;数据必须保留在同一文件中＃34;。
为什么呢？因为这是我们能够有效地做到这一点的全部原因。我们无法在F1中获取范围（甚至单个数据页），并突然使它们成为F2（或F3或F4）的一部分，因为其他文件可能位于其他磁盘上。你不能说＆＃34;这个磁盘的这个页面现在是该文件的一部分，位于另一个磁盘上＃34; - 那不是（最传统的）文件系统的工作方式 - 当然是SQL Server的工作方式。
如果想要跨文件组移动，您不能突然说F1（或其中的一部分）现在是FG2的一部分，或者代替，它属于FG1。文件只属于一个文件组，因为File Groups是多个功能的管理级别。
如果我们想在两个表之间移动一组行，但我们想以不受数据移动限制的方式编写它，我们已经有了这样做的工具 - {{ 1}}和INSERT（可能使用DELETE中的OUTPUT作为DELETE的行来源，将其写为一个可爱的组合语句。
微软的某个人可以坐下来写一个INSERT的实现，它确实允许数据移动 - 但他们还没有看到实现这一点的必要性。相反，他们已经记录了当前的限制。
（我注意到我还没有链接到任何＆＃34;官方来源＆＃34;或者真的在这里添加了很多新内容，而这些新内容无法从了解哪些文件组实际上是我希望有人在遇到他们实际上试图在他们之间移动数据的情况之前至少会有一些熟悉感。
答案 2 :(得分：0)
一个文件组可以存储多个表的数据。该语句引用的表不是文件组。当文件组存储多个表的数据并且您尝试仅移动一个表的数据（仅将一个表切换到另一个FG）时，应该拆分原始文件组，这需要大量资源来执行操作（以物理方式移动数据）。在这种情况下，操作类似于将索引或群集密钥移动到另一个文件组时。
编辑此外，源和目标FG以及相关的分区方案和功能不必相同，并且您尝试移动的数据不一定适合新文件组中的分区定义。< / p>
来自以下评论
为什么不能像SQL Server更新存储到B-tree根目录的元数据那样更新存储文件组信息的元数据？在这个答案中，我没有找到交换机无法切换文件组的原因。
这不是不可能的，但是一个物理文件不能成为多个FG的一部分。如果您只将元数据更改为另一个FG并且原始FG存储多个表的数据（这意味着物理文件存储多个表的数据），则需要进行文件拆分，或者如果数据未移动，则文件将成为多个FG。
答案 3 :(得分：0)
SWITCH的用例不是将数据重定位到不同的存储，而是将数据作为仅元数据操作移动到不同的表中。这是设计的。没有任何技术原因阻止SQL Server将分区移动到不同的文件组，但它不再仅仅是元数据，并且由于大量数据移动，操作可能非常耗时。这基本上与您目前手动执行的操作相同。
这引出了一个问题，即为什么要将数据移动到另一个表中。我认为您只是想将分区移动到不同的文件组，但将其保留在原始表中。