Oracle 11g RAC運維總結

1 術語解釋
1.1 高可用(HA)
什麼是高可用?顧名思義我們能輕鬆地理解是高度可用的意思,也說是說高可用(high availability)指的是運行時間能滿足預計或期望的一個系統或組件,我們常聽說的247365系統,這種系統追求一種不間斷提供服務的目標,任何時候都不能停止服務,否則會給用戶造成比較大的影響。在信息、通訊、互聯網技術發展如此快的今天,越來越多的系統都希望成爲一個高可用的系統,比如銀行、證券系統等。
1.2 負載均衡(LB)
負載均衡(load balance)是指將業務的負載儘可能平均、合理地分攤到集羣的各個節點,每個節點都可以處理一部分負載,並且可以根據節點負載進行動態平衡,提高各個節點硬件資源的利用率以及降低單節點因爲負載過高而導致的故障。
1.3 RAC集羣
RAC集羣,全稱Real Application Clusters,譯爲“實時應用集羣”,是Oracle提供的一種高可用、並行集羣系統,RAC除了具有高可用能力還有負載均衡能力,整個RAC集羣系統由Oracle Clusterware (集羣軟件)和 Real Application Clusters(RAC)兩大部分組成。 我們平時一直經常提的RAC,它僅僅是RAC集羣中的一部分,是運行在集羣軟件Oracle Clusterware上的一個應用,就是數據庫,它和集羣軟件的關係類似單機環境中應用程序和操作系統的關係。
1.4 CRS
我們知道RAC集羣需要集羣軟件,那麼CRS是什麼呢?在Oracle 10g版本前,RAC集羣所需的集羣軟件依賴於硬件廠商,在不同平臺上實施RAC集羣都需要安裝和配置廠商的集羣軟件,而Oracle只提供了Linux和Windows平臺上的集羣軟件,叫Oracle Cluster Manager。但從10.1版本開始,Oracle推出了一個與平臺獨立的集羣產品:Cluster Ready Service,簡稱CRS,從此RAC集羣的實施不再依賴各個硬件廠商,從10.2版本開始,Oracle將這個集羣產品改名爲Oracle Clusterware,在11g中又被稱爲GI(Oracle Grid Infrastructure),但我們叫慣了CRS,所以平時很多時候也就稱之爲CRS,這個產品並不侷限用於數據庫的集羣,其他應用都可以借用其API輕易實現集羣功能。

2 架構
2.1 RAC環境組成
2.1.1 硬件環境
整個RAC集羣的硬件環境包括主機、共享存儲、互聯網絡設備。

  1. 主機(節點)
    一個RAC集羣環境中至少有兩臺主機,也就是兩個節點,每個節點的硬件配置應該都一樣,每個節點至少配置兩塊物理網卡。
  2. 互聯網絡設備
    1) 兩塊網卡:也就是上面所說的每個節點上必須至少配置兩塊物理網卡。一塊網卡用於集羣內部的私有通信,集羣節點間數據塊的傳輸都是通過這塊網卡,我們稱之爲私有網卡,上面配的IP稱爲Private IP;另一塊網卡用於對外服務,比如數據庫的查詢等,我們稱之爲公有網卡,上面配的IP稱爲Public IP。除此之外,每個節點還有第三個IP,我們稱之爲VIP(Virtual IP),在所有節點都正常運行時,每個節點的VIP會被分配到公有網卡上,當某個節點出現故障宕機時,這個節點的VIP會被移到還在正常運行節點的公有網卡上。
    2) 網絡交換機:整個RAC集羣中需要幾個網絡交換機呢?個人認爲至少兩個。一個用於連接所有節點的公有網卡以提供對外的數據庫服務,一個用於連接各個節點之間的私有網卡(當然Oracle官方也認爲如果是兩個節點,其實也可以通過網線直連的方式,但是生產環境中幾乎不存在這種方式)以傳遞集羣節點之間的心跳數據和數據庫數據塊(Cache Fusion)。
  3. 共享存儲
    在RAC集羣中,最重要的是共享存儲,RAC是一個“多實例、單一數據庫”的架構,所有的節點共享一個數據庫。數據文件、聯機日誌、參數文件、控制文件都必須放在共享存儲上以保證每個節點的實例都能訪問。每個節點必須安裝HBA卡,然後通過光纖線和存儲設備連接。
    2.1.2 軟件組成
    概括來說,RAC集羣的軟件組成包含:操作系統、集羣軟件、集羣文件系統、數據庫軟件。
  4. 操作系統
    每個節點上所安裝的操作系統必須是相同版本的,操作系統在RAC架構中所處位置是硬件與集羣件中間。
  5. 集羣件(CRS)
    集羣件是安裝在操作系統之上的一個特殊軟件,負責管理整個集羣環境中的硬件資源,併爲上層的RAC集羣提供基礎服務。它與上層應用(例如數據庫)的關係類似於單機環境中操作系統和應用程序的關係。單機環境下,OS能代理應用程序對硬件訪問,但是在集羣中有多臺計算機,把整個集羣想象成一臺虛擬的計算機,那集羣件就是這臺虛擬計算機上的操作系統,RAC是運行在它上面的一個應用程序。
  6. 集羣文件系統
    RAC集羣中有很多的文件必須放在共享存儲上,保證所有節點都能訪問。這就需要對節點的訪問進行控制,普通的文件系統並不支持集羣功能,必須採取特殊的存儲策略。在10g以前,Oracle只提供了對裸設備的支持,並沒有提供集羣文件系統,但從Oracle 10g開始,Oracle提供了OCFS和ASM兩種集羣文件系統,後者在現在的環境中用的最多,也最爲流行。
  7. 數據庫軟件
    這個就是rdbms軟件了,只有安裝了數據庫軟件,我們才能創建數據庫,存儲數據,對外提供數據服務。

