自动运行的DB2存储过程未触发

Question

我有一段时间前创建的存储过程，实际上是在2016年，它设置为每年在第一天运行。该程序自动在2017.01.01运行，但现在在2018年，这并没有自动发生，我不得不手动触发它。你有什么提示我可以检查什么出错了？ 您可以在下面找到所需的详细信息：

DB2服务器操作系统：Linux; DB2版本：10.1.3.0; 调度员：我正在使用cron。

1. 我检查了ADMIN_TASK_LIST并且END_TIME列是NULL，所以从我的观点来看，这应该永远不会停止运行; 2.在1月1日，2018年没有进入，仅在2017年;
2. 我会检查文件并通知你;
3. 我找不到任何ATS_TASK_LIST，你的意思是ADMIN_TASK_LIST吗？

我检查过db2diag并且发现了一个空格错误但是根据我的同事的反馈应该与此无关。另外，我想提一下昨天我们已经创建了一个测试任务，该任务设置为今天在某个小时执行并且没有被触发。我附上了TEST任务详细信息的图像，以便您查看是否存在任何设置错误。此外，这是我正在谈论的错误：＆＃34;事件监视器＆＃34; DB2DETAILDEADLOCK＆＃34;已达到其文件容量＆＃34;

TEST TASK IMAGE

Answer 1

看来你不知道你的工作安排是什么。

如果cron是调度程序（正如您最初编写的那样），那么很可能您的问题与Db2无关，请参阅本答案末尾的检查。如果您缺乏cron的技能，请询问您的Linux管理员或研究文档，并且有大量的在线信息。

如果Db2管理任务调度程序（ATS）是调度程序（正如您随后从您的注释中暗示的那样），那么问题可能在于Db2。 Cron与ATS无关，它们是无关的。那么你的问题是“为什么ATS不能完成我的工作”。这也经常被问到。

建议检查ATS作业。

1. 检查作业是否仍存在于ADMIN_TASK_LIST中且定义正确，尤其是END_TIME列。

2. 检查1月1日此作业的ADMIN_TASK_STATUS中是否有条目，并研究该条目以了解作业失败原因的详细信息

3. 如果ADMIN_TASK_LIST中的作业具有正确的定义，并且如果ADMIN_TASK_STATUS中没有该作业的条目，则检查db2acd是否仍在运行，并检查db2acd是否内存不足（db2diag中的证据） ）。我已经看到停止db2acd可以解决这个问题（Db2看门狗会立即重启db2acd）。

4. 如果您仍然卡住，请编辑您的问题以显示失败的运行的ATS_TASK_LIST条目和ADMIN_TASK_STATUS条目。请注意准确回应澄清请求。

============================================

如果cron是调度程序，则以下建议适用：

很可能你的问题是“为什么cron没有完成我的工作”。

这是一个经常被问到的问题，所以你可以研究一下（有很多页面提供有关该主题的建议）。

请参阅https://unix.stackexchange.com/questions/207/where-are-cron-errors-logged

检查crontab条目以确保它仍然有效。

检查cron entry命令（通常是脚本）是否仍然存在，并且具有 正确的权限，它可以运行 指定的帐户。

调查cron日志文件（如果仍然可用）并研究该文件 寻找线索。这将显示cron是否尝试启动作业，以及退出代码是什么。

当cron无法运行作业且该作业有一些输出时，cron会通过电子邮件向crontab所有者发送失败作业的输出。 但这可能取决于cron条目中的确切命令 （如果它将stdout和stderr重定向到某个文件，而不是 在哪种情况下你应该查阅该文件）。 如果cron条目没有重定向stdout / stderr，并且脚本/命令在运行时给出输出，那么请参考cron所有者的邮箱以查看1月1日收到的电子邮件。