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

lovehewenyu

gytyl 发表于 2013-8-21 18:13
先给徽章，我再决定后面的要不要回答

呵呵，把我的汽车！赠送给大师了！

希望大师可以多多指导其他想学习的童鞋!

gytyl

lovehewenyu 发表于 2013-8-21 18:16
呵呵，把我的汽车！赠送给大师了！

希望大师可以多多指导其他想学习的童鞋!

没有吧，我没收到这个玩意么。
不和你们扯淡了，吃饭去
晚上还要继续收尾升级的事情，做容灾切换演练了。
bye-bye

lovehewenyu

gytyl 发表于 2013-8-21 18:19
没有吧，我没收到这个玩意么。
不和你们扯淡了，吃饭去
晚上还要继续收尾升级的事情，做容灾切换演练了 ...

呵呵 赠送给你了 一个小夏利徽章 ！

您继续忙吧！ 再次谢谢您热心的回答！

bluemoon0083

gytyl 发表于 2013-8-21 17:17
数据库停机时间是3.5小时
回退方案。准备了很多，在升级的每个阶段发生问题，回退都会不一样。

每个阶段都会建一个restore point吗保证可以快速回退？

bluemoon0083

gytyl 发表于 2013-8-21 17:26
如果升级后，库打开了，业务数据进来了，你准备怎么样回退？丢数据还是？

这里肯定不允许再回退了吧？我觉得升级后特别是业务数据进来，若出现问题，这时只能再马上处理，查找原因，个别优化了

这里我有个问题，升级后，开放业务前，此时如何保证性能没有问题？把之前测试过的spa里的所有sql做成一个大集合再跑一边看下有没有性能下降的？

gytyl

bluemoon0083 发表于 2013-8-21 20:34
这里肯定不允许再回退了吧？我觉得升级后特别是业务数据进来，若出现问题，这时只能再马上处理，查找原因 ...

这里是有策略的，可以直接对oracle做降级处理。降级到10g；
也可以硬顶，进行优化，但是如果出现大的bug，根本无法优化的时候，会选择降级。
另外，还要评估是降级要的时间长还是直接回退使用升级前的数据库，然后补数据的时间长。
决策的因素很多，所以在不同的阶段，会有不同的决策会，决策会也就是讨论按照原定的计划中的步骤进行回退是否通过，如果决策会的多数同意，则直接按照手册进行回退。
现场的决策会其实更类似通气会，无法进行临时的更改，也不允许进行临时的更改。

gytyl

bluemoon0083 发表于 2013-8-21 20:23
每个阶段都会建一个restore point吗保证可以快速回退？

当然不是，只是针对每个会阶段的现状，制定不同的回退策略
所有的回退分支在手册上都是有的，按照手册，召集决策会，然后执行，就好了。

bluemoon0083

drew 发表于 2013-8-21 17:31
不了解，你们业务应该没淘宝量大吧？

不能这么比较的吧，淘宝的业务模式又不能代表地球上所有的应用模式

gytyl

bluemoon0083 发表于 2013-8-21 20:39
不能这么比较的吧，淘宝的业务模式又不能代表地球上所有的应用模式

淘宝就是一切呀。当然是一切了，一切和淘宝不一样的都是技术不如淘宝呀。

bluemoon0083

gytyl 发表于 2013-8-21 20:38
当然不是，只是针对每个会阶段的现状，制定不同的回退策略
所有的回退分支在手册上都是有的，按照手册， ...

了解了，感谢回答

人多就是好，还能开决策会
有些操作也确实不是DBA一个人能够决定的

先期做plan，plan做好一旦都同意，go live的时候就不许随便更改，一定要按照plan一步一步来做，个人特别喜欢这种方式
以前给日本ORACLE on demand做事的时候就这样，虽然死板了点，但适应之后带来的好处是显而易见的