一個公司的核心交易數據庫是一個公司業務的生命線，都是需要最高保障級別的維護，有的公司甚至是要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備份超時報警等等。在標準監控的基礎上，加了一個又一個的監控點，從而使得這個核心交易庫，從一輛中國高鐵慢慢變成了哪哪都坐著人的印度火車。

死磕了幾年后，我離開了那家公司，去到新公司之后，看著新公司盡量瘦的核心系統，長舒一口氣。歸根結底，數據庫軟件哪有那么多神奇的坑，其實都人為制造的，有些還是中外組合坑。