Troubleshooting
Problem
Administrative Task Scheduler (ATS) cannot handle the time change if time springs forward. For existing tasks, ATS daemon executes the task. If done, it schedules the next execution of this task (for a daily task, wait 24 hours after last invocation) and goes to sleep until the next scheduled time comes up. If the clock springs forward (DST change), ATS wakes up one hour too late and does not execute the task.
Symptom
Tasks like daily or weekly database backups are planned with the Administrative Task Scheduler (ATS). After the system time springs forward (DST), the first scheduled task after this time change does not run. The second and all other tasks scheduled after the time shift are started automatically through the ATS daemon.
Cause
ATS wakes up every 5 minutes to check for new or updated tasks.
For existing tasks, the daemon wakes up when the next scheduled execution time arrives.
Information Center:
Every five minutes the DB2 autonomic computing daemon checks for new or updated tasks. To do this, it briefly connects to each active database and retrieves the new and updated task definitions.
...
Internally, the daemon maintains a list of the active tasks. When a task's scheduled execution time arrives, the daemon connects to the appropriate database and calls the procedure associated with the task.
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.gui.doc/doc/c0054380.html
If for example a task is scheduled to run every 10 minutes (i.e. to run at 14:40, 14:50, 15:00), the ATS daemon waits for 10 minutes after the task at 14:40 was executed. Then it wakes up to execute the task at 14:50. If the clock is moved forward 5 minutes, ATS daemon will wake up at 14:55, (it waited the same 10 minutes, but the clock fly from 14:40 to 14:55), it will find the task at 14:50 already expired and will not execute it.
For the ATS daemon thread, the way how it determines "When a task's scheduled execution time arrives" is, it gets the information of the first task in its in-memory task list which is sorted by time, check its next scheduled execution time, execute it if it is time to run, otherwise it will calculate the time to wait (in seconds) and go to sleep, it does not wake up until the waiting-time elapsed.
To reflect this behavior the DB2 documentation chapter "ADMIN_TASK_ADD procedure - Schedule a new task" was updated to describe both cases:
1) all tasks scheduled during the DST change time (e.g. 2am-3am) will not run
2) first task after the DST change will not run
The documentation now states:
The begin_timestamp, end_timestamp, and schedule are based on the server's time zone. Special attention is required when scheduling a task during the transition period of daylight savings time (DST). If the task is scheduled to run 2:01 AM and it is the time of year when the time springs forward, the task will not run as the clock skips from 2:00 AM to 3:00 AM. If the DST change occurs when the database is activated and there is no task scheduled during the DST change time, the first scheduled task after the DST change will not run. Tasks will run normally from the second task onwards. For example, if no task is scheduled between 2:00 AM to 3:00 AM but there is a task at 3:10 AM which is also the first task after DST change, this task will not run. This is independent of the time after the DST change in which the task is scheduled. For example, whether the first task after DST is scheduled one day or one month after the DST change, the task will not run as long as it is the first task after DST change and the database is kept active the entire time. On the other hand, when the time falls back an hour, tasks that were originally scheduled between 2:00 AM and 3:00 AM will execute twice. The user is responsible for making adjustments for daylight savings time to ensure their required behavior.
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.sql.rtn.doc/doc/r0054371.html
Environment
Db2 LUW versions 12.1, 11.5, 11.1, 10.5, 10.1, 9.8, 9.7, 9.5, and 9.1.
Diagnosing The Problem
Scheduled task was not executed after time change.
There is no entry in the db2diag.log, nor in SYSTOOLS.ADMIN_TASK_STATUS which shows that the task was not started by the ATS daemon.
You can diagnose the issue by using these commands:
1. Enabled ATS by
db2set DB2_ATS_ENABLE=yes
2. Created task by
db2 call sysproc.admin_task_add('vspr every 10 min online backup', current_timestamp, null, null, '*/10 * * * *', 'SYSPROC', 'ADMIN_CMD', 'VALUES(''BACKUP DATABASE SAMPLE ONLINE'')', NULL, NULL)
Online backup of sample db is now on c:\ProgramData\IBM\DB2\DB2COPY1\DB2\
3. After the clock is moved 5 min forward at the time of 14:41 to 14:45, the task didn't start at 14:50 as it has to.
There is no entry in the db2diag.log, nor in SYSTOOLS.ADMIN_TASK_STATUS which shows that the task was not started by the ATS daemon.
You can diagnose the issue by using these commands:
1. Enabled ATS by
db2set DB2_ATS_ENABLE=yes
2. Created task by
db2 call sysproc.admin_task_add('vspr every 10 min online backup', current_timestamp, null, null, '*/10 * * * *', 'SYSPROC', 'ADMIN_CMD', 'VALUES(''BACKUP DATABASE SAMPLE ONLINE'')', NULL, NULL)
Online backup of sample db is now on c:\ProgramData\IBM\DB2\DB2COPY1\DB2\
3. After the clock is moved 5 min forward at the time of 14:41 to 14:45, the task didn't start at 14:50 as it has to.
Resolving The Problem
To avoid this problem during the DST change in spring every year, one way is to reactivate the database after the time change, or remove the tasks and add them back again. Thus the polling thread can pick up the tasks again and the ATS daemon thread can calculate a proper sleep time to execute them.
Another work around is, to add a dummy task right after the DST change and schedule it to run 10 minutes later, e.g. 3:15am (assume DST change happened 2:00 - 3:00), thus the polling thread will detect this dummy task in 5 minutes and add it to ATS daemon thread in-memory list, then ATS daemon thread will wake up and pick up this task, then the process will be back to normal. It will get a proper sleep time for the original normal next task and this dummy task can be removed at a later time.
This should be performed for each DB2 instance rather than each database, so the effort could be small.
Another work around is, to add a dummy task right after the DST change and schedule it to run 10 minutes later, e.g. 3:15am (assume DST change happened 2:00 - 3:00), thus the polling thread will detect this dummy task in 5 minutes and add it to ATS daemon thread in-memory list, then ATS daemon thread will wake up and pick up this task, then the process will be back to normal. It will get a proper sleep time for the original normal next task and this dummy task can be removed at a later time.
This should be performed for each DB2 instance rather than each database, so the effort could be small.
[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m500000008PlmAAE","label":"Administrative Tools-\u003EAdmin Task Scheduler"}],"ARM Case Number":"","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"10.1.0;10.5.0;11.1.0;11.5.0;12.1;9.1.0;9.5.0;9.7.0;9.8.0"}]
Was this topic helpful?
Document Information
Modified date:
19 March 2024
UID
swg21595837