戴明明

寶存科技數據庫方案架構師

本文來自于本周四云和恩墨大講堂戴明明（Dave）的分享內容：基于?PCIE?閃存卡的Oracle 數據庫使用場景。課程通過對?PCIE?閃存卡的說明，讓大家了解了如何使用?PCIE 閃存卡來提升?Oracle 數據庫的性能。

PCIE 閃存卡概述

對于閃存卡的概念，大家應該是有一定的了解，即使沒有聽過，那么也應該了解固態硬盤，他們是同一種存儲方式，即使用Nand Flash。

先看一組對比數據：

通過這組數據可以非常明顯的看出來，PCIe 閃存卡的性能是最好的。

對于運維人員，尤其是 DBA，也非常的明白，對于數據庫，最大的性能瓶頸也就是 IO。所以 PCIe 閃存加 數據庫就是一個完美的組合，可以極大的提升數據庫的性能。

上面的是不同存儲介質的性能對比，我們在看一組 PCIe 閃存卡的性能數據，從而來顛覆一下對傳統存儲介質的速度觀。

容量	800GB	1.2TB	1.6TB	3.2TB	6.4TB
閃存類型	MLC	MLC	MLC	MLC	MLC
讀帶寬	1.4GB/s	2.0GB/s	2.6GB/s	2.6GB/s	2.6GB/s
寫帶寬	1.2GB/s	1.8GB/s	1.8GB/s	1.9GB/s	1.9GB/s
隨機讀延遲(4KB)	67us	67us	67us	67us	67us
隨機寫延遲(4KB)	9us	9us	9us	9us	9us
隨機讀IOPS(4KB)	300,000	450,000	590,000	590,000	590,000
隨機寫IOPS(4KB)	310,000	460,000	480,000	480,000	480,000
寫入壽命	每天5次全盤寫(5DWPD)， 持續3年

在這個表格里，我們需要重點關注幾組數值：

1．? 讀寫帶寬，以6.4TB 的為例，讀帶寬是2.6GB/s,寫帶寬是1.9GB/s.

2．? 讀寫延遲分別是67us和 9us。 這里可能有人可能會有疑問。

為什么寫延遲比讀延遲還低很多，還不是一個數量級。

這個問題與閃存卡的設計有關，閃存卡的FPGA里有個緩存，寫數據，只要寫入到緩存就認為寫成功了。但讀數據是正的要從Nand Flash 中讀取。所以寫延遲比讀延遲低很多。

3．? IOPS，分別是59w和48w。這個指標對于數據庫非常重要。

除了這些性能指標之外，做完運維人員更關注的是穩定性。否則即使閃存卡的性能再好，我們也不敢用，因為數據對于企業來說是無價的，不能因為性能，而丟失了數據。

講到閃存卡的壽命，需要引入另一個知識點：閃存卡的分類，見下圖：

另外因為閃存卡使用的Nand Flash作為存儲介質，那么具有如下特性：

?

其中有一個就是擦除壽命，閃存卡讀不壞，但會寫壞，就是 page 擦除次數達到壽命后，這個 page 就不能使用了，就是閃存卡容量的降低。

所以閃存卡廠商在設計的是，都會留足夠多的 Over-Provision (OP) 空間。

總之，Nand Flash 的類型決定其page的擦除次數。 OP 值影響的是閃存卡的性能和安全性。

民用級的 SSD 采用的是 MLC 和 TLC，并且 OP 值一般也控制在10%以內，這樣可以控制成本，但 OP 值低，會導致寫放大系數高，也會影響整體閃存卡的性能。

企業級的 PCIE Flash 閃存卡采用的是 MLC，OP 值可以做到 20% 以上，OP 值高，寫放大系數可以控制的更低，大的 OP 值也可以給閃存卡提供更好的性能。

根據上面的說明，我們舉個例子，假設我們買了一張6.4T 的閃存卡。

它的壽命是：6.4T * 5 * 365 * 3 = 34P。

就是每天全盤寫5遍，能連續寫3年。實際上很少有人的數據庫能每天寫30T的數據。所以閃存卡的壽命決絕可以滿足我們的需求。

當然閃存卡也分很多廠家，對于閃存卡的性能，在存儲行業有通用的測試工具。就是 FIO。

FIO 是 linux 下的測試工具，如果是 Windows 的系統，那么對應的工具是 IOMETER。

關于這2個工具的使用，這里不在說明，有興趣的可以參考我的Blog：

IO壓力測試工具 -- FIO 使用說明

http://cndba.cn/article/89

