企业官网建设流程全解析

Oracle AI Database 26ai 内核深度解析：特性实现、诊断命令与极致高可用架构

从"数据库支持AI"到"AI原生数据库"，Oracle 26ai 是一次架构级别的范式转移。本文将深入内核，逐一拆解每个重磅特性的底层实现机制、精准的诊断查询命令，以及在实际运维中的落地实践。

引言：不只是版本号变更，而是内核的重构

Oracle AI Database 26ai 并非在 23ai 上简单叠加功能，而是将 AI 推理、向量计算与事务处理深度耦合进同一套数据库内核。Larry Ellison 在 2025 Oracle AI World 上明确其定位：无需数据搬运（No Data Movement）——企业无需为了 AI 单独构建数据管道，一切在数据库原地完成。

对于 DBA 和架构师而言，这意味着我们需要从"管理数据"转变为"管理数据 + 模型 + 向量 + 代理的融合基础设施"。本文涵盖的每一个特性，其背后都有对应的内部进程（如 LREG、LMS、CSSD）、内存结构（如 MGA、Vector Pool）和诊断视图（如V$、X$表）作为支撑。

26ai 包含超过300项新特性，覆盖 AI、开发者生产力、性能和企业安全等多个领域。其最核心的突破在于：OLTP事务处理与AI向量运算可以在同一数据库引擎中并行运行，无需单独搭建AI堆栈、无需数据复制、无需同步开销。

Part 1：AI 原生内核——向量不是附加品，而是原生公民

1.1 向量数据类型与内存管理机制

内核实现：

在 26ai 中，VECTOR成为与VARCHAR2、NUMBER平级的一级数据类型。其存储结构分为元数据头（长度、维度、类型）和二进制浮点数数组。对于高频访问的向量，数据库利用向量内存池（Vector Memory Pool）进行缓存，该池由参数VECTOR_MEMORY_SIZE控制，独立于 SGA 的 Buffer Cache 和 Shared Pool，避免了向量检索对事务缓存造成冲击。

Oracle 26ai 引入了多项向量搜索增强：

• 分布式 HNSW 索引：HNSW 索引可在 RAC 数据库的所有实例间无缝扩展，向量内存池可跨越多个 RAC 实例

• 混合向量索引与混合搜索：支持将向量与关系型、文本、JSON、图和空间数据在同一查询中融合检索

• 标量量化压缩：可用于压缩 HNSW 索引，在几乎不损失精度的前提下降低存储需求

• BINARY向量支持与稀疏向量PL/SQL支持

• Sharding支持：AI Vector Search现已支持分片架构

诊断命令：

-- 查看向量内存池的分配情况（内核级） SHOW PARAMETER VECTOR_MEMORY_SIZE; -- 查看当前实例向量内存使用率（来自V$SGASTAT） SELECT POOL, NAME, BYTES/1024/1024 AS MB FROM V$SGASTAT WHERE NAME LIKE '%Vector%'; -- 查看已创建的所有向量索引详情（HNSW/IVF） SELECT INDEX_NAME, INDEX_TYPE, VECTOR_INDEX_TYPE, VECTOR_DISTANCE_METRIC FROM USER_INDEXES WHERE VECTOR_INDEX_TYPE IS NOT NULL;

1.2 分布式 HNSW 索引与混合搜索

内核实现：

HNSW（Hierarchical Navigable Small World）索引在 RAC 集群中采用"分区共识"策略。当在一个节点创建索引时，该节点写入检查点至磁盘，其他节点在启动或首次查询时快速复刻（Fast Fork）内存中的图结构。针对 26ai 新增的稀疏向量（Sparse Vector），内核采用了专门的倒排索引压缩技术，大幅降低存储开销。

