Oracle 12c-23c 核心新特性培训文档

原创张超 2026-03-31

Oracle 12c-23c 核心新特性培训文档

一、培训总览

1.1 培训目标

• 系统掌握Oracle 12c至23c期间的核心新特性，明确各特性的迭代逻辑、核心价值及适用场景；

• 熟练掌握关键特性的实操方法，能够结合业务场景落地应用，提升数据库运维效率、性能及安全性；

• 理解Oracle数据库生命周期管理规范，掌握特性升级与版本适配的核心要点；

• 适配医疗、互联网等多行业需求，重点掌握高可用、安全、性能优化类特性的落地技巧。

1.2 培训对象

Oracle数据库管理员（DBA）、数据库运维工程师、开发工程师，需具备Oracle基础运维与SQL操作能力，适合从12c向高版本升级的技术人员学习。

1.3 培训时长

1天（6小时），以“特性讲解+实操演示+疑问答疑”为主，重点突破高频使用特性，兼顾理论与落地。

1.4 前置准备

• 环境：Oracle 19c/21c/23c数据库环境（单机/集群均可）、SQL Developer或PL/SQL Developer工具；

• 权限：具备SYSDBA权限，可执行创建表、索引、审计策略、配置ADG等操作；

• 资料：本培训文档、Oracle官方特性手册（精简版）、实操命令清单。

二、核心新特性详解（按版本迭代+功能分类）

2.1 性能优化类特性

2.1.1 In-Memory Column Store（IM 列存储）

核心定位：Oracle 12c引入的高性能存储特性，后续版本持续优化，核心是将表数据以“列存储”模式加载到内存中，与传统行存储形成互补，大幅提升复杂查询、聚合分析的性能。

核心价值：

• 突破行存储瓶颈：传统行存储适合OLTP高频增删改场景，IM列存储适合OLAP分析场景（如统计报表、多表关联聚合），查询速度提升10-100倍；

• 内存智能管理：支持自动将热点表、高频查询表加载到IM列存储，无需手动干预，且不占用SGA额外内存（独立的IM内存池）；

• 兼容现有业务：无需修改应用SQL，数据库自动判断查询场景，选择行存储或列存储执行，对应用透明。

实操演示：

-- 1. 启用IM列存储（需重启数据库）
ALTER SYSTEM SET INMEMORY_SIZE = 2G SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

-- 2. 为表启用IM列存储（全表加载）
ALTER TABLE medical_reports INMEMORY; -- 医疗场景：检查报告表，适配高频统计分析
-- 或指定部分列加载
ALTER TABLE patients INMEMORY (patient_id, name, id_card) NO INMEMORY (create_time);

-- 3. 查看IM列存储加载状态
SELECT table_name, inmemory_status, bytes/1024/1024 AS im_size_mb
FROM v$im_user_segments;

-- 4. 验证查询性能（对比行存储与列存储）
-- 列存储查询（聚合分析，速度更快）
SELECT dept_id, COUNT(*) AS patient_count
FROM patients INMEMORY
GROUP BY dept_id;

适配场景：医疗行业的病历统计、检查报告分析、科研数据批量查询；互联网行业的用户行为分析、订单统计等。

2.1.2 Automatic Indexing（自动索引）—— 19c 引入

核心定位：Oracle 19c推出的智能化索引管理特性，替代人工创建、维护索引，数据库自动识别高频查询语句，创建、使用、删除索引，降低DBA运维成本，避免索引冗余或缺失。

核心价值：

• 减负增效：无需DBA手动分析SQL、创建索引，自动适配业务查询负载变化；

• 智能优化：自动判断索引有效性，对无效、冗余索引进行标记或删除，避免索引过多导致的DML性能下降；

• 透明化操作：索引的创建、使用、删除对应用透明，不影响业务正常运行，支持手动干预调整。

实操演示：

sql
-- 1. 启用自动索引（全局启用）
ALTER SYSTEM SET AUTO_INDEX_MODE = ON SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

-- 2. 查看自动索引状态
SELECT index_name, status, auto_index_status
FROM dba_auto_indexes;

