每每谈到Oracle MAA，大家条件反射般就会想到Oracle的RAC和ADG等核心选件，当然，这些技术有口皆碑，也的确是MAA的构建基础，但本文我们不再过多谈这些耳熟能详的技术，而是来跟大家探讨下在此基础之上，我们如何将基础MAA优化到业务连续性MAA这个程度，最终实现应用程序的连续可用性。
在本次OCW大会上，下面几位大咖就在演讲中探讨了这个话题：
现在就让我们跟着专家的思路，一起来看下该如何使用Oracle MAA实现应用程序的连续可用性：
1.为什么建议选择透明的应用程序连续性
我们先看下Oracle最大可用性体系架构的概览：
架构里面红框标注的AC部分，也随着版本演进有了TAC，但其实两种方式并不是替代关系，而是有各自的适用场景：
针对文章开头提到的基础MAA和业务连续性MAA，基础MAA可以提供数据库级别的最大可用性，而业务连续性MAA则是在基础MAA之上，面向业务和最终用户所演进出的增强版MAA：
在Oracle自治数据库中，TAC就是默认配置的，提高了自治数据库的业务连续性：
2.确保业务连续性的高可用性要求
配置业务连续性时，需要指定数据库服务，这里需要特别注意我们要使用用户定义的数据库服务，而不要使用默认的服务。
笔者之前就遇到过有客户因为使用了默认服务而导致部分场景异常的问题，最终修正为用户自定义的服务之后，一切回归正常。
确认使用正确的服务之后，继续来看下应用连接串的连接最佳实践参考：
然后我们需要了解下FAN和排空的基础概念：
下面这张图非常关键，非常清晰的说明了AC/TAC的整个处理过程逻辑：
在第一个箭头指向的时间点，节点1首先进行排空操作，也就是继续处理节点1上未完成的事物，不再接受新的连接，此时新的连接都会连接节点2，当到达设置排空的超时时间窗口后，节点1上还未完成的事物将会被强制中断，然后到节点2上重放这些未完成的事物，整个过程，对应用程序或用户而言，是感知不到错误信息的。
3.如何有效使用TAC应对计划内维护和计划外停机
现实客户场景中，针对停机有两种情况：一是计划内的维护，会提前申请停机窗口；二是计划外的停机，因为各类软硬件故障导致突发的停机。有效使用TAC可以应对这两种情况：
此外，需要注意存在一些例外情况，无法启用回放功能：
4.当透明应用程序连续性不适合时该怎么办
前面提到，AC/TAC两种方式并不是替代关系，而是有各自的适用场景，当TAC不适合时，可以考虑AC是否能够满足你的需求，下面是两种方式的简单对比：
如果上面的对比表格还不够清晰，那么下面的指引会让你更容易的选择究竟是AC还是TAC更适合你的场景。
此外，针对使用套装应用软件的用户，也不用太过于着急，因为很多主流的套装软件都开始支持或部分支持AC/TAC，且不支持的部分也基本都在积极的开发过程中：
5.客户案例分享
最后，我们跟大家分享一例来自真实客户的实践，该客户使用Oracle 19c 透明应用连续性功能，通过简化应用程序工程师的弹性设计，提高了整个公司的应用程序弹性：
客户在整个实践过程中还总结了一些经验供大家参考：
客户的直观感受，在遵循了所有指导并满足要求后，发现TAC真是一项惊人的功能，给用户也带来了惊奇的感觉！如果屏幕前的你也想进一步为你的企业提升业务连续性，却还没有体验过AC/TAC功能的话，就赶快在自己的环境实际去测试感受下吧。
说明：本文是笔者在甲骨文云技术公众号发布的文章。
图片来源是依据OCW演讲者的英文PPT翻成中文的，另外图片中所有的字体，按要求，都是 先刷Noto sans SC regular、再刷Oracle Sans的方式统一调整优化过。