Oracle | erp、mrp、性能优化 | 设计文档

4926 字
25 分钟
Oracle | erp、mrp、性能优化 | 设计文档

Oracle | erp、mrp、性能优化 | 设计文档#


一、项目背景#

DBA 对 MRP 相关表执行了 SHRINK 操作:

ALTER TABLE xxxxx ENABLE ROW MOVEMENT; -- 允许行物理移动
ALTER TABLE xxxxx SHRINK SPACE COMPACT CASCADE; -- 压缩数据,不降高水位
ALTER TABLE xxxxx SHRINK SPACE CASCADE; -- 降低高水位线(HWM)
ALTER TABLE xxxxx DISABLE ROW MOVEMENT; -- 禁用行移动保护 ROWID

目的: 回收表碎片空间,降低高水位线(HWM)。
结果: MRP 排产并发请求显著变慢,正式环境排产耗时超过 50 分钟


二、根本原因:聚簇因子(Clustering Factor)恶化#

什么是聚簇因子#

聚簇因子衡量索引键值顺序表物理行存储顺序的吻合程度。

CF 范围含义对范围扫描的影响
接近块数行按索引顺序集中存储快,顺序读 ✅
接近行数行分散在各个块慢,随机读 ❌

记忆规则:索引范围扫描 + 扫描行数多 + CF 大 → 需要访问的块越多 → 越慢

SHRINK 为什么会恶化 CF#

SHRINK 在压缩数据时会物理移动行(ROWID 改变),导致行的存储顺序与索引键值顺序不再对应。原本顺序读 2 个块,移动后每行都可能落在不同块,索引范围扫描变成随机跳块读,CR 暴增。

恶化后的等待事件#

等待事件场景原因
latch cache buffer chain单节点 / RAC随机块访问过多,Buffer Get 过高,latch 成为瓶颈
GC buffer busyRAC 集群跨节点传输散乱数据块,Global Cache 争用

聚簇因子检测#

-- 先收集统计信息
EXEC dbms_stats.gather_index_stats(ownname => 'SCHEMA', indname => 'INDEX_NAME');
-- 查询 CF 异常索引(CF > 行数/2 且 CF > 块数)
SELECT *
FROM (
SELECT d.clustering_factor, d.table_name, d.index_name,
d.num_rows, d.last_analyzed
FROM dba_indexes d
WHERE d.clustering_factor > d.num_rows / 2
AND d.clustering_factor > (
SELECT t.blocks FROM dba_tables t
WHERE t.table_name = d.table_name
AND t.owner = d.table_owner
)
ORDER BY 1 DESC
)
WHERE rownum <= 10;

三、分析方法#

工具链#

工具用途
tkprof解析 Trace 文件,输出各 SQL 的 CR、PR、执行次数、耗时
AWR 报告Top SQL / Top Wait Events 全局视角
SQL 执行计划确认访问路径(INDEX RANGE SCAN、FULL SCAN 等)
v$session_wait实时等待事件观察

关键指标#

指标含义
crConsistent Reads,逻辑读次数,越高说明扫描越多
prPhysical Reads,物理读,有 pr 说明数据未命中缓存
elapsedSQL 总耗时
executions执行次数,高频低耗的 SQL 累计影响同样不可忽视

定位流程#

AWR Top Wait Events
→ 发现 latch / GC buffer busy 占比高
→ AWR Top SQL by Buffer Gets 找 CR 最高的 SQL
→ tkprof 分析 Trace,确认执行次数 × CR 贡献最大的 SQL
→ 查执行计划,确认 INDEX RANGE SCAN + 高 CF 组合
→ 查 DBA 操作记录,SHRINK 时间与性能劣化吻合
→ 确认根因,制定优化方案

四、优化方案#

4.1 在线表重定义(降低聚簇因子)#

核心原理: 按特定索引键列顺序重建表的物理存储顺序,等效于:

CREATE TABLE new_table AS SELECT * FROM old_table ORDER BY <目标索引列>;

在线重定义(DBMS_REDEFINITION)可在不停业务的情况下完成;若允许停机维护,直接 CTAS + 重命名速度更快。


4.1.1 BOM_COMPONENTS_B — 优化等级:🔴 高#

问题定位:

文件 20640,1210 行,执行次数 1 次,SQL 执行时间 17 秒,返回 9418 行
INDEX RANGE SCAN BOM_COMPONENTS_B_N2 (cr=89869 pr=0 pw=0 time=320951 us cost=2 card=20)

