上午接到电话说ASCP的计划数据收集又出问题了。看了一下请求记录和咨询业务人员搞清了问题的起因：业务人员提交了计划数据收集的请求，过了近半小时看到请求的状态是暂停，就cancel掉了请求。此时请求的状态变为：已终止。然后无论是重新运行计划数据收集请求还是清除分段表都会报以下log记录的错误。
+---------------------------------------------------------------------------+
高级供应链计划管理系统: Version : 11.5.0 - Development
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
MSCPDX module: 请求集 - 计划数据收集
+---------------------------------------------------------------------------+
当前的系统时间为 03-12-2008 12:45:41
+---------------------------------------------------------------------------+
**Starts**03-12-2008 12:45:42
**Ends**03-12-2008 12:45:42
已提交阶段 计划数据提取 的请求。
+---------------------------------------------------------------------------+
FND_FILE 中日志消息开始
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
FND_FILE 中日志消息结束
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
当前的系统时间为 03-12-2008 12:45:42
+---------------------------------------------------------------------------+
重新启动请求在：03-12-2008 12:46:13
**Starts**03-12-2008 12:46:13
**Ends**03-12-2008 12:46:13
已正常完成此设置并产生结果 错误。
此结果由阶段 计划数据提取 确定。
+---------------------------------------------------------------------------+
FND_FILE 中日志消息开始
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
FND_FILE 中日志消息结束
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
正在执行请求完成选项...
已完成执行请求完成选项。
+---------------------------------------------------------------------------+
已完成并发请求
当前的系统时间为 03-12-2008 12:46:13
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
高级供应链计划管理系统: Version : 11.5.0 - Development
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
MSCPDP module: 计划数据提取
+---------------------------------------------------------------------------+
当前的系统时间为 03-12-2008 12:46:11
+---------------------------------------------------------------------------+
**Starts**03-12-2008 12:46:12
**Ends**03-12-2008 12:46:12
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启动“计划数据收集”。
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启
+---------------------------------------------------------------------------+
FND_FILE 中日志消息开始
+---------------------------------------------------------------------------+
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启动“计划数据收集”。
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启动“计划数据收集”。
+---------------------------------------------------------------------------+
FND_FILE 中日志消息结束
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
正在执行请求完成选项...
未打印输出文件，因为：
已禁用此报表的打印选项。
已完成执行请求完成选项。
+---------------------------------------------------------------------------+
已完成并发请求
当前的系统时间为 03-12-2008 12:46:12
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
高级供应链计划管理系统: Version : 11.5.0 - Development
Copyright (c) 1979, 1999, Oracle Corporation. All rights reserved.
MSCPDCP module: 计划数据收集 - 清除分段表
+---------------------------------------------------------------------------+
当前的系统时间为 03-12-2008 12:51:25
+---------------------------------------------------------------------------+
**Starts**03-12-2008 12:51:25
**Ends**03-12-2008 12:51:26
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启动“计划数据收集”。
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数
据收集 - 清除分段表”程序，然后再次启
+---------------------------------------------------------------------------+
FND_FILE 中日志消息开始
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
FND_FILE 中日志消息结束
+---------------------------------------------------------------------------+
+---------------------------------------------------------------------------+
正在执行请求完成选项...
未打印输出文件，因为：
已禁用此报表的打印选项。
已完成执行请求完成选项。
正在删除输出文件。
+---------------------------------------------------------------------------+
已完成并发请求
当前的系统时间为 03-12-2008 12:51:26
+---------------------------------------------------------------------------+
--以上是三个请求的日志。我们知道计划数据收集是一个请求集，里面有很多子请求比如：计划数据提取；刷新集合快照；计划数据提取进程；装入计划ODS工作进程；最后是清除分段表。当运行其子请求的时候这个请求集的状态会变为暂停的状态，我们不能取消它。如果计划数据收集出错一般按照日志的提示，清除分段表再跑计划数据收集就应该没问题了。
清除分段表为什么没有成功呢？来看一下清除分段表到底做了什么。
以系统管理员的身份进去EBS 并发-》方案-》定义 打开并发程序form，查询程序"计划数据收集 - 清除分段表" 记住可执行的名称："MSCPDCP" 这时可以看到可执行的方法是PL/SQL存储过程还是JAVA代码。我们再来查看一下这个可执行并发程序的详细信息：方案-》可执行 打开可执行并发程序form。输入可执行的名称：MSCPDCP 然后查询可以看到执行文件名了：MSC_CL_COLLECTION.Purge_Staging_Tables
。呵呵。用OEM或pl/sql deverlop 查看这个包体的方法。包体和包头名为MSC_CL_COLLECTION。来看看Purge_Staging_Tables的定义：
/* purge the staging tables
it should be launched as a concurrent program */
PROCEDURE PURGE_STAGING_TABLES( ERRBUF OUT NOCOPY VARCHAR2,
RETCODE OUT NOCOPY NUMBER,
pINSTANCE_ID IN NUMBER,
pVALIDATION IN NUMBER)
IS
BEGIN
SELECT APPS_VER,
SYSDATE,
FND_GLOBAL.USER_ID,
SYSDATE,
FND_GLOBAL.USER_ID
INTO v_apps_ver,
v_current_date,
v_current_user,
v_current_date,
v_current_user
FROM MSC_APPS_INSTANCES
WHERE INSTANCE_ID= pINSTANCE_ID;
IF pVALIDATION= SYS_YES THEN
IF SET_ST_STATUS( ERRBUF, RETCODE,
pINSTANCE_ID, G_ST_PURGING) THEN
COMMIT;
ELSE
ROLLBACK;
RETURN;
END IF;
END IF;
PURGE_STAGING_TABLES_SUB( pINSTANCE_ID);
IF SET_ST_STATUS( ERRBUF, RETCODE, pINSTANCE_ID, G_ST_EMPTY) THEN
COMMIT;
END IF;
END PURGE_STAGING_TABLES;
FUNCTION SET_ST_STATUS( ERRBUF OUT NOCOPY VARCHAR2,
RETCODE OUT NOCOPY NUMBER,
pINSTANCE_ID IN NUMBER,
pST_STATUS IN NUMBER)
RETURN BOOLEAN
IS
lv_staging_table_status NUMBER;
BEGIN
---===================== PURGING ===================
ELSIF pST_STATUS= G_ST_PURGING THEN
SELECT mai.ST_STATUS
INTO lv_staging_table_status
FROM MSC_APPS_INSTANCES mai
WHERE mai.INSTANCE_ID= pINSTANCE_ID
FOR UPDATE;
IF lv_staging_table_status= G_ST_EMPTY THEN
FND_MESSAGE.SET_NAME('MSC', 'MSC_ST_ERROR_NO_DATA');
ERRBUF:= FND_MESSAGE.GET;
RETCODE := G_WARNING;
RETURN FALSE;
ELSIF lv_staging_table_status= G_ST_PULLING THEN
FND_MESSAGE.SET_NAME('MSC', 'MSC_ST_ERROR_PULLING');
ERRBUF:= FND_MESSAGE.GET;
RETCODE := G_ERROR;
RETURN FALSE;
ELSIF lv_staging_table_status= G_ST_COLLECTING THEN
FND_MESSAGE.SET_NAME('MSC', 'MSC_ST_ERROR_DATA_EXIST');
ERRBUF:= FND_MESSAGE.GET;
RETCODE := G_ERROR;
RETURN FALSE;
ELSIF lv_staging_table_status= G_ST_PURGING THEN
FND_MESSAGE.SET_NAME('MSC', 'MSC_ST_ERROR_PURGING');
ERRBUF:= FND_MESSAGE.GET;
RETCODE := G_ERROR;
RETURN FALSE;
ELSE
RETCODE := G_SUCCESS;
UPDATE MSC_APPS_INSTANCES
SET ST_STATUS= G_ST_PURGING,
SO_TBL_STATUS= SYS_YES,
LAST_UPDATE_DATE= v_current_date,
LAST_UPDATED_BY= v_current_user,
REQUEST_ID= FND_GLOBAL.CONC_REQUEST_ID
WHERE INSTANCE_ID= pINSTANCE_ID;
RETURN TRUE;
END IF;
程序到判断状态的时候应该是过不去了，也就是这段代码：IF SET_ST_STATUS( ERRBUF, RETCODE,pINSTANCE_ID, G_ST_PURGING)
系统从MSC_APPS_INSTANCES这张表取ST_STATUS字段的值来赋给变量lv_staging_table_status。我检查系统当前ST_STATUS字段的值：
SQL> SELECT ST_STATUS FROM MSC_APPS_INSTANCES;
ST_STATUS
----------
1
1对应什么变量呢？查看包头发现一些常量的定义：
G_ST_EMPTY ：=1
G_ST_PULLING ：=1
G_ST_READY :=2
G_ST_COLLECTING :=3
G_ST_PURGING :=4
我们的变量是1所以查看这个语句：
ELSIF lv_staging_table_status= G_ST_PULLING THEN
FND_MESSAGE.SET_NAME('MSC', 'MSC_ST_ERROR_PULLING');
ERRBUF:= FND_MESSAGE.GET;
'MSC_ST_ERROR_PULLING'这个消息代表什么呢？以应用开发员的职责进系统，应用产品-》消息 输入消息的名称：'MSC_ST_ERROR_PULLING'
当前信息文本显示：
正在为此例程运行其它“计划数据提取”流程，或者较早的“计划数据提取”流程意外中止。如果出现后一种情况，则需要首先启动“计划数据收集 - 清除分段表”程序，然后再次启动“计划数据收集”。
Either another Planning Data Pull process is running for this instance or an earlier Planning Data Pull process may have
terminated abnormally. In the latter case, you need to launch the 'Planning Data Collection - Purge Staging Table' program
before launching Planning Data Collections again.
这刚好是跑清除分段表请求出错的提示。问题到这似乎很明显了。MSC_APPS_INSTANCES这张表ST_STATUS字段的值决定验证程序是否能通过。其实我们也可以绕过验证程序，还记得PURGE_STAGING_TABLES这个procedure么？有这样一段代码：
IF pVALIDATION= SYS_YES THEN
IF SET_ST_STATUS( ERRBUF, RETCODE,
pINSTANCE_ID, G_ST_PURGING) THEN
COMMIT;
ELSE
ROLLBACK;
RETURN;
END IF;
END IF;
我们在提交清除分段表的时候有两个参数需要输入，一个是instance，另一个就是是否需要验证。我们可以选不需要验证，这样就绕过了这段代码。我们选择否，然后继续提交清除分段表的请求就OK了。计划数据收集，计划数据提取等请求也能正常运行了。注意清除分段表请求跑完后ST_STATUS字段的值为：
SQL> SELECT ST_STATUS FROM MSC_APPS_INSTANCES;
ST_STATUS
----------
0
那没跑之前我估计是2，也就是G_ST_READY :=2这种情况。我们是否可以直接update MSC_APPS_INSTANCES这张表ST_STATUS字段的值呢？我没有在prod环境尝试，测试环境我做了测试是可以的。但对应用是否有影响就不确定了。
