從DBA到Oracle Applications DBA的轉變過程 (轉)

從DBA到Oracle Applications DBA的轉變過程 
 
釋出時間：2008.08.05 04:44     來源：賽迪網    作者：汽水糖

【賽迪網－IT技術報導】這篇論壇文章（賽迪網技術社群）講述瞭如何從一個普通的Oracle DBA轉變為一個Oracle Applications DBA(Oracle應用程式資料庫管理員)，接著講述一些Oracle應用軟體架構方面的內容 。

從一個“普通”的Oracle DBA(Oracle資料庫管理員)轉變為Oracle Applications DBA(Oracle應用程式資料庫管理員)，有兩個內容你必須去弄清楚。第一個內容是如何成為一個Oracle Applications DBA(Oracle應用程式資料庫管理員)。第二個內容是你要搞清楚Oracle應用程式背後的架構體系，也就是說你要明白諸如以下產品的結構體系：Oracle電子商務套件、Oracle 11i資料庫、Siebel產品等。

如何成為Oracle應用程式資料庫管理員

首先是角色的轉變

Oracle Applications DBA(Oracle應用程式資料庫管理員)對“普通”的Oracle DBA(Oracle資料庫管理員)來說是一個很大的挑戰。拿Oracle EBS DBA(Oracle 電子商務套件DBA)來說，不僅需要了解EBS的各個元件、服務，而且還要更主動和其他相關人員接觸。 一個Oracle Applications DBA(Oracle應用程式資料庫管理員)不僅需要和其他DBA一樣去負責managing、 sizing、maintaining和 tuning database這些日常的資料庫管理的工作，如果他的Apps database是OLTP系統的話，他還需要監察wait和lock 。Oracle E-Business Suite還有一些特性需要DBA去完成，比如從外部資源裡灌資料到Apps database裡，或支援開發人員從已有資料中提取資料。

接著工作內容的轉變

作為一個Oracle Applications DBA(Oracle應用程式資料庫管理員)，要想更好的對Oracle Application database做支援，需要仔細記住以下幾項。

1.網路上沒有什麼比較容易簡單的文件讓你去熟悉Apps DBA,所以我建議去看幫助。

2.在你沒有經過多次測試並且得到客戶認可的時候不要去打補丁，並且你要確信這個補丁解決了現有的問題，而且沒有帶來其它新的問題。

3.記住Oracle Applications會有很多索引，定期rebuild index會對效能有好處，當然做這項工作應該在系統的空閒時間。

4.不要為了提高效能而在沒有詢問oracle Support前試著去增加額外的indexes。如果你一定要去做，那千萬記住要有文件作記錄，因為在這之後你再打patch的時候它可能會把你做的修改自動復原。

5. 知道怎麼樣是正確的打patch，先計劃打哪個patch，然後取得patch，接著打patch，測試，最後文件記錄。

6. 要知道任何時刻資料庫都可能會有一些object 是invalid的，你的一些操作也會增加invalid objects，定期檢查這些invalid objects的數量，然後定期用utlrp去重新編譯，utlrp.squ在ORACLE HOME的rdbms/admin下，需要用SYS執行。在你的DB執行過程中如果碰到錯誤，就可以先重新編譯invalid objects，如果沒有解決問題再去遞交iTAR(Internet created Technical Assistance Request).

7.能看懂日誌。

8.瞭解Apps database的環境，包括作業系統和DB的，當你對你的工作環境瞭如指掌後，一切也就變得容易了，那時，你就是一個悠閒的Apps DBA了。

另外，對於APPS DB(應用程式資料庫)來說，你可能需要建立或複製(克隆)多個生產庫以外的資料庫，比如測試和開發資料庫，當然，需要多少資料庫是由你的商業需求所決定的。開發環境資料庫是供開發人員進行report,PL/SQL等開發的，這個環境可以在開發人員覺得資料已經不再滿足開發需求的時候，當然也可以在這個環境測試補丁(patches)。當然最終使用patch的時候還需要在測試環境做測試，因為測試資料庫是和生產資料庫環境最接近的。(上面說的克隆cloning是一種將applications layer和database layer完全複製的一種方法。)所以，當你擁有這三個資料庫的時候，打patch的步驟是先development database再test database最後才在production database環境應用。

構架應用體系

如果你研究過Oracle Forms，使用過Application Server和Developer Suite來開發、配置部署form和report，並且曾經作為一名Oracle DBA，經歷過許多管理和維護的工作如patching和cloning的話，那麼你就已經能夠掌握了OA 90%的內容。Oracle Apps應該是這樣的應用軟體，高速度、低拖延的ERP應用軟體，使用Oracle所能提供的最好的web和資料庫元件。我說的對嗎?實際上不完全對，在11.5.9的版本里，你能看到應用伺服器最早期的一個版本，並且Oracle的版本還是8.0.6。

EBS環境最簡單配置也包括兩個伺服器，這兩個伺服器也就是我們熟知的兩層：資料庫層，和中間層，也叫應用層。資料庫層就如字面的意思，就是應用程式的後端資料庫。中間層就類似Application Server(應用程式伺服器)。