這裏附上一張RAC集羣簡單的拓撲圖:
在這裏插入圖片描述
2.2 CRS組成
Oracle Clusterware,在11g中又被稱爲GI(Oracle Grid Infrastructure),我們這裏統一直接稱之爲CRS好了,它由磁盤文件、後臺進程、網絡組件組成。

  1. 磁盤文件
  1. OCR:OCR(Oracle Cluster Registry)是爲了避免每個節點的配置信息不同步而保存了整個集羣的配置信息,且整個集羣只有一份配置,所有節點共享,配置信息以“Key-value”的形式保存其中。當集羣配置需要發生改變時,每個節點都有一個OCR Process來讀取OCR Cache中的內容,而只有一個節點(OCR Master)有權限讀寫OCR Disk的內容,然後同步到本地和其他節點的OCR Cache。
  2. Voting Disk:Voting Disk這個文件主要用於記錄各個節點的狀態,以防在某個或某幾個節點出現問題時,決定哪部分節點具有集羣的控制權,而把其他節點從集羣中剔除,從而能夠繼續正常地對外提供服務。
  1. CRS後臺進程
    其中最重要的三個進程是CRSD、CSSD、EVMD,分別對應了CRS、CSS、EVM三個服務,而每個服務又是由一系列的模塊組成的,我們可以通過crsctl命令來查看有哪些模塊組成,如查看css服務,crsctl lsmodules css。那麼這三個進程又是什麼時候啓來的呢?在安裝Clusterware的最後階段,會要求在每個節點中執行root.sh腳本,這個腳本會在/etc/inittab文件中最後三行添加三個後臺進程的啓動信息,類似:
    h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
    h2:35:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 </dev/null
    h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null
    如果CRSD和EVMD出現異常,系統會自動重啓這兩個進程。但是如果CSSD進程異常,系統會立即重啓。羅列Linux和Unix中各個服務所對應的進程如下:
    在這裏插入圖片描述
    以Oracle 11g在linux上爲例來查看一下各個進程:
[oracle@node1 ~]$ ps -ef|grep css
root      4408     1  0 04:23 ?        00:00:05 /oracle/app/grid/product/11.2.0/bin/cssdmonitor
root      4427     1  0 04:23 ?        00:00:05 /oracle/app/grid/product/11.2.0/bin/cssdagent
grid      4445     1  0 04:23 ?        00:00:56 /oracle/app/grid/product/11.2.0/bin/ocssd.bin
[grid@node1 bin]$ ps -ef|grep crs
root      4767     1  0 04:24 ?        00:00:20 /oracle/app/grid/product/11.2.0/bin/crsd.bin reboot

[grid@node1 bin]$ ps -ef|grep evm
grid      4623     1  0 04:24 ?        00:00:07 /oracle/app/grid/product/11.2.0/bin/evmd.bin
grid      4861  4623  0 04:24 ?        00:00:00 /oracle/app/grid/product/11.2.0/bin/evmlogger.bin -o /oracle/app/grid/product/11.2.0/evm/log/evmlogger.info -l /oracle/app/grid/product/11.2.0/evm/log/evmlogger.log

