SharePoint 如何分拆你的content db

一个客户要在48小时内(周六, 周日)分拆他唯一的Content DB.

几十个site collection.

几百G数据.

希望分拆后每个site collection有单独的content db.

最大的site collection 大概100G+.

分拆后, 用alternative access mapping, 把url 映射到新的web app中. 对于end users透明.

问我怎么办. 艹, 开玩笑... 没办法.

 

最开始GURU建议, 用DocAve按站点迁移数据.

48小时后(肯定跑不完). 用户开始工作. 源端数据开始变化.

所以第一次job 结束后, 再追加一次INCREMENTAL.

 

艹, 开玩笑, 660G的数据, 弄好了2星期都跑不完. INCREMENTAL Restore... 开玩笑.

 

基本思路是, 1. 化整为零, 必须要一个site collection, 一个site collection做. 2. 拒绝INCREMENTAL, 这个概念听着很美, 结果在细节上会有小问题. 3. 解决掉site collection 级别url映射的问题.

问题看上去很简单, 头疼得问题在于.

1. 超过48 小时, 就得做INCREMENTAL. 所以要一个site collection 一个site collection 的做. 在第一个48小时内, 完成一批. 在剩下的48小时完成另一批.

2. 要映射url, 48小时候, 成功的site collection要立即被映射回原来的url, 这样end users立即在新站点中编辑数据.

3. 没有site collection 级别的url 映射. 要么全在源端, 要么全在目的端. 不能做好一个site collection 映射一个.

4. 48 小时完成不了全部的. 哈哈, 问题又走回来了...

 

自己的环境里瞎点了一天, 终于一步一步的完善出了一个solution. 应该可以更完善...

1. 备份客户的DB. 把文件备份出来.

2. 找第二大site collection. 进行迁移, 迁移到一个temp web application.

3. 把原来的site colletion 删除了.

　　如果想保护数据的话, 可以先detach db. attach content db. reatach 最开始的content db.

　　这是一个关于orpaned db 的一个小把戏. 如果两个db 有相同url site collection. 后一个会被隐藏掉. 成为orphaned site collection.

　　来回detach reattach, 可以交换orphaned site colletion.

4. attach 新的db回到源端的web app.

5. 继续找原来db 中第二大的site colletion. 做1-4.

6. 最大那个, 可以不管...

 

这里有几篇参考blog,

1. 如何删除content db里, 被删除的site colletion data.

// 好像msdn 里就有, 地址弄没了, 注意stsadm -o deletesite中, guradulxxxxx 参数... 具体参数名称记不住了...

2. 关于orphaned site collection.

http://www.spfoxhole.com/blog/Lists/Posts/Post.aspx?ID=7

http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/b2a73ec1-28f9-4fdd-8719-34802bdceffc/  //reatach 有风险...

http://www.sharepoint.bg/radi/post/Recreating-the-SiteMap-in-your-configuration-database.aspx  //这个是大牛, 专门做DR的. 虽然讲的我没用上, 但是很喜欢这篇文章.

cheers,

转载于:https://www.cnblogs.com/tigerblue/archive/2011/12/05/howtosplitsharepointcontentdb.html