前段時間，一家原資料庫工廠的售後人員跟我聊天時，似乎我們老甲骨文DBA更能理解和容忍國產資料庫的現狀。 我說當然，現在的年輕DBA只見過超級牛xOracle資料庫，這就像我們被Oracle濫用得淋漓盡致。他們不知道，資料產品在越來越好之前，會經歷乙個難以忍受的童年，國產資料庫也是如此。
甲骨文的苦澀過去
誠然，甲骨文並不是天生就像現在這樣優秀，當我第一次開始使用甲骨文時，甲骨文就像乙個仍然又愛又恨的渣男。 就算不提難以忍受的90年代，也只是乙個相對靠譜的Oracle 92 說到那個時代，當時的甲骨文的過去對於DBA來說也是非常淒美的。
oracle資料庫執行平穩，永不宕機這不適合十幾二十年前的場景。當時，有太多的事情，比如資料庫宕機、重啟、掛起，以及使用速度太慢。 資料庫重新啟動並且一小時或半小時沒有關閉的情況並不少見。 而且因為當時對oracle資料庫的原理了解不多，甚至不知道為什麼關不掉也起不來，也不敢隨便操作，甚至有些使用者也不敢輕易關閉或重啟資料庫。
面對莫名其妙的掛起的無奈，或者乙個資料庫太慢而無法使用，仍然經常被記住。 CBC 閂鎖、緩衝繁忙等待、無閂鎖、...，這個問題會讓DBA忙上半天。 更不用說是共享池、庫快取鎖定還是 ora-4031 問題。
ORA-1591 錯誤
當我想到甲骨文難以忍受的過去時，首先想到的是 ORA-1591 錯誤。 能一下子分辨出問題所在，估計至少有40年的歷史了，因為從Oracle 10G開始，Oracle就具備了自動處理分布式事務故障的強大能力。
適用於 Oracle 8i、9i 甚至更早的使用者這是一場噩夢。
當時，基於 Tuxedo 的 XA 分布式事務相當流行，dblink 也是開發者常用的技術。 對於兩階段提交，如果分布式事務失敗，資料庫系統或 XA 管理器應自動回滾或提交事務。 但是，早期的oracle資料庫在這方面的處理能力較差，並且由於資料庫本身不夠成熟，因此分布式事務失敗的比例相當高。
如果分布式事務失敗，並且與 dba 2pc xxx 相關的資料字典不完整，則資料庫無法自動回滾或提交分布式事務。 如果碰巧另乙個應用程式需要訪問掛起的資料，則會出現 ORA-1591 錯誤。
通常，如果資料庫出現問題，重新啟動資料庫可以解決問題。 但是，ora-1591（分布式事務失敗引擎）的錯誤在重新啟動資料庫時不會消失許多使用者反覆重新啟動資料庫，卻無法解決此問題。 這種情況下，只能手動完成系統字典的資料，如dba 2pc pending，然後使用rollback force或commit force強制回滾或提交相關的本地事務。 這是我差不多二十年前半夜被吵醒後最常遇到的問題。 大多數使用者可以在遠端指導下在十幾到二十分鐘內解決問題。 甲骨文的這個問題很煩人，但它也讓我時不時地發財。
ORA-1578 問題
Ora-1578 也是 Oracle 使用者的常見問題。 當時 Oracle 資料庫的 bug 太多了，數不清，最頭疼的就是可能導致邏輯壞塊的 bug，起初我以為壞塊是硬體造成的，但後來我發現 oracle bug 產生邏輯壞塊的幾率遠遠大於硬體。 一旦出現邏輯壞塊，就必須使用DBMS修復來修復，唯一無法修復壞塊的工具就是使用這個工具強制將該塊標記為壞塊，否則在進行全表掃瞄時會報SQL錯誤。 當時，該應用程式寫得非常糟糕，幾乎不可能避免全表掃瞄。
一些邏輯壞塊不以 ORA-1578 的形式報告，但有時會出現ora-600[kcbgtcr_x]這也意味著應用程式會掃瞄邏輯壞塊。
有一次，乙個哥們為操作員做了 9 個2.0.2 至 92.0.5 次公升級。 公升級後的第二天，資料庫開始報告大量 ora-600 錯誤。 好友還在睡夢中被使用者叫到現場，在IT部門大大小小的領導的注視下坐在終端前，腦子一片空白。
事後，他心悸地對我說，他當時腦子一片空白，不知道該如何分析這個問題，但是在那麼多甲方領導的注視下，他不能傻傻地坐在那裡什麼都不做，於是不停地在SQLPLUS中輸入所謂的SQL語句來拖延時間。 因為他在路上的時候叫我**，他知道自己在場上的所有工作都沒有任何希望，他唯一能指望的就是我在遠處幫他查元鏈結。
那天我很幸運，他在鍵盤上打了十多分鐘後，我發現了乙個類似的bug，我的**救了他。 當時我們倆都不確定是否是這個錯誤導致了 600 錯誤，但別無選擇。 幸運的是，玩完這個補丁後，錯誤實際上消失了。
Oracle DBA 的不同之處
在那些難以忍受的歲月裡，作為一名 Oracle DBA除了擁有過硬的技術，還必須有非凡的勇氣。就像我的朋友一樣，在一群領導的注視下，他能夠不停地打訂單十多分鐘。 如果這種品質被替換，我肯定做不到。
在處理複雜問題的情況下，DBA 必須具備多項獨特的技能。 例如，您可以讀取和分析告警日誌、分析系統狀態轉儲、執行掛起分析以及檢視作業系統日誌。 資料庫掛起，sqlplus無法登入資料庫，你還有辦法做掛起的診斷嗎？沒有掌握sqlplus -prelim 'as sysdba'技能的人，遇到這樣的問題會麻木
如果遇到ORA錯誤或ORA-600錯誤，是否可以根據錯誤號大致確定故障範圍？在那些日子裡，我敢說我是這方面的大師，每天必須多次瀏覽錯誤段表，這讓我對這些錯誤非常敏感。
前兩天，有朋友在群裡問了乙個錯誤資訊，我很多年沒有在一線做運維了，但是基於20年的機械記憶，沒有翻過資料，我很快就給出了乙個大致的方向，沒想到竟然是對的。 對於被Oracle資料庫折磨多年的老DBA來說，這方面有一些特長。
總結
Oracle 並不是天生的好資料庫，宕機、bug、壞塊、GCS GES、共享池、掛起和不可用也時不時地困擾著 DBA。 然而，問題嚴重的Oracle培養了大量極高階別的DBA。 二十年前，我經常幫助一些國外DBA解決MSN上的一些難題。 曾經有個外國人問我，你應該是中國最好的Oracle DBA。 “我回答說：”沒關係，它比最好的DBA差得多。 他最後說：“中國的DBA太好了”。
現在我們面對的國產資料庫也像預言機那不是超級厲害的那麼多問題，前段時間我聽到一位朋友評論國產資料庫，“自主研發都是bug，基於開源並不新鮮”，非常鄙視國產資料庫。 資料庫等複雜的基礎軟體系統，必須在使用大量使用者的過程中不斷完善，才能消除大量的軟體bug，最終逐漸成熟。 甲骨文花了20多年的時間，已經變得十足了，我們也應該給國產資料庫幾年的時間來成長。
作者丨白鰻**丨***白鰻洞 （ID： baishan755） DBAPLUS社群歡迎技術人員投稿，投稿郵箱：editor@dbapluscn