我們來看一下各個進程的作用:
OCSSD
進程是Clusterware最關鍵的進程,如果出現異常會導致系統重啓,這個進程提供CSS(Cluster Synchronization Service)服務,它通過多種心跳機制實時監控集羣的健康狀態,提供集羣的基礎服務功能。
CRSD
是實現高可用的主要進程,它提供了CRS(Cluster Ready Service)服務。這些服務包括Clusterware上集羣資源的關閉、重啓、轉移、監控等。集羣資源分爲兩類:一類是Nodeapps型的,就是說每個節點只需要一個就行,這類有GSD(Global Service Daemon)、ONS(Oracle Notification Service Daemon)、VIP、Listener;另一類是Database-Related,就是和數據庫相關,不受節點限制,這類有Database、Instance、Service等。
EVMD
該進程負責發佈CRS產生的各種事件,同時也是CRSD和CSSD兩個進程之間的橋樑。
RACGIMON
該進程負責檢查數據庫健康狀態,負責Service的啓動、停止、故障轉移等。
OPROCD
在非Linux平臺,且沒有使用第三方集羣軟件時纔有該進程,用來檢測節點的CPU掛起,起過1.5秒會重啓節點。
OHASd
Oracle在11gR2引入了OHASd(Oracle High Availability Services Daemon,Oracle高可用服務後臺進程),再由它來啓動其他的集羣件守護進程。

  1. 網絡組件
    我們從RAC集羣架構中的硬件環境組成已經知道,集羣環境中的節點上必須配置兩塊物理網卡,在公網網卡上面我們除了設置公有IP外還設置了VIP,Oracle的TAF(所謂TAF就是連接建立後,如果某個實例發生故障,連接到這個實例上的用戶會被自動遷移到其他健康實例上,對於應用程序而言,這個遷移過程透明,不需要人工介入)是建立在VIP技術上的,它與IP最主要的不同就是VIP是浮動的,IP是固定的,當某個節點宕機時,該節點上的VIP自動會移到健康節點的公網網卡上,所能對該節點的連接自動會移到健康節點。
    VIP還有幾個特點需要我們注意一下:
    a) VIP是在Clusterware安裝最後階段通過腳本vipca創建的;
    b) VIP作爲一個Nodeapps類型的CRS資源註冊到OCR,並由CRS維護狀態;
    c) 每個節點的監聽會同時在Public網卡的Public Ip和VIP兩個地址上監聽;
    d) 客戶端的tnsnames.ora一般配置指向節點的VIP

2.3 單實例與RAC環境
1、 單實例與RAC環境對比
在這裏插入圖片描述

2、 RAC新增的組件和後臺進程
RAC的環境中雖然每個實例都有自己的buffer cache與shared pool,但它們現在已經變成全局的,需要特殊處理才能做到沒有衝突、無損壞地管理資源,所以也新增了一些單實例環境中沒有的組件,最主要的有以下兩部分:

  1. GRD
    RAC實例的SGA中多了一個GRD(Global Resource Directory)部分,Oracle數據庫中數據的操作都是在內存SGA中完成的,與傳統的單實例數據庫不同,RAC有多個實例,每個數據塊在任何一個實例中都有拷貝,RAC必須知道這些拷貝的分佈、版本、狀態,而GRD就是保存這種信息的內存區。值得注意的是,每個節點都只有部分GRD內容,所有節點合在一起才能構成完整的GRD。
  2. 後臺進程
    RAC也有和單實例中的DBWR、LGWR、ARCn、CKPT這些後臺進程,此外還有一些RAC特有的後臺進程:
    lms
    該進程是Cache Fusion的主要進程,負責數據塊在實例間的傳遞,對應的服務是GCS(Global Cache Service),可以通過GCS_SERVER_PROCESSES參數來控制進程的數量,默認是2個,取值範圍爲0~9。
    lmd
    該進程提供GES(Global Enqueue Service)服務,在多個實例間協調對數據塊的訪問序,保證數據的一致性訪問,和LMSn進程以及GRD共同構成RAC的核心功能Cache Fusion。
    lck
    這個進程負責Non-Cache Fusion資源的同步訪問,每個實例都有一個LCK進程。
    lmon
    各個實例的LMON進程都會定期通信,檢查集羣中各節點的健康狀態,當某個節點出現故障,該進程負責集羣重構、GRD恢復等,它提供的服務是CGS(Cluster Group Services)。
    diag
    Diag進程監控實例的健康狀態,並在實例出現運行錯誤時收集診斷數據記錄到Alert.log日誌中。
    GSD
    這個進程負責從客戶端工具,比如srvctl接收用戶命令,爲用戶提供管理接口。

3 Oracle 11g RAC集羣搭建
該部分詳細內容參考我寫的RAC的搭建文檔

4 維護
4.1 集羣維護
CRS有一整套的工具集,它們都出現在$GRID_HOME/bin目錄下,在 $ ORACLE_HOME中也有部分CRS工具可用,但Oracle推薦只使用$GRID_HOME/bin目錄下的工具集。常用的有crsctl、crs_stat、diagcollection.pl、oifcfg等,下面介紹一些簡單的應用。
4.1.1 啓動和停止CRS
通常,RAC環境中的CRS都配置成了隨機自動啓動,但有時候需要調試CRS,或者OS需要維護,或者需要爲GI軟件打補丁時,需要手工啓停CRS,手工啓停CRS的命令很簡單,與以前版本也是一致的,開啓CRS:crsctl start crs,關閉CRS:crsctl stop crs,依舊需要特權用戶root來完成CRS的啓停。
11g還引入了一個命令集來啓停所有節點上運行的全部集羣資源,包括數據庫實例、ASM、VIP等等資源,非常方便:

Usage:
  crsctl start cluster [[-all]|[-n <server>[...]]]
    Start CRS stack
where
    Default         Start local server
    -all            Start all servers
    -n              Start named servers
    server [...]    One or more blank-separated server names

例如:
停止所有節點上的css及資源:

crsctl stop cluster -all

啓動所有節點上的css及資源:

crsctl start cluster -all

4.1.2 驗證CRS
面這些命令用來驗證集羣及其相關進程的狀態(以grid、root用戶執行皆可)。
檢查一個集羣的當前運行狀態:

/opt/11.2.0/grid/bin/crsctl check cluster

例如:

