https://blog.csdn.net/laven54/article/details/9840365
最近數據庫升級到11G之后，出現一些問題，慢慢的開始發現一些需要總結的東西，每次心里都在想：下次，我自己搭建數據倉庫的時候，一定要注意這些細節，在倉庫的創建初期就做好這些工作。
1、redo log的設計
1）如果可以單獨放，redo和數據文件單獨划組做條帶化等。物理上分開。
2）redolog如果可以單獨放，就不要設置得太大，最多500M一個，因為日志太大，可能會導致實例恢復的時間很長。另外在極端倒霉的情況下，如果再數據恢復過程中，實例再次down掉，比如掉電。那你就慘了。總之，那么多數據放在日志里不安全，放在datafile里放心一些。
3）如果你和我一樣悲催，redo和datafile所在磁盤組都在一個，因為存儲底層直接划分的一個大池子（基於成本、速度的綜合考慮），那你就把日志調大一些（目前我的是2G/個），組數增加一些（目前我的20組），如果還是出現日志不夠用，那就多增加組數，比如30組。另外ASM在這種大池子面前，基本無法提高IO了，因為你無法解決redo和datafile競爭IO的問題。
2.undo策略
1）undo_retention的設計
一般可以直接設置3小時，先保證系統可用。當然undo表空間要足夠大。
好吧，如果你說無法定量，我給你一個參考值。
數據量3T的數據庫，設置undo表空間為300G，undo_retention時間為10800，默認單位是秒，也就是3小時。
2）guarantee參數的取舍
我覺得，如果你未充分了解你的業務系統和數據庫狀況之前，不要輕易啟用這個參數。有可能會導致異常災難。
上述條件不成立的，可以嘗試使用該參數，以防止ORA-01555的出現。
3、DB和OS級別都要記得開啟異步IO
前面已經寫過了，不在贅述：
http://blog.csdn.net/laven54/article/details/9771327
4、。。。其他的，等想到了再加上來吧
5、OLTP和DSS不同數據庫設計
轉載自：http://space.itpub.net/26464953/viewspace-712124
| oltp 數據庫 | dss 數據庫 |
| oltp = online transaction processing | dss = data warehousing |
| 聯機事物處理 | 數據倉庫 |
| 例如：飛機訂票,網上交易,bbs等 | 例如：各種資源資料查詢系統 |
| 大量的在線用戶和dml操作 | 很少的dml操作 |
| 大量基於索引的查詢 | 大量的全表掃描的查詢 |
| 用b-tree，reverse key索引，定期索引重建 | 用bitmap索引 |
| 需要較多的小的回退段 | 需要較少的大的回退段 |
| 不要用分布式查詢 | 用分布式查詢 |
| 數據對象的存儲參數pctfree 20 或者更高 | 數據對象的存儲參數pctfree 0 |
| 共享程序代碼和各種變量常量 | 字符變量和線索 |
| 啟動多線索服務 | 使用大的數據塊,db_file_mutiblock_read_count |
| 使用較大的日志文件 | 使用較小的日志文件 |
| listener開多個響應端口 | 增加sort_area_size |
從itpub上又找到一些內容，我直接轉過來了，轉載地址為：http://www.itpub.net/thread-1726429-8-1.html
1.數據倉庫生產庫和OLTP系統的生產庫的配置具體有哪些地方不相同？
（1）、內存
和OLTP相比，DW系統PGA意義重大，我以前還通過修改隱藏參數讓DW可以用更多的PGA
（2）、表空間：
TEMP表空間要大，可以分用戶使用不同的臨時表空間。
（3）、並行
並行進程的數量要足夠，我們以前DW做大的報表，全靠並行了。
（4）、備份
增量備份可以開啟“塊改變跟蹤文件”，提高增量備份速度。
(5)、塊大小、區大小
使用大塊、大區。
我以前DW是用32K塊大小。
另外，分區設計也要重點考慮。還可以考慮RAC擴展CPU、內存。存儲磁盤越多越好，磁盤越多吞吐量才能越大。OLTP我一般用RAI10，DW為節省空間一般用RAID5就行。曾用過RAID6模式，效果不是太好，寫性能有點慢。歸檔空間要足夠，並切要快。DW要經常做大的數據加載，我們以前歸檔是瓶徑。
2.數據倉庫系統在日常性能維護和調優的過程中，有哪些特點以及需要注意的地方？
除OLTP的常見指標外，一是要關注PGA、臨時表空間的消耗。二是DW系統空間耗用比較大，可以多關注空間的消耗。SQL方面，DW的SQL一般都巨長無比，調優難度還是比較大的。大部分的表，我都是以5%的比例收集統計信息，讓Oracle自己生成計划，只有客戶反應慢的SQL才會發精力去看。
| 1：我們的數據倉庫歸檔是關閉，oltp一般開歸檔 2：數據倉庫大量的數據IO瓶頸是在臨時表空間，臨時表空間我們用2TB的固態盤；oltp io一般在數據表空間 3：數據倉庫 單個redo較大，數目較多； 4：數據倉庫db_block一般較大16,32K，oltp較小，8,16kB 5：數據倉庫一般數據裝載采用sqlldr direct=true parallel=true，一般采用多個進程同時加載 6：數據倉庫一般采用二級分區，oltp表設計一般為表或一級分區 7：數據倉庫數據插入一般采用append，parallel優化指示，oltp不采用。 8：數據倉庫一般設定並行服務,設定parallel相關參數，oltp不用 9：數據倉庫rac間通訊成為瓶頸，所以采用rds的ib協議，oltp較少使用。 10：數據倉庫接口表一般不建索引，oltp一般都建立索引 |
公司最近也要我研究數據倉庫，了解不多，討論兩個問題吧
1.數據倉庫生產庫和OLTP系統的生產庫的配置具體有哪些地方不相同？
答：
（1）OLTP系統中PGA的設置通常規律是：總物理內存*80%*20%，而在數據倉庫中PGA的比重要增加：總物理內存*80%*50% （當然都是些前者總結的經驗值，不可完全照搬）；
（2）在OLTP系統中，通常建好庫我們會將數據庫模式調為歸檔；但在數據倉庫中常常會需要將模式調為非歸檔，特別在載入時；
（3）在數據庫設計上來說，OLTP系統常用到的3范式就不能再在數據倉庫中照搬了。OLTP提倡的降低數據冗余，而在數據倉庫維度建模中為避免過度的雪花處理（過度的雪花處理會導致數據倉庫過多的表和連接，造成查詢緩慢，另外也降低了用戶在維度中進行瀏覽的能力，並且還挫敗了位圖索引的使用），維度表常常出現一些數據冗余。相對動則10多GB的事實表，無需花太多精力去規范化比事實表小很多的維度表。
2.數據倉庫系統在日常性能維護和調優的過程中，有哪些特點以及需要注意的地方？
答：
（1）數據倉庫系統常常都是批量操作，小事務操作很少，因此無論在導入還是查詢都可以考慮采用並行提高性能；
（2）分區技術在數據倉庫日常維護中發揮了更大的作用，由於OLTP系統事務性強，經常做小事務的DML操作的表是不適合做分區的，並且分區索引的使用要求也相對比較苛刻，而在數據倉庫中對於維護大批量歷史數據備份與遷移這塊，分區技術使本來笨重麻煩的工作變得輕松簡單；
（3）說到數據遷移，基於表空間的數據遷移方法也不錯，比普通EXPDP/IMPDP快捷；
（4）由於數據倉庫修改操作比較少，在每次批量操作以后將表空間設置為只讀也便於備份與查詢的效率提升；
（5）數據倉庫中位圖索引使用的好處就不說了，這個你懂的
| 大db_block_size,pctfree 0,pga比較大，db_file_multiblock_read_count |