淺談 Grid Computing & Oracle RAC - 2

Oracle RAC（Real Application Clusters）允許應用程式在不做改變的情況下來進行 clustered servers 上 Database 的存取。這樣的架構提供了高度的可用性（Highest Availability）及最大的擴充彈性（flexible scalability）。倘若有任何的一台 clustered server 故障，Database 仍可在剩餘的 clustered server上運作。當使用者需要更多運算能力，亦可在不要求使用者離線的情況下增加另一台 server 來滿足需求。

RAC 為企業網格運算架構（Enterprise Grid Computing Architecture）提供了一個基礎。在這個基礎上，RAC 使用低成本的硬體規格來提供優質的服務品質以及高度的可用性與擴充性。在以往，同樣的服務等級得由搭載多顆處理器（SMP）的昂貴大型主機才能夠達成。

RAC 架構
RAC 資料庫其實就是一種叢集資料庫（clustered database）。而所謂的叢集就是讓一群獨立的主機互相合作，如同單一系統般的運作。叢集除了能提升容錯性外，也比 SMP 架構更有效率的因應漸進式的系統成長需求。當系統錯誤發生時，叢集能夠維持系統的可用性，確保關鍵資料不會因此流失。下圖為 RAC 的架構：

透過 RAC，我們可以分離（de-couple） Oracle Instance（泛指 Server 上執行的 process 與 memory 結構）與 Oracle Database（真正儲存資料的部份，一般是指 datafile）一對一的關連性。叢集資料庫允許多個 instance 去存取單一的 database。每一個 instance 是在叢集內的獨立 server 上執行。當系統需要額外的資源時，便可在不用中斷系統的情況下，輕易將 instance 加入叢集。一但新的 instance 加入並啟動後，應用程式不需要做任何的變動或設定，就可使用其帶來的效益。

Oralce Clusterware
Clusterware（叢集軟體）是負責監控與管理 RAC 資料庫。當叢集內有任何一台主機啟動，所有其它的 instances、listeners 與相關 services 也會被一併自動啟動。當任何一個 instance 發生錯誤時，clusterware 會自主性的去重新啟動該 instance。因此往往能在管理者發現錯誤前就修復。另外在 10gR2 版本，Oracle 也提供一個非 Oacle processes 也能使用的 HA（High availability）API。當該 process 向 clusterware 完成註冊程序，並且提供如何去啟動、停止與監控的資訊後，就能夠使用 HA 架構所帶來的優勢。

Hardware Architecture
RAC 是建立在共享的架構上。叢集內所有的 servers 必須共享儲存媒體上的 RAC database。這些共享的儲存空間通常是採用 NAS、SAN 或 SCSI 來建置。選擇儲存媒體的重點在於，是否能如同將 server 加入叢集般，隨著應用程式 I/O 需求來擴充儲存媒體。
叢集使用 LAN 來提供應用程式與 database server 間的連線，也需要使用私有網路（private network）來進行各個節點（node）間的互連（interconnect）。Oracle 官方建議使用兩組網路卡來建置，以達到 HA 的效果。對外提供與 AP 連線的網路，同時具備 failover（錯誤後轉移）與 load balancing（負載平衡）的功能。而對內互連的網路，除用於內部各節點間訊息的傳遞外，並被 RAC 使用作為 cache fusion（快取融合）的傳輸媒介。Oracle 建議在 Gigabit Ethernet 上使用 UDP 的方式建立 interconnect，另外，RAC 不支援使用 crossover cable 來作為 interconnect。
Oracle 10gR2 RAC 叢集最多可支援到 100 節點，叢集內 server 的規格並不需要完全一致，但必須使用相同的作業系統以及相同版本的 Oracle。