?IO壓力測試工具 -- IOMETER 使用說明

http://cndba.cn/article/90

PCIE 閃存卡的使用場景

1

基于閃存卡的 Oracle 能跑出什么樣的性能

前面說閃存卡+ 數據庫是完美的搭配，我們這里看一組測試數據，看到底能碰撞出多大的火花。

測試環境：

服務器：?? 八路X86 服務器???????????????

操作系統： RedHat6.5?????????????

CPU:? Intel E7-8870v2? * 8??????????

內存：1T

數據庫：11.2.0.4

測試工具：HammerDB

使用 Hammer DB 壓了5000個 warehouses，然后使用 200 個 Virtual User 來進行壓力測試，然后得到了上圖的數據：

TPM:4044739（400w）

NOPM:1344006（134w）

Redo size：340M/s

執行SQL： 139w/s

事務：6.7w/s

這個還是一張卡和一臺八路的X86服務器。這個性能跑我們絕大部分業務都沒啥問題了。

這里提到了 HammerDB 的工具。實際上我們測試數據庫性能壓力的方法很多。

關于數據庫性能測試這塊的內容，可以參考我的Blog：

數據庫基準測試（Database Benchmarking）說明

http://cndba.cn/article/87

數據庫壓力測試工具 -- Hammerdb 使用說明

http://cndba.cn/article/88

數據庫壓力測試工具 -- Swingbench 使用說明

http://cndba.cn/article/102

數據庫壓力測試工具 -- BenchmarkSQL 使用說明

http://cndba.cn/article/103

2

基于閃存卡的 Data Guard 解決方案

單卡的性能再好，還是會存在單點故障的可能性。所以我們需要結合具體的解決方案來使用。

這里最簡單也是最方便的，就是 Data Guard方案。

我們的這種架構和傳統的Data Guard一樣，只不過我們替換了2種硬件。

1．??底層的存儲，我們直接使用 PCIE 閃存卡，能大幅的提升數據庫的性能。

2．??主備庫之間的數據傳輸。我們使用的是 Infiniband 網絡。

因為閃存卡的性能很高，傳統的千兆網絡已經不能滿足我們的性能性能需求，帶寬不夠，延遲也高。

替換這兩種硬件之后，可以直接將 Data Guard 的保護模式切換成最大可用，做到實時的數據傳輸，在也不用擔心單點故障帶來的數據丟失。

當然這種方案里還是有弊端，就是發生故障的時候，系統還是中斷一會。

如果想方案在好一點，那么就是上一體機。

3

基于閃存卡的RAC 解決方案

這種架構是一種分布式的存儲。 采用2+3的架構。 上面2層是2個計算節點，底下3層是存儲節點，采用 ASM 的 Normal 或者 High 容易來保證數據安全。

整個一體機的通訊都走 Infiniband 的 RDMA 協議，性能很高。

基于 PCIE 閃存卡的 Online Redo log 優化

在使用閃存卡的情況下，還有進一步的優化就是，數據庫的 Online redo log。

1

Oracle 官方的建議

在 MOS 的文檔（ID 857576.1）中提到如下一句話：

Also putting theSLOG on an SSD (Solid State Disk) will reduce redo log latency further.?This will help improve the performance of synchronous writes.

在另一篇MOS文檔（ID 1376916.1）中提到：

If the proportion of the?'log filesync' time spent on?'log file parallel write' times is high, then most ofthe wait time is due to IO (waiting for the redo to be written). Theperformance of? LGWR in terms of IO should be examined. As a rule of thumb,an average time for 'log file parallel write' over 20 milliseconds suggests aproblem with IO subsystem.

Recommendations

• Work with the system administrator ? ? to examine the filesystems where the redologs are located with a view to ? ? improving the performance of IO.

• Do not place redo logfiles on a ? ? RAID configuration which requires the calculation of parity, such as ? ? RAID-5 or RAID-6.

• Do not put redo logs on Solid ? ? State Disk (SSD)

? ? ? ??Although generally, Solid State Disks writeperformance is good on average, they may endure ? ? ? ? ? ? ?write peaks which will highlyincrease waits on 'log file sync'.

? ? ? ? ?(Exception to this would be for Engineered Systems(Exadata, SuperCluster and Oracle ? ? ? ? ? ? ? ? ? ? ? ? ?Database Appliance) which have been optimizedto use SSDs for REDO)

• Look for other processes that may ? ? be writing to that same location and ensure that the disks have sufficient ? ? bandwidth to cope with the required capacity. If they don't then move the ? ? activity or the redo.