混合搜索（Hybrid Search）的实现依赖DBMS_HYBRID_VECTOR包，它允许在同一 SQL 中融合全文搜索（Oracle Text）的CONTAINS子句和向量相似性计算的VECTOR_DISTANCE函数。内核通过成本优化器（CBO）生成最优的联合执行计划，支持使用全文搜索与向量相似性搜索的组合来索引和查询数据。

诊断命令：

-- 创建包含VECTOR类型的表 CREATE TABLE vector_data ( id NUMBER, embedding VECTOR(25, FLOAT32) ); -- 创建HNSW向量索引（正确语法） CREATE VECTOR INDEX vec_idx ON vector_data(embedding) ORGANIZATION NEIGHBOR DISTANCE COSINE WITH TARGET ACCURACY 95; -- 查看向量索引的构建进度（针对大规模数据集） SELECT * FROM V$VECTOR_INDEX_LOAD_PROGRESS; -- 分析混合索引的优化器执行计划 EXPLAIN PLAN FOR SELECT * FROM products WHERE CONTAINS(description, 'waterproof hiking boots') > 0 AND VECTOR_DISTANCE(emb, :query_vec) < 0.8; -- 使用混合向量索引进行混合搜索 SELECT * FROM DBMS_HYBRID_VECTOR.SEARCH( index_name => 'vec_idx', query_vector => :embedding, top_k => 10, search_type => 'HYBRID' );

1.3 In-Database Machine Learning

26ai 对数据库内机器学习算法进行了显著改进，使文本和数据的分类更加简单，同时提供了更好的性能和灵活性。AI 工作负载受益于数据库现有的加密、审计和基于角色的访问控制等保护机制。同时，26ai 引入了对Agentic AI工作流和模型上下文协议（MCP）的支持，使 AI 代理能够在数据库安全边界内安全运行。

Oracle Unified Memory Core 提供了有状态、持久化的内存供 AI 代理使用；Oracle AI Database Private Agent Factory 则提供了无代码平台，用于部署数据中心的 AI 代理。

Part 2：RAC 内核革新——从"被动恢复"到"主动韧性"

2.1 Smart Connection Rebalance（智能连接再平衡）

内核实现：

该特性背后的核心是实时亲和性分析引擎。该引擎由内核级工作负载监视器驱动，持续采集GV$SESSION和GV$LOCK的数据，识别出那些频繁争用相同数据块（Data Block）的跨实例会话。与传统的 Connection Load Balancing（连接负载均衡）不同，SMART_CONN干预已建立连接（In-flight Sessions），通过触发"服务漂移"将高冲突会话无缝牵引至同一实例。

传统 RAC 环境中，连接到不同实例但更新相同数据库对象的会话会产生资源争用。Smart Connection Rebalancing 通过以下方式解决这一问题：

• 实时、零中断地再平衡运行中的工作负载会话

• 无需DBA干预，自动且无缝地重定向会话

• 通过将服务属性RLB_GOAL设置为SMART_CONN即可启用

• AWR 报告会提供智能连接再平衡的推荐建议，基于集群等待时间、GC争用等待时间等指标生成

• 在高争用工作负载的测试中，集群等待时间减少高达95%

诊断命令：

-- 查看服务是否启用了智能再平衡 SELECT NAME, GOAL, (CASE WHEN GOAL = 8 THEN 'SMART_CONN' END) AS CONN_TYPE FROM V$SERVICES; -- 通过DBMS_APP_CONT_ADMIN包为指定服务启用Smart Connection EXEC DBMS_APP_CONT_ADMIN.ENABLE_SMART_CONNECTION('service_name'); -- AWR自动推荐查询（26ai内核自动记录建议） SELECT * FROM DBA_HIST_SMART_RECONS WHERE RECOMMENDATION LIKE '%Enable%'; -- 在RAC环境中查看所有实例的服务状态 SELECT INST_ID, NAME, GOAL FROM GV$SERVICES; -- 强制对特定服务进行即时再平衡诊断 EXEC DBMS_SERVICE.RECOMMEND_SMART_CONNECTION('SALES_APP');