中間層

在中間層，更確切的說執行在中間層上的還有幾種服務。所有的服務都不相同，有OC4J、report engine、form等。你能看到應用伺服器(Application Server)存在於中間層，另外還有Oracle應用程式具體的伺服器。總的來說，有六種伺服器存在於中間層和應用層，它們是：

• Web 伺服器

• Forms伺服器

• Reports 伺服器

• Discoverer伺服器

• 併發處理伺服器

• Admin伺服器

至於Application Server，上面列舉的其它伺服器和Application Server性質不同的就是併發處理伺服器了。對於併發處理伺服器，我們可以認為它是一個助手的角色，在EBS使用者請求和資料處理過程中協調作業和過程;另外，如現代的Application Server，上面列舉的服務並不是每個都必須在相同的伺服器上。

我們可以類似的認為Oracle Apps配置就是對Forms 和 Reports 服務，以及後端資料庫的配置。在app server 和資料庫之間物理或者邏輯關係是什麼樣的?在Oracle應用程式世界裡，在中間層生成的檔案能夠，有時是需要放到資料庫層。這些檔案大多以文字檔案的形式存在，包括配置資訊。其他檔案是與cloning相關的。

下面的圖示有助於說明每層的主要組成部分。該圖示來自Oracle Applications Concepts Release 11i的圖2-1。如下圖所示：

 

在中間層有許多的“父級”目錄。特別要提到其中的兩個，這個兩個在文件中一次又一次的看到，它們就是APPL_TOP 和COMMON_TOP。

資料庫層

資料庫層又是什麼樣子了?令人驚奇的是，Oracle Apps資料庫檔案格式或許令人難以置信，並不是由於它的複雜性，而恰恰是一點都不復雜。同樣在“父級”結構中，資料庫有四種資料,他們分別是資料、索引、系統和臨時表空間位置。你或許能看到所有的和資料庫檔案相關的資料都放在一個路徑，或者分割槽裡，所有的索引也是在一個路徑下，同樣系統和臨時表空間也是如此。重做日誌能夠放在兩個位置。你或許看到上百的表空間都有一到兩個檔案，你能看到四個表空間模型。

說到重做日誌和一般的重做操作，我們肯定知道的一件事情就是在真實的DBA世界裡，我們希望重做日誌存在快速磁碟中，由於寫入量的緣故。你曾經在磁碟中放置一個控制檔案嗎?如果你沒有看到控制檔案在事務等待過程中並行寫入，那麼看一看Oracle Apps安裝過程，情況就是這樣的。當前文件聲稱或者說分配重做日誌緩衝區大小最好是1MB。Oracle在MetaLink上有一個註釋，推薦Oracle Apps DBA將重做日誌緩衝區設為10MB。

另外一個和一般資料庫不同的地方就是必須要設定初始引數。在初始檔案中設定初始引數還不常見。

在使用Oracle Apps時，你不得不向你的OLTP或者DSS資料庫打補丁的時候，如何保證5個9的可靠性呢，5個9的可靠性意味著每年只有5分鐘的停機時間。好了，雖然說沒有這麼嚴格，但是仍舊有許多測試工作和質量保證工作需要完成。為了更好的服務於終端使用者，你還需要了解些Apps的結構，並且掌握專有名詞的含義，比如雖然你不需要掌握財務模組是如何實現的，但是還是需要知道AR是借，AP是貸，GL是總帳，這樣你在遇到問題的時候就可能及時知道資料是怎麼來的，是那個模組，該找什麼人去溝通。

你如何備份你的資料庫?在EBS中，資料庫備份時非常直接的，中間層元件就有一些複雜了。慶幸的是，Oracle開發了一個叫做Rapid Clone的工具，步驟歸納如下：

• 在每層執行基於perl的指令碼語言(建立一個XML檔案，裡面包含了配置資訊，不過對源系統不影響)

• 將每層的相關部分複製到目標系統

• 執行基於perl語言的config/clone指令碼來重新配置環境或者每層的context檔案。

Application,middle tier,database之間有著複雜的連線，常常某一個地方出了問題卻在其他地方上表現出來(有點象中醫)，或者說在一個地方出的問題，影響到另一個地方，又影響到其他，然後最終影響到整體效能。比如一個FORM. 沒有被正確執行，而你作為一個DBA可能最先發現的是效能的下降，這會讓你很頭疼。另外，在打補丁後，原有的forms 或 reports也可能在執行上與打補丁之前有所不同了。

最後，我要說，你現在接觸和管理的是比你以前複雜的多的系統，這套系統的每一個部分都不能單獨來看，一葉障目，不見泰山，遇到問題應該從整體思考。一個Apps DBA是一個對這套系統每一部分都有所瞭解的人。

結論:

Oracle Applications DBA(Oracle應用程式資料庫管理員)比“普通”的Oracle DBA(Oracle資料庫管理員)門檻高了很了很多，不僅要有處理資料庫問題的能力，還需要了解整個應用程式的構架，從大處著眼，整體考慮問題。總之，扮演者DBA 和 系統分析師的角色。