原作者：Bert Scalzo

目前，HP，Compaq，Dell，IBM 以及 Oracle 都在加快速度擁抱 Linux ，這個開放源碼的操作系統。根據 eWeek 的統計，去年 Linux 服務器的銷售量大約占據了 Compaq 的 30%，Dell 的 13.7%，IBM 的 13.5%。而且 IBM 2001年度在 Linux 上的投入有 10 個億。 Intel 最新的 64 位的 Itanium CPU 只支持四種操作系統：Windows, Linux, AIX 和 HP-UX。我們也不要忘記 Oracle 的 9i 數據庫 Linux 版本要比 Windows 版本早一個月。
盡管 Linux 能跑在從 IBM S/390 到 Sun SPARC 結構的服務器，但是對于大多數人來說，Intel 還是 Linux 跑得最多的平臺。本文就是要講述通過簡單的性能調正，使 Oracle 的性能提升 1000% 的辦法。
本文采用的測試環境是一臺 Compaq 4 CPU，512 MB ，8 部 7200 rpm SCSI 磁盤的服務器，然后在幾乎同樣的單 CPU Athlon 系統上作了測試，內存一樣，但是只有一部 7200 rpm 的 Ultra 100 IDE 磁盤。盡管最后的結果和得到的百分比不一樣，但是觀測得到的性能提升是一致的。
為了簡單起見，我們的測試環境采用 TPC 基準測試，它廣泛地用于 OLTP 的負荷測試。Quest 公司有一個叫做 Benchmark Factory 的工具，使測試工作變得就像發送電子郵件一樣簡單。
下面我們將分別通過 DB 的調整和 OS 的調整來看測試的結果。

DB1 的初始化參數一般不常見，為了說明問題，我們使用這些參數并作為基準。

DB1: Initial Database

Database Block Size 2K
SGA Buffer Cache 64M
SGA Shared Pool 64M
SGA Redo Cache 4M
Redo Log Files 4M
Tablespaces Dictionary

TPC Results Load Time (Seconds) 49.41
Transactions / Second 8.152

顯然需要加大 SGA 大小，我們來看 DB2 的結果：

DB2: Cache Pool

Database Block Size 2K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 4M
Redo Log Files 4M
Tablespaces Dictionary

TPC Results Load Time (Seconds) 48.57
Transactions / Second 9.147

增大 SGA 已經緩沖看來對于性能的提升并不顯著，加載時間只提升了 1.73%。下面我們增加 SGA 重做日志的大小：

DB3: Log Buffer

Database Block Size 2K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 16M
Redo Log Files 16M
Tablespaces Dictionary

TPC Results Load Time (Seconds) 41.39
Transactions / Second 10.088 我們可以看到加載時間提升了 17.35%，TPS 也提升了 9.33%。因為加載和同時插入，更新，刪除需要比 8M 大的空間，但是看起來增加內存性能并沒有顯著提升，我們加大塊大小：

DB4: 4K Block

Database Block Size 4K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 16M
Redo Log Files 16M
Tablespaces Dictionary

TPC Results Load Time (Seconds) 17.35
Transactions / Second 10.179

我們看到加載時間提升了 138%！而對 TPS 值沒有很大的影響。下面一個簡單的念頭是表空間的管理從目錄切換為本地：

DB5: Local Tablespaces

Database Block Size 4K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 16M
Redo Log Files 16M
Tablespaces Local

TPC Results Load Time (Seconds) 15.07
Transactions / Second 10.425

下面我們把數據庫塊加大到 8K 來看結果：

DB6: 8K Block

Database Block Size 8K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 16M
Redo Log Files 16M
Tablespaces Local

TPC Results Load Time (Seconds) 11.42
Transactions / Second 10.683

看來結果并不壞，我們沒有理由繼續增加塊大小了，我們還沒有根據 CPU 個數調整相應的參數，這次我們設置 I/O 的進程數來繼續調整：

DB7: I/O Slaves

Database Block Size 8K
SGA Buffer Cache 128M
SGA Shared Pool 128M
SGA Redo Cache 16M
Redo Log Files 16M
Tablespaces Local
dbwr_io_slaves 4
lgwr_io_slaves (derived) 4

TPC Results

Load Time (Seconds) 10.48
Transactions / Second 10.717

我們的測試是基于 Red Hat 6.2 進行的，內核版本為 2.2.14-5smp。對于 Linux 的內核而言，有將近幾百個參數可以調整，包括對 CPU 類型，SMP 支持，APIC 支持，DMA 支持，IDE DMA 缺省參數的使用以磁盤限額支持。根據 Oracle 的文檔，我們要做的主要調整是共享內存和信號量的大小，SHMMAX 最少配置 0x13000000，SEMMNI, SEMMSL 和 SEMOPN 分別至少設置 100, 512, 100。這些參數的設置可以通過下面的命令實現：

# echo 0x13000000 >/proc/sys/kernel/shmmax
# echo 512 32000 100 100 >/proc/sys/kernel/sem

OS1: 單內核和 IPC