2.2 Ordered Sequences 性能提升

有序序列（Ordered Sequences）在 26ai 中实现了2倍的性能提升。通过批量预留（Batched Reservations）优化——持有排他锁的预留者为等待者预留值——减少了等待时间并提升了吞吐量：单节点序列访问吞吐量提升约 40%，全节点访问吞吐量提升 2 倍。

诊断命令：

-- 查看序列的缓存和排序设置 SELECT SEQUENCE_NAME, CACHE_SIZE, ORDER_FLAG FROM USER_SEQUENCES; -- 监控序列争用 SELECT EVENT, TOTAL_WAITS, TIME_WAITED FROM V$SYSTEM_EVENT WHERE EVENT LIKE '%row cache lock%' OR EVENT LIKE '%enq: SQ%';

2.3 Fast Start Reconfiguration (FSR) —— 告别"重启阵痛"

内核实现：

传统 RAC 发生节点故障时，集群需要经历Reconfiguration（重新配置）阶段（GRD 冻结、块恢复）。FSR 打破了这一铁律：对于"干净块"（Clean Blocks，即未修改的共享块），内核允许新主节点上的前台进程立即读取（Immediate Direct Read），无需等待 DOM（Data Object Map）完全同步。在 Exadata 环境下，利用 RDMA 协议直接拉取远端 SGA 数据，使得 Brownout Time 压缩至3.072 秒。

在 YCSB 工作负载测试中（Exadata X9M 3节点，更新密集型，读写比50/50），非计划停机的棕出时间（Brownout Time）仅为3.072 秒。恢复时间受系统负载影响，需要通过调整fast_start_mttr_target参数进行调优。

诊断命令：

-- 查看快速启动目标时间设置（影响FSR的激进程度） SHOW PARAMETER fast_start_mttr_target; -- 设置快速启动平均恢复时间目标（秒） ALTER SYSTEM SET fast_start_mttr_target=5 SCOPE=BOTH; -- 监控实例故障时的重配置耗时（AWR历史） SELECT EVENT, WAIT_CLASS, AVERAGE_WAIT FROM V$SYSTEM_EVENT WHERE EVENT LIKE '%reconfiguration%'; -- 查看当前集群GRD（Global Resource Directory）合并状态 SELECT * FROM V$GES_STATISTICS WHERE NAME LIKE '%reconfig%'; -- 查看RAC实例状态变化 SELECT INST_ID, INSTANCE_NAME, STATUS, STARTUP_TIME FROM GV$INSTANCE ORDER BY INST_ID;

2.4 Two-Stage Rolling Updates（两阶段滚动更新）

内核实现：

两阶段滚动更新将补丁应用分为两个阶段，补丁应用与激活分离是 26ai 的杀手锏。内核中引入了一个状态位掩码（Fix Status Bitmask），位于V$SYSTEM_FIX_CONTROL中。

• 阶段一：将补丁应用于所有实例，但不启用修复。二进制 Patch 文件落地并更新"元数据注册表"，但不翻转状态位。

• 阶段二：执行ALTER SYSTEM ENABLE...时，内核原子性地翻转该掩码，所有 RAC 实例瞬间感知并启用新逻辑。

这解决了历史级痛点：许多涉及底层接口变更的补丁不再需要停机。该功能与 FPP（Fleet Patching and Provisioning）、OpatchAuto 和 Opatch 等现有工具无缝协作。

诊断命令：

-- 执行全局启用 ALTER SYSTEM ENABLE RAC TWO_STAGE ROLLING UPDATES ALL; -- 查看所有实例的补丁启用状态（内核寄存器） SELECT FIX_NAME, FIX_ID, IS_ENABLED, INST_ID FROM V$SYSTEM_FIX_CONTROL WHERE FIX_ID = &patch_id; -- 检查是否还有未启用的fix（待命状态） SELECT COUNT(*) FROM V$SYSTEM_FIX_CONTROL WHERE IS_ENABLED = 0 AND BUNDLE_ID = &latest; -- 查看两阶段滚动更新状态 SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME LIKE '%two_stage%';

