Skip to content

DBAzine.com

Sections
Personal tools
You are here: Home » Blogs » Chris Foot Blog » Chris Foot's Oracle10g Blog » DST Deadline - One Week and Counting
Seeking new owner for this high-traffic DBAzine.com site.
Tap into the potential of this DBA community to expand your business! Interested? Contact us today.
Who Are You?
I am a:
Mainframe True Believer
Distributed Fast-tracker

[ Results | Polls ]
Votes : 3620
 

DST Deadline - One Week and Counting DST Deadline - One Week and Counting

Although I didn’t want to break the flow of our series on access path scientific analysis, it is important for us to review the upcoming DST changes one last time. We’ll return to our original discussion on access paths in my next blog.
We should all know by now that the DST changes will impact many of this systems we are charged with supporting. Since we administer a LOT of different environments here, I thought it may be helpful to discuss some of our findings.

The Problem
Before we begin, we need to understand exactly what the problem is. If you haven't read my previous blogs on this topic, I highly suggest you do so before continuing.

Metalink DST Information
In my first blog on DST, I provided you with numerous links to Metalink Notes that focused on Daylight Saving Time. In my second blog, I provided a link to Oracle's new Metalink support category on DST.

Updates
We have patched dozens of databases and operating systems since I wrote that first blog on DST. I've compiled a a few notes on what we have found:

Operating System Patches

Windows
We have patched all of our customers database servers that we are responsible for providing OS support for and have experienced no issues. But some of our customers have notified us that they have experienced problems when they patched their mail and application servers.

If one implementation experiences a problem, you have a tendency to chalk that one up to that specific environment. When multiple implementations experience problems, we decided to inform our entire customer base of the potential for issues. Especially when we know that several of the customers that reported problems have top-notch Windows administrators on staff.

All of the environments had test and production operating systems that were configured to mirror each other as closely as possible. The test patches worked as advertised but a few of their production environments failed. Either the patch wasn't applied successfully or the environment refused to work after the patch was applied. In one case, Microsoft support had the administrator apply the patch again using the exact same steps and it worked the second time. Go figure. Several of the other customers were asked by Microsoft support to make various changes to their O/S configuration and attempt the patch a second time.

A few of our customers experienced mail performance problems because the DST patch caused the mail engine to generate dozens (upon dozens) of meeting time updates. The DST patch forces the mail engine to change the meeting times for all meetings that were sheduled between March 11 (new DST date) and April 1 (old DST date).

I do apologize that I don't have specifics on the the other issues. I do know that each fix was specific to that environment. I know that this may seem not very helpful at this time but I think a general warning was warranted.

Recommendations
Just because all of your test patches worked, don't assume that the production environment will also be successful. When you patch the production environment, be prepared for issues that did not occur during the test patches. You can't blame Microsoft either; test and production environments that are configured "as closely to each other as possible" aren't mirror images of each other. Close doesn't count when it comes to operating system/hardware configurations. Visit Microsoft's website regularly to ensure that there is no additional information you need to be aware of.


UNIX, LINUX

Our O/S admins experienced a few minor issues with UNIX and Linux. Please remember - if the server has its own Java engine (and you run Java programs on the O/S), your best bet is to patch both the operating system and the Java engine. We did find that several O/S vendors were updating their DST patching instructions on a regular basis.

Recommendations
Don't forget to patch that Java engine too! Visit your O/S vendor's website regularly to ensure that there is no additional information you need to be aware of.


Oracle Database Patches
The biggest issue we had was with Oracle's updates to the DST patching documentation. Since we were required to do a LOT of patching, it was important for us to get a head start. In the middle of January, we download all of the DST documentation and studied the information. We then created our plan of attack and began implementing it.

We also checked the DST area on Metalink every few days for updates. Here's where the problem arose. Some of the database patching documentation (10G specifically) can be described as "somewhat fluid" in nature. Our DST coordinator, Brian "Captain Patch" Hays found that some of the changes forced him to assemble his DST team to review their impact.

Although the updated documentation did not force us to redo any patches, we did have to revisit several of the environments that we already patched to ensure that we didn't have to reapply them. In one case, the initial documentation did not provide a complete listing of DST datatypes that could be used in table definitions. We reviewed each of the environments looking for tables containing the additional DST datatypes and were pleased to find that none were in use. I can state that when we did apply the database patches (both for the database and the Oracle Java Engine), they worked flawlessly.

Recommendations
We intend to check for updates to all Oracle DST documentation until March 11. I would highly suggest that you also do so.


Oracle Application Server
Oracle's application server was the biggest challenge. Oracle recommended numerous patches for the infrastructure database to ensure DST compliance. Many of the patches required that the infrastructure database be at a specific release. Oracle also recommended that we apply DST patches to all of the target databases that could potentially be accessed by the application server. Once again, all of the patches worked.

Recommendations
If you haven't patched your application server yet, you had better get started! Review the Metalink DST documentation for updates.


Oracle E-Business Suite Applications
All of the patches worked flawlessly.

Recommendation
Review the Metalink DST documentation for updates.


General Recommendations
Visit Oracle's and your operating system vendor's websites regularly to ensure that you have the most up-to-date information possible. Ensure that your database and application support technicians are readily available during the week of March 11th. The challenge is that some of the problems that could occur may not become readily apparent. They could very well crop up days, weeks and possibly months later. Be ready.

Thanks for reading and good luck on DST. Let me know how it works out for you!

Thanks for Reading,

Chris Foot
Oracle Ace



Monday, March 05, 2007  |  Permalink |  Comments (2)
trackback URL:   http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2007-03-04.1596857853/sbtrackback

Is the Oracle world still standing?

Posted by cmullins at 2007-03-12 03:26 PM
So, how did the daylight savings change go over in the land of Oracle? Are all your instances up and running? Any glitches of interest to report?
 

Powered by Plone