File Systems 與 Volume Management
由於 RAC 是建立在一種分享的架構下，因此 volume management 與 file system 也必須是 cluster-aware（支援叢集）。Oracle 建議在 10g 的版本下使用 ASM（Automatic Storage Management）自動儲存管理。ASM 除了能在 file system 上管理非同步 I/O 外，更重要的是，它能分散 I/O 負載至所有可用的硬體資源上來達到最佳化的效能並減少人為的 I/O 調教。
另一個替代方式是採用 raw device 與叢集檔案系統（cluster file systems），例如：Oracle Cluster File System（OCFS），目前此檔案系統支援 Windows 與 Linux 作業平台。

Virtual Internet Protocol Address（VIP）
為叢集內的每一台 server 綁定 Virtual IP（虛擬 IP）是建置 10g RAC 的另一項必要條件。Virtual IP 是指在同一個 LAN 上沒有被使用的 IP，僅被 AP 使用來連線至 RAC database。當任何一個節點發生錯誤時，該點的 Virtual IP 會自動被移轉到叢集的另一個節點上，並繼續提供 AP 服務。這機制大幅的提升 AP 的可用性，不必再等待到錯誤發生並網路中斷，就可以在第一時間直接連線到其他節點。


Oracle RAC 的效益：
RAC 帶來的效益可分為以下兩個層面：High Availability（高度可用性）與 Scalability（擴充性）。

High Availability 主要是透過以下特性來提供：
# Reliability（可靠性）－ Oracle database 原本就是以可靠而聞名；透過 RAC 機制來避免 single point of failuer（單點故障）更使其可靠性往前跨出一大步。舉例來說，當其中一個 instance 發生錯誤時，叢集內其它的 instance 仍可維持正常的運作狀況並提供服務。

# Recoverability（可回復性）－ 當 RAC database 中有任何一個 instance 發生故障時，叢集中的其它 instance 會將其指認出，並開始自動回復。

# Error Detection（錯誤偵測）－ Oracle 叢集軟體自動監看環境中的 RAC database 並提供快速問題偵測。另外，它更能在問題被通知至管理者之前就將其回復。

# Continuous Operations（持續運行）－ RAC 架構能提供持續系統運作來面對計畫性與突發性的中斷。當任何一個節點故障時，database 仍然維持正常運作來服務 AP 的資料存取。大部分的資料庫維護作業能循序的進行（rolling fashion），並在不影響使用者的情況下完成。


Scalability
Oracle RAC 提供了一種相當獨特的系統擴充性。傳統上，當 database server 負載能力不足時，往往是採購更高規的 server 來取代。而更高規的 server 也代表著更昂貴的價格。RAC 則是採用另一種替代方式增加負載能力。與其把系統建置在一台高規格的 SMP server 上，不如將其移轉到由中低階 servers 組成的叢集上。這樣的好處在於既有的硬體投資不會被浪費掉，又可透過增加新的 server 至叢集內來增加負載能力。叢集內所的有 server 必須是相同的 OS（Operation System）與相同版本的 Oracle，但負載能力／硬體規格則不需要相同。

Oracle RAC 架構能夠快速改變系統 workload（工作負荷）來因應市場上的瞬息萬變。例如透過指定 service name 的方法來讓 AP 與 database 連線，RAC 便能平衡叢集內的各節點系統負載。RAC 也允許透過指定的方法，來分配特定 AP 連線至特定 database 節點的方法。這些機制讓管理者能夠無痛處理 AP 需求增加帶來的額外負載。

Parallel Execution（平行處理）是 RAC 提供的另一種分散負載的方法。Parallel execution 是將 sql statement 的處理切割成多個程序（process）。在 RAC 的環境下，這些程序可以被分散到多個 instnace 上來進行處理，並且可依據各節點上運算資源的忙碌／閒置狀況來決定程序的分配。例如說，一個需要 6 個 processes 才能夠處理的 transaction 產生時，RAC 會先查看本機節點（local node）是否有 6 個閒置的 CPUs，若有的話，則只會使用本機資源（local resources），來避免跨節點運算帶來的額外負擔；這種動作通常被稱為 intra-node parallelism。倘若本機節點只有 2 個 CPUs 閑置的話，則這 2 個 CPUs 與另一個節點上閒置的 4 個 CPUs 會被使用來作為運算資源；這種分散運算到不同 nodes 的作法就是所謂的 inter-node parallelism。但不管是 intra-node 還是 inter-node parallelism，主要都是著眼在提升系統效能。

