一个公司的核心交易数据库是一个公司业务的生命线，都是需要最高保障级别的维护，有的公司甚至是要24小时有人值守。经历过几个公司不同的核心交易数据库，都是oracle，因为历史原因，虽然都多多少少有一些坑，但是其中一个，却是我维护过的最坑的一个，而且多数都是主动的人工制障，没有因为妥协等其他原因。
先说一下大概情况，oracle 11.2.0.4，生产环境在北京，灾备环境在上海，两边是对等的双节点rac，用dataguard来做数据同步，放在符合金融级别安全的数据中心里。
第一个坑，权限认证
因为是金融行业的系统，所以在权限认证上非常的严格，采用了kerberos的方式认证。
账号分为应用系统账号和个人账号，应用系统账号登录通常是用密码，而个人账号比较复杂。公司每个拥有权限的it员工，比如dba、sa、应用维护人员、开发人员，都可以登录到数据库，只不过认证的方式不同。dba和sa可以直接登录数据库服务器，然后通过操作系统认证来进入oracle。但是应用维护和开发人员是没有权限的。只能通过登录自己的sso账号到指定的客户端，然后登录到映射后的数据库账号中。
乍一看似乎没什么问题。但是要考虑到，这是一家跨国金融企业，各种权限相关的kdc服务器都在国外，并且中国员工没有管理权限。每当一个新员工入职的时候，所有的权限必须自己去申请，然后由几千公里外素未谋面的同事来确定，这个人是否需要某某权限。更糟糕的是，有时候涉及到的系统不止一个，负责申请sso账号的、负责申请sso与linux账号关联的、负责申请数据库账号的、负责申请数据库权限的、负责申请数据库账号映射的、负责申请账号所能登录服务器的、负责申请申请数据库登录的，哪个忘了申请，对不起登不进去。
于是隔三差五就有同事跑来找我，怎么这里登不了了，怎么那个账号不能用。问题是这些申请系统都不在我手里，我也只是其中一个用户而已，我能做的只有一件事，拉着国外同事开个会，把需要申请的东西和流程让他们给本地同事解释清楚，然后有问题再帮他们反馈。
而在公司一台服务器服役年限是有严格限制的，年底强制下线的服务器，年初老外就要隔三差五催促迁移。每次迁移之后的第二个周，必然会出现稀奇古怪的权限认证错误问题。然后我们拉人开会，开完会异口同声：原来还有这么个流程要提啊。各种流程之间没有统一的部门管理，完全开盲盒。
第二个坑，特别服务
跨国金融企业，不差钱，于是在十几年前开发了很多特别定制的东西。有些东西确实是好，dba们的个人账号可以通过账号管理工具实现在不同服务器之间自动创建，也有一些东西真的匪夷所思。其中最特别的是，有个中央数据库，就是管理数据库的数据库，保存着很多数据库的定制信息和统一任务。每隔一段时间自动执行。
有一次，一个新业务上线，开了一个dblink到核心交易库，上线的周末测完，各种功能都没问题。谁知道周一工作时间，突然之间dblink不通了。应用负责人跑来找我，问我是不是对dblink做了什么操作，导致了无法正常登录。我给他看了这一周的登录记录，过去几天我没有登录过该数据库，仅仅是从oem进入查看过状态，而且也没有其他国家的dba有过登录记录。这件事情很匪夷所思，于是紧急拉个会，叫上国外数据库团队的同事去咨询。
开了会才知道，这个库的安全级别设置的最高，所以特别定制了安全策略。大概意思是，如果超过多少小时没有从其他库连接进入，就会判定为该dblink不再使用从而自动重置一个随机密码。而我在的公司，周末系统维护人员会选择把不用应用停机，到周一交易时间开始之前启动。周一恰好过了这个时间阈值，导致dblink已经无法使用
后来我们决定，改用ogg的方式来做数据同步，这样总没问题了吧？对不起，ogg也是特别待遇。配置一个ogg数据同步，需要通过中央数据库去自动认证，比如源端和目标端数据库是否是同一个业务线、是否是同一个机房，如果不符合就会提示你请去提一个申请单说明，然后由中央数据库的dba去创建。而我本人的账号因为只能登录中国区的数据库因此在申请ogg的时候没有办法直接去认证，自动认证这一步就走不下去了。只能去提交申请单。整个流程折腾了半个月，终于决定，还是用回dblink，配置了一个脚本，每隔一段时间自己跑一次，让中央数据库以为，这个dblink一直在用。
第三个坑，全球统一
这个坑要从oracle10g升级到11g开始，dataguard特性得到了强化说起。有了active dataguard，能做到读写分离，对于很多报表提升了效率。这是一个需要付钱的特性。
对于核心交易系统莱说，把不必要的资源消耗降到最低以获得交易性能是一个极其重要的指标。所以在我们升级到11.2.0.4时，就决定要在备库开启readonly模式，一些报表都从备库出。然而就在上线之前，收到了全球数据库团队老大的一封邮件，告诉我们公司虽然购买的是unlimited使用权，但是没有对active dataguard额外付费。所以这个特性我们不能使用。于是我问他，是否可以中国区单独购买从而启动这个功能。得到的答案是不。因为全球数据库支持团队已经制定了统一标准，公司内部的运维文档里没有任何管理adg的运维资料。如果在交易以外的时间，我不在公司的时候adg出现了问题，是没有人能有能力解决的。
于是应用系统的架构进行了大改动，之前预计在备库使用的报表功能全部放到了生产库，同时告诉业务部门，为了 保证白天交易系统的性能，请尽量在每天闭市时间做复杂报表的业务。这期间我们也讨论过是否用物化视图的方式将数据同步一份到其他服务器来做报表，但是又被全球统一这件事情卡住了。具体的问题已经记不太清楚，只记得是被一个伦敦的印度人以很客气的语气劝退。
到了即将升级12c的时候，我们决定采购了一套一体机，将12c安装在上面，然后通过逻辑standby的方式做滚动升级，这样能够把升级时间尽量缩短，用一天一晚就能完成。就在我们提交了方案之后，又被全球统一卡住了。按照公司规定，所有的standby必须大版本小版本都保持一致，禁止跨版本做逻辑standby。那一刻我真的差点爆粗口了，真想把对方按到业务部门面前，让他好好看看业务部门给我们的压力。然而最终还是不得不选择了用停机加rman做恢复这个极慢的方式。
此外还有个叫做global tns的东西，所有应用都必须通过这玩意来指向数据库，不允许使用本地tns。同样，我没有维护权限。每次做灾备演练的时候，必须要等国外同时把这个global tns修改了生效了，我们才能切到备库。真到了紧急切换的时候，根本达不到监管部门多少分钟内切过去的要求。
第四个坑，核心应用
如果说前三个都是外来坑，那这个就是典型的本地坑。
因为scan ip是11g才引入的，应用最早是基于10g的单节点开发，因此我们的应用在很长一段时间里都只能支持从单个vip登入。你会发现一套rac两台服务器，node1的会话数都几百上千了，node2的会话数寥寥无几。以至于我在那几年都养成了一个习惯，所有的dba操作都是从node2登入进行。我也曾经和应用的开发人员说，你们能不能把两个vip都写到连接字符串里，运维同事说，系统开发的公司不敢确认这样做能不能好用。他们也不敢。
于是某一个周一早上刚开市没多久，监控报警了，连接数已经到达上限的90%。我看完有点懵，怎么周一刚开市会话数就报警，按照以往的经验，这个会话数会随着开市小幅上升，但是之前从来没有过到达90%阈值的时候。于是查询相关v$视图，被一台很陌生的服务器占用了相当比例的连接数。仔细一查才知道，这是一台新上线的服务器，其中兼具了连接数据库账号查询各类应用需要数据的功能。恰好周末这台服务器的应用没有停机，而应用本身又有问题，不断地创造新的连接进来，终于在周一刚开市就出现了连接数快满的情况。
这套核心交易系统每次升级，我都如坐针毡，每次自认为自己准备的比较充分，但是却总能在我意想不到的地方翻车。例如有些新上线的语句没有绑定变量、业务逻辑出现错误导致短期内归档日志生成量暴涨、大量中间数据写入表中没有定时清理导致rman备份超时报警等等。在标准监控的基础上，加了一个又一个的监控点，从而使得这个核心交易库，从一辆中国高铁慢慢变成了哪哪都坐着人的印度火车。
死磕了几年后，我离开了那家公司，去到新公司之后，看着新公司尽量瘦的核心系统，长舒一口气。归根结底，数据库软件哪有那么多神奇的坑，其实都人为制造的，有些还是中外组合坑。