-- 3. 手动干预：禁止自动索引对某张表生效（如医疗敏感表）
ALTER TABLE patients NO AUTO INDEX;

-- 4. 查看自动索引建议
SELECT recommendation, rationale
FROM dba_auto_index_recommendations;

注意事项：核心业务表（如医疗HIS系统的患者表、订单表）可结合手动索引，自动索引适合非核心、查询模式多变的表；不支持JSON列、向量列的自动索引创建。

2.2 高可用类特性（Active Data Guard 增强）

Active Data Guard（ADG）是Oracle高可用核心方案，从12c到21c持续增强，核心目标是提升备库可用性、性能，降低主库压力，适配7×24小时业务场景（如医疗核心系统、金融交易系统）。

2.2.1 12c 增强：Far Sync Instance（远同步实例）

核心价值：解决“零数据丢失”与“主库性能”的矛盾，在主库与备库之间增加Far Sync实例，主库将redo日志同步到Far Sync实例（同步模式，确保零数据丢失），Far Sync实例再异步同步到备库，避免主库直接异步同步备库导致的数据丢失，同时不影响主库性能。

核心优势：

• 零数据丢失：主库与Far Sync实例采用同步模式，redo日志确认写入Far Sync实例后，主库才提交事务；

• 零性能影响：Far Sync实例仅存储redo日志，不执行介质恢复，轻量无压力，主库无需等待备库恢复完成；

• 异地容灾适配：适合主备库跨地域部署（如医疗集团总部分院、跨城市容灾），降低跨地域网络延迟对主库的影响。

2.2.2 19c 增强：ADG DML Redirection（DML重定向）

核心价值：允许用户在备库执行DML操作（insert、update、delete），数据库自动将DML操作重定向到主库执行，执行完成后，主库的redo日志同步到备库，备库自动应用，实现“备库只读+DML重定向”，降低主库查询压力。

实操演示：

sql
-- 1. 备库启用DML重定向（需ADG正常运行）
ALTER SESSION ENABLE ADG_DML_REDIRECTION;

-- 2. 备库执行DML操作（自动重定向到主库）
INSERT INTO patients (patient_id, name, id_card)
VALUES ('P20240001', '张三', '110101199001011234');

-- 3. 备库查询验证（主库执行后，备库同步）
SELECT * FROM patients WHERE patient_id = 'P20240001';

适配场景：医疗场景中，医生在备库查询患者病历并补充信息（DML操作），无需切换到主库，提升操作效率，同时减轻主库压力。

2.2.3 21c 增强：ADG with In-Memory（备库实时分析）

核心价值：将IM列存储与ADG结合，备库可启用IM列存储，加载热点数据，实现“备库实时分析+主库OLTP”分离，彻底释放主库性能，同时保证分析数据的实时性（与主库数据延迟秒级）。

核心优势：

• 实时分析：备库数据与主库同步，分析结果实时准确，无需批量同步数据；

• 负载分离：主库专注于OLTP高频增删改（如患者挂号、缴费），备库专注于OLAP分析（如病历统计、科室绩效分析）；

• 资源复用：无需额外部署分析库，利用备库资源实现分析需求，降低硬件成本。

适配场景：医疗行业的实时病历分析、科研数据查询、医院运营报表生成；互联网行业的实时用户画像、订单分析等。

2.3 安全类特性

2.3.1 Unified Auditing（统一审计）—— 12c 默认启用

核心定位：12c引入，替代传统审计（Fine-Grained Auditing），提供统一的审计框架，集中管理所有审计日志，支持细粒度审计策略，满足合规要求（如医疗HIPAA、等保2.0）。

核心价值：

• 统一管理：所有审计日志集中存储在统一审计 trail 中，无需分散管理，便于查询、分析与归档；

• 细粒度管控：可针对用户、表、操作（select、insert、delete）、IP地址等设置审计策略，精准追踪敏感操作；

• 合规适配：支持审计日志加密、防篡改，满足医疗、金融等行业的合规审计要求，可追溯所有数据操作行为。

实操演示：

sql
-- 1. 创建审计策略（追踪患者病历查询、修改操作）
CREATE AUDIT POLICY audit_medical_operation
ACTIONS SELECT, UPDATE, DELETE ON medical_reports;

