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）的架構與特性。
2009年5月20日 星期三
2009年5月11日 星期一
效能調教概論 (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 牽涉的範圍太廣，將再擇期討論。
廣義上來講，效能問題指的是系統回應（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 牽涉的範圍太廣，將再擇期討論。
2009年5月8日 星期五
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 的最上端。
通常使用 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='
2) ORACLE_SID=demo2;export ORACLE_SID
PS1='
3) ORACLE_SID=demo3;export ORACLE_SID
PS1='
*) unset ORACLE_SID
PS1='
esac
=================================================
當使用者登入時，會有 1、2、3 與 any key 四種選項，當選擇 1 或 2 或 3 時，即會載入該選項下的環境變數，並在 command line 顯示目前所在環境名稱與工作路徑。當選擇其他非 1、2、3 的選項時，則會使用 *) 選項下的環境變數。
若某些環境變數適合應用於所有的選項，則可直接置於 profile 的最上端。
訂閱：
文章 (Atom)