数据库管理-第116期 Oracle Exadata 06-ESS-下（202301114）

距离上一次正儿八经的技术分享又过了整整一周了，距离上一期Exadata专题文章也过了11天了，今天一鼓作气把ESS写完，毕竟明天又要飞北京了。

1 Smart Scan

其实之前在数据库管理-第六十一期 Exadata是否需要索引（20230314）中简单介绍过smart scan，数据的查询和检索处理可以卸载(offload)到Exadata存储节点：

负载下沉到存储服务器，充分发挥存储的计算能力
存储转变为智能存储，仅返回需要的数据 – 行过滤，列过滤
减少数据返回量，减少IO通道需求
减少数据库服务器CPU, 内存要求

Smart Scan自动优化使用直接路径读的full table scans, fast full index scans和fast full bitmap index scans，即并行操作和大规模顺序扫描。其实最简单的触发offload的方式就是SQL使用并行。

在Exadata上数据库的SQL Monitor中，可以看到语句的存储offload效率，具体执行计划中也能看到TABLE ACCESS STORAGE FULL的操作内容。

2 Storage Index

存储索引是一个透明且自动维护，无需任何额外开销即可消除减少IO的特性：

存储索引不像Oracle的传统B-tree或位图索引那样存储在数据库中。它们无法识别在给定列中具有特定值的一组记录。是存储服务器软件的一个功能。
存储索引的工作原理是为磁盘存储单元存储最小和最大列值，默认情况下为1 MB，称为区域索引。
执行Smart Scan时SQL谓词会传递到存储节点，因此存储软件可以在执行请求的I/O之前，根据存储索引元数据（最大值和最小值）检查谓词。将跳过任何不可能具有匹配行的存储区域。

3 EHCC

EHCC，混合列压缩兼顾性能和压缩比

占用磁盘空间更小
压缩下获得更好的性能
– 基于压缩数据进行扫表
– 可在内存、Flash中保留更多数据
– 从磁盘到内存、Flash数据传递时使用更少IO
在查询更快的前提下平均节省10倍空间
– QUERY：5-10X， ARCHIVE MODE：10-15X

EHCC语法：

Warehouse Compression Syntax:
CREATE TABLE emp (…) COMPRESS FOR QUERY [LOW | HIGH];
Online Archival Compression Syntax:
CREATE TABLE emp (…) COMPRESS FOR ARCHIVE [LOW | HIGH];

不同的压缩方式采用的算法不同：query low使用LZO算法，query high和archive low采用ZLIB算法，archive high采用BZIP2算法。

Exadata特有的压缩：compress for query|archive low|high –只有直接路径插入的数据才会被压缩，普通的DML操作会降低压缩等级。
在混合列压缩中，多个数据块组成一个压缩单元CU（Compression Unit），压缩单元中数据是按列的形式存储的，而不是将整个表的数据按列的形式来存储，所以是混合列压缩，而压缩单元中包含的数据块的个数也不是固定的，由压缩模式，被加载数据的压缩率等因素来决定；使用了混合列压缩的表，普通的insert数据插入，新增的行记录会降级成OLTP压缩模式（此时对表进行一个move操作重组一下表就会变成混合列压缩，如果又进行DML操作则可能又会被退化为OLTP压缩，因此HCC的表应该尽可能少的进行DML操作），数据只有在以下几种方式加载时才会触发混合列压缩：

直接路径insert语句(/*+ append */)；
并行的DML语句；
直接路径sqlloader;
CTAS(Create Table As Select)方式。

HCC可以在表级别，分区级别及表空间级别来指定。
可以在创建表时指定HCC，也可以把现有的表修改为HCC的表，此时表中的原数据没有进行压缩，需要对表执行一下move重组才会使已有的数据进行混合列压缩。

4 智能存储处理流程

综合前面提到的Smart Scan, Storage Index和EHCC，在Exadata中将一般存储智能化之后，数据的处理流程变为下图所示：
在这里插入图片描述
在充分利用硬件特性与资源，基于Oracle对自己数据库存储充分的了解，使用ESS极大加快了Exadata上的数据查询效率。

5 Smart Flash Cache

智能闪存缓存与回写：
在这里插入图片描述
将热数据缓存在PMEM/XRMEM或Flash Card中，即可以加速数据查询效率，也可以加速数据库写的效率。
监控数据是否被cache：

SQL> SELECT data_object_id FROM DBA_OBJECTS object_name='EMP'; 
	DATA_OBJECT_ID
	---------
	57435
CellCLI> LIST FLASHCACHECONTENT WHERE objectNumber=57435 DETAIL 
	cachedKeepSize: 0
	cachedSize: 495438874
	dbID: 70052
	hitCount: 415483
	missCount: 2059
	objectNumber: 57435
	tableSpaceNumber:

保证热数据被cache：

SQL> ALTER TABLE xxx STORAGE (CELL_FLASH_CACHE KEEP);

注意：cell_flash_cache有三个值：none（永不放到闪存），default（按策略来放），keep（尽可能的放到闪存）；为了防止keep属性的对象占满整个flashcache，系统限制有keep属性的对象占用的总空间不得超过flashcache的80%，为了防止一些极少访问却拥有keep属性的对象无限制的占用flashcache，系统会定期的使用淘汰策
略来剔除这些对象。一般无需人为干预，默认即可。
从 Oracle Exadata 系统软件 23.1.0 版开始，XRMEM (PMEM) 缓存只能以 Write-through 模式运行。

6 Smart Flash Logging

智能闪存日志：
在这里插入图片描述
即日志哪先写好，即返回事务成功，无需人为配置与干预，加速写操作。

7 IORM

IO资源管理：
存储资源池：数据动态重分布，消除I/O分布热点块，数据库平台可不断线性扩展，数据自动分布，提供最高性能和高可用性

当新硬件添加时均衡仍然得以保持
当旧硬件移除时均衡仍然得以保持
当硬件出故障时均衡仍然得以保持
单块磁盘损坏/单个storage cell损坏都能忍受

IORM可以根据承载业务数据库的重要程度、IO要求细粒度控制每个数据库的存储IO性能，当然Exadata本身强大的IO性能，在绝大多数环境是无需对IORM进行配置的。可以通过CELLCLI或EMCC对IORM进行配置：