自动运行的 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 任务详细信息的图片，以便您查看是否有任何设置错误。另外，这是我所说的错误：“事件监视器“DB2DETAILDEADLOCK”已达到其文件容量”

TEST TASK IMAGE

Answer 1

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

如果 cron 是调度程序（如您最初编写的那样），那么您的问题很可能与 Db2 无关，请参阅此答案末尾的检查。如果您缺乏使用 cron 的技能，请咨询您的 linux 管理员或研究文档，在线信息很多。

如果 Db2 管理任务调度程序 (ATS) 是调度程序（正如您随后从 cmets 中暗示的那样），那么问题可能出在 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 入口命令（通常是脚本）是否仍然存在，并且有 正确的权限，它可以运行 指定帐户。

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

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