问题分析:

  • 执行仅 1 次,但 CR 高达 89,869,是最理想的重定义优化目标
  • 问题索引 BOM_COMPONENTS_B_N2 仅含 BILL_SEQUENCE_ID 单列,选择性差
  • 每次范围扫描都随机访问大量分散数据块

相关索引:

索引名类型
BOM_COMPONENTS_B_N1NormalCOMPONENT_ITEM_ID, BILL_SEQUENCE_ID, EFFECTIVITY_DATE
BOM_COMPONENTS_B_N2NormalBILL_SEQUENCE_ID
BOM_COMPONENTS_B_N8NormalBILL_SEQUENCE_ID, EFFECTIVITY_DATE, COMPONENT_ITEM_ID, OPERATION_SEQ_NUM
BOM_COMPONENTS_B_U2UniqueCOMPONENT_SEQUENCE_ID

重定义策略:COMPONENT_SEQUENCE_ID(主键序列)排序重定义

主键按序列号写入,BILL_SEQUENCE_ID 也近似有序写入,聚簇因子随之显著下降。


4.1.2 BOM_STRUCTURES_B — 优化等级:🔴 高#

问题定位:

文件 20640,1208 行,执行次数 1 次,SQL 执行时间 17 秒,返回 9418 行
INDEX RANGE SCAN BOM_STRUCTURES_B_N2 (cr=9336 pr=0 pw=0 time=57158 us cost=2 card=1)

问题分析: 虽然是小表(约 25 万行),但一次范围扫描 CR 达 9,336,读取了全表近 1/5 的数据,聚簇严重失序。

重定义策略: 按 U1 主键顺序(OBJ_NAME, PK1_VALUE, PK2_VALUE, ALTERNATE_BOM_DESIGNATOR)重定义

不按 N2 索引列(ASSEMBLY_ITEM_ID, ORGANIZATION_ID)排序,原因:为优化单个索引而改变物理顺序会导致其他索引效率下降;按主键排序是恢复数据到自然写入状态的最优平衡。


4.1.3 MRP_SCHEDULE_DATES — 优化等级:🟡 低#

INDEX RANGE SCAN MRP_SCHEDULE_DATES_N3 (cr=2300 pr=45 time=291062 us)
INDEX RANGE SCAN MRP_SCHEDULE_DATES_N3 (cr=5598 pr=0 time=486020 us)

说明: 由于业务存在频繁增删(详见 5.1 节),重定义效果会随运行时间持续退化,N3 索引聚簇甚至反而有所上升,非根治方案。

重定义顺序: MPS_TRANSACTION_ID, SCHEDULE_LEVEL, SUPPLY_DEMAND_TYPE(U1 主键)


4.1.4 MRP_SOURCING_HISTORY — 优化等级:🟡 低#

INDEX RANGE SCAN MRP_SOURCING_HISTORY_N1 (cr=3 pr=0 time=17 us cost=3 card=1)

说明: 索引选择性极好(每次仅读 3 个块),上榜原因是 SQL 执行次数较多(16,309 次),重定义收益有限,已改用修改 INITRANS 方案(详见 4.3 节)。


4.1.5 MRP_SYSTEM_ITEMS — 优化等级:🔴 高#

INDEX RANGE SCAN MRP_SYSTEM_ITEMS_N1 (cr=2684 pr=0 time=22149 us cost=71 card=14577)
执行次数:147,556

重定义顺序: ORGANIZATION_ID, COMPILE_DESIGNATOR, INVENTORY_ITEM_ID(U1 唯一索引)

效果: 聚簇因子有明显降低。


4.1.6 MTL_ITEM_REVISIONS_B — 优化等级:⚫ 非常低#

INDEX RANGE SCAN MTL_ITEM_REVISIONS_B_N1 (cr=9773142 pr=0 time=10366045 us cost=3 card=1)
执行次数:9,523,591

结论: N1 聚簇降低不明显,重定义收益小于风险,暂不推荐。


4.1.7 MTL_ITEM_REVISIONS_TL — 优化等级:🔴 高#

INDEX UNIQUE SCAN MTL_ITEM_REVISIONS_TL_U1 (cr=7279966 pr=0 time=7849002 us cost=1 card=1)
执行次数:9,523,591

特殊说明: 已缓存进 Keep Pool,但聚簇因子仍偏高,重定义后聚簇降低明显,进一步减少内存命中时的 latch 争用。

重定义顺序: INVENTORY_ITEM_ID, ORGANIZATION_ID, REVISION_ID, LANGUAGE(U1 主键)


4.1.8 MTL_SYSTEM_ITEMS_B — 优化等级:🟡 低#

INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=485300 pr=0 time=333503 us cost=2 card=1)
执行次数:294,088