-- 2. 启用审计策略（对所有用户生效）
AUDIT POLICY audit_medical_operation;

-- 3. 查看审计日志（追踪操作人、操作时间、SQL语句）
SELECT event_timestamp_utc, db_user, object_name, sql_text, client_ip
FROM unified_audit_trail
WHERE object_name = 'MEDICAL_REPORTS';

-- 4. 禁用审计策略
NOAUDIT POLICY audit_medical_operation;

医疗场景适配：追踪医护人员对患者病历的查询、修改操作，实现操作可追溯，满足医疗数据隐私保护与合规要求，避免敏感病历数据泄露或篡改。

2.3.2 Data Redaction（数据脱敏）—— 12c 引入

核心定位：12c引入的敏感数据保护特性，可对数据库中的敏感字段（如身份证号、手机号、病历号）进行动态脱敏，不同权限用户看到不同数据，既保证数据可用性，又防止敏感信息泄露。

核心价值：

• 动态脱敏：无需修改数据存储，仅在查询时对敏感字段进行脱敏，不影响数据本身的完整性；

• 细粒度控制：可根据用户、角色、会话等设置脱敏规则，如管理员看到完整数据，普通用户看到脱敏后数据；

• 零应用侵入：无需修改应用代码，数据库层面自动实现脱敏，降低开发与维护成本。

实操演示（医疗场景）：

sql
-- 1. 创建数据脱敏策略（患者身份证号脱敏：显示前6位+后4位，中间隐藏）
BEGIN
DBMS_REDACT.ADD_POLICY(
object_name => 'patients', -- 患者表
column_name => 'id_card', -- 敏感字段（身份证号）
policy_name => 'redact_patient_idcard',
function_type => DBMS_REDACT.PARTIAL, -- 部分脱敏
function_parameters => '1,6,4', -- 从第1位开始，显示6位，再显示最后4位
expression => 'SYS_CONTEXT(''USERENV'', ''SESSION_ROLE'') != ''DOCTOR''' -- 医生角色看到完整数据
);
END;
/

-- 2. 普通用户查询（脱敏后）
SELECT patient_id, name, id_card FROM patients;
-- 结果：id_card显示为110101****1234

-- 3. 医生角色查询（完整数据）
SET ROLE DOCTOR;
SELECT patient_id, name, id_card FROM patients;
-- 结果：id_card显示完整18位

-- 4. 禁用脱敏策略
BEGIN
DBMS_REDACT.DROP_POLICY(object_name => 'patients', policy_name => 'redact_patient_idcard');
END;
/

医疗场景适配：对患者身份证号、手机号、病历隐私信息进行脱敏，普通运维人员、科研人员无法查看完整敏感信息，仅医护人员可查看，保护患者隐私，符合医疗数据安全规范。

2.4 运维效率类特性

2.4.1 Long Identifiers（长标识符）—— 12.2 引入

核心定位：12.2版本突破Oracle传统限制，将对象名（表、列、索引、视图等）的最大长度从30字节扩展至128字节，兼容PostgreSQL、MySQL等数据库的命名习惯，提升数据库设计的灵活性。

核心价值：

• 命名更规范：可使用更具描述性的对象名，如“medical_patient_clinical_examination_report”（医疗患者临床检查报告表），避免命名缩写导致的歧义；

• 跨库迁移便捷：从PostgreSQL、MySQL迁移到Oracle时，无需修改长对象名，降低迁移成本；

• 适配复杂业务：复杂业务场景（如医疗多系统集成）中，可通过长对象名区分不同系统、不同用途的对象，提升可维护性。

实操演示：

sql
-- 创建128字节长度的表名（医疗场景：患者临床检查报告表）
CREATE TABLE medical_patient_clinical_examination_report (
    report_id NUMBER PRIMARY KEY,
    patient_id VARCHAR2(20) NOT NULL,
    examination_type VARCHAR2(50) NOT NULL, -- 检查类型（CT、MRI等）
    examination_result CLOB, -- 检查结果
    create_time DATE DEFAULT SYSDATE
);