• Ensure that the log_buffer is not ? ? too big. A very large log_buffer can have an adverse affect? as waits ? ? will be longer when flushes occur. When the buffer fills up, it has to ? ? write all the data into the redo log file and the LGWR will wait until the ? ? last I/O is completed.

Oracle 不建議把 redo log 放在 SSD上，但 Exadata 系統中 redo 是存放在 SSD 上的。 不建議的理由是：

Although generally,Solid State Disks write performance is good on average, they may endure writepeaks which will highly increase waits on 'log file sync'.

Oracle 擔心的是可能存在的 writepeaks 導致 log file sync 等待的增加。

Flasn 閃存卡使用的 Flash 介質分三種：SLC,MLC,TLC。?

民用級的 SSD 采用的是 MLC 和 TLC，并且 OP 值一般也控制在10%以內，這樣可以控制成本，但 OP 值低，會導致寫放大系數高，也會影響整體閃存卡的性能。所以在這種情況下，確實可能出現 oracle 擔心的 write peaks 帶來的性能下降問題。

但企業級的 PCIE Flash 閃存卡采用的是 MLC，OP 值可以做到20%以上，OP 值高，寫放大系數可以控制的更低，大的 OP 值也可以給閃存卡提供更好的性能。所以在這種情況下，不會出現 Oracle 擔心的 write peaks 帶來的性能問題。

2

4K Online Redo Log

①?扇區大小

上一代存儲多采用 512 bytes 的扇區，現在的存儲則采用 4k 的扇區，扇區即每次最小 IO 的大小。

4k 扇區有兩種工作模式：nativemode 和 emulation mode。

Native mode：即 4k 模式，物理和邏輯的 block 大小一樣，都是 4096bytes。 Native mode 的缺點是需要操作系統和軟件（如 DB）的支持。Oracle 從 11gR2 開始支持 4k IO 操作。 Linux 內核在 2.6.32 之后也開始支持 4k IO 操作。

emulation mode：物理塊是 4k，但邏輯塊是 512bytes。在該模式下，IO 操作時底層物理還是 4k 進行操作，所以就會導致 Partial I/O 和 4k 對齊的問題。

在 emulation mode下，每次 IO 操作大小是 512bytes，但存儲底層的 IO 操作大小必須是 4k，如果要讀 512 bytes 的數據，實際需要讀 4k，是原來的8倍，就是 partial IO。而在寫時，也是先讀 4k 的物理 block，然后更新其中的 512 bytes 的數據，再把 4k 寫回去。所以在 emulation mode 下，增加的工作會增加延時，降低性能。

②Online Redo Logs

在 Oracle 數據庫的文件中，默認情況下，datafile 的 block 是 8KB，控制文件是 16KB，所以都沒有 partial IO 的問題，唯有 online redo log，默認是 512 bytes，存在 partial IO 的問題。

從 Oracle 11gR2 開始，在存儲支持 4k 扇區的情況下，可以創建 Blocksize 為 512，1024，4096 的 redo log。

如：alter database add logfilegroup 5 size 100m blocksize 4096;

如果是 emulation mode 的 4k 扇區，創建 4k 的 redo log 時可能會觸發如下錯誤：

ORA-01378: Thelogical block size (4096) of file +DATA is not compatible with the disk sectorsize (media sector size is 512 and host sector size is 512)

只要確認存儲物理是 4k 的扇區，可以設置_disk_sector_size_override 參數為 true，來覆蓋扇區的設置。該參數支持動態修改，如：

ALTERSYSTEM SET “_DISK_SECTOR_SIZE_OVERRIDE”=”TRUE”;

3

實際測試

①?測試環境

--內存：

[root@dave ~]# free -g

????????????total?????? used?????? free????shared??? buffers???? cached

Mem:??????????? 15???? ????15?????????0????????? 0????????? 0????????? 8

-/+ buffers/cache:????????? 6????????? 9

Swap:?????????? 31????????? 0???????? 30

[root@dave ~]#

--CPU:

processor? :3

vendor_id :GenuineIntel

cpu family :6

model?????????????????? :60

model name?????? :Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz

stepping??? :3

cpu MHz????????????? :800.000

cache size :6144 KB

--磁盤：/dev/dfa 是 3.2T 的 PCIE 閃存卡。

[root@dave ~]# df -lh

Filesystem??????????????????????????? Size? Used Avail Use% Mounted on

/dev/mapper/lvm-root????????????????? 886G?? 35G?806G?? 5% /

tmpfs???????????????????????????????? 7.8G? 2.0M?7.8G?? 1% /dev/shm