如果在所有实例完成两阶段滚动更新之前尝试启用功能，将收到错误提示。

2.5 Local Rolling Maintenance（本地滚动打补丁）

内核实现：

该特性要求在同一物理服务器上运行两个 ORACLE_HOME和两个实例（利用srvctl modify database -localrolling）。内核通过临时共享归档重做日志（Temporary Redo Log Sharing）机制，使得新旧实例能平滑切换。此操作不涉及跨节点网络传输，内存同步直接利用IPC（进程间通信）或MGA（Managed Global Area），因此 CPU 和网络开销远低于跨节点迁移。

• 本地滚动打补丁：无需影响其他集群节点，即可在单节点上完成滚动补丁和维护操作

• 会话迁移优化：会话切换到同一节点的新实例，显著降低 CPU 和网络开销

• 资源要求：需确保节点上有足够的 CPU 和内存运行两个实例

该功能支持多节点 Oracle RAC和Oracle RAC One Node数据库。

诊断命令：

# 配置新ORACLE_HOME路径 srvctl modify database -d prod -o /u01/app/oracle/product/26.0.0_new -localrolling # 启动本地滚动实例（在同一节点启动第二个实例） srvctl start instance -d prod -i prod_2 -node node1 # 将服务连接迁移至新实例（零停机），而非迁移整个实例 srvctl transfer service -d prod -s sales_svc -instance prod_2 # 查看数据库实例状态 srvctl status database -d prod # 启动/停止特定实例 srvctl start instance -d prod -i <instance_name> srvctl stop instance -d prod -i <instance_name>

2.6 General Purpose Cluster (GPC)

内核实现：

General Purpose Cluster 是一种新的集群部署选项，只需最少的网络和存储配置：

• 精简版 Grid Infrastructure：无需共享存储、VIP 等资源即可提供集群管理服务

• 可升级为完整 RAC：通过添加 VIP 等资源即可转换为完整的 Oracle RAC 集群

• 部署方式：Oracle Grid Infrastructure 安装程序提供交互式或静默模式的简化配置选项

诊断命令：

# 安装GPC（使用命令行界面安装Grid Infrastructure） ./gridSetup.sh -silent -responseFile <response_file> # 查看GPC集群状态 crsctl get cluster mode # 将GPC转换为完整RAC集群（以root用户执行，为每个节点添加VIP） srvctl modify vip -node node_name -address {VIP_name|ip}/netmask[/if1[|if2|...]] # 检查所有节点的集群状态 crsctl check cluster -all

2.7 更快的部署与更小的磁盘占用

26ai 在部署效率上实现了显著提升：

• Grid Infrastructure磁盘占用减少2倍以上（相比19c）

• GI软件初始部署和添加节点速度提升2倍以上

• 两节点Grid安装比19c快33%

• 创建10,000个服务快8倍；创建单个服务快14倍，删除快23倍

诊断命令：

# 查看GI磁盘使用情况 du -sh $GI_HOME # 查看服务创建性能 time srvctl add service -d <dbname> -s <service_name> -r <preferred_inst>

Part 3：Exadata 深度融合——RDMA 驱动的微秒级响应

3.1 RDMA Cache Fusion 与 Commit Cache

内核实现：

在非 Exadata 平台，Cache Fusion 依赖 UDP，常出现乱序和丢包重传。在 26ai + Exadata 上，LMS进程通过 InfiniBand/RoCE 网卡实现RDMA 单边读写。传统 3-way 消息传递（请求-转发-响应）被优化为2-way Grant + Direct Read：

1. Foreground 向资源导演实例的 LMS 进程发送 RDMA 请求消息