perl to exe

基於商業上的需求，有時必須將 perl 轉換成 exe 檔來進行程式的部署。通常較常使用 IndigoSTAR 的 Perl2Exe 工具。其轉換指令相當直覺，如下：

# perl2exe XXX.pl

便可產生名為 XXX.exe 的可執行檔。

然而，根據經驗，有時候會發生某些程式在 perl 下可正常執行，但一但轉換成 exe 後，執行就會出現錯誤。

因此，筆者後來改而使用 ActiveStats Perl Dev Kit (PDK) 來進行 perl to exe 的轉換。目前 PDK 8.0 已經可以支援 ActivePerl 5.8 & ActivePerl 5.10。轉換的語法如下：

# perlapp --norunlib --exe XXX.exe XXX.pl


* 在沒有註冊 PDK 的情況下，轉換出的 exe 只能使用 21 天。

淺談 Grid Computing & Oracle RAC - 1

RAC（Real Application Clusters）是 Oracle 能夠穩站資料庫市場寶座的一項重要創新，同時也是實現 Grid Computing（網格運算）的重要的里程碑。

Enterprise Grid Computing 主要是在 IT 架構下，提供一個更靈活（flexible）、更具彈性（resilient）與低成本（low cost）的企業 IT 資源運用。採用 Grid 將有助於 IT 去反應當前快速變化與不可預測的市場景氣狀況，並在管理成本、營運彈性與服務水準上取得最大的優勢。

那到底什麼是 Grid Computing 呢？簡單的說，就是虛擬化與聯合化 IT 資源（EX:運算能力、儲存空間和網路傳輸等...）成為一個單一的 shared services，隨後並能根據不同的資源需求程度來進行分配或調整。

實際上，Utility Computing（公用運算）也正是使用 Grid Computing 的架構來提供運算委外服務。而在 2008 年開始即被熱烈討論的 Cloud Computing（雲端運算）亦是基於 Grid Computing 的架構下，協助企業透過 public / private 網路來更有效率的使用運算資源。

Grid Computing 主要是依據以下原則來建立：
標準化：藉由採購標準化的作業系統、主機、儲存設備、中介軟體與網路設備，來有效的提高軟硬體互通性與降低系統管理負擔。同時也能簡單化應用程式部署、組態與整合程序，進而減少運作上的複雜度。

虛擬化：是將 IT 資源抽象化的一種表現，藉以提高使用上的彈性。虛擬化 IT 資源是指應用系統不需綁定在特定的主機、儲存或網路設備上，就能夠使用任何虛擬的 IT 資源。虛擬化的達成是透過建立一個介於底層 IT 軟硬體資源與前端應用系統的軟體層（software layer），來提供一個簡單與一致的介面。

自動化：由於 Grid computing 的環境涵蓋了大量虛擬與實體的構成要素，因此大規模的自動化是不可獲缺的。每一個構成要素都需要組態管理、隨需應變供應、由上而下監控以及其他管理。這樣的規模與複雜度代表著 Grid 管理方案必須提供高度的自動化，來確保架構上所省下的成本不會被額外的 Grid 管理成本抵消。


而 Grid Computing 可以帶來的效益大概可歸納為以下幾點：
快速反應市場變動需求 － 當前企業身處於一個持續變化的全球競爭環境，如何去預測市場供需、競爭者的威脅、供應鏈風險以及日常需求，已變成管理者的一大挑戰。企業期待 IT 能夠提供「隨機應變」的能力，來協助因應外在環境的快速變化，例如：改變定價模式來因應競爭、調整訂單管理流程來承接臨時急單、整合併購公司等等...。而 Grid 正是能滿足這些需求的 IT 架構。