[root@node1 bin]# ./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

檢查CRS的當前狀態:

/opt/11.2.0/grid/bin/crsctl check crs

例如:

[grid@node1 ~]$ crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

檢查ohasd進程的狀態:

/opt/11.2.0/grid/bin/crsctl check has

例如:

[grid@node1 ~]$ crsctl check has
CRS-4638: Oracle High Availability Services is online

檢查ctssd進程的狀態:

/opt/11.2.0/grid/bin/crsctl check ctss

例如:

[grid@node1 ~]$ crsctl check ctss
CRS-4700: The Cluster Time Synchronization Service is in Observer mode.

備註:如果RAC時間的同步是採用第三方軟件,比中ntp方式,那麼ctss會處於observer狀態

4.1.3 禁用與啓用CRS
若是不想讓CRS隨機啓動,那麼可以disable它:

/opt/11.2.0/grid/bin/crsctl disable crs

如果又改變了注意,可以enable:

/opt/11.2.0/grid/bin/crsctl enable crs

4.1.4 顯示集羣資源狀態
這個功能是11gR2中crsctl新具有的,顯示集羣資源的狀態:

/opt/11.2.0/grid/bin/crsctl stat res -t

該命令與以前的crs_stat -t基本類似

4.1.5 使用oifcfg配置集羣網絡
該命令包含了獲取、刪除與設置三部分,分別爲oifcfg getif、oifcfg delif、oifcfg setif,更加具體的語法可以通過oifcfg -h來獲取到
例如:

[grid@node1 ~]$ oifcfg getif
eth0  192.168.100.0  global  public
eth1  10.10.17.0  global  cluster_interconnect

4.1.6 使用diagcollection診斷集羣
該工具可以幫助DBA們一次性收集有關所有必需組件的診斷信息,如主機、操作系統、集羣等等,這個工具位於$GRID_HOME/bin目錄下,默認情況下,該工具將收集完整的診斷信息,但也可以使用正確的選項只收集想要的信息,如下命令只收集CRS的診斷信息:

/oracle/app/grid/product/11.2.0/bin/diagcollection.pl --collect --crs

4.2 管理OCR
OCR用來存儲集羣數據庫的配置信息,對它的管理操作包括備份、恢復、添加、刪除以及遷移等等

4.2.1 備份
OCR有自動備份,默認情況下,在集羣運行的過程中,每4個小時就會對OCR進行一次備份,並保留最後的3個備份,每天和每週結束時,也會保留相應的一個備份。有幾個命令被用來執行OCR備份相關的各種操作,比如查看OCR當前的一些信息並檢查OCR是否損壞(用root用戶執行):

/opt/11.2.0/grid/bin/ocrcheck

例如:

[root@node1 bin]# ./ocrcheck
Status of Oracle Cluster Registry is as follows :
         Version                  :          3
         Total space (kbytes)     :     262120
         Used space (kbytes)      :       2792
         Available space (kbytes) :     259328
         ID                       :  465396144
         Device/File Name         :      +DATA
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

         Cluster registry integrity check succeeded

         Logical corruption check succeeded

因爲OCR的重要,備份OCR是項非常重要的工作,以下命令查看OCR的備份信息:

/opt/11.2.0/grid/bin/ocrconfig -showbackup

切換至root,使用如下命令可以用來手工備份OCR文件(root用戶執行):

/opt/11.2.0/grid/bin/ocrconfig -manualbackup

OCR的備份文件是一個二進制文件,但是可以使用ocrdump命令來查看它的內容(同樣需要使用root用戶):

cd /opt/11.2.0/grid/bin/
./ocrdump -backupfile /opt/11.2.0/grid/cdata/racdb-cluster/backup00.ocr

爲了讓word中的顯示不太混亂,先cd到了ocrdump命令所在的目錄,這個命令會在命令執行的工作目錄下生成一個名爲OCRDUMPFILE的文本文件

4.2.2 恢復
備份是爲了在OCR損壞的關鍵時刻能夠對其進行恢復,下面是一個簡單的模擬恢復測試(使用root用戶來執行下面這些命令):
在所有節點上執行如下命令來停止crs:

/opt/11.2.0/grid/bin/crsctl stop crs

如果OCR文件已經損壞,那麼上述命令可能會報錯,在命令中使用“-f”選項強制關停crs,然後在其中一個節點上將crs啓動到獨佔模式:

/opt/11.2.0/grid/bin/crsctl start crs -excl

使用ps命令來觀察,如果crsd進程存在,使用如下命令先行關閉該進程:

crsctl stop resource ora.crsd -init

然後再使用ocrconfig命令查看備份文件所在的位置,並找合適的備份來恢復OCR:

/opt/11.2.0/grid/bin/ocrconfig -restore /opt/11.2.0/grid/cdata/racdb-cluster/backup00.ocr

再度使用ocrcheck來檢查OCR的狀況,如正常,先將當前節點的crs關閉:

/opt/11.2.0/grid/bin/crsctl stop crs -f

crs可以正常啓動了。