结论: U1 聚簇降低不明显,且 N1、N2 索引聚簇有上升趋势,重定义反而可能劣化。


4.1.9 RCV_SHIPMENT_LINES — 优化等级:⚫ 非常低#

INDEX RANGE SCAN RCV_SHIPMENT_LINES_N1 (cr=4 pr=0 time=13 us cost=3 card=71)
执行次数:约 14,000+

结论: 单次范围扫描块数极低(cr=4),执行慢主因是次数多。重定义后 N1 聚簇从 0.7 降为 0.05,但实测第一次执行时间反而有所上升,性价比低。


4.2 修改索引#

4.2.1 RCV_TRANSACTIONS 添加新索引#

高频关联 SQL:

SELECT rct.transaction_type trans_type,
rct.transaction_id trans_id,
rct.parent_transaction_id parent_trans_id,
rct.primary_quantity trans_qty
FROM rcv_shipment_lines rsl,
rcv_transactions rct
WHERE rct.source_document_code = 'PO'
AND rsl.item_id = :b3
AND rct.shipment_line_id = rsl.shipment_line_id
AND rct.transaction_type = 'DELIVER'
AND rct.transaction_date BETWEEN :b2 AND :b1
AND EXISTS (SELECT 1
FROM po_headers_all poh
WHERE rsl.po_header_id = poh.po_header_id
AND nvl(poh.vendor_site_id, -99) = nvl(:b5, -99)
AND poh.vendor_id = :b4
AND rownum = 1)

统计信息:

Execute 16309 0.14 0.15 0 42 0 0
Fetch 16309 23.44 27.19 46 12044152 0 0

优化效果:

操作执行时间
优化前100 秒
添加 RCV_TRANSACTIONS 新索引后18 秒
进一步将视图改为基表 MTL_ITEM_REVISIONS_B5 秒

4.3 修改存储参数(MRP_SOURCING_HISTORY)#

背景: mrp_get_sourcing_history 存储过程执行 16,309 次,每次为自治事务,包含频繁的增删操作。

-- 备份原始参数
-- ALTER TABLE MRP.MRP_SOURCING_HISTORY PCTFREE 10;
-- ALTER TABLE MRP.MRP_SOURCING_HISTORY INITRANS 1;
-- ALTER INDEX MRP.MRP_SOURCING_HISTORY_N1 INITRANS 11;
-- 执行优化
ALTER TABLE MRP.MRP_SOURCING_HISTORY PCTFREE 0; -- 原 10
ALTER TABLE MRP.MRP_SOURCING_HISTORY INITRANS 20; -- 原 1
ALTER INDEX MRP.MRP_SOURCING_HISTORY_N1 INITRANS 20; -- 原 11

参数说明:

  • PCTFREE 0: 不预留块内更新空间,同等行数占用块数更少,范围扫描需访问的块数减少。该表存储过程内无 UPDATE 操作,设为 0 安全。
  • INITRANS 20: 提高事务槽数量,支持更多并发事务同时修改同一数据块,避免默认值 1/11 在高并发写入时的块级 latch 争用。

4.4 核心表缓存至 Keep Pool#

操作: 将 2 个核心高频全表扫描的表(合计约 1.2 GB)固定缓存至 Keep Buffer Pool(保留池)。

Keep Pool 大小设置: 直接设置为 10 GB(标准建议为段大小的 2 倍,考虑 UNDO 影响,为未来类似需求预留充裕空间)。

效果: 第二次执行时,Snapshot Monitor 从缓存读取,耗时降低约 50%

Keep Pool 优势:

  • 命中率极高,碎片极少(运行良好的保留池无频繁页入页出)
  • 避免大表全表扫描将共享池中其他 SQL 解析缓存刷出
  • 在 RAC 环境下减少跨节点 GC 传输

五、深度分析#

5.1 MRP_SCHEDULE_DATES 频繁增删导致聚簇持续退化#

问题现象: 每次 MRP 排产对 MRP_SCHEDULE_DATES 执行大批量 DELETE + INSERT(schedule_level=3 数据全量删除重建),每批次限 75,000 行循环执行。

核心 SQL:

-- DELETE 操作
DELETE FROM mrp_schedule_dates
WHERE schedule_level = 3
AND (schedule_designator, organization_id) IN (
SELECT input_designator_name, input_organization_id
FROM mrp_plan_schedules_v
WHERE organization_id = :b0
AND compile_designator = :b1
AND input_designator_type = 1
)
AND rownum <= :b2;
-- INSERT 操作(紧随其后)
INSERT INTO mrp_schedule_dates (
inventory_item_id, reference_schedule_id, organization_id,
schedule_designator, schedule_level, ...
)
SELECT inventory_item_id, reference_schedule_id, organization_id,
schedule_designator, 3, ...
FROM mrp_schedule_dates
WHERE schedule_level = 2
AND supply_demand_type = 1
AND (organization_id, schedule_designator) IN (
SELECT input_organization_id, input_designator_name
FROM mrp_plan_schedules_v
WHERE organization_id = :b2
AND compile_designator = :b3
AND input_designator_type = 1
);