2. 收到授权消息后，直接从持有者实例的 SGA 中RDMA 读取当前缓冲区块

3. "gc current block direct read" 延迟控制在< 10 微秒

Commit Cache则是针对索引维护的优化。在 Right-Growing Index（RGI）场景下，以往需要传递整个 8KB 事务表块。26ai 在内存中开辟了专用的 Commit Cache 区域，记录提交时间戳 SCN。远端 LMS 直接 RDMA 读取该缓存校验提交状态，消除了 60% 的 Cache Fusion 块流量。

在非 Exadata 系统上，Oracle RAC Cache Fusion 确保默认的 UDP 协议限制（如乱序发送、缺乏可靠发送和接收）不会导致块丢失。块丢失通常是私有网络不稳定或配置错误的副作用。

26ai 引入的IPCO 后台进程负责将所有进程的 IPC 缓冲区注册到 InfiniBand HCA（Host Channel Adapter）；MGA（Managed Global Area）内存池则允许一组进程高效共享地址空间——既不是 SGA 也不是 PGA，而是介于两者之间。

诊断命令：

-- 查看RDMA相关的统计（Exadata特有） SELECT NAME, VALUE FROM GV$SYSSTAT WHERE NAME LIKE '%RDMA%'; -- 查看提交缓存命中率 SELECT NAME, GETS, MISSES, HIT_RATIO FROM V$ROWCACHE WHERE PARAMETER LIKE '%commit%'; -- 监控gc current grant（RDMA模式）与gc current block（传统模式）的比例 SELECT NAME, WAIT_TIME_MICRO FROM V$EVENT_HISTOGRAM WHERE NAME IN ('gc current grant 2-way', 'gc current block direct read'); -- 查看Cache Fusion块传输统计 SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%gc %blocks%' OR NAME LIKE '%gc %current%';

3.2 即时故障检测（Instant Failure Detection）

内核实现：

非 Exadata 依赖心跳超时（约 30 秒）。Exadata 的 CSSD 进程（Cluster Synchronization Services Daemon）利用RDMA Read 探针（Probe）向疑似故障节点发送 4 次读取请求，分别交叉源端口和目标端口的所有组合。即使 OS 因 CPU 高负载挂起，RDMA 网卡（HCA）的固件依然能响应硬件级 ACK。若四次均失败，CSSD 直接启动驱逐流程，从检测到写 Kill Block（投票文件）仅需不到 1 秒，与传统基于消息的协议相比速度提升 3 倍。

诊断命令：

# 查看CSS日志中的RDMA节点死亡事件时间戳 tail -f $GI_HOME/log/`hostname`/cssd/ocssd.log | grep -i "EXADATA NodeDeath" # 查看集群节点驱逐历史 crsctl query css votedisk -detail

3.3 Optimized Object Checkpoints（优化的对象检查点）

内核实现：

使用直接读取的查询需要发出对象检查点（enq:KO - fast object checkpoint）。26ai 中，仅当 RDMA 检查脏缓冲区返回 true 时才执行检查点，显著提升了 Exadata Smart Scans 在 AI 向量搜索操作中的性能。

诊断命令：

-- 查看对象检查点等待事件 SELECT EVENT, TOTAL_WAITS, TIME_WAITED FROM V$SYSTEM_EVENT WHERE EVENT LIKE '%object checkpoint%'; -- 查看Enqueue统计 SELECT * FROM V$ENQUEUE_STAT WHERE EQ_TYPE = 'KO';

Part 4：高可用性——MAA白金级与钻石级

4.1 Platinum-Tier Availability（白金级可用性）

Oracle AI Database 26ai on Exadata 提供白金级可用性，灾难故障切换时间通常低于30秒，包括高吞吐量多节点集群。相比 Oracle Database 19c，故障切换速度提升高达4倍，且无需应用更改或性能权衡。

白金级可用性的关键能力包括：