4.2.3 鏡像維護
當前的OCR所在的位置可以通過兩個途徑得到:一是ocrcheck命令,二是/etc/oracle/ocr.loc文件,既然OCR這麼重要,如果使用前面的幾個方法得知只有一份OCR的話,那麼應該考慮爲其創建鏡像,OCR只能有一個鏡像,也就是說OCR磁盤最多有兩個,一個primary ocr,一個mirror ocr,以下操作都可以在crs運行時進行,依舊使用root用戶來執行ocrconfig命令:

/opt/11.2.0/grid/bin/ocrconfig -add +ASM_TEST

這裏需要注意一點,在11.2版本具是用ASM來存放OCR,用來做OCR的diskgroup,也就是這裏的+ASM_TEST,需要滿足以下條件:
1) 冗餘配置爲External時,至少需要300M;冗餘配置爲Normal的至少需要600M;冗餘配置爲High的至少需要900M;
2) 該磁盤必須在所有節點上掛載;
3) Compatible.asm參數必須設置至少爲11.2(alter diskgroup +ASM_TEST set ATTRIBUTE ‘compatible.asm’=‘11.2’;);
4) 所有節點上,GRID_HOME的權限爲“6751”或“-rwsr-s—x”。
下面的命令用來刪除多餘的OCR:

/opt/11.2.0/grid/bin/ocrconfig -delete +ASM_TEST

4.2.4 移動OCR
有時在維護時可能會更改OCR的磁盤,也就是說將OCR從一個磁盤移動到另一個磁盤,那麼也是可以的,只是在移動前必須先給OCR添加鏡像OCR,然後再移動,步驟如下:
當前的OCR是DATA,創建鏡像DATA1,然後移動到DATA2

opt/11.2.0/grid/bin/ocrconfig -add +DATA1
/opt/11.2.0/grid/bin/ocrconfig -replace +DATA -replacement +DATA2

值得一提的是,ocrconfig還有-export和-import選項可以用來替代上面的備份與恢復過程。

4.2.5 管理OLR
OLR是11gR2引入的,它只存儲與當前節點有關的配置信息,可以用ocrconfig命令來查看其信息:

/opt/11.2.0/grid/bin/ocrcheck -local

很多管理ocr的ocrconfig命令可以在添加-local的選項下來對olr進行管理,如前面的-showbackup、-manualbackup等。

4.3 管理Voting Disk
從11gR2開始,無需對Voting Disk進行手工的備份,只要對集羣的結構做了任何更改,Voting Disk會被自動備份到OCR中,如果添加了新的Voting Disk,那麼Oracle會自動將以前備份的Voting Disk數據恢復到新添加的Voting Disk中。與OCR不同的是,Voting Disk的管理需要使用crsctl命令,下面的命令用來查詢Voting Disk的有關信息:

/opt/11.2.0/grid/bin/crsctl query css votedisk

例如:

[grid@node1 ~]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   1ed6e4e28dc94fb2bf991a1ff18b818f (ORCL:DATAVG) [DATA]
Located 1 voting disk(s).

當Voting Disk在ASM上的時候,不可以使用crsctl add/delete css votedisk命令,唯一可做的操作是可以將Voting Disk搬遷到其他的磁盤組上,不過這樣的操作看來也沒太多的用武之地,除非想要將其搬遷到冗餘度更高的磁盤組上:

/opt/11.2.0/grid/bin/crsctl replace css votedisk +asm_test

4.4 ASM維護
從11gR2開始,Oracle不再支持在dbca建庫的時候選擇裸設備,因此共享存儲部分主要的選擇就剩下了ASM,這裏也只對ASM的管理進行簡單的說明。
在Oracle 11g RAC中,Oracle將ASM集成於GI軟件中,現在的Voting Disk與OCR可以放置於ASM上了,這省去了爲他們單獨創建並管理一些裸設備的麻煩,在GI安裝好後ASM實例就創建好並已經啓來了,因爲CRS要用到OCR和Voting Disk,如果ASM沒有啓來,CRS就無法讀取它們的信息,當然ASM實例創建和ASM磁盤組管理都可以使用圖形界面asmca來完成,因此下面這兩部分主要以命令爲主。

4.4.1 ASM實例創建
要想使用ASM,首要的工作就是創建ASM實例,既然是與數據庫實例類似的實例,那麼首先就需要有一個參數文件,只不過,ASM實例只需要關注少量的參數,與數據庫的實例相比,比較特別的參數如下表所示:
在這裏插入圖片描述
srvctl工具可以用來操作ASM實例,這與以往版本是一樣的:srvctl status asm、srvctl start asm與srvctl stop asm,當然具體語法可以使用類似srvctl status asm –h來得到。

