..Oracle數據庫規劃設計和運行維護方案〔V1.0目錄1.前言71.1.編寫目的71.2.方案說明71.3.預期讀者82.數據庫部署模式82.1.單機模式82.2.雙機熱備模式〔HA模式82.3.集群模式〔RAC92.4.主從模式〔DataGuard102.5.混合模式〔DataGrard+RAC112.6.數據庫運行模式選擇113.系統特點和數據庫類型123.1.業務系統的特點123.1.1.OLTP特點123.1.2.OLAP特點133.2.數據庫的規模133.3.數據庫版本建議144.數據庫運行環境規劃144.1.主機規劃144.2.網絡規劃154.3.存儲規劃175.數據庫安裝部署規劃185.1.軟件安裝路徑185.2.表空間設計195.2.1.業務數據量估算195.2.2.表空間使用規則205.2.3.表空間的概念和分配原則245.2.4.表空間的參數配置255.2.5.Undo/temp表空間的估算295.2.6.表的參數設置295.2.7.索引的使用原則305.3.文件設計315.3.1.RAC配置文件315.3.2.參數文件315.3.3.控制文件335.3.4.重做日志文件346.數據庫應用規劃356.1.數據庫用戶設計356.1.1.用戶權限規劃356.1.2.用戶安全實現376.1.3.用戶類型及角色命名規范396.2.數據庫分區416.2.1.數據庫分區介紹416.2.2.邏輯分割426.2.3.物理分割426.2.4.數據分區的優點426.2.5.數據分區的不足436.2.6.Oracle分區技術436.2.7.分區使用建議446.2.8.分區索引446.3.數據庫實例配置456.4.數據庫參數設置466.4.1.必須修改的初始化參數466.4.2.建議修改的初始化參數516.4.3.不可修改的初始化參數536.4.4.建議不可修改的初始化參數546.4.5.與并行有關的參數576.5.數據庫連接服務586.5.1.專用服務器連接586.5.2.共享服務器連接596.5.3.連接服務建議596.6.數據庫安全建議596.7.數據庫備份和恢復606.7.1.RMAN備份606.7.2.EXP/IMP備份616.7.3.存儲級備份616.7.4.數據庫恢復626.8.數據庫網絡配置636.8.1.監聽器的使用配置原則636.8.2.TNSNAMES的使用配置原則636.8.3.RAC環境下TNSNAMES的配置637.業務系統開發建議657.1.數據庫模型設計規范657.1.1.命名規則657.1.2.數據庫對象667.2.PLSQL開發規則697.2.1.總體開發原則697.2.2.程序編寫規范707.3.SQL語句編寫規則977.3.1.查詢語句的使用原則977.3.2.DML語句的調整原則1088.數據庫體系結構1128.1.整體結構1128.2.內存結構1128.2.1.系統全局區〔SGA1138.2.2.程序全局區〔PGA1168.2.3.后臺進程1168.3.存儲結構1198.3.1.物理結構1198.3.2.邏輯結構1219.數據庫基本管理1239.1.參數文件管理1239.2.表空間管理1249.2.1.用戶表空間管理1249.2.2.臨時表空間管理1279.2.3.回滾段表空間管理1319.3.重做日志文件管理1339.3.1.增加重做日志文件組1339.3.2.添加重做日志文件組成員1339.3.3.改變重做日志文件組成員1349.3.4.刪除重做日志文件組成員1349.3.5.刪除重做日志文件組1349.3.6.重做日志切換1359.3.7.重做日志清理1359.3.8.重做日志切換次數查詢1359.4.歸檔模式設置1379.4.1.單實例數據庫設置歸檔模式1379.4.2.RAC數據庫設置歸檔模式1379.4.3.歸檔路徑設置1389.5.控制文件重建1399.6.內存參數管理1419.6.1.Oracle內存管理發展階段1419.6.2.自動內存管理AMM1419.6.3.自動共享內存管理ASMM1419.6.4.自動PGA管理1429.7.其它管理內容1429.7.1.查看數據庫版本1429.7.2.數據庫字符集1439.7.3.創建密碼文件1439.7.4.關閉數據庫審計功能1439.7.5.賬號管理1449.7.6.Profile管理14410.數據庫集群〔RAC管理14410.1.RAC狀態檢查14410.1.1.檢查守護進程14410.1.2.檢查資源狀態14510.2.RAC啟動與關閉14510.3.管理OCR14610.3.1.OCR盤狀態查看14610.3.2.OCR備份與恢復14610.3.3.查看OCR內容14710.3.4.指定OCR盤14710.3.5.增加OCR盤14710.3.6.刪除OCR盤14810.4.管理VOTINGDISK14810.4.1.檢查VotingDisl盤14810.4.2.VOTINGDISK備份與恢復14810.4.3.添加VOTINGDISK盤14910.4.4.刪除VOTINGDISK盤14910.5.CSS管理14910.6.SRVCTL管理工具14910.6.1.管理實例15010.6.2.管理監聽程序15010.6.3.管理ASM15110.6.4.管理service15110.7.修改RAC的IP及VIP15210.7.1.修改外網IP和心跳IP15210.7.2.修改VIP15210.7.3.查看與刪除IP15310.8.管理ASM15410.8.1.管理DiskGroup15410.8.2.ASM兼容性管理15610.8.3.ASM中添加disk的方法15810.8.4.ASMCMD管理命令介紹15910.8.5.ASM常用視圖16211.數據庫備份16411.1.備份概念說明16411.1.1.脫機備份16411.1.2.聯機備份16511.1.3.RMAN備份16611.2.備份策略規劃16611.3.RMAN備份和恢復案例16711.3.1.歸檔模式下的完全恢復16711.3.2.歸檔模式下的不完全恢復17012.數據庫運維管理17212.1.運維職責17212.2.運維要求17212.3.技能要求17212.4.運維內容17312.4.1.檢查數據庫運行情況17312.4.2.檢查操作系統和數據庫日志文件17512.4.3.檢查Oracle對象狀態17612.4.4.檢查數據庫相關資源的使用17912.4.5.檢查數據庫備份18312.4.6.檢查數據庫的性能18312.4.7.數據庫安全性檢查189前言編寫目的隨著以使用Oracle數據庫的應用系統不斷增加,為了加強應用系統在規劃、開發、實施、維護等環節工作的規范化,特編寫本文檔,力求對實際的設計、實施工作起到規范和指導作用。本方案以設計者的角度進行組織編寫,其主要思路是：作為設計人員首先要了解數據庫系統的運行模式,如何選擇運行模式,其次要考慮系統的規劃設計因素,有針對性的做好數據庫的設計,提高數據庫的性能,并對系統開發也提出相關要求。方案說明本方案分為兩大部分,其中第一部分是第二到七章,主要介紹Oracle數據庫的運行方式和規劃設計以及與開發相關內容；第二部分是第八到十二章,主要介紹數據庫的日常運行維護相關的內容。第一部分偏重于規劃和開發,第二部分偏重于實際管理及命令。其中：第二章介紹了Oracle數據庫的部署運行方式；第三章介紹了業務系統特點和數據庫的類型規模以及部署前的建議；第四章介紹了數據庫運行的物理環境的配置規劃；第五章介紹了Oracle數據庫的安裝部署規劃以及命名原則；第六章介紹了數據庫的應用規劃；第七章介紹了系統開發的建議；第八章介紹數據庫的體系架構；第九章介紹數據庫的基本管理方法；第十章介紹了數據庫集群的管理；第十一章介紹了數據庫的備份和恢復；第十二章介紹了數據庫的日常運行維護管理。本方案編寫過程中注重實際的可操作性,所提出的建議盡量覆蓋系統生命周期中的各個關鍵點。其中所涉及的參數和指標對系統的建設和運營起指導作用,但是在實際工作中,每個系統都有各自的特點,所以建議在初期對系統進行初始配置后,應根據系統的實際運行狀態進行相應調整。預期讀者項目基礎設施可行性研究、設計和實施人員,項目組系統設計開發人員,相關運行維護技術人員。數據庫部署模式單機模式數據庫服務器采用單服務器模式,滿足對可用性和性能要求不高的應用,具備以下特點:1、硬件成本低。單節點,硬件投入較低,滿足非重要系統的需求。2、安裝配置簡單。由于是單節點、單實例,所以安裝配置比較簡單。3、管理維護成本低。單實例,維護成本低。4、對應用設計的要求較低。由于是單實例,不存在RAC系統應用設計時需要注意的事項,所以應用設計的要求較低。5、可用性不高。由于是單服務器、單實例,所以服務器和實例的故障都會導致數據庫不可用。6、擴展性差。無法進行橫向擴展,只能進行縱向擴展。當應用對性能有更高的要求時,該模式的數據庫服務器無法進行增加節點、實例等橫向擴展,只能進行增加硬件配置等縱向擴展,且擴展性有局限。7、根據該模式的特點有如下要求：1> 硬件配置方面預留擴展量。由于該模式無法進行橫向擴展,所以在選擇硬件配置時要為以后的縱向擴展預留擴展量,避免硬件無法滿足性能需求的情況。2> 充分考慮該模式是否滿足應用未來一段時間的需求。需要考慮應用在未來一段時間是否會發生變化,該模式是否滿足應用變化的需求。雙機熱備模式〔HA模式數據庫服務器采用雙機熱備模式,可以滿足對可用性有一定要求的應用,具備以下特點：1、需要冗余的服務器設備。該模式需要有冗余的服務器硬件,以滿足一備一或者一備多的需求。硬件成本較高。2、需要HA軟件的支持。該模式需要配合HA軟件才可以實現。3、安裝配置相對簡單。該模式比單節點、單實例的模式配置復雜一些,需要更多的配置步驟,但相比較RAC、DATAGUARD等模式要簡單。4、管理維護成本低。單實例,對維護人員的要求較低,維護成本低。5、對應用設計的要求較低。由于是單實例,不存在RAC系統應用設計時需要注意的事項,所以應用設計的要求較低。6、具備一定的高可用性。由于是多服務器、單實例,所以服務器和實例有故障時會發生實例在不同服務器上的切換,導致數據庫的暫時不可用。無法滿足對可用性有嚴格要求的應用類型。7、擴展性差。無法進行橫向擴展,只能進行縱向擴展。當應用對性能有更高的要求時,該模式的數據庫服務器無法進行增加節點、實例等橫向擴展,只能進行增加硬件配置等縱向擴展,且擴展性有局限。根據該模式的特點有如下要求：1> 硬件配置方面預留擴展量。由于該模式無法進行橫向擴展,所以在選擇硬件配置時要為以后的縱向擴展預留擴展量,避免硬件無法滿足性能需求的情況。2> 充分考慮該模式是否滿足應用未來一段時間的需求。需要考慮應用在未來一段時間是否會發生變化,該模式是否滿足應用變化的需求。集群模式〔RAC數據庫服務器采用RAC模式,滿足對高可用性要求高的應用類型,具備以下特點:1、需要多個硬件服務器。根據節點的個數,相應的需要多個硬件服務器。硬件成本較高。2、某些數據庫版本需要HA軟件的支持。該模式下,某些數據庫版本需要配合HA軟件才可以實現。3、安裝配置復雜。該模式比起單實例模式,安裝配置相對復雜,安裝配置周期長。4、管理維護成本高。該模式的管理維護,對管理維護人員的要求較高,管理維護成本較高。5、對應用設計的要求較高。需要充分考慮業務的邏輯性,以避免在多節點之間的信息交換和全局鎖的產生。6、具備較高的高可用性。由于是多服務器、多實例,單服務器和實例有故障不會影響數據庫的可用性。可以滿足對可用性有嚴格要求的應用類型。7、擴展性好。既可以進行橫向擴展,也可以進行縱向擴展。當應用對性能有更高的要求時,該模式的數據庫可以通過增加節點的方式進行橫向擴展,也可以通過增加硬件配置等縱向擴展,具備良好的擴展性。根據該模式的特點有如下要求：1>硬件配置方面預留擴展量。預留一定的硬件擴展量,可以更靈活的進行擴展。2>在應用設計時,充分考慮業務邏輯,減少多節點間的信息交換量,更好的發揮RAC的優點。主從模式〔DataGuard數據庫服務器采用DataGuard主從模式,可以滿足對可用性有特殊需求的應用,具備以下特點：1、需要冗余的服務器設備。該模式需要有冗余的服務器硬件。硬件成本較高。2、需要冗余的存儲設備。主機和備機都需要同樣的存儲空間,成本較高。3、安裝配置比較復雜。該模式比單節點、單實例的模式配置復雜一些,需要更多的配置步驟。4、管理維護成本高。該模式對維護人員的要求較高,維護成本高。5、具備一定的容災特性。當主機整個數據庫系統不可用并短期內無法恢復時,可以把數據庫系統切換到備機上,具備容災的功能。6、備機可以用作只讀查詢。備機可以切換到只讀狀態供報表之類的查詢操作,減輕主機的壓力。根據該模式的特點有如下要求：1主機與備機在物理上要分開。為了實現容災的特性,需要在物理上分割主機和備機。2進行合理的設計,充分實現DATAGUARD的功能。混合模式〔DataGrard+RAC數據庫服務器采用DataGuard+RAC模式,可以滿足對可用性和容災都有特定需求的應用,具備以下特點：1、需要冗余的服務器設備。該模式需要有冗余的服務器硬件。硬件成本較高。2、需要冗余的存儲設備。主機和備機都需要同樣的存儲空間,成本較高。3、安裝配置比較復雜。該模式既需要配置RAC又需要配置DATAGUARD,配置過程比較復雜,配置周期長。4、管理維護成本高。該模式對維護人員的要求較高,維護成本高。5、具備很高的可用性和容災性。該模式既滿足高可用性也滿足容災的需求。6、備機可以用作只讀查詢。備機可以切換到只讀狀態供報表之類的查詢操作,減輕主機的壓力。根據該模式的特點有如下要求：1主機與備機在物理上要分開。為了實現容災的特性,需要在物理上分割主機和備機。2進行合理的設計,充分實現DataGuard的功能。數據庫運行模式選擇在設計數據庫時必須考慮系統的可用性、業務連續性,針對系統所能容忍的最大業務中斷時間〔RTO和最大數據丟失數量〔RPO需求,采用不同的數據庫部署模式：1、系統不能中斷且不允許數據丟失的業務,建議數據庫采用集群或混合模式,數據庫單臺設備故障時對業務沒有影響,并考慮災備系統的設計。2、對于允許以分鐘級別中斷,數據不能丟失的系統,建議數據庫采用雙機熱備或主從的模式,設備故障時通過HA技術切換到備用設備,保證系統的可用性,對重要的系統要考慮災備的設計。3、對于允許以天為級別中斷的業務系統,建議可采用雙機熱備模式,或單機。4、對非關鍵系統、開發環境、測試環境,建議采用PC服務器、冷備或單機的模式。系統特點和數據庫類型業務系統的特點業務系統處理數據的特點決定了設計人員規劃和創建什么樣的數據庫,通常來說,業務分為兩類：在線事務處理系統〔OLTP和在線分析系統〔OLAP或者DSS〔決策支持系統。這兩類系統在數據庫的設計上是不同的,比如OLTP系統強調數據庫的內存效率,強調各種內存指標的命中率,強調綁定變量,強調并發操作：而OLAP系統則強調數據分析,強調SQL執行時長,強調磁盤I/O,強調分區等。OLTP特點通常OLTP〔在線事務處理系統的用戶并發數很多,但只對數據庫做很小的操作,數據庫側重于對用戶操作的快速響應,這是對數據庫最重要的性能要求。對于一個OLTP系統來說,數據庫內存設計非常重要,如果數據都可以在內存中處理,那么數據庫的性能會提高很多。內存的設計通常是通過調整Oracle和內存相關的初始化參數來實現的,比較重要的幾個是內存相關的參數,包括SGA的大小〔DataBuffer,SharedPool,PGA大小〔排序區,Hash區等等,這些參數對一個OLTP系統是非常重要的。OLTP系統是一個數據塊變化非常頻繁,SQL語句提交非常頻繁的一個系統。對于數據塊來說,應盡可能讓數據塊保存在內存當中,對于SQL來說,盡可能使用變量綁定技術來達到SQL的重用,減少物理I/O和重復的SQL解析,能極大的改善系統的性能。此外,沒有綁定變量的SQL會對OLTP數據庫造成極大的性能影響,還有一些因素也會導致數據庫的性能下降,比如熱塊〔hotblock的問題,當一個塊被多個用戶同時讀取的時候,Oracle為了維護數據的一致性,需要使用Latch來串行化用戶的操作,當一個用戶獲得了這個Latch,其他的用戶就只能被迫的等待,獲取這個數據塊的用戶越多,等待就越明顯,就造成了這種熱塊問題。這種熱塊可能是數據塊,也可能是回滾段塊。對于數據塊來講,通常是數據塊上的數據分布不均勻導致,如果是索引的數據塊,可以考慮創建反向索引來達到重新分布數據的目的,對于回滾段數據塊,可以適當多增加幾個回滾段來避免這種爭用。OLAP特點OLAP數據庫在內存上可優化的余地很小,但提升CPU處理速度和磁盤I/O速度是最直接的提高數據庫性能的方式。實際上,用戶對OLAP系統性能的期望遠遠沒有對OLTP性能的期望那么高。對于OLAP系統,SQL的優化顯得非常重要,如果一張表中只有幾千數據,無論執行全表掃描或是使用索引,對用戶來說差異都很小,幾乎感覺不出來,但是當數據量提升到幾億或者幾十億或者更多的時候,全表掃描,索引可能導致極大的性能差異,因此SQL語句的優化顯得重要起來。分區技術在OLAP數據庫中很重要,這種重要主要是體現在數據管理上,比如數據加載,可以通過分區交換的方式實現,備份可以通過備份分區表空間,刪除數據可以通過分區進行刪除。數據庫的規模對于數據庫的規模,僅從數據量來衡量其規模的大小。因為數據量的規模是反映數據庫規模的主要指標。具體如下：1數據庫業務數據量小于100GB屬小規模數據庫2數據庫業務數據量1TB以內屬中大規模數據庫3數據庫業務數據量大于1TB屬大規模數據庫數據庫版本建議Oracle數據庫產品推出新的主要版本后,要經歷一個版本不穩定期。在此期間新版的數據庫產品存在較多的bug。在安裝和運行過程中,會存在數據庫安裝困難和運行不穩定現象。因此在選擇版本時,要選擇成熟穩定的版本。數據庫運行環境規劃根據用戶需求在業務系統前期的實施規劃上,需要做好詳細的規劃設計,包括主機、網絡和存儲環境規劃等,要將整個軟硬件融為一體,充分考慮系統的安全性,可靠性,高可用性等因素,只有一個規劃好的系統才能充分發揮其優于單節點的優勢,同時也為后期的運維管理提供方便。在評估數據庫服務器性能時,最困難的事情是如何把握準確度問題,到底考慮哪些因素等。理想情況下,應考慮下列要素：交易的復雜性、交易率、數據讀/寫比例、并發連接數目、并發交易數目、數據庫最大表的大小、性能度量的目標。主機規劃主機規劃主要需考慮服務器在不同的用戶數量下,系統的響應時間和吞吐量,并得出當前服務器的各種資源的利用情況。在規劃系統配置時要預留做系統管理時所消耗的資源,如在做備份、恢復、問題診斷、性能分析、系統維護時都會對系統資源帶來額外的消耗,對重要資源要考慮為將來留下升級和可擴展的余地。在進行服務器配置規劃時,要注意以下幾點：1CPU：要考慮業務高峰時處理器的能力,并適當保留一些緩沖,確保在業務增長時,系統有擴展的余地。2內存：要為運行在此服務器的所有應用軟件考慮內存,所需要的內存主要依賴于用戶數、應用程序類型、進程的方式、和應用程序處理的數據量決定。3磁盤：評估業務的實際用戶的數據量,以此推算出磁盤的最小個數,不要忘記選擇備份設備〔如磁帶機。4IO槽：盡量保留更多的IO槽,防止將來插更多的PCI卡。5網絡：選擇合適的網卡,保證網絡不是系統的瓶頸。數據庫服務器優先考慮使用小型機和UNIX操作系統,但是當前用戶大都選擇PC服務器和Linux操作系統,推薦的數據庫服務器配置如下：處理器：核心不低于24,主頻不低于2.6GHz,三級緩存不低于30MB。內存：容量不低于256G,DDR4頻率不低于2133MHz,支持ECC糾錯、內存鏡像、內存熱備等功能。存儲：雙盤,單盤容量不低于300GB,支持RAID。網卡和HBA卡：2個千兆網口,2個萬兆網口,2個FC接口。網卡進行綁定。操作系統：Linux。網絡規劃網絡規劃的基本原則就是將業務生產網絡、存儲網絡和管理網絡分開,推薦在生產網絡使用萬兆網,存儲使用SAN存儲網絡,管理網可使用千兆網。對于數據庫單機模式、HA雙機模式以及主備模式的生產環境,主要基本符合網絡規劃的基本原則即可。對于集群模式,因Oracle有其特殊要求,所以在結合網絡規劃基本原則的基礎上,可進行細化實施。在Oracle11gR2中,安裝RAC發生了顯著變化。在10g以及11gR1的時代,安裝RAC的步驟是先安裝CRS,再安裝DB,而到了11gR2的時代,crs與asm被集成在一起,合稱為GRID,必須先安裝GRID后,才能繼續安裝DB。本方案以主流的ORACLE11gR2RAC的網絡規劃為例進行詳細說明。假設服務器上有4塊網卡：eth0,eth1,eth2,eth3.可以將eth0和eth2綁定成bond0。作為RAC的public-ip,提供外部通信。然后將eth1和eth3綁定成bond1,作為RAC的private-ip,提供內部心跳通信。服務器上的HBA卡通過光纖交換機與后端存儲通信。公有IP和虛擬IPOracleRAC中每個節點都有一個虛擬IP,簡稱VIP,與公網PUBLICIP在同一個網段。VIP附屬在public網口接口。VIP和PUBLICIP最主要的不同之處在于：VIP是浮動的,而PUBLICIP是固定的。在所有節點都正常運行時,每個節點的VIP會被分配到publicNIC上；在linux下ifconfig查看,public網卡上是2個IP地址；如果一個節點宕機,這個節點的VIP會被轉移到還在運行的節點上。也就是幸存的節點的publicNIC這個網卡上,會有3個IP地址。PUBLICIP地址是一個雙網卡綁定的公有地址,用戶通過交換機來進行訪問。RAC中的私有IPRAC中的Private私有IP用于心跳同步,這個對于用戶層面,可以直接忽略。簡單理解,這個IP用來保證數據庫節點同步數據用的,屬于RAC內部之間通信。priv與public不應同屬一個接口。Metalink上的RAC文檔是推薦使用交換機作為內部網卡的連接,而不使用交叉線,原因是避免因為對連節點關閉或重啟而導致網卡檢查到鏈接故障狀態而刪除綁定的協議。導致高速緩存合并網絡將會變為不可用。SCANIP在11gR2中,SCANIP是作為一個新增IP出現的,SCANIP其實是Oracle在客戶端與數據庫之間,新加的一個連接層,當有客戶端訪問時,連接到SCANIPLISTENER,而SCANIPLISTENER接收到連接請求時,會根據LBA算法將該客戶端的連接請求,轉發給對應的instance上的VIPLISTENER,從而完成了整個客戶端與服務器的連接過程。簡化如下：client->scanlistener->locallistener->localinstance也可以把scan理解為一個虛擬主機名,它對應的是整個RAC集群。客戶端主機只需通過這個scanname即可訪問數據庫集群的任意節點。當然訪問的節點是隨機的,Oracle強烈建議通過DNSServer的roundrobin模式配置解析SCAN,實現負載均衡〔即輪換連接SCAN對應的IP地址。存儲規劃數據庫一般使用磁盤陣列〔RAID保存數據,使用磁盤陣列有兩個優點：首先,盤陣可以提供一個具有容錯能力的I/O系統,當系統中某個磁盤驅動器出現故障時,可避免丟失數據,因此具有容錯能力；其次,允許多個但磁盤驅動器配置成為一個大的虛擬磁盤驅動器,從而方便管理,提高性能。盤陣RAID方式分為RAID0,RAID1,RAID10,RAID2,RAID3,RAID4,RAID5等,其邏輯和物理組合方式各有差異。基于Oracle數據庫配置RAID系統,有以下幾種解決方案：1、最佳解決方案對容錯能力最好的解決方案就是最大限度地使用RAID1和RAID10,規劃部署時遵循以下原則：1對操作系統和Oracle程序使用RAID1；2對數據庫重做日志文件使用RAID1,可以優化性能；3對歸檔日志文件使用RAID01,既能保護數據,又不會影響性能；4對數據文件使用RAID10,并使用多個磁盤驅動器以保證不超過單塊盤的負載。2、較好的解決方案對于容錯能力,較好的解決方案是混合使用RAID10和RAID5,遵循以下原則：1對操作系統和Oracle程序使用RAID1；2對數據庫重做日志文件共享一個RAID1或RAID10；3對歸檔日志文件可使用RAID10或RAID5,這兩種方式均可保護數據且不影響性能；4對數據文件使用RAID10,并使用過個磁盤驅動器以保證不超過單個磁盤負載。混合使用RAID10和RAID5可實現很好的性能,容錯能力也很高。3、經濟型解決方案對容錯能力,此方案使用RAID1和RAID5,遵循以下原則：1對操作系統和Oracle程序使用RAID1;2對重做日志文件使用RAID1;3對歸檔日志文件使用RAID10或RAID5;4對數據文件使用RAID5或RAID0,其中RAID0用來提供必要的性能,并使用過個磁盤驅動器以保證不超過單盤的負載。此方案提供的系統性能比前兩個方案要低,其價格是優勢。在進行存儲規劃時,需要特別注意：1若系統沒有使用容錯功能,那么只要有一塊磁盤驅動器發生故障,就必須恢復整個數據庫；2容錯磁盤不能替代數據庫備份策略；3系統可能會發生變化,要緊跟用戶的需求；4以上的解決方案都要考慮磁盤驅動器的數量,應具備足夠數量的磁盤驅動器以防系統瓶頸的產生；5對于硬件的保護不僅僅是磁盤驅動器,還包括冗余電源,磁盤控制卡和風扇等等,如果存儲系統沒有冗余機制,則這其中任何一項故障都會導致業務系統停機和丟失數據等損失。數據庫安裝部署規劃軟件安裝路徑建立單獨的文件系統來安裝數據庫軟件,且文件系統的mount點不要直接建立在根目錄下。安裝路徑：/home/db/oracle各種環境變量設置：ORACLE_BASE=/home/db/oracleCRS_HOME=/home/db/oracle/crs/{數據庫release版本}ORACLE_HOME=/home/db/oracle/product/{數據庫release版本}普通使用模式的Oracle數據庫的服務名和實例名〔SID是相同的；RAC模式下的Oracle數據庫的服務名與實例名不同。數據庫服務名的命名格式為：XXXYYdb{m}數據庫的SID的命名格式為：XXXYYdb{m}{n}說明：1、其中XXX表示長度為3個字符的應用項目縮寫,具體的見相關設計文檔。2、YY：代表數據庫用途,pd代表生產庫,hi代表歷史庫,rp代表報表庫,cf代表配置庫；3、m表示數據庫序號,從0-9,根據項目的數據庫數量進行編號。4、n表示RAC節點實例序號1,2,3……。用以區分多節點的RAC數據庫的不同實例。對于普通模式的數據庫,該位不指定。表空間設計業務數據量估算估算所有業務對象下的所有表的尺寸。數據量估算的前提：1數據庫的物理表結構已經確定,并且設計已凝固。2用戶方提供較為準確的估算依據,例如業務變動的頻率、數據需要保存的周期等。該表是一個示例,可根據業務的不同有所變化。序號表名增長量〔/小時/天/周增長量〔/月/半年年數據量數據庫生命周期內的總計 合計 新上線或擴容時,對所申請的存儲不得全部一次性掛上,應該預留出30％左右的空間用于追加,以防止出現業務發展和預期不一致時剩余空間多寡不均,調整困難。操作系統上應該預先做好幾個合適大小的邏輯卷備用,包括用于system/sysaux等表空間的小尺寸的邏輯卷和用于數據表空間、索引表空間的大尺寸邏輯卷,這些邏輯卷要求在HA兩邊主機都可見,不必單純因為數據庫增加數據文件而需要重新同步HA。表空間使用規則目前多數數據庫系統采用數據"大集中"原則,對數據庫的性能要求較高。這就要求對數據庫進行必要的優化配置。在表空間的配置上,應遵循以下原則：1、最小化磁盤I/