【恩墨學院】深入解讀Oracle 18c對於DBA的影響及應對措施

恩墨學院發表於2018-03-21

【恩墨學院】深入解讀Oracle 18c對於DBA的影響及應對措施


Joel Perez   

Oracle ACE Director,雲和恩墨高階雲技術專家


"DBA 將要失業了嗎? 當引入自治資料庫之後,就永遠不需要DBA了嗎?"


很顯然不是,無論你是否相信,我要肯定地告訴你,上雲之後,DBA在企業將會扮演更重要的角色


我已經從事了17+年的DBA職業,對於這方面有比較深刻的體會和理解。很多朋友擔心以後是否會失業,我們首先來看這個:


行業有哪些發展趨勢


1、會出現更多精細和高階的特性,每一個新的版本都是這樣的。


2、在資料庫中,越來越多的任務能夠被系統自動完成,因此無論對於企業還是個人來說,儘快地升級到新版本是非常有好處的,而不要等到被迫升級。


3、未來在雲上,對於DBA的要求將會更高。


因此在本文中,我將會談一談Oracle自治資料庫的推出對於DBA的影響,同時跟大家一起探討DBA該如何應對新的趨勢。


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(https://community.oracle.com/blogs/Sir.DBaaSJoelPerez/2017/09/25/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都擔心,自治資料庫服務套件是否會讓他們失業,其實這還是很遠的事情。


loud上提供資料庫的服務:


1、雲服務


2、Oracle裸機雲資料庫服務


3、一體機雲服務


4、一體機雲機器


5、快速雲服務


自治資料庫服務套件將代表你可以簽約的其他可能的服務。


關於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已經解釋了自動升級和打補丁的過程在18c資料庫中是如何實現的,針對的是18c執行在Exadata環境下的資料庫,由於18c 支援滾動進行升級和打補丁的所有過程,包括OJVM,針對Oracle提供的服務,也能夠進行線上打補丁


Oracle的自治資料庫中一些最吸引人的一些功能和特性:


自動應用補丁:在當前的情況下,如果你想給資料庫應用補丁集的話,過程是很簡單的。到官網查詢最新的補丁集,並根據安裝文件和說明進行,很快就可以完成。


因此,這種流程化的手動操作很快被系統自動化的程式來實現也是預料之中的。


還有一些補丁集在應用的時候,是需要停機的,因為程式會對系統中的二進位制檔案進行修改。但這種情況Oracle很可能也已經有了相應的自動化實現的機制,其實只要能夠將意見任務分解成一些按順序的步驟,那麼就有可能透過系統的自動化實現,因此,對於打補丁這樣的流程化的工作,自然而然會成為首先要自動化的任務之一。


升級:在使用databse cloud service的時候,如果要升級一個雲中執行的資料庫的話,唯一的辦法就是建立一個新的服務,在這個新的服務中,有一個專門的計算節點我們可以用來完成升級資料庫的過程。不過我們要明確一點的是,在PDB的管理方面,Oracle努力建立了很高階的機制,比如我們能夠對PDB進行熱克隆,在不影響業務和執行的情況下,將PDB從一個容器遷移到另一個容器當中。這些功能從本質上來講,跟線上遷移資料檔案的原理是差不多的,但實現的級別更高階,因此我們看到Oracle的技術是越來越成熟了。


像是升級這種工作,也能夠很快被定義為:比如在PDB上需要完成哪些任務,在CDB上需要做什麼樣的配置保證資料庫升級之後能夠正常地執行。而且我確定,這些工作將能夠線上的完成,無需關閉資料庫。從這個角度來講,自動升級的技術跟我們現在在本地資料庫上使用的技術本質上並沒有區別,只是說在一個新的服務模式下,這些技術可以在更高的級別進行應用。


自我最佳化:這個聽起來很複雜,事實上是很簡單的原理。在當前的環境下,當我們使用資料庫中一些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 眾多的選擇中做合理規劃設計而不至迷失。


恩墨學院隸屬於雲和恩墨(北京)資訊科技有限公司,致力於提供專業高水準的與大資料培訓服務,挖掘培養大資料與資料庫人才。恩墨學院提供包括個人實戰技能培訓、個人認證培訓、企業內訓在內的全方位大資料和資料庫技術培訓。ACE級別超強師資,配備專業實驗室,沉浸式學習與訓練,專業實驗室、配備專業助教指導訓練。能迅速融入專家圈子,業內資源豐富,迅速積累職場人脈。課程包括:班、Oracle Oracle OCP考試等。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28530558/viewspace-2152068/,如需轉載,請註明出處,否則將追究法律責任。

相關文章