今天在公司被问到DB Migration是否会影响到要不要将　CLP 挂　Maintenance Page 一事，这问题还真是难倒我了。

　　站在QA 立场，对于DB Migration会有不知道会不会Lock DB Table的不确定性，我们考量到如果IAM在做 Account DB Migration 的时候，虽然是做塞资料到新Table而已，但因为会Select 资料从旧Table，所以担心此时CLP有User来注册新产品跟帐号时，会因为DB Lock而失败，但又无法确定这可能性多高，所以为确保安全，CLP会被上Maintenance Page。

　　不过问题来了，CLP有很多的User，一旦上Maintenance Page势必冲击客户的使用经验。更何况这变成之后的还有两到三次的DB Migration都要挂Maintenance ，这中间要跟很多Partner和Stack Holder 沟通，其成本之巨大，难以想像。

　　所以我去找了我们最专业的DBA　Ju姐问说有没有办法评估说DB Lock＂会或不会＂在做DB Migration时发生？

　　于是我得到两个评估这个问题宝贵知识：

1. DB Lock 一般会发生在DB Migration Script需要做大量Delete与Update资料时，因为这两个动作会必需锁住Table 的部份page，如此就有可能造成DB Lock，但如果Script都是在做Insert新资料甚至是Insert into new table，那应该不会有DB Lock 风险。
2. 担心做DB Migration时某些使用者行为可能因为DB Lock造成影响，那就只要在非Production环境做DB Migration时进行这些Behavior的测试看会不会发生问题即可，这也是证明问题存不存在的一种方式。

而在秉持第一项知识做DB Lock评估时，应该考虑到所有欲评估之使用者行为背后所有相关的DB Table，并把这些Table与DB Migration的Script放在一起由DBA帮忙评估，这样就比较能知道DB到底会不会因为做Migration时Lock某些Table而造成使用者受到影响了。

　　真是长知识了！确实在评估产品该不该因为DB Migration而暂停Maintain时更应该审慎评估，尤其产品是很多客户在使用时，这时候就必需要精准且科学的提供评估方式与测试方法来证明DB Migration的影响程度为何，既而下判断，真是不经一事，不长一智呀！

 

2018年6月29日星期五