I imagine there was a lot of spilled brandy and lost monocles upon reading that title. Now that I have your attention, what I really meant was "Don't patch your database without giving it careful thought." I bet some of you are probably thinking, "Well of course that makes sense, why wouldn't you do that?" That's a really great question. It does make sense yet many people approach their patching plans without thinking through all the possible factors.
"But wait," you say. "I worked directly with Oracle to figure this out! They strongly recommended this patch. It has fixes that can help this problem." Okay, that sounds great. Now tell me how applying this patch will affect the business?
A technically-oriented person would say that it fixes a problem that can only help the business. It's a no-brainer to apply it. What they might not consider is that there's often more than one fix in a patch. Sure you've got this one bit in there, but what about the rest of it? What other things does the patch touch? Are you sure that the improvements within are all beneficial (or at least benign) to the system?
An extension of that topic is "recommendation creep". This is when you're applying a patch with specific fixes, but there are strongly recommended security patches or other add-ons that can be applied at the same time. It might be very tempting to include these patches, but you have to ask yourself if they are truly going to add value right now. It doesn't matter how "strongly recommended" a patch is – if it's not adding value then it really is okay to leave it out.
All right, you've looked at the patches and determined that you're not going to break anything. In fact, you took out a patch that doesn't really matter right now. The next thing to look at is how the actual patch event will affect the business. When you are applying the patch, what is happening to the business?
I'll use a real-world example for this. A company with performance issues decided to apply a database combo patch at the recommendation of a consulting company and the database vendor. The only problem was that applying the patch required 6 hours of downtime for their entire business. The company had 24/7 worldwide operations and could not find more than 4 contiguous hours even after shifting around numerous critical operations.
They asked for my advice on the patch, and I found that the patch they wanted to apply was a combo patch – three separate patches bundled together. In truth, only one of those three patches were required and it could be applied in a fashion that would result in zero downtime. In fact, they could still apply the entire combo patch in a slightly different order and reduce the total downtime to only one hour.
When you make the decision to patch the database, you're not just fixing a problem. You could be introducing new problems as well, and not just with additional steps and fixes. Before you patch, ask yourself these questions:
Does this patch actually fix a problem? Don't apply patches just because you hope it'll fix something.
What else does this patch do? Don't inadvertently apply something that changes something critical.
Are there parts of this patch that aren't really needed? It might be nice to add on that security patch, but don't change too much at once.
How does the patch process affect the business? Always try to reduce downtime even if it makes the process itself a little more complex.
Remember this: In the end, you are the one applying the patch. No matter how strongly someone recommends you do something, you are the decision maker. You really don't have to apply a patch just because it's on a list somewhere. Look at the patch, study it, test it, and know exactly how it's going to affect your system and your business before you drop it in.
For assistance with JD Edward, please email us at inquiries@GetGSI.com.