Oracle 21c 中 Cell Flash Cache 已彻底移除，由 Smart Scan、Storage Index、PMEM 和 Database In-Memory 等存储层智能机制透明加速 I/O，不再支持相关参数、视图或手动配置。
oracle 21c 中 cell flash cache 已被弃用，无法再用于加速表空间 i/o —— 它在 exadata 环境中自 12.1 起就被 database smart flash cache（dsfc）逐步替代，而到 21c 时，dsfc 本身也已彻底移除，由更底层的存储智能（如 exadata storage index、smart scan、持久化内存 pmem 分层）接管加速职责。
为什么在 21c 上找不到 Cell Flash Cache 相关参数或视图
因为该机制只存在于早期 Exadata 存储服务器（X2–X4 系列），依赖专有固件和 cellcli 命令管理；21c 默认运行在 X9M 及之后硬件上，存储层完全由 Exadata Storage Server 的智能扫描引擎动态优化，不再暴露“Flash Cache”这类手动配置项。
常见误操作包括：
- 执行
ALTER SYSTEM SET db_flash_cache_file=...;→ 报错ORA-02065: illegal option for ALTER SYSTEM - 查询
V$FLASHFILESTAT或V$DB_CACHE_ADVICE→ 视图不存在或无数据 - 在
init.ora中设置db_flash_cache_size→ 启动时报ORA-00406: compatibility parameter value is too low（因 21c 兼容性最低为 21.0）
21c 中真正生效的 IO 加速机制是什么
不是靠“缓存开关”，而是靠存储层与数据库实例的协同感知。关键点如下：
-
Smart Scan自动跳过不匹配的存储块（基于 Storage Index 和 predicate 下推），减少网络和 CPU 开销 -
Exadata Hybrid Columnar Compression (EHCC)在存储层完成解压，仅传输必要列数据 -
Persistent Memory (PMEM)支持直接映射为SGA或redo log buffer的扩展区，绕过传统 DRAM→SSD 路径 -
Database In-Memory的inmemory_automatic_level=HIGH会自动将热列数据加载进内存，并按访问频次动态压缩冷数据
这些能力无需 DBA 手动绑定表空间或数据文件——它们对整个数据库透明生效。
如果仍需对特定表空间做 IO 行为干预，该怎么做
21c 中唯一可操作的粒度是「存储策略」和「I/O 调度权重」，但必须通过 Exadata 存储侧命令，而非数据库 SQL：
- 确认所在环境是否为 Exadata：
SELECT * FROM V$EXADATA_CELL;（若返回空，则Cell Flash Cache概念根本不适用） - 在存储服务器上使用
cellcli查看当前策略：list cell attributes flashCacheMode（输出通常为disabled或writeback，但该模式不作用于数据库表空间） - 对高优先级表空间对应的数据文件，可在 ASM 层设置
disk_repair_time和failure_group来影响 I/O 路径选择 - 启用
INMEMORY并指定压缩级别，比任何闪存缓存都更直接地消除物理读：ALTER TABLESPACE users INMEMORY;（注意：此语句实际作用于该表空间内已显式启用INMEMORY的对象）
真正容易被忽略的是：21c 的 IO 加速效果高度依赖存储服务器固件版本与数据库 COMPATIBLE 参数对齐。比如 COMPATIBLE=21.0 但存储固件停留在 20.1，会导致 Smart Scan 降级为传统全表扫描。检查方法是运行 SELECT * FROM V$CELL_CONFIG WHERE CONFVALUENAME = 'firmwareVersion'; 并比对 Oracle 文档中该版本支持的特性矩阵。