-- 创建长列名（如：患者检查报告诊断结论）
ALTER TABLE medical_patient_clinical_examination_report
ADD patient_examination_report_diagnosis VARCHAR2(200);

-- 创建长索引名
CREATE INDEX idx_medical_patient_examination_report_patient_id
ON medical_patient_clinical_examination_report(patient_id);

2.4.2 Autonomous Health Framework（AHF）—— 18c+ 引入并增强

核心定位：18c引入，是TFA Collector（跟踪文件分析器）的增强版，一套自动化的数据库健康管理框架，自动收集诊断数据、检测配置问题与性能瓶颈，降低DBA运维成本，实现“主动运维、提前预警”。

核心功能：

• 自动收集诊断数据：实时收集数据库日志、trace文件、性能指标、系统配置等数据，统一存储与管理，无需手动收集；

• 主动检测问题：自动检测数据库配置错误、性能瓶颈（如IO过高、会话阻塞）、集群异常等，生成预警信息；

• 自动分析与建议：针对检测到的问题，自动分析根因，并给出解决方案建议（如索引优化、参数调整）；

• 支持集群与单机：适配RAC集群、单机环境，可集中管理多个数据库节点的健康状态。

实操演示：

bash
# 1. 查看AHF版本（需root或oracle用户）
ahfctl version

# 2. 手动收集诊断数据（应急排查）
ahfctl collect --all

# 3. 查看健康检查报告
ahfctl healthcheck --database ORCL

# 4. 查看性能瓶颈预警
ahfctl alert --database ORCL

# 5. 查看诊断数据存储路径
ahfctl show config --data_dir

医疗场景适配：实时监控HIS、LIS、PACS等核心医疗系统的数据库健康状态，提前预警性能瓶颈或故障，避免数据库异常导致医疗业务中断，降低运维成本。

2.5 扩展性类特性

2.5.1 Sharding（分片）—— 12.1.0.2 引入，12.2 增强

核心定位：Oracle的分布式数据库解决方案，将大规模数据水平拆分到多个独立的数据库（Shard）中，每个Shard存储部分数据，通过Shard Director（分片控制器）实现应用透明访问，支持线性扩展，适配超大规模OLTP场景。

核心价值：

• 线性扩展：数据量增长时，只需增加Shard节点，无需修改应用代码，实现性能与容量的线性提升；

• 负载均衡：应用请求通过Shard Director自动路由到对应的Shard，避免单节点压力过大；

• 高可用：单个Shard故障，不影响其他Shard正常运行，应用可继续访问其他节点的数据；

• 透明访问：应用无需感知分片逻辑，如同访问单机数据库，降低开发与维护成本。

核心特性（12.2 增强）：

• 支持全局索引：跨Shard的全局索引，实现跨Shard的聚合查询、排序；

• 动态分片：支持在线添加、删除Shard，无需中断业务；

• 多分片策略：支持按范围（如时间）、哈希（如患者ID）、列表（如科室）等方式分片，适配不同业务场景。

适配场景：

• 医疗行业：大型医疗集团、区域医疗平台，患者数据、病历数据超大规模（千万级以上），需拆分存储，提升访问性能；

• 互联网行业：用户表、订单表等超大规模OLTP场景，需要线性扩展能力。

实操演示（简化版）：

sql
-- 1. 创建分片目录（Shard Catalog）
CREATE SHARD CATALOG DATABASE shard_catalog
USER shard_dba IDENTIFIED BY shard123;

-- 2. 配置分片策略（按患者ID哈希分片）
CREATE SHARDING KEY patient_id (NUMBER)
PARTITION BY HASH (patient_id)
PARTITIONS 4;

-- 3. 创建分片表（患者表）
CREATE TABLE patients (
    patient_id NUMBER PRIMARY KEY,
    name VARCHAR2(50) NOT NULL,
    id_card VARCHAR2(18) UNIQUE NOT NULL
) SHARDED BY (patient_id);

-- 4. 查看分片分布
SELECT shard_name, shard_key, status FROM dba_shards;

2.6 Oracle 数据库生命周期管理

