将多个数据库迁移并合并为一个

在更新项目中,我必须执行以下操作:

将3个数据库从SQL2000移动到SQL2005并同时合并它们.SP和视图中已经有很多交叉数据库查询.当前计划是将每个旧数据库移动到1个数据库中的单独模式中.

这意味着我们还必须更改当前的SP和视图,我们现在拥有:

SELECT OrderId, OrderDate FROM Sales.dbo.Orders

并期望我们必须改变它

SELECT OrderId, OrderDate FROM Sales.Orders

问题是:我们如何尽可能自动化？

我知道SED和类似的更改脚本.我会欢迎有关如何"聪明"的提示,例如分区脚本的策略,性能(大量INSERT INTO行)等.

注意:我确实查看了导入/导出向导,但显然我必须在每个输出表上手动设置Schema,并通过ALTER脚本修复SP.

几年前我这样做了,我遇到了一些你想要注意的问题.

假设:

你有一个SQL 2000数据库服务器,有3个数据库,A/B/C.

您希望所有对象最终都在数据库A中的SQL 2005中(我们将其称为目标)

你想最终摆脱数据库B和C(旧的来源)

您没有一个完整的测试环境,您可以每天自动恢复生产数据库,并一次又一次地编写脚本直到它是正确的.(这是最好的方式,我也采用了这种方法,但这是劳动密集型的.)

这是我的经验教训:

不要进行合并,SQL 2005会在同一天进行更改.要么在进入2005年之前,要么在之后进行合并,但是不要试图在一次中断中完成所有这些.这将是指责一团糟.如果是我,我会先到2005年才能让它脱离困境.这样,我知道任何中断的不是因为模式更改,而且这些类型的中断更容易修复.在宣布胜利并继续进行合并之前,您希望在2005年框中至少有一周的最终用户活动.

提前在Target中构建新对象.即使他们没有在您的实时制作应用程序中查询,也请立即构建他们.这样,您可以在其中填充假测试数据,以提前测试您的应用程序.是的,这意味着混合实时和测试数据,但坦率地说,你已经在那里没有网络工作了.但要注意身份字段,因为您最终可能会遇到具有相同标识号但目标和源数据库中的数据不同的冲突记录.

提前在Target中创建视图.您提到您已经拥有已经进行跨数据库查询的视图.现在将那些从Source复制到Target,并告诉任何其他开发人员(报告人员,高级用户)开始引用Target视图.这不会加快你自己的工作,但它加快了他们的工作.如果你能够确定他们只是在击中Target(即使目标视图仍指向Source中的表),那么它将在迁移日更容易进行故障排除.然后,您可以提前开始拒绝源视图的权限.

提前同步表格. 列出需要从源中移出的所有表,并为每个表分析如何更新它.如果仅将其插入(未更新或删除),如日志表,则编写T-SQL脚本以开始在Target中保持同步.在服务器上的低活动期间通过SQL代理作业运行该脚本,例如每晚.这样,当它处于上线状态时,您将不必推送尽可能多的记录,这意味着您的上线窗口将更小并且您的目标事务日志可以保持更小.不断更新或删除的表并不容易,您是否决定同步这些表也取决于您.我们为超过一百万行的任何表做过.

检查源数据库之间的记录冲突.听起来这个并不特别适用于你,但我在这里注意它以防其他人合并并且他们正在阅读它以获取提示.如果您有多个Source数据库,请转储对象列表.如果您有两个具有相同名称的对象,请检查其架构.我曾经在每个数据库中都有一个State或Region表的实例中工作,它们应该是相同的,但是它们的主键有标识字段.每个子表(如Customers,链接到Region表)通过主键(标识字段)引用父表(Region) - 从一个数据库到另一个数据库不匹配.在这种情况下,明智的做法是在迁移日之前提前停止窗口,以使用手动更新脚本清理这些记录.

禁用任何约束或外键关系

更改标识字段(如果它们是查找表,您可以关闭标识内容并只使用手动指定的PK编号运行)

修改Region表以添加NewID字段,与其将要匹配的内容相匹配,以及OldID字段,显示它曾经是什么

更新所有子表(Customers)以使用NewID号而不是原始号

更新Region表,以便真实ID字段现在具有NewID值,OldID字段具有Region曾经使用的值.(你可能会想起一些你不知道的儿童桌,你会想知道它曾经是什么.)

将迁移分解成碎片.列出所有数据库中的每个存储过程.如果可以移动其中任何一个而不移动数据,请先执行此操作.例如,如果您有Source.dbo.usp_RunReport,并且它仅引用Target数据库中的表,那么请在第一阶段执行此操作.如果您的小型系统查找表仅在您的应用程序内部使用,对客户或报告不可见,那么也将其置于第一阶段.这听起来太小了,不能打扰,但想法是减少迁移日的恐慌情绪.你想的越少,你就可以越好地排除故障.我们提前移动了每个静态查找表(状态,区域,日历等).第1阶段所需的工作量 - 只需移动那些小的静态表 - 让管理层了解移动其余部分的巨大程度,

预生成Target的数据文件.如果您没有使用SQL 2005的新即时文件初始化,则数据文件的增长需要相当长的时间.如果您有选择,则启用即时文件初始化,然后增大数据文件以确保它们不会碎片化.如果它们在您的迁移日期间自然生长,它们可能会分散.如果您无法使用即时文件初始化,则仍需要预先生成文件,但是您希望在低活动期间提前执行此操作以加快维护时段.

在迁移日,一次运行一个表或更小的表. 您希望尽可能地保持插入事务的紧密性.插入事务越小,事务日志中所需的空间就越小.请记住,即使在简单模式下,事务日志也会随插入语句一起增长.在每轮插入之后,进行完整性检查以确保它们正常工作,并且您不会用尽数据文件或t-log文件的驱动器空间.

更新完成后,更改源数据库的安全性.将每个非SA登录名放入源数据库中的dbdenydatareader和dbdenydatawriter角色.这样,如果他们在连接字符串中对数据库名称进行了硬编码,他们仍然可以登录,但他们将无法做任何事情.这也使你的故障排除更容易:如果一个应用程序或查询遇到问题,你可以考虑从拒绝角色中取出他们的登录,看看它是否有效 - 如果有的话,它就会被剔除.这样做的风险在于,它们可能运行使用源数据库数据更新目标数据库的事务(从Source获取客户,在Target中更新它们),这可能会导致问题.

Source数据库的其他选项是:

重命名它们,这样您仍然可以查询它们,但应用程序不会触及它们

分离它们,但保留文件可用,以防您需要进行故障排除

删除所有登录,并使用新登录来访问现有数据库以防万一.然后,如果某人的只读报告完全被禁止,您可以通过向他们发布新登录并告诉他们指的是错误的数据库来暂时让它工作.

更新完成后,重建Target上的索引和统计信息.如果您只是进行连续插入,这不是什么大问题,但如果您要合并多个数据库(例如两个已分解到该国家/地区的销售数据库),那么您将需要清理.

恕我直言,除非你可以证明从多个模式中获益,否则使用一个模式.最后一个只是我的两分钱,但听起来你要经历大量的工作,从每个3个数据库1个模式到1个具有3个模式的数据库.如果你不确定3架构的东西,你可能会考虑使用1架构 - 否则你将在以后的另一个混乱的返工.如果您有特定的安全需求,3个模式确实有意义,但除此之外,请确保您获得所需的优惠.现在是进入一个架构的好时机.