根因: 频繁增删彻底破坏行的物理有序性,重定义只能是临时手段。

建议方向:

  • 业务层面使用 TRUNCATE PARTITION(若表已分区)替代批量 DELETE
  • 减少中间临时数据的写入量
  • 评估是否可将 schedule_level=3 的数据改为内存计算,不落库

5.2 SQL 高频执行累计消耗大#

相关 SQL:

SELECT RCT.TRANSACTION_TYPE TRANS_TYPE,
RCT.TRANSACTION_ID TRANS_ID,
RCT.PARENT_TRANSACTION_ID PARENT_TRANS_ID,
RCT.PRIMARY_QUANTITY TRANS_QTY
FROM RCV_SHIPMENT_LINES RSL,
RCV_TRANSACTIONS RCT
WHERE RCT.SOURCE_DOCUMENT_CODE = 'PO'
AND RSL.ITEM_ID = :B3
AND RCT.SHIPMENT_LINE_ID = RSL.SHIPMENT_LINE_ID
AND RCT.TRANSACTION_TYPE = 'DELIVER'
AND RCT.TRANSACTION_DATE BETWEEN :B2 AND :B1
AND EXISTS (
SELECT 1 FROM PO_HEADERS_ALL POH
WHERE RSL.PO_HEADER_ID = POH.PO_HEADER_ID
AND NVL(POH.VENDOR_SITE_ID, -99) = NVL(:B5, -99)
AND POH.VENDOR_ID = :B4
AND ROWNUM = 1
)

性能数据:

Fetch 16309 23.44 27.19 46 12044152 0 0

问题分析:

  • 单次执行快(毫秒级),但执行 16,309 次,累计 CPU 时间 23 秒,Elapsed 27 秒
  • NVL(POH.VENDOR_SITE_ID, -99) 函数包裹导致 vendor_site_id 列的索引完全失效
  • EXISTS 子查询每次均需全量扫描 PO_HEADERS_ALL

建议改写:

-- 将 NVL 函数改为等效的条件判断,使 vendor_site_id 索引可用
AND (
(POH.VENDOR_SITE_ID = :B5 AND :B5 IS NOT NULL)
OR (POH.VENDOR_SITE_ID IS NULL AND :B5 IS NULL)
)

或为 NVL(VENDOR_SITE_ID, -99) 创建函数索引:

CREATE INDEX PO_HEADERS_ALL_FN1 ON PO_HEADERS_ALL (NVL(VENDOR_SITE_ID, -99), VENDOR_ID);

5.3 自治事务频繁提交导致 log file sync 等待#

统计信息:

Execute 16309 30.16 34.79 46 12120936 166836 16309
等待事件:
log file sync Waited: 16309 Max.Wait: 0.32 Total Waited: 70.09

根因: mrp_get_sourcing_history 使用 PRAGMA AUTONOMOUS_TRANSACTION(自治事务),每次调用均独立提交。16,309 次调用即产生 16,309 次 COMMIT,每次 COMMIT 强制 LGWR 将 Redo Buffer 刷入在线重做日志,前台进程挂起等待(log file sync),累计等待 70 秒

Oracle Redo 刷新触发条件:

触发条件说明
Redo Buffer 超过 1/3 或 1 MBLGWR 自动后台刷新
DBWn 写脏块前约 3 秒超时,强制刷新
COMMIT 调用无条件立即刷新,前台进程挂起等待

类比说明:

把 Redo Buffer 比作水桶,本来是接了三分之一水才往外倒;现在每插入一行就发一次”快倒水”的命令,相当于每接一杯水就强制倒一次,效率极低。前台进程必须等 LGWR 倒完才能继续,这段等待就是 log file sync。

日志组状态(v$log):

GroupSequenceStatus
21001ACTIVE(日志已写磁盘,但 Buffer Cache 脏块尚未全部写入数据文件)
31002CURRENT(正在接收 Redo 写入)
41003INACTIVE(已完成检查点)

最优提交频率估算:

  • 若每 1,000 行 INSERT 产生约 1 MB Redo → 最优提交间隔 ≥ 每 1,000 行一次
  • 若循环处理 100 行需 3 秒 → 最优提交间隔 ≥ 每 100 行一次(避免超过 3 秒后台刷新触发时 Redo 浪费)

