"The North American Daylight Saving Time (DST) switch happened on the 14th of March. Since then our Enterprise Manager scheduled RMAN backups are running 1 hour later than ususal - essentially they haven't taken notice of the DST switch. We have Oracle 10.2.0.4 on Solaris 10. We use individual Enterprise Manager dbconsoles for each database. My timezone version is 4. Newfoundland Canada, standard GMT offset of -03:30, DST offset of -02:30. Dbtimezone from dual is -02:30 (this is correct). The agentTZRegion from the emd.properties file (for the specific instance of dbconsole, not the global emd.properties file) is Canada/Newfoundland which is correct. But the RMAN jobs in OEM are still showing a GMT offset of -03:30 hours (explaining the 1 hour offset when they run). These are my two questions/issues:
1. Shouldn't that offset have auto-corrected to -02:30 when DST occurred?
2. I can't change the jobs to have an -02:30 GMT offset because that option doesn't exist in my Time Zone drop down list when trying to schedule an RMAN backup via OEM. Is there an additional patch I need to apply?"
My answer:
Mate, did you search in Metalink for this issue? I found a note that explains your particular case perfectly:
Jobs In Dbconsole Shows One Hour Difference After Dst Patch Is Applied [ID 749147.1]
The reason is simple - your JDK and JRE was not made DST compliant. Simply follow the
instructions in Note:553534.1
The issue has nothing to do with Enterprise Manager 10g or its jobs system which is quite good, and better in Enterprise Manager 11g. Certainly better than crontab jobs that we DBAs have been doing for years. And who wants to use a crontab when we have a central Grid Control job system controlling multiple unix servers?
No comments:
Post a Comment