m******y
发帖数: 588 | 1 我们其中一个production database server 的SAN 不够用了，又买了个新的，要把上
面大概600 GB的sql server databases移到新的SAN上，. 这个production db server
是一个active/passive cluster, 因为要minimal downtime，所以不能停了sql server
copy，现在想了两个方案，但是还都没试过，想问问这里有人干过这个吗？有什么好
建议。 |
B*****g
发帖数: 34098 | 2 I do not know the answer, but I guess it will be better to give your sql
server version
server
server
【在 m******y 的大作中提到】
: 我们其中一个production database server 的SAN 不够用了，又买了个新的，要把上
: 面大概600 GB的sql server databases移到新的SAN上，. 这个production db server
: 是一个active/passive cluster, 因为要minimal downtime，所以不能停了sql server
: copy，现在想了两个方案，但是还都没试过，想问问这里有人干过这个吗？有什么好
: 建议。
|
m******y
发帖数: 588 | |
i****a
发帖数: 36252 | 4 there should be a clone option at storage level.
detach disks, clone, attach new disks
server
server
【在 m******y 的大作中提到】
: 我们其中一个production database server 的SAN 不够用了，又买了个新的，要把上
: 面大概600 GB的sql server databases移到新的SAN上，. 这个production db server
: 是一个active/passive cluster, 因为要minimal downtime，所以不能停了sql server
: copy，现在想了两个方案，但是还都没试过，想问问这里有人干过这个吗？有什么好
: 建议。
|
g***l
发帖数: 18555 | 5 COPY过去，DETTACH ATTACH是比较保险的。如果出问题还可以SWITCH BACK。如果能
LIVE接上新SAN的话，调试好CLUSTER，就是DETACH-COPY-ATTACH的时间，不过要注意你
的MASTER, MSDB ,TEMPDB在什么盘上，如果旧SAN还保留的话就是个PRODUCTION DB，应
该很容易。如果旧SAN要关掉，你的MASTER TEMDB MSDB MODEL都要移走，就很麻烦了。
SAN的CLONE也可以，我觉得风险很高，但愿PROGRAM没装在SAN上，要CLONE的话，要随时
准备不WORK，SWITCH BACK，而且在线CLONE的话，会损失数据，离线CLONE，又有DOWNTIME，
其实不如连SERVER也换了得了，另起炉灶，调试好了，搞个RENAME SERVER得了。而且现在
都是64BIT的操作系统，不如升级全做了，WINDOWS 2008+SQL SERVER 2008，一次到位，
用个BACKUP测试好了全换掉，老系统就当DEV好了。单换个STORAGE，风险高，就是硬盘大点，
新SAN可能IO PERFORMANCE好一点，挺不划算的。 |
g***l
发帖数: 18555 | 6 问，600GB都是什么数据啊，你们不做ARCHIVE?如果就几年3RD NORMALIZED的不会那么
大吧。 |
j*****n
发帖数: 1781 | 7 600GB is just so so... you can ask how big Beijing's DB is.
【在 g***l 的大作中提到】
: 问，600GB都是什么数据啊，你们不做ARCHIVE?如果就几年3RD NORMALIZED的不会那么
: 大吧。
|
B*****g
发帖数: 34098 | 8 I guess our production DB is in similar size(not DBA, cannot check). But we
only store 6 months data in prod, 6+ months data will be moved to Archive
database. And DBA can bring down DB for 1 day if necessary, not too critical.
【在 j*****n 的大作中提到】
: 600GB is just so so... you can ask how big Beijing's DB is.
|
m******y
发帖数: 588 | 9 我们保存一年的数据。每天晚上做purging. 我们测试了一下copy,需要4小时左右，因
为这是一个payment system的一部分，没法down4个小时。所以还是不能detach/attach
copy.
可能只能break up cluster, 用原来的passive node attach 新的san,然后log
shipping data 到新的san, 然后再把那个passive node弄成新的cluster的active
node, switch over. 最后把原来的active node加进来。这样dns和ip肯能都不太好
handle. 还有就是再build一个temp cluster，也用log shipping data, 做temp prod.
然后现在的prod attach新的san, 然后再move回去。都不是很容易。:( |
z***y
发帖数: 7151 | 10 你说的情况有代表性。
我给一个Financial 客户做了一个近似的方案几年前。
先做一个全局备份， 然后需要另外一台和这台差不多性能的， 连在SAN上。 把备份
restore 在新
的san上。
两台做transactional replication.
最后在旧的server 上做最后的tail backup， 然后把新的server做为新的prod。
600GB, 差不多200分钟备份， 200分钟restore, 然后看Xsac 多少， 差不多再来50分
钟SYNC,
这中间没有downtime.
mirroring 也可以。
server
server
【在 m******y 的大作中提到】
: 我们其中一个production database server 的SAN 不够用了，又买了个新的，要把上
: 面大概600 GB的sql server databases移到新的SAN上，. 这个production db server
: 是一个active/passive cluster, 因为要minimal downtime，所以不能停了sql server
: copy，现在想了两个方案，但是还都没试过，想问问这里有人干过这个吗？有什么好
: 建议。
|
|
|
m******y
发帖数: 588 | 11 咱们小公司还真没有新的和目前这两个dbserver差不多的server可以来用。唉。目前我
们就有transaction replication,但是在另外一个data center。我可以set up 一个另
外的subscription来代替log shipping, 但主要replication的时间有时比较难掌握，
mostly under 5 seconds, 但有时候sync慢，而且我们需要在特定时间完成，比较好控
制所以我想用log shipping.最后就少于15分钟的log backup,然后move, apply一下就
可以了。加上renaming cluster, downtime应该还比较reasonable.不过还没test,以后
来报告把。
【在 z***y 的大作中提到】
: 你说的情况有代表性。
: 我给一个Financial 客户做了一个近似的方案几年前。
: 先做一个全局备份， 然后需要另外一台和这台差不多性能的， 连在SAN上。 把备份
: restore 在新
: 的san上。
: 两台做transactional replication.
: 最后在旧的server 上做最后的tail backup， 然后把新的server做为新的prod。
: 600GB, 差不多200分钟备份， 200分钟restore, 然后看Xsac 多少， 差不多再来50分
: 钟SYNC,
: 这中间没有downtime.
|
v*****r
发帖数: 1119 | 12 Not a sqlserver person， 但我想这种migration 不管是sqlserver 还是 Oracle, 步
骤大概是一样的。
用 Oracle 的话，如果没有 budget for two new servers, zero downtime 是不可能
的了，能 minimize 到一，两分钟的 downtime就不错了， 最好是在 SAN level 用
vendor provided tool to do online LUNs copy between old LUNs and new LUNs，
then at cutover time, shutdown database, do a final sync-split on SAN，mount
database, use scripts to rename all files to new location (whether it is
filesystem or Oracle ASM), open database. It is done.
不管是用 Oracle RAC 还是 single node Oracle server， 以上步骤都一样，
downtime 也一样.
如果是 SQLServer 的话，我想 downtime for Single node SQLServer 和 SQLServer
on MS Cluster 很可能会不一样 due to MS Cluster's "Share Everything" nature.
Plus it is easy to use shell scripts to automate some steps for Oracle, I
guess you will have to do lots of point/clicks for SQLServer Cluster while
doing the steps such as takedown/bringup MS Cluster resources. So I guess it
will be a good job if you can achieve 10 minutes downtime on Clusted
SQLServer.
欢迎 SQLServer 大牛拍砖
【在 m******y 的大作中提到】
: 咱们小公司还真没有新的和目前这两个dbserver差不多的server可以来用。唉。目前我
: 们就有transaction replication,但是在另外一个data center。我可以set up 一个另
: 外的subscription来代替log shipping, 但主要replication的时间有时比较难掌握，
: mostly under 5 seconds, 但有时候sync慢，而且我们需要在特定时间完成，比较好控
: 制所以我想用log shipping.最后就少于15分钟的log backup,然后move, apply一下就
: 可以了。加上renaming cluster, downtime应该还比较reasonable.不过还没test,以后
: 来报告把。
|
S***Z
发帖数: 1029 | 13
attach
prod.
什么Copy 600G要4小时？旧SAN和新SAN同样牌子吗？如果是，用Vendor的LUN Copy工具
最好。
【在 m******y 的大作中提到】
: 咱们小公司还真没有新的和目前这两个dbserver差不多的server可以来用。唉。目前我
: 们就有transaction replication,但是在另外一个data center。我可以set up 一个另
: 外的subscription来代替log shipping, 但主要replication的时间有时比较难掌握，
: mostly under 5 seconds, 但有时候sync慢，而且我们需要在特定时间完成，比较好控
: 制所以我想用log shipping.最后就少于15分钟的log backup,然后move, apply一下就
: 可以了。加上renaming cluster, downtime应该还比较reasonable.不过还没test,以后
: 来报告把。
|
s**********3
发帖数: 102 | 14 That's very easy, you can use 3rd party software to do it. We use redgate to
do this. Use redgate to backup and restore to the new san box. When it
complete, update the tables etc... Change the connection string with the new
db.
You can download redgate for 30 days trial. It is full version and working
great. |
m******y
发帖数: 588 | 15 不是同一牌子，原来是dell md300i, 现在用HP P4500 G2. 应该好了不少。
【在 S***Z 的大作中提到】
:
: attach
: prod.
: 什么Copy 600G要4小时？旧SAN和新SAN同样牌子吗？如果是，用Vendor的LUN Copy工具
: 最好。
|
v*****r
发帖数: 1119 | 16 Just found out that actually it is much easier than I thought to achieve
zero downtime for Oracle (single node or RAC) on moving to new SAN storage (
no matter same vendor or not) by using Oracle ASM.
Using Oracle ASM, the migration is as easy as first add new LUNs to ASM,
then drop old LUNs and it is done (some extra small steps to move OCR and
voting disk if it is RAC). ASM will take care of moving data from old LUNs
to new LUNs and re-striping in the background. The cool thing is Oracle
database remains online during the whole migration process. So with ASM,
there is no need to do SAN level mirror/sync or Oracle level backup/restore
etc for this type of migration.
【在 m******y 的大作中提到】
: 不是同一牌子，原来是dell md300i, 现在用HP P4500 G2. 应该好了不少。
|
B*****g
发帖数: 34098 | 17 要不说oracle向傻瓜机发展。
(
restore
【在 v*****r 的大作中提到】
: Just found out that actually it is much easier than I thought to achieve
: zero downtime for Oracle (single node or RAC) on moving to new SAN storage (
: no matter same vendor or not) by using Oracle ASM.
: Using Oracle ASM, the migration is as easy as first add new LUNs to ASM,
: then drop old LUNs and it is done (some extra small steps to move OCR and
: voting disk if it is RAC). ASM will take care of moving data from old LUNs
: to new LUNs and re-striping in the background. The cool thing is Oracle
: database remains online during the whole migration process. So with ASM,
: there is no need to do SAN level mirror/sync or Oracle level backup/restore
: etc for this type of migration.
|
v*****r
发帖数: 1119 | 18 嗯， dba 也是越做越傻呀，有同感
【在 B*****g 的大作中提到】
: 要不说oracle向傻瓜机发展。
:
: (
: restore
|
B*****g
发帖数: 34098 | 19 developer也一样，昨天参加一个webinar，knime一个家伙说，不会写程序的也可以用
。drag几下，report，data mining啥的都出来了。
【在 v*****r 的大作中提到】
: 嗯， dba 也是越做越傻呀，有同感
|
g***l
发帖数: 18555 | 20 设计DATAWAREHOUE还是很动脑子的，对数据关系要特别清楚，傻瓜的前提是有人给你设
计好了，设计不好，就有搞不完的麻烦。 |
j*******7
发帖数: 6300 | 21 Here today our tech guy seems directly extend one of our production drive
by adding 500GB without we DBA to stop sql server or to copy database and
do not need to reboot the machine. I guess modern SAN technology perhaps
can already resolve your problem quite easily.
server
server
【在 m******y 的大作中提到】
: 我们其中一个production database server 的SAN 不够用了，又买了个新的，要把上
: 面大概600 GB的sql server databases移到新的SAN上，. 这个production db server
: 是一个active/passive cluster, 因为要minimal downtime，所以不能停了sql server
: copy，现在想了两个方案，但是还都没试过，想问问这里有人干过这个吗？有什么好
: 建议。
|
m******y
发帖数: 588 | 22 adding disks is easy. Completely changing a SAN is another story.
【在 j*******7 的大作中提到】
: Here today our tech guy seems directly extend one of our production drive
: by adding 500GB without we DBA to stop sql server or to copy database and
: do not need to reboot the machine. I guess modern SAN technology perhaps
: can already resolve your problem quite easily.
:
: server
: server
|