建议方案: 修改存储过程逻辑,改为批量操作后统一提交,或缩短自治事务使用范围(仅对真正需要独立提交的操作使用自治事务)。

注意: 长时不提交的代价是 UNDO 维护量增大,严重时导致 ORA-01555(快照太旧)。需根据业务场景权衡提交间隔。


5.4 视图替代基表导致全表扫描#

问题 SQL(执行一次耗时 57 秒):

SELECT MAX(rev.revision), items.inventory_item_id, items.organization_id
FROM mtl_item_revisions rev, -- ← 此处为视图,含 TL 多语言表 JOIN
mrp_system_items items,
mrp_plan_organizations_v mpo
WHERE trunc(rev.effectivity_date) = (
SELECT trunc(MAX(rev2.effectivity_date))
FROM mtl_item_revisions rev2 -- ← 相关子查询自关联
WHERE rev2.implementation_date IS NOT NULL
AND rev2.effectivity_date <= (trunc(SYSDATE) + .99999)
AND rev2.organization_id = rev.organization_id
AND rev2.inventory_item_id = rev.inventory_item_id
)
AND rev.organization_id = items.organization_id
AND rev.inventory_item_id = items.inventory_item_id
AND items.organization_id = mpo.planned_organization
AND items.compile_designator = mpo.compile_designator
AND mpo.organization_id = :b0
AND mpo.compile_designator = :b1
GROUP BY items.inventory_item_id, items.organization_id

执行统计:

Fetch 1477 54.64 57.21 30019 26034502 28 147556
↑ 物理读 30,019 块,CR 超 2,600 万

性能对比:

SQL 版本执行时间
使用视图 mtl_item_revisions约 57 秒
使用基表 MTL_ITEM_REVISIONS_B约 11 秒(降至原来约 1/5)

根因: mtl_item_revisions 是包含多语言(TL)表 JOIN 的视图,查询时额外关联 MTL_ITEM_REVISIONS_TL,大幅增加数据量和 JOIN 操作,且相关子查询存在自关联,优化器难以有效处理。

阻碍: 该 SQL 位于 Oracle EBS 标准 Package(源代码不可直接修改),需通过以下方式解决:

  • 申请 Oracle Support Patch
  • 联系 Oracle 客服提交 SR
  • 使用 Oracle Application 的个性化开发机制(若有)

六、优化效果汇总#

优化手段涉及对象优化等级状态核心收益
在线表重定义BOM_COMPONENTS_B🔴 高✅ 已完成CR 89,869 → 大幅降低
在线表重定义BOM_STRUCTURES_B🔴 高✅ 已完成小表读 1/5 问题解决
在线表重定义MRP_SYSTEM_ITEMS🔴 高✅ 已完成聚簇明显降低
在线表重定义MTL_ITEM_REVISIONS_TL🔴 高✅ 已完成9.5M 次唯一扫描 CR 大幅下降
在线表重定义MRP_SCHEDULE_DATES🟡 低✅ 已完成效果随时间退化,非根治方案
在线表重定义RCV_SHIPMENT_LINES⚫ 非常低✅ 已完成收益极有限,首次反而略慢
添加/修改索引RCV_TRANSACTIONS🔴 高✅ 已完成100s → 18s;改用基表后 → 5s
修改存储参数MRP_SOURCING_HISTORY🟡 中✅ 已完成PCTFREE 10→0;INITRANS 提升至 20
Keep Pool 缓存核心全扫表(1.2GB)🔴 高✅ 已完成Snapshot Monitor 耗时降约 50%
SQL 改写(基表替换视图)mtl_item_revisions🔴 高⏳ 待解决可降至 1/5 时间,需修改 EBS 标准包
减少自治事务提交频率mrp_get_sourcing_history🔴 高⏳ 待解决log file sync 等待 70s 可消除
MRP_SCHEDULE_DATES 架构优化MRP 增删逻辑🟡 中⏳ 待解决根治聚簇退化问题
SQL 改写(NVL 函数索引失效)PO_HEADERS_ALL🟡 中⏳ 待解决高频 SQL 索引可用性提升

七、MRP 性能优化扩展框架#

基于 Oracle Support 官方调优指南(Doc 100956.1 / 100964.1),结合本次优化实践,整理完整优化框架如下:

7.1 数据库基础资源层#

