Smart Flash Cache on Exadata(3)—Write-back

在Exadata image 11.2.3.2.0以前的版本中，仅支持Write Through模式，该模式的读写流程已经在”Smart Flash Cache on Exadata(2)—Write through“种讨论过了。需要注意的是：这个模式的flash cache在Cellsrv重启之后Flash Cache上的数据变成Invalid，而Write-Back模式则不会，这是他们的工作原理决定的……。

从Image 11.2.3.2.0版本开始，原来仅支持Write Through 模式的Flash Cache现在可以支持Write Back模式了。但是Wtite Back模式不是缺省属性（缺省值还是Write through模式），需要手工修改来启用这个特性。Write Through和Write Back这两个模式之间的切换需要重启Cellsrv服务，否则会报错：

CELL-01552: Stop CELLSRV. Cell flashCacheMode cannot be modified while CELLSRV is running.

将Smart Flash Cache修改为Write Back模式的具体方法如下：

1.查看当前FlashCache的工作模式
list cell 命令来查询flashcachemode属性（缺省是WriteThrough模式）：
CellCLI> list cell attributes name, flashcachemode
         dm02cel02        WriteThrough
 

2.enable Write-back模式

Drop FlashCache
cellcli -e drop flashcache
  
停止cellsrv服务
cellcli -e alter cell shutdown services cellsrv
 
修改flashcachemode
cellcli -e alter cell flashCacheMode=WriteBack
 
启动cellsrv
cellcli -e alter cell startup services cellsrv

创建FlashCache
cellcli -e create flashcache all

另外，要支持Write Back模式需要以下版本的介质（老版本的cellcli上使用DESCRIBE CELL命令也看不见flashCacheMode这个属性）：
 DB Patch for Exadata 11.2.0.3.x BP 9以上
 推荐Exadata 11.2.3.2.x + patch 16042459（取代了以前的patch 15841041），具体请参考MOS NOTES 1515324.1和 1485475.1）。
 patch 16042459的主要修复了如下问题，具体请参考MOS NOTES 1485475.1和1270094.1：

Write-back Smart Flash Cache fixes：
	。Systems running with Write-back Smart Flash Cache enabled should upgrade to this release (or later).
	。Note that a subset of the Write-back Smart Flash Cache fixes were backported andsupplied in one-off patch 16003324 (which superseded 15887843 and 15841041) for Exadata 11.2.3.2.0 to address Exadata critical issue EX11. Patch 16003324 is not required for 11.2.3.2.1. No
separate action during upgrade is required if patch 16003324 (or 15887843 or 15841041) is already installed.

另外，如果没有打patch的话，11.2.3.2.1版不带上面的FlashCacheMode选项。

顺便说一句，image 11.2.3.2.0 是X3-2出厂预设的最早版本。从2013年3月份左右，X3-2的image版本已经是11.2.3.2.1这个相对稳定的版本了。如果是X2或者以前的机器，那么可以升级image到指定的版本（11.2.3.2.0以上，并且apply patch 16003324），具体的更新信息请参考MOS NOTES 888828.1.

X3系列（image 11.2.3.2.0以后的版本）Exadata Smart Flash Cache Write-Back的特点：
1. 提高Write操作在多个场景的性能
 频繁更新表或索引的Case
 X3的话，可以达到磁盘20倍的Write IOPS
 V2或X2的话、磁盘10倍的Write IOPS

2. 对Database的Write IO直接缓存到flash
 Block根据LRU算法进行缓存
 缓存以后，Read与Write都在缓存上操作
 Block老化后再写入磁盘

3. 智能化缓存
 在不手工指定keep的情况下，只会缓存频繁访问的小表（非全表扫描的），他有一个算法，后面会具体描述
 以下IO不被缓存:
–Backup、DataPump I/O
–临时表空间的I/O
–Direct path insert（未设置Keep的对象）
–表的全扫描（未设置Keep的对象）
–表空间的格式化

4. Write Back模式的智能化缓存
 Write Back模式实现了永久性Write缓存（重启不丢失）
 Crash Recovery也更快
 Flash无需Recovery
 Data Guard的redo apply也更快（Redo Apply是依赖Write I/O的，据说速度大概是原来的3倍）
 Flash卡的故障由Exadata的ASM自动透明管理，缓存的内容通过其他Cell的镜像数据来进行恢复

Exadata Smart Flash Cache Write-Back:
Flash Cache作为Cell中磁盘的缓存，其冗余性由ASM来保障，其读写也是以4MB的AU为单位进行条带化和镜像的。Flash Cache的数据跨越多个Fail group（分布在各个Cell）写入primary copy和mirror copy（类似于磁盘数据）。

1.Flach Cache 总是作为磁盘缓存，冗余性由ASM来保障：

