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