• Active Data Guard远程数据传输：未加密数据快2倍，加密数据快9倍（相比19c）

• Oracle RAC快速重启恢复：OLTP应用在节点故障后恢复工作快10倍，PDB启动快2倍

• Transparent Application Continuity：查询故障切换快40%，数据库CPU开销降低50%，客户端CPU开销降低55%

• Oracle True Cache：查询响应快10倍，主库故障期间仍可保持缓存数据读访问

4.2 Diamond-Tier Availability（钻石级可用性）

对于要求极致可靠性的应用（如实时信用卡处理），26ai 提供了钻石级可用性：

• 灾难故障切换通常低于3秒，从人类感知角度而言零停机

• 零数据丢失

• 使用Oracle GoldenGate 26ai实现跨全球分布区域的Active-Active数据复制

• 自动冲突检测与解决，确保多地同时更新时数据一致性

Part 5：应用连续性（AC/TAC）与 RESET_STATE 内核级联动

5.1 AC/TAC 的重放机制（Replay）

内核实现：

Application Continuity 通过重建所有进行中的工作（in-flight work）来实现故障透明恢复。TAC 则透明地跟踪和记录会话与事务状态，以便在可恢复的故障后恢复数据库会话。

AC/TAC 依赖数据库模板（Database Template）记录执行点。对于PL/SQL块或复杂的BEGIN...END，内核使用快照级别回滚（Snapshot-level Rollback），在故障时将未提交的变更回滚至保留点（Savepoint），然后在幸存实例上重新执行（Replay）。

26ai 的核心增强包括：

• 数据库模板：AC 使用数据库模板对会话状态进行检查点记录，在重放开始时恢复会话状态，并支持计划维护期间的会话迁移

• SESSION_STATE_CONSISTENCY 变更：从 26ai 开始，不再支持STATIC选项

• 默认超时：AC 的默认超时为10 秒

• 自定义外部动作支持：在 26ai 中，TAC 首次支持自定义外部动作（Custom External Actions）的重放，默认保持禁用

适用场景对比：

诊断命令：

-- 启用Application Continuity EXEC DBMS_APP_CONT_ADMIN.ENABLE_AC('service_name'); -- 启用Transparent Application Continuity EXEC DBMS_APP_CONT_ADMIN.ENABLE_TAC( service_name => 'service_name', failover_restore => 'AUTO', replay_initiation_timeout => 300, session_state_consistency => 'AUTO' ); -- 查看TAC重放统计 SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('user calls protected by Application Continuity', 'replay attempts', 'replay successes'); -- 检查服务是否启用TAC SELECT SERVICE_ID, NAME, FAILOVER_TYPE, FAILOVER_METHOD, FAILOVER_RESTORE FROM DBA_SERVICES; -- 查看AC保护的相关统计（来自AWR报告的经验值） SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME LIKE '%Application Continuity%' OR NAME LIKE '%cumulative%requests%';

5.2 RESET_STATE——连接池污染的"终结者"

内核实现：

当应用连接返回池时，FETCH 游标状态、会话变量（如NLS_DATE_FORMAT）会残留在 SERVER 进程中。26ai 的RESET_STATE提供两种模式，其可用性状态不同：

1. RESET to LEVEL1（现已可用，适用于 26ai SE/EE/Free）：清除游标、取消 Fetch（关闭 SGA 中的私有游标内存），在服务器端自动执行。

2. RESET to LOGIN（即将可用，适用于 26ai SE/EE/Free 及相应驱动）：执行完整的"轻量级 Logout/Login"，重置 NLS、优化器 Hint 等所有环境变量，在客户端与服务器端同时执行。

该功能与ORDS 25.4及APEX 25.4深度集成，ORDS 已嵌入支持重放的数据源并优化使用 RESET_STATE。TAC 配合 RESET_STATE 可确保新请求开始时会话状态是干净的。RESET_STATE 是独立于 AC/TAC 的功能，即使用户未启用 AC/TAC，RESET_STATE 仍可用于清理会话状态。

