11g rac安裝過程感悟

問題的背景是這樣，以前學習oracle 10g rac的時候在rhel 5上安裝，真是快使出吃奶的勁了，前前後後忙活了一個多星期，配網路，配共享儲存，修改vmware的配置檔案，結果在root.sh的部分發現認證系統是rhel 4,rhel 5中還需要手工去修改一些指令碼內容才可以，要不總是在root.sh的時候出現很奇怪的報錯。所以包括我還有很多的DBA朋友們，可能都在這個歷程中感受到了艱辛。越是難做，越發感覺安裝真是一件大活，都特別想親自看看安裝的過程。所以自己也準備了好幾套虛擬機器環境，安裝的過程也是全程截圖，不斷的分析可能哪些步驟會出現哪些錯誤和問題。每次看起來倒也是蠻有收穫和感悟。
    因為之前的配置都是使用裸裝置來繫結的，所以這個思路也就慢慢延續了下來，但是發現工作中都不使用裸裝置的方式，都是udev配置磁碟組，而且不同的作業系統版本配置方式也略有差異，現在的主流作業系統版本都是rhel 6了吧。到了11g後續的版本已經可以從官方文件看到裸裝置已經會慢慢不再支援，究其原因，其實聽了Tony的解釋還是很有說服力的：很多人接觸和使用過裸裝置，也有很多資料庫頁支援裸裝置，但是Oracle最近的版本將不建議使用裸裝置，後面的版本就直接不支援了其原因就在於：裸裝置沒有繁瑣的快取機制，使用者寫入的資料就直接寫入到介質中；同時避免了double cache;裸裝置不僅不快取使用者資料，也不快取基本的metadata;因為使用裸裝置的高效能，曾經比較流行。（實際上這是不對的）,由於裸裝置的性質決定了它不能提供任何快取，也不對資料做任何保證，對資料安全權要全權由使用者跟資料管理系統來保證，所以當使用裸裝置發生斷電的時候，最容易造成資料庫崩潰，資料損壞等不可控的情況出現，所以裸裝置正在遭到拋棄，同時也不建議使用裸裝置，因為不安全，也不可靠。這些都是Tony兄的真知灼見。
    然後說asmlib,也是一種可以配置asm磁碟組的一種選擇，奇怪的是自己從最開始就直接放棄了這個解決方案，因為這個需要額外安裝asmlib的安裝包，同時安裝包也是依賴於作業系統核心版本，當然安裝好之後還是有不少實用的命令，但是在工作中還是幾乎沒有看到使用的場景，直到在11g的某個版本發現asmlib已然不再支援。和同事之間聊asm,如果能夠把asm本身推得更普遍一些，弄成類似mkfs -t ext4這種型別的方式，可能方便使用起來就會有更多的人去接受它。
    所以這些以前看起來的很多難點和坑在後續的版本都進行了改進，甚至說oracle在用一種主流的使用方式來引導我們。所以越是這樣可能對於以前的那一批DBA戰友們這個過程就彌足珍貴，但是也僅僅是回憶之中，我老是喜歡感慨，11g版本實在是太好了，有太多的改進和閃光點，很多功能都是在潛移默化之中使用，你可能都沒有意識到需要專門去開啟某些特性，它們就在那兒。active dataguard,sql monitor,rac-scan,備庫的awr,ash...這些都極大的改善了我們的工作處境。同時對我們的挑戰就是怎麼去填補過去的坑，以前的真知灼見，攻略秘籍肯能就成了昨日黃花。對於更多的新人來說，直接入手11g,他們可能不會有那種改進的感覺，因為他們可能潛意識中就會認為就應該這樣，所以我們的有些痛點不好道出。
    身邊有不少的DBA朋友都在感慨說10g rac著實難裝，很多人可能因此留下了一些陰影：）
    我在學習11g rac的時候就會有各種顧慮，所以整個環境也是配置了很久，最後好不容易搞定，明顯感覺要好很多，當時其實是碰到了一個問題，就直接把grid clusterware和資料庫軟體都安裝在了grid使用者下，所以這些年一直在用這種看似奇怪的方式，然後限於自己使用vware，不想再修改更多的配置檔案，索性使用了nfs這樣，哪種虛擬機器都可以無縫支援。這套rac環境也前前後後出了些小問題，但是最終都把它可以正常open. 很多的安裝細節早都忘記了，也不知道具體什麼問題，最後把所有的東西都裝在了grid下，安裝的掛載點自己也定義了u01,u02,u03,u04裡面的目錄最後我自己都幾乎分不清楚到底哪些是安裝檔案，哪些是臨時生成的。直到最近因為一些需要，覺得還是需要把這個環境得格掉了，重新來做一做。結果幾年後自己來安裝的過程幾乎沒有碰到什麼問題，一路很順利安裝下來，11g中的ssh互信可以只輸入使用者密碼就會分分鐘幫你自動搞定，對於更多的細節驗證也很多到位，使用nfs安裝的過程中我是實在沒有找出任何可以圈圈點點的問題了。最後才發現自己幾年前遺留的問題，把所有東西放在一個使用者下，很可能是因為目錄的許可權導致自己判斷失誤，結果就妥協了，新的安裝我清理了所有的不明確的目錄，不規範的目錄名稱，然後重新來規劃，安裝好之後也感覺清晰乾淨了很多，也算了卻了一件心事。
      所以很多遺留問題，這塊硬骨頭還是要啃;有太多的目錄冗餘，不明確的地方，還是要梳理清楚;自己之前邁不過去的坎，可能壓根就不是什麼技術難題，只是一時理解偏差。所以簡單來說，安裝rac已經過了那個艱苦的歲月，軟體本身就已經支援的很好很強大了。對於我們來說，就要了解這些改進之處，繼續向前，畢竟這些難題解決了，交給我們的應該是更有難度和技術價值的問題了。資料庫軟體做的越好，對於我們來說要求就會更高，一旦不思進取，就會被逐漸時代拋棄，這也是不爭的事實。
      自己也暗暗給自己下了一個目標和任務，需要努力學習更多的未知領域，不能跟擠牙膏一樣，每天都在這種被動的推動之後，自己不努力，下決心去改進，知識範圍就會牢牢被束縛。