4.4.2 磁盤組的創建與刪除
我們想要使用ASM,就必須先創建ASM DG(Disk Group),創建磁盤組的時候可以指定冗餘策略,分別爲:External外部冗餘(依靠磁盤RAID),Normal爲鏡像冗餘,而最高級的High則包含了總共三份冗餘。創建DG的方法很簡單,切換至grid用戶,使用sqlplus命令來登錄ASM實例:sqlplus ‘/as sysasm’,然後輸入如下創建DG的語句:
以grid用戶sqlplus / as sysasm登錄asm實例,然後執行語句:
create diskgroup data_bak external redundancy disk ‘ORCL:TESTVG’,‘ORCL:TESTVG2’;
很像創建表空間的語法,注意ASM DISK的書寫,可以查詢v$asm_disk.path字段來得到這些ASM DISK的正確路徑。在create diskgroup語句完成後,DG將在當前操作的ASM實例中自動掛載,且添加到ASM實例的asm_diskgroups參數中。其他實例需要手工mount一下:

sqlplus / sysasm
alter diskgroup data_bak mount;

刪除DG的語句更加簡單:

drop diskgroup asm_test;

前提是DG中沒有任何內容,否則需要使用如下語句來刪除:

drop diskgroup asm_test including contents;

通過以下語句可以查看asm中是否存在該diskgroup:

SQL> select name from v$asm_diskgroup;

NAME
------------------------------
DATA
DATA_BAK

4.4.3 磁盤組的掛載與卸載
DG只有在當前節點的ASM實例上掛載,才能被該節點的數據庫實例訪問:

alter diskgroup asm_test mount;

想要dismount一個DG也很簡單:

alter diskgroup asm_test dismount;

如果該磁盤組正在被使用,那麼可以在語句最後面添加force子句,強制卸載。
可以通過以下語句來查詢diskgroup的狀態:

SQL>  select name,STATE from  v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
DATA                           MOUNTED
DATA_BAK                       MOUNTED

4.4.4 磁盤的添加與刪除
從DG中刪除磁盤的操作:

ALTER DISKGROUP dgroupA drop DISK '/devices/Disk1’;

添加磁盤:

ALTER DISKGROUP dgroupA ADD DISK '/devices/D*';

無論是添加磁盤還是刪除磁盤,都會觸發磁盤組的重平衡,爲了減少重平衡的影響,應將刪除或者添加磁盤操作一次性完成。還有值得一提的是:在刪除磁盤的時候因爲需要將刪除磁盤上的內容重平衡至其他磁盤,因此刪除操作要比較長的時間,在期間可以用如下命令取消刪除磁盤的操作:

alter diskgroup asm_test undrop disks;

但如果刪除時加上了force關鍵字,那麼這個刪除操作就不可逆了。
可以通過以下語句來查看某磁盤是否還存在,以及它們的狀態:

SQL>  select GROUP_NUMBER,DISK_NUMBER,MOUNT_STATUS,NAME,PATH from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MOUNT_S NAME                 PATH
------------ ----------- ------- -------------------- --------------------
           1           0 CACHED  DATAVG               ORCL:DATAVG
           2           0 CACHED  TESTVG               ORCL:TESTVG

4.4.5 磁盤組信息的查詢
比較常用的幾個Vv視圖:vasm_diskgroup、vasmdiskvasm_disk、vasm_client,還有兩個查詢性能統計信息的視圖:vasmdiskstatvasm_disk_stat、vasm_diskgroup_stat。

4.4.6 磁盤組的重平衡
除了通過ASM的初始化參數asm_power_limit參數來調節重平衡外,也可以使用如下語句來觸發重平衡:
alter diskgroup asm_test rebalance power 11 wait;
其中power子句後的數字指定了重平衡的力度,與參數一樣,取值範圍0~11,但如果這裏的值大於asm_power_limit參數,那麼這裏的指定不起任何作用;最後面的wait子句代表這個命令等待重平衡結束後再返回,如果沒有wait,那麼該命令立刻返回,當然重平衡操作會在後臺繼續。

4.4.7 ASM工具
下面兩個工具,asmcmd在10g就出現了,asmca是11g才新加入ASM家族的實用工具。

  1. asmca
    asmca是從11g引入一個圖形工具,它的使用在前面安裝部分已經有較爲詳細的描述,它可以用來進行ASM相關的絕大部分管理操作,非常方便,有一點需要注意:從11g開始,dbca不再支持創建和配置ASM磁盤組,打開dbca界面後不要傻眼就是。
  2. asmcmd
    10gR2的時候,asmcmd包含了一些UNIX風格的命令,比如ls、du、cd等等,但當時這些命令基本上還處於中看不中用的狀態,11g後,Oracle加入了非常多的新命令,甚至可以在asmcmd下來管理ASM實例和磁盤組,可以完成前面ASM磁盤組管理中介紹的所有管理操作!asmcmd又提供了非常詳盡的命令幫助頁,在以後的工作中可以慢慢去體會。

4.5 數據庫維護
4.5.1 參數維護
在RAC環境中,Oracle建議使用共享的spfile,在默認的安裝下就是如此,而在每個節點oracle用戶的$ORACLE_HOME/dbs目錄下有一個pfile:init ${ORACLE_SID}.ora,裏面有一行參數指定了spfile的所在,比如:
SPFILE=’+ASM_DATA/racdb/spfileracdb.ora’
在這個二進制spfile中,包含了數據庫的非默認初始化參數,參數的格式爲:
<instance_name>.<parameter_name>=<parameter_value>
如果在instance_name部分使用了“*”或者沒有取值,那麼意味着這個參數對於所有的實例都是有效的。

