然而 ， 好景不长 ， 在2011年收藏夹上线之后 ， 整个2012年OceanBase都没有找到第二个价值如此显著的业务 。 阳振坤直言“2012年真有点做不下去了 。 ”
因此 ， 2012年的唯一目标就是 ， 活下来 。
顶着团队随时可能解散的压力 ， 阳振坤找到时任阿里巴巴首席架构师的王坚 ， 吐露难处 。 而后经王坚推荐 ， 在2012年11月15日 ， OceanBase团队从淘宝调到支付宝 。 因为支付宝业务是跟钱打交道 ， 对数据的一致性要求更高 ， 所以希望在支付宝业务找到机会 。 阳振坤知道“如果在支付宝再找不到机会 ， 就完蛋了 。 ” 在“人生地不熟”的新团队 ， 他们一边熟悉人 ， 一边摸索生的机会 。
幸运的是 ， OceanBase团队遇到了一位开明的领导人 ， 时任支付宝技术负责人的程立（花名鲁肃 ， 现任阿里集团CTO） ， 他对新技术持鼓励、支持的态度 。 恰逢七、八月份的时候 ， 支付宝开始讨论怎样“去O” ， 即替换Oracle数据库（早在2009年 ， 阿里巴巴就提出了“去O”） 。 但面临的极大难点在于 ， 如果不用Oracle数据库 ， 不用共享存储 ， 选择类似MySQL这样单机数据库 ， 数据丢了怎么办？在金融领域 ， 这是无法接受的后果 。 而继续使用Oracle数据库 ， 对于业务数据量、数据并发量都巨大的阿里业务 ， 所要付出的软、硬件成本是无法估量的高昂 。
阳振坤胸有成竹地说“我们有办法解决这个事” 。 这个办法就是如今被广泛应用的三副本 ， 每一笔事务在3个节点或者5个节点上同时做 ， 超过半数成功即认为成功 。 举个例子 ， 三台机器中坏掉一台机器 ， 剩下两台机器至少有一台机器的数据是正确的 ， 以此方法解决替换Oracle的核心问题 ， 即放弃共享存储之后数据损坏、丢失的问题 。
OceanBase 0.5版本由此诞生 ， 也为OceanBase开辟了一条生路 。
但阳振坤明白 ， 这只是给了OceanBase一个证明自己的机会 。 从提出解决方案 ， 到0.5版本正式发布 ， 用了7个月左右的时间 。 另一边 ， 业务团队却很难一下子接受OceanBase数据库 。 首先 ， 这个版本没有经过其它业务的验证就应用到核心业务 ， 是否可行？让OceanBase数据库支撑支付宝的交易库 ， 处理交易流水数据 ， 业务团队很难放心 。 其次 ， OceanBase技术方案要求三个机房 ， 需要在原有的主、备机房的基础上 ， 再增加一个机房 ， 而当时除了杭州 ， 阿里和支付宝在其他城市都没有三个或以上的机房 。
为此 ， 双方几次三番激烈地争论 。 对于OceanBase数据库来讲 ， 这是一个生死之战 ， 如果不抓住这次落地机会 ， 不仅是错过支付宝“去O”的历史性机会这么简单 ， 而是OceanBase数据库再也没有机会了 。 所以OceanBase团队当然是极力争取 ， 另一边 ， 业务团队也保持非常谨慎的态度 ， 双方僵持不下 。
最后还是鲁肃出面说服业务团队 ， 便有了OceanBase数据库分流1%的机会 ， 如果出问题 ， 1%的流量会被随时切走 。 回想此事 ， 阳振坤的态度是“我们的运气不错” 。 2014年“双11”前 ， 大抵是9月底或10月初 ， 业务团队开始为“双11”的支撑做压测 ， 由于流量非常大 ， 已经超出Oracle数据库的预定容量 ， 超出系统的I/O能力 ， 系统大量报错 。
由于时间紧张 ， 临时买设备 ， 手提肩扛服务器再次扩容已经来不及 。 业务团队想起压测时支撑1%流量的OceanBase数据库 ， 找到阳振坤说“给你们10%的流量能不能撑得住？”OceanBase团队当然高兴了：“别说10% ， 就是100%都可以支撑得下来” 。 甚至在“双11”当晚的作战室 ， 面对时任蚂蚁金服CEO彭蕾（现任蚂蚁集团董事长）的担忧 ， 阳振坤说出了不成功就跳窗的玩笑话 。