Problem :
There was request from Application team to do some log extract with specific time range. The extract returned zero matching rows for the keys given. On Application team’s confirmation that the changed records should be there, we did found change records 1 hrs. Prior to the range initially requested for.
REASON:
In most cases Log Master for DB2* correctly processes data and time values, regardless of time changes.The product has special features to accommodate daylight savings time changes.In a few uncommon situations, an unusual change in the operating system's clock can cause Log Master for DB2* to select log records from a time period different than the period you request. It is bit tricky behavior, when we the run the log extract for data changes between 15:17 to 15:40, We did not get matching record. So we did run without any filtration, found even though the scan time was between 15:17 to 15:40 , it fetched the change records during time 14:17 to 14:40.
Fix :
If you encounter this problem, you can select the correct log records by - defining your scan range with either log marks or RBA/LRSN values - adjusting the date and time values that you enter to compensate for the time changes in your environment.
Lesson Learnt:
BMC Log Extract timing should be adjusted when you run the product after a time change, But specify date and time values for your log scans that are before the time change. This situation is called scanning across a time change boundary. This problem happens only when you define your scan range with date and time values. It does not occur if you define your range with RBA/LRSN values, or log mark names The problem occurs because the operating system's functions that convert date and time values to store clock format always use the current time zone offset, even if the date and time value reflects a point in time when a different time zone offset was in effect.
There was request from Application team to do some log extract with specific time range. The extract returned zero matching rows for the keys given. On Application team’s confirmation that the changed records should be there, we did found change records 1 hrs. Prior to the range initially requested for.
REASON:
In most cases Log Master for DB2* correctly processes data and time values, regardless of time changes.The product has special features to accommodate daylight savings time changes.In a few uncommon situations, an unusual change in the operating system's clock can cause Log Master for DB2* to select log records from a time period different than the period you request. It is bit tricky behavior, when we the run the log extract for data changes between 15:17 to 15:40, We did not get matching record. So we did run without any filtration, found even though the scan time was between 15:17 to 15:40 , it fetched the change records during time 14:17 to 14:40.
Fix :
If you encounter this problem, you can select the correct log records by - defining your scan range with either log marks or RBA/LRSN values - adjusting the date and time values that you enter to compensate for the time changes in your environment.
Lesson Learnt:
BMC Log Extract timing should be adjusted when you run the product after a time change, But specify date and time values for your log scans that are before the time change. This situation is called scanning across a time change boundary. This problem happens only when you define your scan range with date and time values. It does not occur if you define your range with RBA/LRSN values, or log mark names The problem occurs because the operating system's functions that convert date and time values to store clock format always use the current time zone offset, even if the date and time value reflects a point in time when a different time zone offset was in effect.
No comments:
Post a Comment