![]() |
![]() |
Each scheduled client operation is called an event. All scheduled events, including their status, are tracked by the server. An event record is created in the server database whenever a scheduled event is completed or missed.
You can perform the following activities to manage event records:
Task | Required Privilege Class |
---|---|
Display information about scheduled events | Any administrator |
Set the retention period for event records | System |
Delete event records | System or unrestricted policy |
To help manage schedules for client operations, you can request information about scheduled and completed events by using the QUERY EVENT command.
To minimize the processing time when querying events:
You can display information about all client events by issuing the QUERY EVENT command. The information includes events for both successful and failed schedules. If the administrator specifies a time range that includes the future, Tivoli Storage Manager displays future events with a status of future.
Figure 57 shows an example of a report for client node GOODELL that is displayed after you enter:
query event standard weekly_backup node=goodell enddate=today+7
+--------------------------------------------------------------------------------+ |Scheduled Start Actual Start Schedule Name Node Name Status | |-------------------- -------------------- ------------- ------------- --------- | |03/09/1998 06:40:00 03/09/1998 07:38:09 WEEKLY_BACKUP GOODELL Started | |03/16/1998 06:40:00 WEEKLY_BACKUP GOODELL Future | | | +--------------------------------------------------------------------------------+
You can display information about scheduled events that ended unsuccessfully by using exception reporting. For example, you can issue the following command to find out which events were missed in the previous 24 hours, for the DAILY_BACKUP schedule in the STANDARD policy domain:
query event standard daily_backup begindate=-1 begintime=now enddate=today endtime=now exceptionsonly=yes
Figure 58 shows an example of the results of this query. To find out why a schedule was missed or failed, you may need to check the schedule log on the client node itself. For example, a schedule can be missed because the scheduler was not started on the client node.
Figure 58. Exception Report of Events
+--------------------------------------------------------------------------------+ |Scheduled Start Actual Start Schedule Name Node Name Status | |-------------------- -------------------- ------------- ------------- --------- | |03/06/1998 20:30:00 DAILY_BACKUP ANDREA Missed | |03/06/1998 20:30:00 DAILY_BACKUP EMILY Missed | | | +--------------------------------------------------------------------------------+
If you query the server for events, the server may display past events even if the event records have been deleted. Such events are displayed with a status of Uncertain, indicating that complete information is not available because the event records have been deleted. To determine if event records have been deleted, check the message that is issued after the DELETE EVENT command is processed.
By default, the server retains event records for 10 days before automatically removing them from the database. The server automatically deletes event records from the database after the event retention period has passed and after the startup window for the event has elapsed.
You can specify how long event records stay in the database before the server automatically deletes them by using the SET EVENTRETENTION command. You can also manually delete event records from the database, if database space is required.
You can modify the retention period for event records in the database. To change the retention period to 15 days, enter:
set eventretention 15
You may want to manually delete event records to increase available database space. For example, to delete all event records written prior to 11:59 p.m. on June 30, 2000, enter:
delete event 06/30/2000 23:59