升级到国际化的数据库之升级表至unicode(一)

建立支持国际化的数据库成为每个跨国公司及拓展海外业务的公司来说很有意义。

而如何将现在的数据库升级到国际化的数据库成为了一件很实际的问题。

下面我们来谈谈如何对SQLSERVER2005下表的升级。

（有关升级到unicode，对目前DB的影响，请见我的另一篇文章：升级到unicode产生的影响面）

不同DB的分析：
1. 存在分区表或分区索引 （公司这样的情况是否存在，这次是否需要研究这方面的升级？）
    分区列所在的表将不进行升级。因升级后的列与原来的分区架构（分区函数）中的分区列的类型不同，从而不能再重立起原有的分区表或分区索引。
    若也要升级分区列所在的表，则：（据需要会进一步研究）
分区函数中的分区列，需升级至unicode，但这样那些未升级至unicode的分区列所在的表，将无法使用原分区架构与分区函数。所以：

      a.升级所有分区列所在的表，同时升级对应的分区架构与分区函数。
      b.升级部分分区列所在的表，为了不影响未升级的分区表或分区索引所在的表，

        则不删除仍在使用中的原分区架构与分区函数，而另外再建立新的分区架构与分区函数（分区列改为unicode类型）
2. 无复制分发的情况
直接升级表（除了分区列（分区表及分区索引）所在的表不能升级）
3. 存在复制分发的情况
  (1) 若在不去除复制分发的情况下，用于复制分发的表及与这些表有关联的表（如外健引用）都将不会被升级。
  (2)若要对用于复制分发的表，也进行升级，则必须先删除掉复制分发后再升级
   a.生成原复制分发项目的脚本
   b.删除复制分发项目
   c.升级表(至unicode)
   d.重建复制分发（用生成的脚本重新生成原复制分发项目，更改密码及重新生成snapshot即可）

      生成的原复制分发项目的脚本与列的类型无关，即只与表及分发哪些列的名称有关，所以在修改列的类型 后，仍可用生成的原复制分发项目的脚本（含分布与订阅），重建复制分发。

 

可以升级的表的处理方案大体有两种方案：
方案1：外键不及时建立 ----适用停机升级 
      （缺点是与复制分发及分区列上的与升级后的表上引用即外健会无法建立，
        但这会记录下来，以便手工处理，以后会进一步完善）
WHILE依次传入每个要升级的表-----外层
        具体处理一个表 -----内层，作为一个事务执行
        1． 记录下每个要升级列上的所有对象
          （PK,UQ，INDEX,DEFAULT,CHECK,外健及被引用表上的外健）
        2． 删除一个表上与升级列有关的所有对象，及引用表上的外健
        3． 更新一个表的所有列至unicode
        4． 重新建立本表上与升级列有关的所有对象，除了外健（引用和被引用）。

            因本表列升级后，与之关联的表没有升级对应的列，此时无法再建立起本表上的外健，

         及引用表上的外健（引用和被引用）
       5． 若事务执行失败，则回滚，同时将表名，更改列的SQL，删除对象的SQL，

             重新生成所有对象的SQL，及外健都记录表执行失败的表中，以供分析。
所有表升级后，统一建立每个表上的外键。-----外层
若无法建立，则将建立外健的SQL记录到‘外健建立失败的表中’，以供分析与处理-----外层
（此时主，外表都升级了，所以外健可以建立上）当然也存在引用表上的外健无法建立的情况（即从表升级了，但主表未升级，这会记录下来）。

方案2：外键及时建立，这样外健约束会及时生效  ---适用联机升级（不推）
            递归处理与本表相关联的表，要是关联的表太多，开销会很大。