TPC Results
Load Time (Seconds) 9.54
Transactions / Second 11.511

我們有理由相信采用新的內核版本（2.2.16-3smp）也應該有性能的提升：

OS2: Newer minor version kernel TPC Results

Load Time (Seconds) 9.40
Transactions / Second 11.522

目前已經有 2.4 版本的內核，和 2.2 相比，性能上有了很大的提升，我們采用 2.4.1smp：

OS3: Newer major version kernel TPC Results

Load Time (Seconds) 8.32
Transactions / Second 12.815

Linux 缺省讀操作時更新最后一次讀的時間，但是這個對我們來說并不重要，因此我們關閉這個選項，通過設置 noatime 的文件屬性來實現。（對于 Win NT 和 2000 有相似的設置）
如果只是相對 Oracle 的數據文件設置，我們的命令是

chattr +A file_name

對整個目錄的實施辦法：chattr -R +A directory_name

最好的辦法是修改 /etc/fstab ，針對每個文件系統入口，添加 noatime 關鍵字。

OS4: noatime file attribute

TPC Results
Load Time (Seconds) 5.58
Transactions / Second 13.884

另外一個調整 Linux I/O 的辦法是虛擬內存子系統的調整，修改 /ect/sysctl.cong 文件，增加下面一行：

vm.bdflush = 100 1200 128 512 15 5000 500 1884 2

根據 /usr/src/Linux/Documentation/sysctl/vm.txt 的說法：

第一個參數100 %：控制緩沖區中最大的臟緩沖數據，增加這個值意味著 Linux 可以延遲磁盤寫。

第二個參數 1200 ndirty：給出 bdflush 一次能夠寫入磁盤的最大臟緩沖。

第三個參數 128 nrefill：當調用 refill_freelist() 時，bdflush 添加到自由緩沖區中的最大緩沖數目。

refill_freelist() 512：當這個數目超過 nref_dirt 臟緩沖時，將喚醒 bdflush。

第五個 15 和最后兩個參數 1884 和 2，系統未使用，我們不做修改。

age_buffer 50*HZ, age_super 參數 5*HZ：控制 Linux 把臟緩沖寫到磁盤的最多等待時間。數值用時鐘滴答數（jiffies）表示，每秒為 100 個 jiffies 。

OS5: bdflush settings TPC Results
Load Time (Seconds) 4.43
Transactions / Second 14.988

經過以上一系列調整后，我們得到的最終加載時間減少了 1015.35%，TPS 增加  

下面是其他網友的補充

淺談Oracle 性能優化

基于大型Oracle數據庫應用開發已有6個年頭了，經歷了從最初零數據演變到目前上億級的數據存儲。在這個經歷中，遇到各種各樣的性能問題及各種性能優化。

在這里主要給大家分享一下數據庫性能優化的一些方法和見解。

1、服務器要求及配置

服務器處理器性能很關鍵，CPU的主頻要高，要有較大的內存，IO讀寫速度塊。

如何驗證一臺服務器的IO讀寫效率如何了，可以通過IOPS這個指標來衡量。普及一下IOPS的定義：IOPS (Input/Output Operations Per Second)，即每秒進行讀寫（I/O）操作的次數，多用于數據庫等場合，衡量隨機訪問的性能。目前SSD硬盤的IOPS基本是萬級別。但相對的成本也是比較高的。

在Oracle數據使用場景中，可以實現如下語句來查看當前服務器的IOPS:

declare
    max_iops_out pls_integer ;
    max_mbps_out pls_integer ;
    actual_latency_out pls_integer ;
  begin
    dbms_resource_manager.calibrate_io(
     max_iops=>max_iops_out,
     max_mbps=>max_mbps_out,
     actual_latency=>actual_latency_out);

   dbms_output.put_line('max_iops = ' || max_iops_out
             || ',max_mbps = ' || max_mbps_out
             || ',actual_latency = ' || actual_latency_out);
  end; 

2、Oracle系統級的優化

這里主要是針對ORACLE核心的優化，包括Oracle內存設置、文件大小、日志文件大小、回滾日志及各種系統級參數的設定。

那么如何發現目前的設置是否合理了，

A、在Oracle中提供一個性能分析報告AWR和ASH報告.可以通過命令來獲取該份報告。里面涉及到各種指標值：內存設定是否合理、影響ORACLE慢的幾大因素，數據文件讀寫速度等。

B、也可以通過ORALCE-EM中的性能模塊，來檢測每個時間節點ORALCE的運行情況，從中捕獲那些耗資源的SQL語句，從而進行優化。

3、Oracle SQL語句的優化

數據庫在百萬級別，遇到的任何性能問題時，均可以通過SQL語句的優化。優化的層面有2種：

1、通過索引，這種優化的速度最快，而且見效也很明顯。索引的合理使用我就不在這里敘述，網上很多。

2、通過更改SQL語句的查詢邏輯和算法。有一個比較很效的原則是：先過濾小的結果集，然后通過這個小的結果集和其他表做關聯。

在這里希望大家可以提提一些其他觀點或不同看法。