/dev/sda1??????????????????????????? 1007M?? 47M?910M?? 5% /boot

/root/rhel-server-6.5-x86_64-dvd.iso? 3.6G?3.6G???? 0 100% /mnt

/dev/dfa????????????????????????????? 3.1T? 700G? 2.3T? 24% /u01

[root@dave ~]#

測試工具： HAMMER DB

測試數據量： 5000個 warehouse

--數據庫： 12.1.0.2

SQL> select * from v$version;

BANNER?????????????????????????????????????????????????????????????????????????????????????????????????? ???? CON_ID

------------------------------------------------------------------------------------------

Oracle Database 12c Enterprise EditionRelease 12.1.0.2.0 - 64bit Production????????????????? ? 0

PL/SQL Release 12.1.0.2.0 - Production????????????????????????????????????????????????????????????????????? ? 0

CORE????????? 12.1.0.2.0?????????? Production??????????????????????????????????????????????????????????????????????????????????? ? 0

TNS for Linux: Version 12.1.0.2.0 -Production????????????????????????????????????????????????????????? ? 0

NLSRTL Version 12.1.0.2.0 - Production????????????????????????????????????????????????????????????????????? ? 0

SQL> show pdbs

???CON_ID CON_NAME????????????????????? ? OPEN MODE?RESTRICTED

---------- ---------------------------------------- ----------

?????????? ?2 PDB$SEED????????????????????????? ? READ ONLY?NO

?????????? ?3 DAVE ????????????????????? ??READ WRITE NO

?????????? ?4 ANQING????????????????????????????? ?READ WRITE NO

測試用的 PDB 是 ANIQNG。

②?Online redo log?存放在 PCIE 閃存卡

??查看 online redo log

SQL> selectgroup#,bytes/1024/1024||'M' from v$log;?

???GROUP# BYTES/1024/1024||'M'

---------------------------------------------------

?????????? ?4 2000M

?????????? ?5 2000M

?????????? ?6 2000M

?????????? ?7 2000M

SQL> col member for a90

SQL> select group# ,memberfrom v$logfile;

???GROUP# MEMBER

----------------------------------------------------------------------------------------------------

?????????? ?4 /u01/app/oracle/oradata/DAVE/onlinelog/dave01.log

?????????? ?5/u01/app/oracle/oradata/DAVE/onlinelog/dave02.log

?????????? ?6 /u01/app/oracle/oradata/DAVE/onlinelog/dave03.log

?????????? ?7/u01/app/oracle/oradata/DAVE/onlinelog/dave04.log

??先創建一個快照：

SQL>executedbms_workload_repository.create_snapshot();

??TPCC 測試

在創建一個 AWR 快照：

SQL> executedbms_workload_repository.create_snapshot();

PL/SQL procedure successfullycompleted.

生成AWR 報告：

SQL>@?/rdbms/admin/awrrpt.sql

??AWR?數據

我們這里只看2個部分：Load Profile 和 Top 10 Foreground Events by Total Wait Time

③?Online redo log 存放在 SAS 硬盤

??移動 online redo log 到 SAS盤

[oracle@dave ~]$ mkdir /home/oracle/onlinelog

SQL> set lin 130

SQL> select group# ,memberfrom v$logfile;

???GROUP# MEMBER

----------------------------------------------------------------------------------------------------

?????????? ?1 /home/oracle/onlinelog/dave01.log

?????????? ?2 /home/oracle/onlinelog/dave02.log

?????????? ?3 /home/oracle/onlinelog/dave03.log

?????????? ?4 /home/oracle/onlinelog/dave04.log

SQL> select group#,bytes/1024/1024||'M'from v$log;

???GROUP# BYTES/1024/1024||'M'

---------------------------------------------------

?????????? ?1 2000M

?????????? ?2 2000M

?????????? ?3 2000M

?????????? ?4 2000M

SQL>?alter system flush buffer_cache;

System altered.

SQL>?alter system flush? shared_pool;

System altered.

??先創建一個快照：

SQL> executedbms_workload_repository.create_snapshot();

??TPCC 測試

在之前同等的20個virtual 用戶下，根本無法壓到最大值：

修改成120個virtual user：

再創建一個AWR 快照：

SQL> executedbms_workload_repository.create_snapshot();

PL/SQL procedure successfully completed.

SQL> @?/rdbms/admin/awrrpt.sql

??AWR 數據

未完待續~（后接圖文第二篇）

總結

以上是生活随笔為你收集整理的云和恩墨大讲堂 | 基于PCIE 闪存卡的 Oracle 数据库使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。