與單實例數據庫一樣,還是可以使用alter system set … 命令來修改參數的值,但是語法卻有所不同,這個命令的完整語法爲:
alter system set <parameter_name> = <parameter_value> scope = <memory|spfile|both> comment = <’comments’> deferred sid = <sid|*>
其中:

Scope=memory 表明這些改變會在實例重啓後丟失,如果某參數只能針對本地實例進行修改,那麼這個選項就將使命令報錯;
Scope=spfile 表明只在spfile中進行參數的修改,實例重啓後生效,如果實例不是使用spfile,而是pfile啓動的,那麼這個選項也會使得命令報錯;
Scope=both 表明所做的參數改動在當前環境有效,且在實例啓動後依然有效;
Comment 沒什麼好說的,註釋而已;
Deferred 表明所做的參數修改僅對發出該命令後生成的會話有效;
Sid 使用sid子句允許指定實例名稱,使得指定的實例受參數修改的影響,如果使用“*”,那麼就針對所有實例進行修改,這是默認取值。

4.5.2 啓動和停止實例
Srvctl工具非常強大,在後面將介紹其更多的功能,其中一個簡單的應用就是啓停RAC數據庫。我們可以使用下面兩條簡單的命令分別來啓動、關閉數據庫:

srvctl start database -d racdb
srvctl stop database -d racdb -o immediate

這兩條命令將對RAC數據庫中的所有實例生效,其中stop database時的immediate,與sqlplus中shutdown命令的immediate含義一樣,且srvctl命令也支持其他幾個諸如normal、transactional、abort等參數,下面的stop instance命令中-o選項所跟的參數也是一樣的道理——與10g的時候一樣,也可以使用srvctl命令來啓停RAC中的單個實例:

srvctl start instance -d racdb -n racdb1
srvctl stop instance -d racdb -n racdb1 -o immedaite

單實例數據庫一樣,也可以使用sqlplus中的starup與shutdown命令來啓停數據庫,確切地講,是啓停當前登錄的實例,它們的用法與單實例數據庫是相同的。

4.5.3 管理UNDO
在RAC數據庫中,表空間的管理基本與單實例數據庫是一樣的,也有但有一個例外:UNDO表空間,在RAC中,每個實例都需要一個自己的UNDO表空間,可以查看初始化參數UNDO_TABLESPACE來了解當前實例所使用的UNDO表空間。
說到UNDO,還是提下單實例數據庫中就存在的一個管理操作,就是替換實例的當前UNDO表空間,先創建一個UNDO表空間:

create undo tablespace undo_test datafile size 10m;

再來使用參數切換UNDO表空間:

alter system set undo_tablespace='UNDO_TEST';

測試了下這個參數的更改有點特別,不能指定sid,且只在當前實例生效。

4.5.4 管理redo log
與單實例數據庫不同的是,RAC數據庫中,每個實例都有自己的online redo log,自然也有單獨的log buffer、單獨的歸檔日誌文件。每個數據庫實例的redo log稱爲一個線程,這在v$log、v $archived_log等重要視圖中都可得到。

4.5.5 在線日誌
日常做的最多的與online redo log相關的管理操作就是添加刪除日誌了,其實大多時候還是與單實例是一樣的,簡單的使用如下命令就爲當前實例添加一組在線日誌:

alter database add logfile group 5 size 10m;

如果想爲其他的實例添加日誌文件,那麼就需要制定實例名:

alter database add logfile instance 'racdb2' group 6 size 10m;

或者

alter database add logfile thread 1 group 6 size 10m;

而刪除與單實例相同,只要指定group#即可,無需指定實例名。

4.5.6 歸檔日誌
修改RAC數據庫爲歸檔模式或者關閉歸檔模式的方法也很簡單:關閉所有實例,將其中一個實例打開到mount狀態,執行如下語句:

alter database archivelog;

語句是與單實例時代是一樣的,之後打開所有實例即可。
歸檔日誌的存放可以各實例分離,但是要注意的是,數據庫的備份與恢復是在一個實例完成的,因此必須實現歸檔在各個實例間的共享問題,online redo log也一樣,平常正常工作時各個實例對自己的online redo log進行寫入,但是在實例恢復時,可能需要讀取其他實例的online redo log,因此也需要實現共享。
值得一提的單實例不同的切換日誌的命令在RAC中也與單實例有所不同,alter system switch logfile; 命令只能在當前實例進行日誌切換,想要在所有實例進行日誌切換就需要變通地執行命令:

alter system archive log current; 

當然單實例數據庫也有這個命令。使用這個命令還可以對指定實例進行日誌切換:

alter system archive log instance 'racdb2' current;

最後提一下與日誌相關的發出檢查點操作的命令,在RAC數據庫中也有所不同,以前的alter system checkpoint與alter system checkpoint global; 命令是等價的,將在所有數據庫實例中觸發檢查點操作,若是想要在當前實例觸發檢查點,那麼需要對命令稍作修改:

alter system checkpoint local;