检查项说明本次涉及
物理内存是否充足SGA/PGA 配置
日志组数量和大小log file sync 等待是否成为瓶颈
Redo Buffer 空间空间不足导致重做竞争(redo log space requests
UNDO 表空间磁盘分离与数据文件在同一磁盘会产生 I/O 竞争
SSD vs 机械硬盘SSD 无寻道延迟,适合随机 I/O 密集场景
PGA 排序区多趟排序(sort disk)表明 PGA 不足,可提高 PGA_AGGREGATE_TARGET

7.2 缓存与共享池层#

检查项说明本次涉及
Buffer Cache 命中率< 95% 需扩大 Buffer Cache
Keep Pool 配置固定热点小表,防止被全扫大表刷出
共享池碎片大量游标解析导致共享池碎片化
库缓存(Library Cache)命中率使用绑定变量,减少硬解析
数据字典缓存命中率V$ROWCACHE 中 GETS/MISSES 比
DBWR 进程数脏块写入速度跟不上时增加 DB_WRITER_PROCESSES

7.3 索引与表设计层#

检查项说明本次涉及
聚簇因子(CF)索引范围扫描核心指标,重点关注
行链接与行迁移PCTFREE 不足或行变大导致,影响读取效率
统计信息准确性过期统计信息导致错误执行计划✅(部分)
表分区与索引分区大表分区可显著降低 DML 和扫描代价
列组统计信息多列联合过滤时,单列统计不准,需创建列组统计
高水位(HWM)有全表扫描时需关注;无全表扫描则影响有限✅(已通过重定义降低)

7.4 SQL 执行计划层#

检查项说明本次涉及
函数包裹导致索引失效NVL、TO_CHAR 等包裹索引列时索引无法使用
绑定变量窥视(Bind Peeking)绑定变量数据倾斜时可能生成错误执行计划
视图展开视图内包含多余 JOIN 时阻止合理优化
相关子查询转换相关子查询往往可改写为 JOIN 提升效率
执行次数 × 单次耗时高频低耗 SQL 累计影响同样不可忽视

7.5 并发与事务层#

检查项说明本次涉及
INITRANS 事务槽不足并发 DML 同一块时产生等待
自治事务提交频率每次提交均触发 LGWR 刷盘
RAC GC 等待跨节点数据块传输开销
锁争用行锁、表锁分析

7.6 应用配置层#

检查项说明本次涉及
BOM 深度和大小BOM 层级越深,低层码计算越耗时
并发管理器配置Worker 数量与服务器核数匹配
是否安装最新补丁Oracle EBS 补丁包含已知性能修复
SQL*Net 网络带宽非瓶颈则不需特别关注

八、总结#

项目一句话定位#

Oracle EBS MRP 核心排产链路性能优化,从 50 分钟降至可接受范围,核心手段是通过 Trace/AWR 定位根因后综合运用表重定义、索引优化、Redo 调优和 Keep Pool。

逻辑链(这是整个项目的叙事骨架)#

DBA 执行 SHRINK
→ 行物理移动,存储顺序打乱
→ Clustering Factor 急剧升高
→ Index Range Scan 变随机读
→ CR 暴增,latch / GC buffer busy 等待
→ MRP 排产从正常水平劣化到 50 分钟
→ 通过重定义恢复行顺序 → CF 下降 → CR 下降 → 性能恢复

这条链讲清楚了,整个项目的技术深度就到位了。面试时不管从哪个环节问,都能顺着链条向前和向后延伸。

几个值得强调的细节#

重定义为什么按主键排序而不是按业务索引排序。 按业务索引排序只优化那一个索引的 CF,其他索引会变差;按主键排序是恢复数据自然写入状态,是全局最优平衡。

CF 高不一定要处理。 判断标准是实际 CR,不是 CF 绝对值。没有范围扫描,或者扫描行数极少,CF 高也可以不管。

log file sync 的本质。 不是 IO 慢,而是提交太频繁,把异步的 LGWR 刷盘变成了同步等待。解法是减少提交次数,不是加快磁盘。

MRP_SCHEDULE_DATES 是未根治的遗留问题。 重定义只是治标,业务频繁增删会让 CF 持续退化。这个问题如果被追问,说明面试官在考察你对优化局限性的认知,诚实讲清楚比硬撑更好。

PCTFREE 改为 0 的前提一定要说清楚。 必须确认表没有 UPDATE 操作才能改,否则行更新扩行会导致行迁移(Row Migration),反而劣化性能。这个细节体现了操作严谨性。


九、参考资料#

文档说明
Oracle Support Doc 100956.1MRP Core/Mfg 性能调优及故障处理指南
Oracle Support Doc 100964.1数据库和 Core/MFG MRP 相关性能问题排查
Oracle Support Doc 223603.1MRP 性能优化扩展参考
Oracle Support Doc 836809.1MRP 相关补丁及解决方案
Oracle Support Doc 1931325.1MRP 性能问题 CAUSE 分析
Oracle MRP 官方文档Oracle MRP 架构示意图

报告整理于 Oracle EBS MRP 优化实践文档,适用于 Oracle Database 11g/12c/19c + RAC 环境。

Oracle | erp、mrp、性能优化 | 设计文档
https://tblog.mmzhiku.xyz/posts/projects/projects-oracle-erp-performance-optimization/
作者
MmzMing
发布于
2026-01-02
许可协议
CC BY-NC-SA 4.0

评论区

看板娘
公告
友链 互换友链

正在招募技术类博客友链,要求原创、稳定更新。点击了解更多。

查看详情
维护 服务器升级

本周日凌晨 2:00-4:00 进行服务器维护,期间站点可能短暂无法访问。

欢迎 关于我的介绍

欢迎来到我的博客,我是深耕java、python和react技术开发。热爱技术、持续学习,欢迎同好交流探讨,也欢迎大佬互换友链。

查看详情
音乐
封面

音乐

暂未播放

0:00
0:00
暂无歌词
标签
# AI 6 # 认证 5 # 安全 4 # 登录 3 # Skill 2 # Redis 2 # Bitmap 2 # 部署 2 # Java 2 # 并发编程 2 # 性能优化 2 # 前端 1 # 博客 1 # Prompt 1 # 工作流 1 # RAG 1 # Cloudflare 1 # 缓存设计 1 # 高性能 1 # Bot 1 # Umami 1 # Vercel 1 # 线程池 1 # 虚拟线程 1 # 分布式 1 # JWT 1 # OAuth2 1 # MinIO 1 # 文件存储 1 # 扫码登录 1 # WebSocket 1 # Agent 1 # Oracle 1 # 数据库 1
目录

隐私政策

更新日期: 2026/5/19
生效日期: 2026/5/19

导言#

MmzMing的知识库 是一款由 MmzMing(以下简称“我们”)提供的产品。您在使用我们的服务时,我们可能会收集和使用您的相关信息。我们希望通过本《隐私政策》向您说明,在使用我们的服务时,我们如何收集、使用、储存和分享这些信息,以及我们为您提供的访问、更新、控制和保护这些信息的方式。

本《隐私政策》与您所使用的 MmzMing的知识库 服务息息相关,希望您仔细阅读,在需要时,按照本《隐私政策》的指引,作出您认为适当的选择。本《隐私政策》中涉及的相关技术词汇,我们尽量以简明扼要的表述,并提供进一步说明的链接,以便您的理解。

您使用或继续使用我们的服务,即意味着同意我们按照本《隐私政策》收集、使用、储存和分享您的相关信息。

如对本《隐私政策》或相关事宜有任何问题,请通过 784774835@qq.com 与我们联系。

1. 我们收集的信息#

我们或我们的第三方合作伙伴提供服务时,可能会收集、储存和使用下列与您有关的信息。如果您不提供相关信息,可能无法注册成为我们的用户或无法享受我们提供的某些服务,或者无法达到相关服务拟达到的效果。

  • 个人信息:您在注册账户或使用我们的服务时,向我们提供的相关个人信息,例如电话号码、电子邮件等。
  • 日志信息:指您使用我们的服务时,系统可能通过 cookies、标识符及相关技术收集的信息,包括您的 设备信息浏览信息点击信息,并将该等信息储存为日志信息,为您提供个性化的用户体验、保障服务安全。您可以通过浏览器设置拒绝或管理 cookie、标识符或相关技术的使用。
  • 位置信息:指您开启设备定位功能并使用我们基于位置提供的相关服务时,收集的有关您位置的信息,包括:
    • 您通过具有定位功能的移动设备使用我们的服务时,通过 GPS 或 WiFi 等方式收集的您的地理位置信息;
    • 您可以通过关闭定位功能,停止对您的地理位置信息的收集。

2. 信息的存储#

2.1 信息存储的方式和期限#

我们会通过安全的方式存储您的信息,包括本地存储(例如利用 APP 进行数据缓存)、数据库和服务器日志。

一般情况下,我们只会在为实现服务目的所必需的时间内或法律法规规定的条件下存储您的个人信息。

2.2 信息存储的地域#

我们会按照法律法规规定,将境内收集的用户个人信息存储于中国境内。

目前我们不会跨境传输或存储您的个人信息。将来如需跨境传输或存储的,我们会向您告知信息出境的目的、接收方、安全保证措施和安全风险,并征得您的同意。

2.3 产品或服务停止运营时的通知#

当我们的产品或服务发生停止运营的情况时,我们将以推送通知、公告等形式通知您,并在合理期限内删除您的个人信息或进行匿名化处理,法律法规另有规定的除外。

3. 信息安全#

我们使用各种安全技术和程序,以防信息的丢失、不当使用、未经授权阅览或披露。例如,在某些服务中,我们将利用加密技术(例如 SSL)来保护您提供的个人信息。但请您理解,由于技术的限制以及可能存在的各种恶意手段,在互联网行业,即便竭尽所能加强安全措施,也不可能始终保证信息百分之百的安全。您需要了解,您接入我们的服务所用的系统和通讯网络,有可能因我们可控范围外的因素而出现问题。

4. 我们如何使用信息#

我们可能将在向您提供服务的过程之中所收集的信息用作下列用途:

  • 向您提供服务;
  • 在我们提供服务时,用于身份验证、客户服务、安全防范、诈骗监测、存档和备份用途,确保我们向您提供的产品和服务的安全性;
  • 帮助我们设计新服务,改善我们现有服务;
  • 使我们更加了解您如何接入和使用我们的服务,从而针对性地回应您的个性化需求,例如语言设定、位置设定、个性化的帮助服务和指示,或对您和其他用户作出其他方面的回应;
  • 向您提供与您更加相关的广告以替代普遍投放的广告;
  • 评估我们服务中的广告和其他促销及推广活动的效果,并加以改善;
  • 软件认证或管理软件升级;
  • 让您参与有关我们产品和服务的调查。

5. 信息共享#

目前,我们不会主动共享或转让您的个人信息至第三方,如存在其他共享或转让您的个人信息或您需要我们将您的个人信息共享或转让至第三方情形时,我们会直接或确认第三方征得您对上述行为的明示同意。

为了投放广告,评估、优化广告投放效果等目的,我们需要向广告主及其代理商等第三方合作伙伴共享您的部分数据,要求其严格遵守我们关于数据隐私保护的措施与要求,包括但不限于根据数据保护协议、承诺书及相关数据处理政策进行处理,避免识别出个人身份,保障隐私安全。

我们不会向合作伙伴分享可用于识别您个人身份的信息(例如您的姓名或电子邮件地址),除非您明确授权。

我们不会对外公开披露所收集的个人信息,如必须公开披露时,我们会向您告知此次公开披露的目的、披露信息的类型及可能涉及的敏感信息,并征得您的明示同意。

随着我们业务的持续发展,我们有可能进行合并、收购、资产转让等交易,我们将告知您相关情形,按照法律法规及不低于本《隐私政策》所要求的标准继续保护或要求新的控制者继续保护您的个人信息。

另外,根据相关法律法规及国家标准,以下情形中,我们可能会共享、转让、公开披露个人信息无需事先征得您的授权同意:

  • 与国家安全、国防安全直接相关的;
  • 与公共安全、公共卫生、重大公共利益直接相关的;
  • 犯罪侦查、起诉、审判和判决执行等直接相关的;
  • 出于维护个人信息主体或其他个人的生命、财产等重大合法权益但又很难得到本人同意的;
  • 个人信息主体自行向社会公众公开个人信息的;
  • 从合法公开披露的信息中收集个人信息的,如合法的新闻报道、政府信息公开等渠道。

6. 您的权利#

在您使用我们的服务期间,我们可能会视产品具体情况为您提供相应的操作设置,以便您可以查询、删除、更正或撤回您的相关个人信息,您可参考相应的具体指引进行操作。此外,我们还设置了投诉举报渠道,您的意见将会得到及时的处理。如果您无法通过上述途径和方式行使您的个人信息主体权利,您可以通过本《隐私政策》中提供的联系方式提出您的请求,我们会按照法律法规的规定予以反馈。

当您决定不再使用我们的产品或服务时,可以申请注销账户。注销账户后,除法律法规另有规定外,我们将删除或匿名化处理您的个人信息。

7. 变更#

我们可能适时修订本《隐私政策》的条款。当变更发生时,我们会在版本更新时向您提示新的《隐私政策》,并向您说明生效日期。请您仔细阅读变更后的《隐私政策》内容,若您继续使用我们的服务,即表示您同意我们按照更新后的《隐私政策》处理您的个人信息。

8. 未成年人保护#

我们鼓励父母或监护人指导未满十八岁的未成年人使用我们的服务。我们建议未成年人鼓励他们的父母或监护人阅读本《隐私政策》,并建议未成年人在提交的个人信息之前寻求父母或监护人的同意和指导。