即時反應系統動態負荷 － 現今的應用系統大多綁定於特定的軟硬上，導致無法根據系統負荷來動態調整。在這種架構下，IT 資源的使用成本不但高而且無法被有效率的運用，因為 IT 部門往往被要求建置優於平均系統需求的硬體，以應付尖峰或偶發巨量的系統負荷。Grid Computing 允許 IT 資源在動態 / 隨需應變的情況下進行調整，反應系統的動態負荷。

可預期的 IT 服務水準 － Grid Computing 的特性可促使 IT 更趨近於企業營運目標。高額的系統管理費用、昂貴的系統整合專案以及難以控制的 IT 預算將能被有效的縮減。另外，Grid 的架構能夠避免單點故障以及提供強大的高度可用性（High Availability）來保護珍貴的資訊資產並確保企業持續營運。

透過高效率與產能規劃來降低成本 － Grid Computing 的主要運用目標在於提高運作效能與可預測性。這些特性能夠減少運算資源過度供給（Overprovision）的現象。同時，由於資源能在被需要時才循序的增加，因此也更容易滿足使用者在運算資源與空間使用率上的要求。IT 部門也能夠採取更具成本效益的採購策略，避免在實際需求發生前就購買昂貴的硬體與軟體授權。


接下來我們將探討 Oracle 在 Grid Computing 上的代表作，RAC（Real Application Clusters）的架構與特性。

效能調教概論 (Performance Tuning Overview)

無庸置疑的，效能問題（Performance issue）一直是大部分 DBA 心中揮之不去的夢靨。遺憾的是，這夢靨是沒有終止的一天，能做的只是儘量去減少發生的頻率與程度以及持續的時間。

廣義上來講，效能問題指的是系統回應（response time）時間過長或資料吞吐量（throughput）過低。而效能調教（performance tuning）便是找出造成效能問題的瓶頸（bottleneck）並採取適當的調整來減低或消除因瓶頸所造成的影響。

效能調教主要可分為 Instance Tuning 與 SQL Tuning 兩大方向，但在實際進行調整前，若能先擬定一份效能規劃(Performance Planning)，將可更精準化效能調教帶來的實際效益。

效能規劃包含了"效能設計開發"以及"效能改善方法"。最佳的效能設計開始於系統初始階段並持續在整個系統的生命週期。因此，在系統設計階段若能將效能問題納入規劃，將有助於系統上線後的效能調教。

然而，根據筆者的經驗，絕大多數的系統在設計開發階段，礙於成本考量、時間壓力或技術門檻，往往不會將效能問題納入考量。而且在系統上線初期，資料的累積並不多或功能需求單純，因此也不一定會有效能上的問題。然而當系統運行一段時間，資料累積至某一數量後，效能問題就開始被彰顯出來。

找出使用者認知上的系統預期效能並給予一個明確的定義是執行效能改善方法的前提。典型的使用者反應效能問題範例，大概如下：
# 系統效能太差了，我們都沒辦法做事了
# 這個帳務系統跑太久了
# 系統回應太慢，客戶已經不耐煩了
# 系統要越快越好

將這些使用者的回饋轉化成符合實際的目標，將是影響效能調教是否成功的關鍵，例如：
# 月初的結帳必須在 3 個小時內完成
# 客戶資料查詢結果須在 20 秒內產生
# 網頁的更新時間不得超過 5 秒

