清理 Oracle EBS 集成 SOA 网关（ISG）表

EBS 12.1.3（电子商务套件）、EBS 12.1.3、集成 SOA 网关（Integrated SOA Gateway）、ISG

如果您正在使用 Oracle 电子商务套件集成 SOA 网关（Oracle E-Business Suite Integrated SOA Gateway，简称 ISG），那么在某些时候可能会遇到数据留存过多的问题。您是否知道 Oracle 提供了一个预置的清理程序？该程序可删除底层表中的数据，有助于将数据量维持在合理范围，从而提升系统性能并最小化存储占用。

问题背景与观察

我的 SOA 清理工作始于一个性能问题：当导航至 “集成 SOA 网关” 职责（Integrated SOA Gateway responsibility）>“SOA 监视器”（SOA Monitor）时，加载该网页需要长达 5 分钟。检查数据库后发现，系统正卡在执行以下查询语句：

SELECT *
FROM (SELECT REQUEST_TIMESTAMP AS REQDATETIME,
REQUEST_COMPLETED AS RESDATETIME,
WRQ.IREP_NAME AS WEB_SERVICE_NAME,
FIC.CLASS_ID AS CLASS_ID,
METHOD AS METHOD_NAME,
USER_NAME,
WRQ.USER_ID,
IP_ADDRESS,
REQUEST_STATUS AS REQUEST_STATUS,
RESPONSE_STATUS AS RESPONSE_STATUS,
MESSAGE_ID,
REQUEST_PATTERN,
-- 查询响应状态的含义
(SELECT meaning
FROM fnd_lookup_values_vl
WHERE lookup_type = 'FND_SOA_RESPONSE_STATUS'
AND lookup_code = WRQ.RESPONSE_STATUS)
AS res_status,
-- 查询请求状态的含义
(SELECT meaning
FROM fnd_lookup_values_vl
WHERE lookup_type = 'FND_SOA_REQUEST_STATUS'
AND lookup_code = WRQ.REQUEST_STATUS)
AS req_status,
-- 查询交互架构的含义
(SELECT meaning
FROM fnd_lookup_values_vl
WHERE lookup_type = 'FND_SOA_MESSAGE_PATTERN'
AND lookup_code = WRQ.REQUEST_PATTERN)
AS interaction_architecture,
-- 判断日志是否存在
(SELECT DECODE (COUNT (1), 0, 'LOG_ABSENT', 'LOG_PRESENT')
FROM fnd_log_messages
WHERE transaction_context_id IN (SELECT transaction_context_id
FROM fnd_log_transaction_context
WHERE transaction_type =
'SOA_INSTANCE'
AND transaction_id =
WRQ.MESSAGE_ID
AND REGEXP_LIKE (
WRQ.MESSAGE_ID,
'^-?[[:digit:],.]*$')))
AS ENABLE_LOG
-- 关联SOA请求表、用户表、服务类表
FROM FND_SOA_REQUEST WRQ, FND_USER FU, FND_IREP_CLASSES FIC
WHERE WRQ.USER_ID = FU.USER_ID(+)  -- 左关联用户表
AND FIC.IREP_NAME = WRQ.IREP_NAME  -- 关联服务类表
AND FIC.CLASS_TYPE NOT IN ('SOAPSERVICEDOC', 'WEBSERVICEDOC'))  -- 排除特定类型的服务类
QRSLT
-- 筛选近7天的数据
WHERE ( ( (TO_DATE (TO_CHAR (REQDATETIME, 'dd-mm-yyyy'), 'dd-mm-yyyy')) = TRUNC (SYSDATE - 7)));

进一步排查 SOA 相关的底层表后发现，两个表存储了绝大部分数据，分别是 FND_SOA_REQUEST（SOA 请求表）和 FND_SOA_BODY_PIECE（SOA 消息体片段表），其行数和占用空间都非常大。

执行以下 SQL 语句可查看这两个表的具体数据量和存储大小：

SQL> SELECT table_name,
num_rows,  -- 表行数
ROUND ( (blocks * 8192) / 1024 / 1024, 2) "SIZE-MB"  -- 计算表占用空间（单位：MB）
FROM dba_tables
WHERE table_name IN ('FND_SOA_BODY_PIECE', 'FND_SOA_REQUEST')
ORDER BY table_name ASC;

查询结果如下：

开始清理操作

Oracle EBS 提供了一个预置的清理程序，可直接用于清理上述表的数据。Oracle 实施指南（Implementation Guide）中详细说明了启动该程序的步骤，具体路径为：

集成 SOA 网关职责（Integrated SOA Gateway responsibility）> SOA 监视器（SOA Monitor）。

关于 Oracle EBS 集成 SOA 网关表的清理说明

实施指南已完整覆盖程序启动的步骤，此处不再赘述。从底层原理来看，该清理操作本质是提交一个并发请求（Concurrent Request）。

在我们的环境中，需求是仅保留 90 天内的数据，而当时系统中留存了超过 2 年的数据。最终，本次清理操作耗时约 4 小时。

清理后的后续操作

清理完成后，需执行以下脚本完成三项关键任务：

1. 重建表和索引，回收存储空间；
2. 收集最新的表 / 索引统计信息；
3. 重新编译因重建操作导致失效的对象。

具体脚本如下：

-- 1. 重建FND_SOA_REQUEST表及关联索引
ALTER TABLE FND_SOA_REQUEST MOVE;
ALTER INDEX APPLSYS.FND_SOA_REQUEST_U1 REBUILD;  -- 唯一索引
ALTER INDEX APPLSYS.FND_SOA_REQUEST_N1 REBUILD;  -- 普通索引1
ALTER INDEX APPLSYS.FND_SOA_REQUEST_N2 REBUILD;  -- 普通索引2

-- 2. 收集FND_SOA_REQUEST表的统计信息（100%采样，并行度4）
EXEC fnd_stats.gather_table_stats(ownname=>'APPLSYS',tabname=>'FND_SOA_REQUEST', percent=>'100', degree=>'4');

-- 1. 重建FND_SOA_BODY_PIECE表及关联索引
ALTER TABLE fnd_soa_body_piece MOVE;
ALTER INDEX APPLSYS.FND_SOA_BODY_PIECE_N1 REBUILD;  -- 普通索引

-- 2. 收集FND_SOA_BODY_PIECE表的统计信息（100%采样，并行度4）
EXEC fnd_stats.gather_table_stats(ownname=>'APPLSYS',tabname=>'FND_SOA_BODY_PIECE', percent=>'100', degree=>'4');

-- 3. 并行重新编译失效对象（并行度8）
EXEC sys.utl_recomp.recomp_parallel(8);

清理后的效果

清理及后续操作完成后，两个核心表的数据量和存储占用显著降低，查询结果如下：

总结

如果您的系统使用了 ISG，建议将 SOA 清理程序加入定期维护任务。通过执行清理和对象重建操作，我们不仅大幅降低了存储占用，还将 “SOA 监视器” 网页的加载时间从 5 分钟缩短到了几秒内。目前我们已将该清理任务设置为周期性执行，以持续维持低存储占用的状态。

注意事项

在我们的场景中，仅保留 90 天数据是合理的，因为业务无需使用更早期的数据。但需注意：

部分企业可能因合规政策要求留存更长时间的 ISG 数据。对于这类场景，仍可执行清理操作，但需先将需留存的历史数据迁移到自定义的历史表中，再进行清理，以满足合规要求。