主页 / dba / 问题 / 104981
Accepted
GroovySu
Asked: 2015-06-25 02:06:26 +0800 CST

sql server 重命名表的陷阱

  • 772

我已经想到了一种方法来构建一个相当大的表（200 万行），现在我正在征求意见。用这种重命名方法来让一张桌子“活”起来，有什么会让我心烦意乱的？

背景：表格 (data.CatExt) 是我们产品目录的叠加版本。它每天都在一个复杂的过程中构建（从许多不同的领域获取数据，并在发生冲突时决定哪个来源胜过——复杂性在于业务逻辑，而不是技术方面）。获得最终输出所需的所有工作和任何表都发生在“构建”模式中，最终表位于“数据”模式中。这些模式具有不同的权限。

表很宽，大约有 100 个字段。由于数据源的性质，我们每天都采用从头开始构建它的方法，而不是使用“更改/添加/删除”的方法（很难确定最终需要更改的内容）表。）所以我们每天都建立一个新版本的表，然后（在它通过一些自动检查之后）让它成为新的实时版本。

新方法：这就是新方法的用武之地。替换实时版本的最佳方法是什么？最简单的选择是截断并用新数据替换，但这似乎是不必要的大量数据写入。我们可以对每个字段进行更新，但是有 100 个字段需要进行很多讨厌的编码/比较才能找到任何差异。所以我想，为什么不重命名表呢？它会是这样的：

  1. 实时版本 data.CatExt 存在并且可通过步骤 2 和 3 使用。
  2. 构建新版本的表 build.CatExt。
  3. 对 build.CatExt 的检查、索引等全部完成 - 即，它是完美的。
  4. 删除（好吧，我太鸡了 - 可能重命名）data.CatExt，将 build.CatExt 重命名为 data.CatExt。

瞧，新版本，在实时版本被锁定时，没有不必要的数据移动和相关的长时间。

请指出缺陷。（温柔点，我是新人！:)）

sql-server load

2 个回答

  1. 另一种选择是在设置两个表后使用分区切换创建一个切换表。

    然后像这样执行一个简单的切换命令：

    ALTER TABLE [Table Name] SWITCH
   TO [Table Name]_SwitchOut

ALTER TABLE [Table Name]_SwitchIn SWITCH
   TO [Table Name];

    然后只需放下进出表。

    • 1
  2. Best Answer

    我做了一些类似于Jason的事情——顺便说一下，它不需要分区——但我使用模式传输而不是切换。它需要两个额外的模式来支持多个传输——在我的例子中，我称它们fake为shadow. 基本上你清空影子表，然后填充它（你也可以使用一种upsert方法，但我发现截断/插入更快，更简单，尤其是对于后台进程）。此时您可以选择更新卷影副本上的统计信息，这也是一个后台进程，因此不会中断您的用户，除非工作负载真的超载。然后你开始一个事务，移动生产（dbo) 将表复制到假模式中，将新填充的影子模式移动到生产环境中，然后提交。这只是一个元数据操作，需要模式锁，但它应该几乎是瞬间发生的。最后，将表的旧生产副本移动到影子模式中（并且现在可以选择截断它以节省空间 - 尽管我经常保持表填充，所以我有表的最后一个版本的备份副本，以防万一）。

    TRUNCATE TABLE shadow.Lookup;

INSERT shadow.Lookup([cols]) 
  SELECT [cols] FROM [source];

-- perhaps an explicit statistics update here

BEGIN TRANSACTION;

  ALTER SCHEMA fake TRANSFER     dbo.Lookup;
  ALTER SCHEMA dbo  TRANSFER  shadow.Lookup;

COMMIT TRANSACTION;

ALTER SCHEMA shadow TRANSFER fake.Lookup;

-- optionally truncate shadow.Lookup now

    两者之间并没有真正的优势，但是您应该阅读我的其他一些帖子以了解更多背景知识，我的一些推理，陷阱等。例如，外键在这里不太可能成为您的朋友-在我的场景中最适用于聚合的、非规范化的数据或用于只读工作负载的副本（因此不需要引用约束——不是我提倡这样做或任何东西）。

    • 1

相关问题