Oracle Online Redo Log 能不能放在SSD 閃存卡上?(一)

發布時間:2016-05-31

SSD 的性能遠超SAS 盤,所以在數據庫中使用廣泛。但是online redo log 是否應該存放在閃存卡上一直是有爭議的話題。下面通過理論和實際的實驗,來測試這個問題。

1  Oracle 官方的建議
Alternative and Specialized Options as to Howto Avoid Waiting for Redo Log Synchronization (文檔 ID 857576.1)


在這篇MOS的文章中,提到如下一句話:
Also putting the SLOG on an SSD (Solid StateDisk) will reduce redo log latency further.  This will help improve theperformance of synchronous writes.
Oracle 建議把redo log 放在SSD上,這樣可以減少延時,提升同步寫的性能。
Troubleshooting: 'Log file sync' Waits (文檔 ID 1376916.1)


在這篇MOS文章中,Oracle 的建議如下。
If the proportion of the 'log file sync'time spent on 'log file parallel write' times is high, then most of thewait time is due to IO (waiting for the redo to be written). The performance ofLGWR in terms of IO should be examined. As a rule of thumb, an average time for'log file parallel write' over 20 milliseconds suggests a problem with IOsubsystem.
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 write performance is good on average, they may endure writepeaks which will highly increase waits on 'log file sync'.
(Exception to thiswould be for Engineered Systems (Exadata, SuperCluster and Oracle DatabaseAppliance) which have been optimized to 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 StateDisks write performance is good on average, they may endure write peaks whichwill highly increase waits on 'log file sync'.
Oracle 的意思是說SSD 寫性能很好,但是可能某個時刻出現寫高峰,從而導致更高的log file sync。注意這里是may,是可能。
SSD 分三種型號:SLC,MLC,TLC。

民用級的SSD 采用的是MLC和TLC,而采用TLC,容量大,因為受民用價錢的約束,民用級的SSD, OP值都比較低,一般在10%以內,當滿盤寫之后,性能確實會下降很多,而且寫放大系數也會比企業級的高,在這種情況下,確實可能出現oracle 說的may的可能性。

但企業級的PCIE SSD 采用的是MLC,OP值達到27%,OP值高,閃存卡的性能會更好,寫放大系數也可以控制的更低,所以在這種情況下,不會出現oracle說的write peaks。
這里的OP即Over-Provision,是閃存卡的冗余空間,舉個例子,假設用的是一張6.4T 的 PCIE SSD,那么在27%的op下,實際的物理容量是8128G。大的OP可以給閃存卡提供更好的性能和磨損均衡。
另外一方面需要注意,online redo log 是連續的順序寫,SSD 在順序寫情況,與傳統的SAS盤比,只能提升幾倍的性能,但在隨機寫的情況,能提升幾十倍。但不管怎么樣,都比SAS 盤的性能好,重要的,是延時低。這個關鍵。
所以在使用企業級的PCI-E SSD的情況下,不會出現oracle說的write peaks 帶來的log file sync 增加,只會減少延時,提升性能。


2  4KOnline Redo Log
在MOS 中,Troubleshooting: 'Log file sync' Waits (文檔 ID 1376916.1)。 Oracle提到XD 上redo log 是放在SSD盤的。然后有另外一篇MOS文章:
Using 4k Redo Logs on Flash andSSD-based Storage (文檔 ID 1681266.1)


2.1  扇區大小
現在的存儲,尤其是基于SSD的存儲,都支持4k的扇區,而傳統是512 bytes的扇區。扇區即每次最小IO的大小。
4k扇區有兩種工作模式:native mode和emulation mode。
Native mode,即4k模式,所有物理和邏輯的block完全一樣,都是4096 bytes。但native mode 的缺點是需要操作系統和軟件(如DB)的支持。 Oracle 從11gR2 之后,就支持4k IO操作,操作系統方面, Linux內核在2.6.32 之后都支持4k IO操作。
emulation mode:也稱512e。在該模式下,物理塊還是4k,但邏輯塊是512 bytes。這種模式主要是為了向后兼容性。但在該模式下,底層物理還是4k進行操作,所以就會導致Partial I/O 和4k對齊的問題。
在emulation mode下,每次IO操作大小是512 bytes,底層存儲平臺的IO操作必須是4k大小,如果要讀512bytes的數據,實際需要讀4k,是原來的8倍,這個就是partial IO。另外在512 bytes寫的情況下,實際也是先讀4k的物理block,然后更新其中的512 bytes的數據,在把4k寫回去。所以在emulation mode下,增加的工作會增加延時,降低性能。
在Oracle 數據庫的文件中,默認情況下,datafile的block 是8KB,控制文件是16KB,所以都沒有partial IO的問題,唯有online redo log,默認是512 bytes,存在partial IO的問題。
2.2  Online Redo Logs
默認情況下,Oracle online redo log file 是512 bytes的block size。從Oracle 11gR2 開始,可以修改redo log 的Blocksize為512,1024,4096。
如:
alter database add logfilegroup 5 size 100m blocksize 4096;
當然,前提條件是底層的存儲支持4k扇區。對于native mode的存儲,修改redo log block size 沒有問題。如果是emulation mode存儲,物理上4k扇區,但邏輯上是512 bytes扇區,那么修改就可能會觸發如下錯誤:
ORA-01378: The logical blocksize (4096) of file DATA is not compatible with the disk sector size (mediasector size is 512 and host sector size is 512)
只要確認底層存儲物理是4k的扇區,那么可以設置_disk_sector_size_override參數為true,來覆蓋扇區的設置。該參數支持動態修改:
ALTER SYSTEM SET“_DISK_SECTOR_SIZE_OVERRIDE”=”TRUE”;
Fdisk確認扇區:
[root@dave ~]# fdisk -lu /dev/dfa
Note: sector size is 4096 (not 512)
Disk /dev/dfa: 3454.0 GB, 3454011441152 bytes
32 heads, 32 sectors/track, 823500 cylinders,total 843264512 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes /4096 bytes
I/O size (minimum/optimal): 4096 bytes /65536 bytes
Disk identifier: 0x00000000
3  實際測試
3.1  測試環境
--內存:
[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.6G3.6G    0 100% /mnt
/dev/dfa3.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。
3.2  Online redo log 在PCIE 閃存卡的測試
3.2.1  查看online redo log
SQL>select group#,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
3.2.2    先創建一個快照:
SQL>execute dbms_workload_repository.create_snapshot();
3.2.3    TPCC 測試


在創建一個AWR 快照:
SQL> execute dbms_workload_repository.create_snapshot();
PL/SQL procedure successfully completed.
生成AWR 報告:
SQL>@?/rdbms/admin/awrrpt.sql
3.2.4  AWR數據
我們這里只看2個部分:Load Profile 和Top 10 Foreground Events by Total Wait Time

久久只有这里有精品热久久