核心定位：Oracle数据库从部署、升级、运维到退役的全生命周期管理规范，结合上述所有新特性，确保数据库在不同阶段的稳定性、安全性与性能，适配业务长期发展需求。

核心生命周期阶段与特性适配：

1. 部署阶段：选择合适版本（19c/21c/23c），启用Long Identifiers、IM列存储等特性，规划Sharding策略（超大规模场景）；

2. 运维阶段：利用AHF实现主动运维，Automatic Indexing优化性能，Unified Auditing与Data Redaction保障安全，ADG确保高可用；

3. 升级阶段：从低版本（12c/19c）升级到高版本（21c/23c），重点适配ADG增强、IM列存储优化、AHF升级等特性，确保业务平滑过渡；

4. 退役阶段：通过数据脱敏、审计日志归档，确保敏感数据安全，完成数据迁移与数据库退役，符合合规要求。

版本生命周期重点：

• 12c：长期支持版（已停止主流支持），核心特性为ADG Far Sync、统一审计、数据脱敏；

• 19c：长期支持版（当前主流），核心特性为ADG DML重定向、自动索引，适合生产环境长期部署；

• 21c：创新版，核心特性为ADG with In-Memory，适合需要实时分析的场景；

• 23c：最新长期支持版，整合所有特性，新增融合数据库能力，适合新系统部署或高版本升级。

三、实操练习（重点突破）

3.1 基础实操（必练）

1. 启用IM列存储，为患者表、检查报告表配置列存储，并验证查询性能；

2. 配置统一审计策略，追踪病历表的查询、修改操作，查看审计日志；

3. 创建数据脱敏策略，对患者身份证号进行脱敏，验证不同角色的访问效果；

4. 启用自动索引，执行高频查询，查看自动创建的索引及建议。

3.2 进阶实操（选练）

1. 配置ADG DML重定向，在备库执行DML操作，验证数据同步效果；

2. 使用AHF收集诊断数据，查看健康检查报告与性能预警；

3. 创建长标识符对象（表、列、索引），验证命名规范；

4. 配置简单分片策略，实现患者表的水平拆分。

四、常见问题答疑

4.1 特性适配问题

• Q：19c升级到21c，ADG需要重新配置吗？
A：无需重新配置，升级后ADG会自动适配新特性（如ADG with In-Memory），只需启用对应的功能即可。

• Q：数据脱敏会影响数据库性能吗？
A：影响极小，脱敏操作仅在查询时执行，且数据库会对脱敏操作进行优化，适合高频查询场景。

• Q：Sharding适合小型数据库吗？
A：不适合，Sharding适用于超大规模数据（千万级以上），小型数据库使用Sharding会增加运维复杂度，建议使用单机或RAC集群。

4.2 实操常见问题

• Q：启用IM列存储后，表数据没有加载到内存中？
A：需确保INMEMORY_SIZE参数配置正确，且表已启用INMEMORY属性，可通过v$im_user_segments查看加载状态，手动加载可执行ALTER TABLE 表名 INMEMORY MEMCOMPRESS FOR QUERY HIGH。

• Q：ADG DML重定向执行失败？
A：检查ADG主备库同步状态，确保备库处于MOUNT或READ ONLY状态，且会话已启用ADG_DML_REDIRECTION。

• Q：长标识符对象创建失败？
A：需确保数据库版本为12.2及以上，且对象名不包含特殊字符，长度不超过128字节。

五、培训总结

本次培训重点讲解了Oracle 12c至23c期间的核心新特性，涵盖性能优化（IM列存储、自动索引）、高可用（ADG增强）、安全（统一审计、数据脱敏）、运维效率（长标识符、AHF）、扩展性（Sharding）及生命周期管理，所有特性均结合实操演示，适配医疗、互联网等多行业场景。

核心重点：掌握各特性的核心价值与实操方法，结合自身业务场景（如医疗核心系统、超大规模数据存储）选择合适的特性落地，提升数据库运维效率、性能与安全性，同时遵循Oracle生命周期管理规范，确保数据库长期稳定运行。

oracle

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

Oracle 12c-23c 核心新特性培训文档

评论