當與使用者達成確切調整目標的共識後，就可以開始執行改善方法。然而，面對著複雜及差異化的系統，如何快速準確的找出效能瓶頸也是對 DBA 的一大挑戰。以下為 Oracle 官方建議的步驟：
1. 執行下列幾項標準檢查：
　1.1 取得使用者的回饋，決定調整的範圍與目標
　1.2 蒐集系統、資料庫及應用程式在正常與異常情況下的效能數據
　1.3 對整個系統進行一次健全性檢查（sanity-check），特別是系統資源使用率與硬體狀態診斷部分
2. 檢查 10 大資料庫最常見的錯誤，找出症狀（symptom）並分析蒐集到的資料。
3. 以症狀為依據，建立一個概念模型（Conceptual Model），幫助了解導致效能問題的原因。
4. 提出解決方案並進行實際調整。這其中最重要的準則就是：同一時間內只進行一個項目的調整並衡量所造成的效果。
5. 確認調整是否有效並滿足使用者預期。若效果不彰，嘗試找出其他的瓶頸，並持續修正概念模型。
6. 持續 3~5 這三個步驟，直到達成預期效能調整目標。

若是突發性的效能問題，處理方法也會有所差異，但主要是根據以下的步驟來處理：
1. 詢問使用者或管理者「是否有對系統進行任何的變動」？來取得線索。但有時候得到的回答並無法協助釐清問題，此時，DBA 應該試著蒐集檢查發生前與發生後的統計資料或 log 檔。
2. 針對硬體進行健全性檢查，觀察 CPU 使用率，檢查磁碟、記憶體和網路效能。
3. 判斷效能問題是由 CPU 使用率或是 wait events 引起。
4. 採取緊急措施來穩定系統。例如將非核心應用程式設定離線或限制系統資源的使用。這些動作也包括了重新啟動系統或是中斷某些正在執行的程序。
5. 確認系統是否趨穩並採用前面所提到的一般效能調整方法來進行處理。

由於 Instance Tuning 與 SQL Tuning 牽涉的範圍太廣，將再擇期討論。

profile with multiple choice

有時候基於硬體資源上的限制，必須在同一台主機上使用同一帳號來建立不同的環境，以區隔出不同的需求。最常見的例子就是使用 oracle 帳號來建立兩個 / 多個不同的 database，例如 demo1 與 demo2。

通常使用 oracle 帳號登入系統時，只能載入一個預設的 ORACLE_SID 以及其他相對應的環境變數。如需要切換至另一個 database 時，則需另外執行 export ORACLE_SID=demo2 來改變環境變數。

倘若同一機器上有多個環境時，以上的作法不僅增加使用者的負擔，也容易混淆當前的設定。因此，建議的作法是在登入時，在 .profile / .bash_profile 設定登入環境選項，讓使用者可自由選擇所需的作業環境。

以下是 .profile 的簡單範例：
=================================================
echo "請選擇 1) 正式區 ( ORACLE_SID=demo1 ) "
echo " 2) HR區 ( ORACLE_SID=demo2 ) "
echo " 3) 測試區 ( ORACLE_SID=demo3 ) "
echo " *) nothing "
read ans;
case $ans in
1) ORACLE_SID=demo1;export ORACLE_SID
PS1='';export PS1;;
2) ORACLE_SID=demo2;export ORACLE_SID
PS1='';export PS1;;
3) ORACLE_SID=demo3;export ORACLE_SID
PS1='';export PS1;;
*) unset ORACLE_SID
PS1='';export PS1;;
esac
=================================================

當使用者登入時，會有 1、2、3 與 any key 四種選項，當選擇 1 或 2 或 3 時，即會載入該選項下的環境變數，並在 command line 顯示目前所在環境名稱與工作路徑。當選擇其他非 1、2、3 的選項時，則會使用 *) 選項下的環境變數。

若某些環境變數適合應用於所有的選項，則可直接置於 profile 的最上端。

Windows 下刪除 archived log files

Archived log files 是當資料庫災難發生時，確保資料完整性不可獲缺的要素之一。然而，也因為 archived log files 會伴隨著 redo log switch 持續產生的特性，變成磁碟空間管理上需特別注意的問題。