收益：

• 防止应用安全漏洞（防止数据串户）、减少代码、降低数据库 CPU 使用

• 与 TAC 配合提供更广泛的保护——微服务、APEX、ORDS、Fusion Apps、SwingBench

• 银行、零售、政府等客户高度需求的功能

诊断与配置命令：

-- 通过PL/SQL包修改服务以启用复位（正确方式） BEGIN DBMS_SERVICE.MODIFY_SERVICE( service_name => 'app_svc', reset_state => DBMS_SERVICE.RESET_STATE_ON ); END; / -- 会话级别启用RESET_STATE ALTER SESSION SET RESET_STATE = TRUE; -- 查看当前会话的复位动作计数 SELECT NAME, VALUE FROM V$SESSTAT WHERE STATISTIC# IN (SELECT STATISTIC# FROM V$STATNAME WHERE NAME = 'session state reset calls'); -- 结合TAC查看复位的收益（清理游标数） SELECT * FROM GV$OPEN_CURSOR WHERE RESET_STATE = 'CLEANED';

驱动程序要求：使用 RESET_STATE 需要升级到支持该功能的驱动程序（Oracle AI Database 26ai - 23.6 及以上版本驱动）。如果驱动程序不支持，可选择不使用 RESET_STATE 功能。

5.3 Database Links Draining

26ai 支持数据库链接排空（Database Links Draining），跨数据库透明、带内通知、客户端升级：

• 标记数据库链接进行排空，使用带内通知告知链接协调器数据库链接目标即将进行维护

• 使链接协调器能够启动排空，默认在请求结束时关闭数据库链接

• 向客户端的带内通知可配置

• 对于故障，AC 进行重放；TAC 在服务上设置以进行重放

5.4 CI/CD 集成与监控

使用 AWR 报告监控，使用 ACCHK 进行显式评估，验证连接池是否正确配置以及 Begin/End Request 是否正确使用。

诊断命令：

-- 查看实例活动统计（AC保护情况） SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN ('cumulative DB time in requests', 'cumulative DB time protected in requests', 'cumulative begin requests', 'cumulative end requests', 'cumulative user calls protected by Application Continuity'); -- 高数值=良好保护，低数值=低保护 -- 运行ACCHK进行进一步分析

Part 6：集群基础设施（GI）的隐形进化

6.1 自动恢复（Auto-Recover）框架

26ai 增强了 Grid Infrastructure 的自动恢复能力：

Primary CRSD Hang 自动处理：

• 问题：主 CRSD 无响应，本地 OHASD 无法检测异常

• 解决：自动向本地 CSSD 发送请求，由 CSSD 终止主 CRSD 进程

• 新 CRSD 进程由 OHASD 立即重启，不影响数据库可用性

Transient Storage Failure（瞬态存储故障）自动处理：

• 问题：OCR 磁盘组被卸载

• 解决：自动重试挂载 OCR 磁盘组

• 不影响正在进行的数据库操作，投票磁盘镜像仍然可访问

ASM Listener Issue（ASM监听器问题）自动处理：

• 问题：ASM 监听器进入离线状态

• 影响：ASM 实例无法从其他节点访问

• 解决：自动重启 ASM 监听器

• 仅当集群节点超过 3 个且 ASM 基数设置为默认值时，远程 ASM 才被访问

Memory Leak Detection（内存泄漏检测）：

• 基于资源数量、集群节点数量计算内存使用量

• 内存泄漏阈值非静态，使用预测分析动态计算

• 预测算法能区分泄漏与新增资源（实例、PDB、服务）导致的内存增长

• 监控 Grid Infrastructure 主目录下的所有进程（ocssd 和 onmd 除外）

诊断命令：

