转载

Exadata 第二篇

  什么是DBFC？ 

  DBFC，Database Buffer Flash Cache，是数据库服务器buffer cache的扩展，它是Oracle 11g的标准组件，作为数据库实例的二级buffer cache，它仅支持Solaris和Oracle Enterprise Linus。如果启用DBFC，只要在数据库服务器上增加一块闪存卡，并把它的使用权交给单个数据库实例即可。如果用户访问某个块，而它不在buffer cache中，在请求物理I/O之前，将会看一看它是否在DBFC中。当块从buffer cache中唤出时，（check point触发内存中的脏块写出）它们不是被简单第刷出，而是移动到DBFC中。 

  什么是ESFC？ 

  ESFC，Exadata Smart Flash Cache,是最有效的加速单块离散读访问的方法，为OLTP或混合工作负载应用服务的关键组件。但是它并不提供写回（write-back）缓存，无法提升写瓶颈系统的效果。数据仓库类型查询上，可以通过扫描磁盘和闪存，承担大量的吞吐量。尤其是在特定表上开启CELL_FLASH_CACHE属性为KEEP.  

  一个常见的误解是，将redo日志放在闪存存储上将会显著提升redo的写入性能，从而提升高并发事务系统的吞吐量。虽然对于小I/O的随机写，基于SSD的存储比传统磁盘更快，但是在一个高并发事务系统中，redo的写入并不是小I/O的随机写，因此将redo存放在SSD存储上，实际上并不会带来明显的收益。另外，SSD的写入机制会导致单次写入时间发生大量突变，可能出现个别写入时间比平均值慢好几个数量级的情况，这同样会导致非常繁忙的系统出现问题。所以，当决定把redo放在Exadata宝贵的闪存存储之前，应该进行测试，确保这么做是值得的。 

  磁盘缓存的工作方式：当收到一个查询请求，I/O子系统查询缓存，看看请求的数据是否在缓存中，如果数据在缓存中，它会返回给请求进程，如果请求的数据不在缓存中，需要从磁盘读取并返回给请求进程。 

  Exadata磁盘缓存方式：当收到一个查询请求，cellsrv程序同时向磁盘和闪存发送异步I/O请求。如果请求的数据在缓存中，请求在磁盘完成读取之前，将会通过闪存完成。但是Exadata启用智能扫描（SmartScan）一般会忽略ESFC，直接从磁盘读取。如果正在扫描的对象被指定为优先缓存（通过设置对象存储字句CELL_FLASH_CACHE属性为KEEP），即使是智能扫描也会视图从闪存中读取。 

  alter table kso.skew3 storage(cell_flash_cache keep);  <==速度更快，出现大量的cell flash cache read hits 

  alter table kso.skew3 storage(cell_flash_cache default); 

  ESFC策略：对象是否缓存在ESFC中是由存储软件的自动缓存策略决定的。通过设置对象存储字句的CELL_FLASH_CACHE属性，覆盖特定数据库对象的自动缓存策略。 

  NONE:从不缓存该对象 

  DEFAULT:自动缓存机制生效，默认值 

  KEEP:优先缓存。这个用法改变了智能扫描的默认行为，允许它们可以同时从磁盘和缓存中读取数据。 

  ESFC写操作：写操作会绕过缓存直接写入磁盘。如果判断这部分数据适合缓存，会在写入磁盘的过程中复制到缓存中 

  监控ESFC 

  在v$sysstat中的cell flash cache read hits与ESFC相关。统计值反映了自从会话建立以来的会话累计值。使用该信息的方法就是在要关注的SQL语句执行前后，查看该值得变化。在存储服务器上通过cellcli工具提供了更多的诊断信息，但这些信息只来自于单独的存储节点，没有全面的诊断信息可以覆盖整个存储网络。--当前版本不知道是否已经改进？ 