一般而言，當透過 rman 執行 full/incremental backup 時，就會一併將備份完成的全部或是某一特定時間前的 archived log files 刪除。這同時也是比較建議的作法。

倘若使用 cold backup 搭配 third party 備份軟體時，archived log files 或許就需採用手動（系統排程）的方式來刪除。在 Unix-based 平台下，只需透過 find 指令搭配 ctime 或 mtime 參數便可達成。但是同樣的動作在 Windows 下，使用 VB Script 亦可大幅簡化執行的步驟。以下便列出執行的步驟：

Step 1：將虛線區塊內的 VB Script 存檔為 arch_del.vbs
=================================================
Const WhatchFolder = "C:\temp"
Const MaxDays = 30
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder(WhatchFolder)
Set colFiles = objFolder.Files
For Each objFile in colFiles
If DateDiff("d",objFile.DateCreated,now) >= MaxDays Then
objFSO.DeleteFile(objFile.Path)
End If
Next
=================================================
WhatchFolder 代表存放 archived log files 的路徑。
MaxDays 代表保存天數，若大於此數值的檔案即刪除。

Step 2：在 windows command 模式下執行 wscript arch_del.vbs ，測試 c:\temp 目錄下建立時間超過 30 天的檔案是否已被刪除。

Step 3：將該指令列入系統排程，每日便可自動刪除 archived log files。

淺談 Oracle Data Guard

Business continuity（營運持續）和 disaster recovery（災難復原）是大部分企業高階管理者的優先考量。伴隨著日趨複雜的經濟環境、急遽變動的市場潮流以及高度的競爭壓力，一個有運作效率並且能迅速反應不可預期中斷的 7*24 營運環境已經變成組織內不可獲缺的一環。

Oracle Data Guard 正是其中一個最有效率的解決方案。它提供一個保護企業核心資產，資料，的架構來維持 7*24 運作，以及任何可能的災難或系統中斷。

一般而言，影響企業運作的 downtime（停機時間）可分為 unplanned（非預期中）與 planned（預期中）兩種。Unplanned downtime 是指因硬體或系統故障、儲存裝備故障、人為疏失、電腦病毒、軟體技術故障及自然災害等等。Planned downtime 的發生通常是為了執行某些既定計畫，像是系統或硬體升級。

什麼是 Oracle Data Guard：
Data Guard 透過建置 standby database 來維持與 production database 資料一致。Standby database 可建置在任何可透過網路連線的營運據點。倘若 production database 因任何 planned 或 unplanned 的故障而無法使用時，Data Guard 即可 switch（切換）任何一台 standby database 來成為 production database 的角色。透過此機制，不僅可以 minimizing downtime（極小化停機時間）並可避免任何的 data loss（資料遺失）。

下圖為 Data Guard 架構：



Data Guard 的功能：
Data Guard 包含一個 production / primary database 以及一個或多少 standby database。Data Guard 使用 redo log 來維持 production 與 standby database 間資料的一致性。當在 production database 上有交易發生時， redo log 會被產生並寫至本機 redo log files上。在 Data Guard 的架構下，這些 redo 資料也會傳輸到 standby 主機，並且被套用至 standby database 上來保持資料與 primary database 一致。Data Guard 允許管理者使用同步或非同步的方式來將 redo 資料傳輸至 standby database 上。

Standby Database 又可被分為 Data Guard Redo Apply（physical standby database）及 Data Guard SQL Apply（logical standby database）。

Physical standby database 是基於 "block-for-block" 基礎下，建置有著和 primary database 完全相同的 database 結構，並使用 Oracle media recovery。

反之 logical standby database 則是一個獨立的 database 但具有跟 primary database 相同的資料。它是使用 SQL statement 來進行資料的異動與更新。其中最大的優勢就是可以同時被用於 recovery 及其它工作，例如報表或查詢。