抛出请求名称为：“基于内存的快照”，“快照监控程序”，“基于内存的快照工作进程”的状态错误。
解决思路：首先是查看请求的日志，但是有这么多请求失败，而且日志记录的大多数错误都类似这样：
APP-MRP-22075: 出现内部错误(mrnspxt, 1, 770138, )
@ 错误文本 原因：当前例行程序遇到指定的 @ 错误文本 x 措施：请与您的客户支持代表联系。
APP-MRP-22075: 出现内部错误(main, 13, , )
@ 错误文本 原因：当前例行程序遇到指定的 @ 错误文本 x 措施：请与您的客户支持代表联系。
***** 程序终止 - 基于内存的快照工作进程 *****
去METALINK查发现有多种原因，比如说系统bug，进程异常等等。看这些文档花了不少时间。后来仔细的看日志发现这些报错是有关联的。一些基于内存的快照工作流程的请求都报同一个请求失败。比如：APP-MRP-22100: 请求 770138 失败，而770138这个请求就是快照监控程序的请求。打开这个请求的日志发现：10011APP-MRP-22100: 请求 770133 失败。再找到770133这个请求，请求名称为：“基于内存的快照”，检查改请求的错误日志：
APP-FND-01564: mslsnp_snp_po 中出现 ORACLE 错误 1455
原因：由于 ORA-01455: 转换列溢出整数数据类型
, mslsnp_snp_po 失败。
出现错误时执行的 SQL 语句为: select supplies.transaction_id ,supplies.inventory_item_id ,supplies.o (是从文件 5907099/msc/lib/mslsup.pc 执行该语句的)。
APP-MRP-22075: 出现内部错误(mrnspxt, 12, 10004, )
@ 错误文本 原因：当前例行程序遇到指定的 @ 错误文本 x 措施：请与您的客户支持代表联系。
APP-MRP-22075: 出现内部错误(mrnspgpt, 14, 202 , 10004, )
@ 错误文本 原因：当前例行程序遇到指定的 @ 错误文本 x 措施：请与您的客户支持代表联系。
APP-MRP-22075: 出现内部错误(main, 13, , )
@ 错误文本 原因：当前例行程序遇到指定的 @ 错误文本 x 措施：请与您的客户支持代表联系。
含错误的报表：
select supplies.transaction_id ,supplies.inventory_item_id ,supplies.o
5907099/msc/lib/mslsup.pc
***** 程序终止 - 基于内存的快照 *****
--我想这个才是导致这些请求失败的根本原因，再分析时间上的逻辑也都符合要求。根据这个错误去METALINK上查。Note:387716.1 比较清楚的描述了这个问题。以下是它的一个解决方案。
Symptoms
Planning Process is failing at the Memory Based Snapshot Worker stage with the following error:
APP-MRP-22075: An internal error has occurred (mrnspgmsg, 1, 8674691, )
APP-FND-01564: ORACLE error 1455 in mslsnp_snp_po
Cause: mslsnp_snp_po failed due to ORA-01455: converting column overflows integer datatype
The issue can be reproduced at will with the following steps:
1.Supply Chain Plan --> Launch
Cause
The issue is caused by the following setup: huge number for purch_line_num comming in for order_number.
Changing the PO Line Number (purch_line_num) to a small number and rerunning the plan will complete successfully.
Solution
To implement the solution, please execute the following steps:
1.Search the PO Line Number which cause the issue by running the script first into the APS Instance:
select * from msc_supplies
where purch_line_num > 10000
and plan_id = -1
select purch_line_num,order_number from msc_supplies
where plan_id = -1
and purch_line_num is not null
order by purch_line_num desc
Then into the Source Instance:
select LINE_NUM from apps.po_lines_all
where LINE_NUM > 3000
2.Change the PO Line Number (purch_line_num) to a smaller number.
3. Go into the responsibility: Purchasing > Navigate to Purchase Orders.
4. Query up the purchase order and correct the line number. If needed re-approve the PO (use script poxrespo.sql from Note 390023.1 to reset Standard, Blanket, Planned and Contract purchase orders .
5. Allow the planning manager to cycle once.
6. Recollect the PO data.
7. Rerun the plan(s).
8. If the issue is resolved, please migrate the solution as appropriate to other environments.
--解决方案就是减小这个purch_line_num。在实际的查询中有5条记录purch_line_num的数量达到10几亿。所以“ORA-01455: 转换列溢出整数数据类型”这样的错误发生了。ORACLE EBS在位数超过9位的时候往往会发生这种错误。在实际的解决过程中按照METALINK的解决流程我到第4步就走不下去了。因为我查不到
相应的purchase order 。后来联系业务员才知道ORDER_NUMBER是采购申请号，但根据业务人员反映虽然找到这个采购申请但无法打开并修改line number。但不修改的话ASCP肯定是跑不过的。（其实ASCP在各个事业部是可以分开跑的）最后的解决方案是这样的：根据采购申请号创建采购订单，然后再做退回申请的操作。退回的申请可以重新打开，打开后申请行的数字就可以更改了。问题到此算是圆满的解决了。
--产生问题的原因是什么？这个是最主要的。免的业务老是把问题都怪在系统上。为什么purch_line_num达到十几亿？根据查询这个采购申请找到了这个责任人。经询问他是将ITEM编号误输进去了。看来又是一次误操作引发的故障（之前的财务关不了帐，也是误操作）。所以EBS的稳定运行还要依赖于用户的规范操作，同时ORACLE程序也应该好好考虑这些误操作。