# 查看自动恢复策略（包括内存泄漏检测开启状态） crsctl get autorecover -all # 输出示例： # Problem Name Mode Description # crsjoin enabled Join protocol failure seen by non-primary nodes. # ocrinit enabled No OCR disk group mounted on Oracle ASM. # asmgroup enabled Oracle ASM listener resource is offline. # asmcred enabled Incorrect ASM credentials in OLR/OCR. # memleak enabled Memory Leak Detection. # 针对CRSD无响应时的诊断（手动触发自愈测试） crsctl stop resource -n ora.crsd -force -debug # 查看集群资源状态 crsctl status resource -t

Part 7：安全增强

26ai 在安全方面也进行了多项增强：

• Oracle SQL Firewall：现已包含在数据库中，提供针对 SQL 注入等常见数据库攻击的实时防护

• Azure AD OAuth2集成：支持从 Microsoft Azure Cloud 到 Oracle AI Database 的单点登录

• 模式级系统权限：简化了访问控制管理

• 开发者角色：允许管理员快速为应用开发者分配所需的最小权限

• 监听器管理认证：强制要求本地操作系统认证，有效防止未经授权的监听器管理操作

Part 8：开发者体验与生态集成

8.1 多模型数据访问

26ai 向开发者提供了统一的多模型数据访问体验——同一份底层数据可同时以 SQL、JSON 或图（通过 PGQL）的方式查询，无需独立的存储系统。

8.2 JSON Relational Duality

数据可以透明地以JSON文档或关系表的方式访问和更新，开发者可同时享受两种模型的优势，比对象关系映射（ORM）更简单、更强大。

8.3 Operational Property Graphs

开发者现在可以直接在 Oracle AI Database 中针对运营数据构建实时图分析应用，利用其业界领先的安全、高可用和性能能力。

8.4 JavaScript 存储过程

26ai 支持使用JavaScript 创建存储过程，开发者可以利用庞大的 JavaScript 库生态系统。

8.5 Assertions（断言）

断言允许用户在一个或多个表上定义业务规则，确保表上的 DML 操作始终遵守这些规则，使用清晰、声明式的语法将业务逻辑直接嵌入数据库。

8.6 Lock-Free Reservations（无锁预留）

无锁预留允许并发事务在不锁定行的情况下继续执行——在行上持有预留而非锁定。无锁预留验证更新是否可成功，并将更新推迟到事务提交时，显著改善了最终用户体验和事务并发性。

8.7 APEX 与 ORDS 低代码集成

Oracle APEX 是全球最受欢迎的企业低代码应用平台。ORDS 是企业级 REST API 解决方案。

• TAC 允许 APEX 开发者专注于功能开发——简单报表、图表、表单输入/提交和交互式报表（含原子提交）都可在故障切换时重放

• ORDS 25.4 及以上版本已嵌入支持重放的数据源并优化使用 RESET_STATE

• 使用 Oracle AI Database 26ai - 23.6 及以上版本驱动可充分利用 Autonomous Database 和 Database Links 故障切换

• 对于 Oracle Database 19c，建议使用 RU 26 - 19.26 或更高版本，并相应更新客户端

总结：架构矩阵

最终结论：Oracle 26ai 不仅仅是一个"功能版本"，它通过内核级重构，打通了传统事务（OLTP）、分析（OLAP）与新兴 AI 工作负载之间的壁垒。对于 DBA 而言，掌握上述命令不仅是操作要求，更是理解这个复杂新内核运行态的关键。升级至 26ai 意味着企业可以在同一套物理基础设施上，用同样的 ACID 保障，运行从 RAG 应用到实时风控的所有负载，且获得钻石级（<3秒）的 RTO 保障。

升级路径提示：Oracle AI Database 26ai 是继 19c 之后的长期支持版本。19c 是唯一直接的升级跳板——运行在 11g 或 12c 的组织必须首先升级到 19c。已运行 23ai 的用户只需应用 2025 年 10 月的 Release Update 即可升级到 26ai。