Exadata 第二篇
2015-10-08 14:32
169 查看
什么是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工具提供了更多的诊断信息,但这些信息只来自于单独的存储节点,没有全面的诊断信息可以覆盖整个存储网络。--当前版本不知道是否已经改进?
什么是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工具提供了更多的诊断信息,但这些信息只来自于单独的存储节点,没有全面的诊断信息可以覆盖整个存储网络。--当前版本不知道是否已经改进?
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29047826/viewspace-1813482/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29047826/viewspace-1813482/
相关文章推荐
- git config命令使用第二篇——section操作,多个key值操作,使用正则
- WEB监控系列第二篇:web监控搭建——graphite+statsd(服务器上搭建)
- NesC学习经验总结 第一篇和第二篇
- Android App 开发 设计模式第二篇:Adapter Pattern适配器模式
- Script:收集Exadata诊断信息
- 数据仓库:Oracle Exadata和Netezza的比较
- backbone js学习笔记之第二篇Model层
- 自己动手写一个JQuery插件(第二篇)(转)
- Android UI开发第二篇——多级列表(ExpandableListView)
- GOASM官方帮助翻译第二篇之$ and $$
- android调用第三方库——第二篇——编写库android程序直接调用第三方库libhello.so
- SVN第二篇-----命令集合
- linux设备驱动第二篇:构造和运行模块
- Java系列--第二篇 基于Maven的Android开发HelloAndroidWorld
- Javascript本质第二篇:执行上下文
- Authentication and Integration 第二篇:单点登录SSO的实现原理
- Java中JNI的使用详解第二篇:JNIEnv类型和jobject类型的解释
- Android开源项目第二篇——工具库篇
- OSwatcher on Exadata
- Apriori算法第二篇----详细分析和代码实现