共計 5081 個字符，預計需要花費 13 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關如何解析 Oracle 18c 對于 DBA 的影響及應對措施，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
很顯然不是，無論你是否相信，我要肯定地告訴你，上云之后，DBA 在企業將會扮演更重要的角色。
我已經從事了 17+ 年的 DBA 職業，對于這方面有比較深刻的體會和理解。很多朋友擔心以后是否會失業，我們首先來看這個行業有哪些發展趨勢：
1、會出現更多精細和高級的特性，每一個新的版本都是這樣的。
2、在數據庫中，越來越多的任務能夠被系統自動完成，因此無論對于企業還是個人來說，盡快地升級到新版本是非常有好處的，而不要等到被迫升級
3、未來在云上，對于 DBA 的要求將會更高。
因此在本文中，我將會談一談 Oracle 自治數據庫的推出對于 DBA 的影響，同時跟大家一起探討 DBA 該如何應對新的趨勢。
Oracle 數據庫 18c 是下一代業界領先的數據庫。
Oracle 在今年的 OOW 上引入了世界上第一款的自治數據庫，其對應的云平臺和服務以最低的成本實現了更高的性能、安全和可靠性的需求，并且降低了操作的復雜度，減少了人為誤操作的幾率，大部分的工作能夠自主地完成，減少了手動操作的工作量。
在這里我要強調一下”Database Cloud“和”Oracle 自治數據庫云“，因為當我們談到云上的數據庫，Oracle 的自治數據庫云事實上是一種云端數據庫 的服務。在這篇文章中，我們會將它稱為”云端數據庫“
自治數據庫、云端數據庫，這個話題其實可以從不同的角度進行分析，我看到的大部分的文章中，都在講述這一款未來的數據庫有多少的優勢和好處。那么我們應該重點考慮哪些方面的問題呢？
1、誰來決定數據庫將處于哪個服務模式下？
2、誰將為這些資質數據庫植入政策約束？
3、對于數據庫的常規任務和行為，誰有足夠的認知來決定如何減少這些服務的成本？
4、當我們有更多的選擇的時候，IT 的基礎架構將會變得越來越復雜，誰來決定這些系統的設計？
很顯然，這些問題的答案都是 DBA，然而，不是任何一個普通的 DBA 都能完成。為了完成這些任務，DBA 必須對這一款未來的云上數據庫有深入全面的了解。
正如我剛才所說，自治數據庫事實上就是一種不同的云端數據庫服務。因此，首先要了解的內容就是如何將數據庫從本地遷移到云端。關于數據庫的云端遷移，請參考： Oracle Cloud (DBaaS): Migrating Databases to Oracle Cloud Using RMAN Backup
Oracle 自主數據庫是一種具有許多已經自動化的常規任務的數據庫，這些可自動化完成的任務如下：
1、補丁的應用
2、升級
3、系統的自主優化
但是，這篇文章的重點還沒有開始：
首先我引入我一個 ACED 朋友 Tim Hall 的原話，他說，18c 的預售對于 DBA 幾乎是沒有影響的，只有自治數據庫的服務套件整體推出的時候才會對 DBA 產生比較大的影響。
對于這句話要怎么理解呢？
首先，對于前半句，Oracle18c 對于 DBA 是沒有影響的，它只不過是一個更高的版本罷了。它并不是一個運行在自治模式下的普通意義的關系型數據庫的管理軟件，事實上，自治數據庫本身就是被設計用于今后的環境和需求的，它只是針對云上的，跟本地的數據庫并不相關。
而后半句，自治數據庫的服務套件對于 DBA 是有影響的。自治數據庫是一款用于 Oracle 公有云上的可用的服務套件。這也就意味著本地的數據庫是不可以被運行在自治的模式下的，當然也許以后會實現。
目前有很多 DBA 都擔心，自治數據庫服務套件是否會讓他們失業，其實這還是很遠的事情。
事實上有幾種在 Cloud 上提供數據庫的服務：
1、Oracle 數據庫云服務
2、Oracle 裸機云數據庫服務
3、Oracle 數據庫一體機云服務
4、Oracle 數據庫一體機云機器
5、Oracle 數據庫快速云服務
自治數據庫服務套件將代表你可以簽約的其他可能的服務。
接下來我們將討論，關于 Oracle 的自治數據庫，我們還應該了解哪些內容：
1、Oracle 自治數據庫或者說拯救我驅動數據庫，將會在 18c 的版本中全面推出，這與當前的 12c 的版本跨度很大。
2、Oracle12.1 的版本應該至少還有 4 年的時間，預計在 2021 年之前都不會被淘汰
3、Oracle12.2 則應該在 2025 年都會提供擴展服務，我們都知道，在一個新版本推出的時候，很多用戶都不會著急將數據庫升級到最新版本，而是到需要響應的服務或者新的版本的擴展服務將要到期的時候才會升級。這樣考慮的話，Oracle18c 要被真正大規模投入生產環境的話，還是需要很長的時間，
目前，Oracle 自治數據庫是針對 Exadata 設計的，我們知道 Oracle Exadata 雖然很強大，但非常昂貴，因此很多用戶都不會選擇，尤其是對于一些中小型的企業來說。
因此，DBA 們不用擔心，從目前來看 Oracle18c 并不會完全自治，而自治數據庫也不會完全取代傳統數據看的運行機制。
接下來我們要討論幾個在比較重要的話題：
1、Oracle 18c 并不是自治的數據庫服務，反之亦然，這是兩個概念
2、自治數據庫服務組件目前只適用于 Oracle 公有云服務
3、根據目前的情況，自治數據庫服務組件僅支持 Exadata 的環境。（當然也許以后會變化）
4、Oracle 18c 只是數據庫的一個新的版本而已
當我們了解這些之后，我們就可以很確定地說，自治數據庫的推出，對于當前運維本地的 DBA 并沒有多大的影響。但 這并不意味著面對云的趨勢和與數據庫的趨勢，我們不需要做改變。我們只有 深入了解新的技術和方向，了解其優勢和不足，提前做準備，才不至于被新的浪潮打得措手不及。
接下來我們聊一下 Oracle 的自治數據庫中一些最吸引人的一些功能和特性。畢竟 Oracle 自治數據倉庫云在今年 12 月份就推出了。
自動應用補丁：在當前的情況下，如果你想給數據庫應用補丁集的話，過程是很簡單的。到官網查詢最新的補丁集，并根據安裝文檔和說明進行，很快就可以完成。
因此，這種流程化的手動操作很快被系統自動化的程序來實現也是預料之中的。
還有一些補丁集在應用的時候，是需要停機的，因為程序會對系統中的二進制文件進行修改。但這種情況 Oracle 很可能也已經有了相應的自動化實現的機制，其實只要能夠將意見任務分解成一些按順序的步驟，那么就有可能通過系統的自動化實現，因此，對于打補丁這樣的流程化的工作，自然而然會成為首先要自動化的任務之一。
升級：在使用 databse cloud service 的時候，如果要升級一個云中運行的數據庫的話，唯一的辦法就是創建一個新的服務，在這個新的服務中，有一個專門的計算節點我們可以用來完成升級數據庫的過程。不過我們要明確一點的是，在 PDB 的管理方面，Oracle 努力建立了很高級的機制，比如我們能夠對 PDB 進行熱克隆，在不影響業務和運行的情況下，將 PDB 從一個容器遷移到另一個容器當中。這些功能從本質上來講，跟在線遷移數據文件的原理是差不多的，但實現的級別更高級，因此我們看到 Oracle 的技術是越來越成熟了。
像是升級這種工作，也能夠很快被定義為：比如在 PDB 上需要完成哪些任務，在 CDB 上需要做什么樣的配置保證數據庫升級之后能夠正常地運行。而且我確定，這些工作將能夠在線的完成，無需關閉數據庫。從這個角度來講，自動升級的技術跟我們現在在本地數據庫上使用的技術本質上并沒有區別，只是說在一個新的服務模式下，這些技術可以在更高的級別進行應用。
接下來的內容，我的 ACED 朋友 Tim 幫助我解釋清楚了一些元素，能讓大家更好地理解 Oracle 18c 數據庫。以下我引用他的原話“Oracle 已經解釋了自動升級和打補丁的過程在 18c 數據庫中是如何實現的，針對的是 18c 運行在 Exadata 環境下的數據庫，由于 18c 支持滾動進行升級和打補丁的所有過程，包括 OJVM，針對 Oracle 提供的服務，也能夠進行在線打補丁”
自我優化：這個聽起來很復雜，事實上是很簡單的原理。在當前的環境下，當我們使用數據庫中一些 adaptive 特性的時候，數據庫相當于在進行自我優化，比如自動創建索引等，這些都是在線完成的，同時，在數據庫中加入 AI 的引擎對數據進行更好地收集和分析處理，之后體現到 SQL 查詢的工程中，并不是一件很難的事情。
也就是說，自我優化就是通過 AI 程序進行分析后在使用類似 adaptive 特性影響 SQL 的執行路徑的選擇等。
對于以上系統能夠自主完成的一些事情，我們來看一下其執行的頻率：
1、應用補丁集：應用補丁集并不是一項頻繁的任務，定期打一次，執行頻率很低。
2、升級：頻率更低，一般數據庫版本好幾年才更新一次，但對于絕大部分的客戶來說，并不會緊隨著新版本的發布就著急升級，因此這樣的操作的需求就更少了。
3、自我優化：頻率會很高，幾乎是持續在發生，因為數據庫中數據變更是很頻繁的，對數據進行增刪查改，幾乎都會用到相應的優化，也就是說，這個功能的啟用會開銷很大。我們知道在當前的數據庫中，有 tuning advisors，在我們的經驗中，效果并不是太好。很多時候，我們采納了 advisor 給出的優化建議進行調整之后，性能反而更差了，那么在自治數據庫中自動優化的特性將會達到什么樣的效果呢？如果真的很完美，能夠在真實的應用場景中進行很好的優化，那的確是會減少對 DBA 相應的需求。
因此，有一個很重要的事情就是，在沒有百分百的肯定下，你覺得一個企業有多大的可能會完全采用系統的自我優化，而不附加任何的人為檢測和控制。
我認為這樣的可能性是很低的，因而優化要考慮的因素很多，除了 SQL 本身，還要考慮應用的邏輯，架構的設計，甚至一些政策限制等等，很多時候，人為在進行優化的時候都做不到完美顧及每一個方面，何況是機器。
我們舉一個簡單的例子，在一些環境下，Oracle Dataguard 有自動 failover 的機制，有時候在數據庫中發生一些人為的錯誤導致數據庫會自動進行 failover 的切換，事實上這些場景我們并不希望切換。因此為了避免自動 failover 帶來的影響，很多企業都很怕使用 FSF（Fast Start Failover），該特性雖然功能很好，但總是會在系統中應用很多系統并不允許植入的數據。
綜合來講，我認為自主數據庫將會在很大程度上減少對 DBA 工作的需求，但并不能夠完全取代 DBA 的存在和作用。
自治數據庫向用戶承諾了以下優勢：
1、減少管理時間
在基礎架構搭建上，在升級和打補丁上，在保障高可用上，以及在性能有劃傷，時間都將大幅減少
2、增加了創新的時間
在數據分析，數據政策，數據安全以及在數據庫的設計上，都將需要花更多的時間。
因此，上云之后，DBA 必須增強在安全方面的管理技能。
那么，重點來了，面對 Oracle 的云端數據庫，DBA 的未來將是什么樣的？
17 年前，那時候我剛開始做 DBA，那個時候設計一套數據庫架構是很簡單的，只需要決定將數據庫安裝在什么環境下，比如服務器，大型機或者在一些特定的場景下，是安裝在桌面機器也就是 PC 上的。
現在數據庫可選的部署環境很多，比如服務器，虛擬機，集成式系統比如 Exadata, 還有很多其他的選擇。
還必須決定數據庫將植入何種架構，比如最通用的本地的選項，私有云，混合云，集成云，而隨著 18c 的推出，選擇還在增多。
那么這種情況下，誰來決定將數據庫部署在上面環境下，以何種服務模式部署，當然，還是 DBA。因此，不是不需要 DBA，而是要求 DBA 要懂得系統以外更多的知識，要了解業務，了解平臺等。
我把現在的 Oracle DBA 分為以下三類，他們的方向如下：
第一類：日常工作只圍繞一些最基礎常規的任務展開，比如打補丁，擴容等等。那么當自治數據庫推出后，如果他們不努力求變的話，很可能會失業
第二類：在運維數據庫的同時，還做 IT 相關的其他工作，或者在其他領域也有比較豐富的經驗，那么這類 DBA 就可以通過各類知識的全面學習，為公司做更重要的決定，而不局限于數據庫。這就是我們常說的，從 DBA 到架構師的轉型。
第三類：對于那些決定在 Oracle 領域深入走下去的 DBA 來說，由于系統變得越來越智能和強大，對 DBA 的要求也越來越高，因此這類 DBA 需要努力學習跟多的知識，去了解業務，了解云，了解所有在云上需要到的技能，才能在 Oracle 眾多的選擇中做合理規劃設計而不至迷失。
關于如何解析 Oracle 18c 對于 DBA 的影響及應對措施就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