更新数据到DB buffer Cache，然后DBWR进程发起写数据的请求通过iDB协议给Cellsrv，Cellsrv收到请求后，直接写入Flash Cahche。注意DBWR进程会写两份数据，一个是Primary copy，一个是Secondary copy，流程都一样（这是ASM新特性的机制保证的）。此时，磁盘上依然保留着旧数据，当数据age out后，会被同步到磁盘。而这期间，flash cache的数据跟磁盘数据的工作模式一样：都是ASM来保证的。

2. 读数据的时候，直接读取Flash上的Primary Copy：

客户端发出请求，Server Process进程将请求通过iDB协议传给Cellsrv，Cellsrv检测到Flash Cache的Primary copy，于是将这个数据返回给server process进程。因此，读的时候都是直接读取Flash上的Primary Copy，Mirror Copy一般在Read的时候不需使用，当Secondry copy
数据Age Out的时候会被写入磁盘。当然，你也可以手工将数据agent out，以触发将flash cache写入磁盘的操作。

3、Backup 或 ASM Diskgroup恢复的时候，读取最新的数据：

 磁盘上有最新的数据的话，则从磁盘读取
 只在Flash cache上有最新的数据的话、从Flash cache读取。
 数据的写入则在Disk执行，这类IO不被缓存。

4、读取时发生的Flash cache数据的故障切换：

客户端发出请求，Server process进程将请求发给Cellsrv，Cellsrv发现flashcache有最新的数据，同时也发现这个flash cache出现故障了，不可读取，于是就直接从其他Cell的磁盘读取镜像数据。这个过程中，Cellsrv会直接自动重定向到保存着最新数据的Cell，因此不会返回应用错误。
这里别忘记了，上面“2. Read的时候，直接读取Flash上的Primary Copy”的时候介绍了，当数据age out后，会被从flash cache写入磁盘，或者手工出发一个age的操作，也会将数据同步到磁盘。

5、Resilvering Rebalance：

Flash发生故障时、将利用其他Cell上的镜像数据采取称之为”Resilvering”的数据处理。
这个操作不需要像磁盘一样手工做Drop disk和Add disk那样的Rebalance处理，但是你仍然可以通过 v$asm_operation 查询状态，并且其自动Rebalance的操作跟disk的类似，其Rebalance power可以通过初始化参数asm_power_limit、或者alter diskgroup power语句来影响。

下面是ASM的alert.log中将会记录resilvering rebalance操作：

Fri Nov 02 16:27:11 2012
NOTE: repairing group 2 file 268 extent 0
Errors in file /u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_r000_123901.trc:
ORA-27603: Cell storage I/O error, I/O failed on disk o/192.168.20.54/DATA_L_CD_07_test04 at offset 24683479040 for data length 1048576
ORA-27626: Exadata error: 223 (Block needs to be resilvered)  提示块需要resilvering
WARNING: Read Failed. group:2 disk:41 AU:5885 offset:0 size:1048576
path:o/192.168.20.54/DATA_L_CD_07_test04
         incarnation:0xe9688e67 synchronous result:'I/O error'
         subsys:OSS iop:0x7f2b7246edc0 bufp:0x7f2b7235de00 osderr:0xdf osderr1:0x0
SUCCESS: extent 0 of file 268 group 2 repaired - all online mirror sides found readable, no repair required
Fri Nov 02 16:27:19 2012
Starting background process XDWK

XDWK是XD上ASM特有的进程，即Exadata Automation Worker进程，他负责执行由XDMG后台进程发起的请求。比如对磁盘进行ONLINE , DROP, ADD等操作的时候，XDMG进程就会发出请求让XDWK进程去具体落实了。XDWK进程在inactive 5分钟后，自动stop。简单的说，就是XDMG是监工，负责监控disk和cell的状态，当他们需要online，drop，add等操作的时候，XDMG就会去启动或者唤醒XDWK进程来干活)

Fri Nov 02 16:27:19 2012
XDWK started with pid=39, OS id=123956
SQL> /* Exadata Auto Mgmt: Resilver diskgroup */   自动执行resilvering rebalance
alter diskgroup DATA_L
  rebalance nowait
NOTE: GroupBlock outside rolling migration privileged region
NOTE: requesting all-instance membership refresh for group=2
…..
SUCCESS: /* Exadata Auto Mgmt: Resilver diskgroup */

可以使用list griddisk查看当前flash cache使用的flash disk的相关信息：

X3-2的每块Flash Card（每块Card内有4个Flash Module）的数据映射到12块Celldisk其中的3块之上，这样的算法是为了最大化保护数据（就如同最小的ED配置是3个cell一个道理）。

可以使用“list griddisk attributes name, cachedby”命令查看：

出现故障时的状态：

待续……