4.5.7 管理服務
服務用來在Oracle RAC環境中來管理工作量,它提供了一種對工作量進行分組的邏輯方法,將採用相同數據集、相同功能以及相同服務級需求的用戶分組在一起,因此服務也經常被用來將不同的用戶分組的連接“引導”到不同的RAC實例上,從而減少RAC數據庫環境中集羣方面的相關等待。
早期的版本中可以使用dbca來管理服務,那也是最方便快捷的添加服務的方法,但是在11gR2中,dbca關於服務的這個選項已經被去除了,還可以通過em來進行配置,但Oracle推薦使用上面介紹的srvctl命令來對服務進行管理。
用oracle用戶登錄,使用如下命令來爲racdb數據庫創建一個服務ssfxdw,將racdb1定義爲首選實例,將racdb2定義爲次選實例,且創建basic TAF策略,將服務配置爲自動啓動:

srvctl add service -d racdb -s ssfxdw -P BASIC -y AUTOMATIC -r racdb1 -a racdb2

動上面創建的服務:

srvctl start service -d racdb -s ssfxdw

關閉服務:

srvctl stop service -d racdb -s ssfxdw

4.5.8 備份與恢復

  1. 備份
    1) 操作系統的冷備:在關閉數據庫的情況下,在文件級別對數據庫的數據文件、控制文件、歸檔日誌、在線日誌、參數文件。
    2) 使用rman工具對數據庫備份和恢復,這裏主要要了解全庫備份、兩種增量備份方式(差異增量備份和累積增量備份)
  2. 恢復
    1) 不完全恢復
    2) 完全恢復
    Oracle RAC的備份與恢復與單實例數據庫其實相差不大,有幾點需要注意:

RAC數據庫的實例恢復與崩潰恢復是不一樣的概念,雖然兩者都只需要讀取online redo log,但是實例恢復是指正常實例利用異常終止實例的online redo log,對該實例中被修改但未寫入數據文件的數據塊進行恢復,所以,RAC數據庫的哦你online redo log必須共享;而崩潰恢復是指RAC數據庫中的所有實例都出現故障,需要使用online redo log進行恢復;

RAC數據庫的介質恢復與單實例基本相同,但是在RAC數據庫恢復過程中,需要讀取所有實例的歸檔日誌,所以它們的歸檔日誌也必須是共享的。
查看附錄中備份與恢復的實例進一步地瞭解。

4.5.9 查看監聽
查看監聽狀態:

lsnrctl status

啓動監聽:

lsnrctl start

關閉監聽:

lsnrctl stop

4.6 告警日誌查看
一般系統出現問題,在我們查看過操作系的CPU、內存、磁盤IO後,往往只瞭解這些信息是不夠的,我們還得從集羣軟件、ASM、數據庫層去查找問題的所在,首先肯定要查看的各個層面的告警日誌,那麼這日誌文件是放在哪裏的呢?

  1. 集羣軟件日誌
    Oracle的集羣軟件Clusterware不像數據庫有很多的視圖或者工具來幫助診斷,它的日誌和trace文件是唯一的選擇,它主要的日誌文件目錄結構如下:
    日誌的根目錄CRS的安裝目錄,也就是grid用戶的 $ ORACLE_HOME(在10g中會設置成$ CRS_HOME)/log/[node],其中node是節點的名稱。
    alertnode1.log:其中node1是結點的名稱,這個日誌相當於數據庫的alert.log,一般應該作爲檢查的起點;
    crsd、cssd、evmd:分別是3個目錄,分別對應着Clusterware三個同名的進程的日誌,日誌的名字和進程名字一致,分別叫crsd.log、ocssd.log、evmd.log;
    racg:這個目錄裏放置的是所有nodeapp的日誌,包括ONS、VIP,每個日誌從名字上就很容易辨別所對的nodeapp;
    client:這個目錄裏放置的是工具執行日誌,比如ocrcheck、ocrconfig等,這些工具運行時產生的日誌就會放在這個目錄下。
  2. ASM日誌
    這裏只需要掌握一下ASM的告警日誌存放路徑就行了,如果ASM實例啓不來,我們就可以去查看一下這個日誌文件,它在grid用戶的$ORACLE_BASE/diag/asm/+ASM/+ASM1/trace目錄下,以.log結尾的那個文件就是了,其中+ASM1是ASM實例的名稱,一般情況下,第一個節點就是+ASM1,第二個節點就是+ASM2,以此類推。例如:
/oracle/app/oracle/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log
  1. 數據庫日誌
    數據庫的告警日誌文件存放的路徑默認是在oracle用戶的$ORACLE_BASE/diag/rdbms/數據庫名/實例名/trace目錄下,以.log結尾的文件就是了,例如:
/oracle/app/oracle/diag/rdbms/orcl/orcl1/trace/alert_orcl1.log
  1. 監聽日誌
    監聽日誌文件是$ORACLE_BASE/diag/tnslsnr/node1/listener/alert/log.xml,其中node1是節點名,也可以從lsnrctl status中Listener Log File後面內容看出來。
發佈了61 篇原創文章 · 獲贊 92 · 訪問量 1萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章