浙江移动升级（7套RAC升级，目前全国最大的升级案例）

gytyl

bluemoon0083 发表于 2013-8-21 20:58
了解了，感谢回答

人多就是好，还能开决策会

我们的割接，一般都是在晚上，晚上脑子不是很清楚，特别是在晚上还碰到突发情况的时候。
最好是前期做好所有的计划和分支，并且，所有的分支如何决策，如果继续走下去都要想好。
这才是做这个项目比较麻烦的一个地方，至于升级用了什么技术，那是整个项目中我最不担心的事情了。
这样的结论，是不是让很多小伙伴很失望？

luckyrandom

没必要想得像神一样，当然也不是简单的测试环境随便玩，数据量大，更严肃
更多的人（有一定功底的）都有能力去做升级，但可能永远没机会
环境和机会的资源短板会限制更多的人接触有一定层次的项目和经验积累
对于大项目，反而有足够的预算资源（备机）去模拟、测试、验证

last_day_1983

gytyl 发表于 2013-8-21 17:18
如果新库打开了，业务已经进来了。然后应用崩溃，必须回退，你说的方案就是废纸了。

我说的是升级的过程奔溃，根本还不到新库打开的阶段，新库还不能打开，当然可以用回原库。另外应用的崩溃，跟数据库完全是两码事，应该在应用层有回退方案，即使应用奔溃，新数据库还是可以用吧。

gytyl

last_day_1983 发表于 2013-8-21 21:49
我说的是升级的过程奔溃，根本还不到新库打开的阶段，新库还不能打开，当然可以用回原库。另外应用的崩溃 ...

应用开放，然后发现，应用因为使用了11g的客户端，直接崩溃；或者，这个时候发现数据库遭遇重大bug，根本无法通过性能优化保障应用能顺利进行等等的问题，你采用何种回退措施，都是要事先想好的了。这个项目难在前期的很多工作，不难在当晚的操作，当晚，不过是所有技术人员的一场技术秀而已。

last_day_1983

gytyl 发表于 2013-8-21 22:04
应用开放，然后发现，应用因为使用了11g的客户端，直接崩溃；或者，这个时候发现数据库遭遇重大bug，根本 ...

假如升级后都没问题，刚好跑了一个钟性能出问题，此时有部分业务数据入库，就按照你说的无法通过性能优化保障，只能回退，确实比较麻烦再直接用回原库，这是关键点啊，你这不是吊人胃口吗？透露点大概的回退策略方案嘛，这个方法论来的，不涉及机密

gytyl

last_day_1983 发表于 2013-8-21 22:13
假如升级后都没问题，刚好跑了一个钟性能出问题，此时有部分业务数据入库，就按照你说的无法通过性能优化 ...

这个结合现场业务的情况。
我要召开决策会评估，因为直接降级的时间是固定的，这个是参考值，然后参考应用提供的时间，如果应用能在原来的库上补回数据的时间更短，你说我会选择啥列。
原理很简单，方法论也很简单。但是你却没有办法直接套用，不是么？
至于开放了之后，这一个小时，会根据平时收集的信息，评估这一个小时的时间段是处于忙时，闲时还是一般来判断如果使用原来的数据库，修复这些数据需要的时间。
另外，也会在决策会召开前，在新库上收集业务数据信息，并和我们之前收集的评估数据对比是否准确。

last_day_1983

gytyl 发表于 2013-8-21 22:16
这个结合现场业务的情况。
我要召开决策会评估，因为直接降级的时间是固定的，这个是参考值，然后参考应 ...

复杂的业务环境回退确实应该具体问题具体分析。

gytyl

last_day_1983 发表于 2013-8-21 22:24
复杂的业务环境回退确实应该具体问题具体分析。

还是那句话，别看割接挺成功的，所有的功夫都在割接外。。。
其实这次升级我个人作为一个所谓的资深dba来讲，最大的收获就是，做好一件事情，不是用了什么牛逼的技术，而是你平衡了所有的因素以后用了最合适的方式来实现你的目的。

last_day_1983

gytyl 发表于 2013-8-21 22:31
还是那句话，别看割接挺成功的，所有的功夫都在割接外。。。
其实这次升级我个人作为一个所谓的资深dba来 ...

当然最最最关键的因素是有钱，有这么多钱砸进去才有充足的资源，否则你就是巧妇最难做的饭---无米之炊。

gytyl

last_day_1983 发表于 2013-8-21 22:39
当然最最最关键的因素是有钱，有这么多钱砸进去才有充足的资源，否则你就是巧妇最难做的饭---无米之炊。

其实你不觉得，如果，我是说如果，其实我们根本不需要升级的。