I’ve mentioned this before in posts such as Automation Patterns for Typical DBA Tasks, but I think it’s worth mentioning again.
A software repository, or library, is really important.
Why?
We should always keep hold of multiple versions of the software we are using. At the very least this should contain all current versions (and patches) of the software being used in our organisation. In addition to actively used software, we need versions/patches to rebuild environments to support data recovered from an old offsite backups.
There is little point having a long term offsite backup, if we have no way to recover it.
In some cases we may be able to retrieve old versions of our software from a vendor, but in some cases that may not be possible, especially if we have some legacy apps that are out of support.
It’s also really important for automation. All our automations pipelines download the software from our repository as part of the deployment or patching processes.
How?
The method you use it not really important. Some obvious possibilities are:
- A central file store.
- A central HTTP server.
- An artifact repository solution, such as Artifactory.
As I said, how is not really as important as what you keep.
What?
I’ll use a couple of examples.
The database patches are straight forward. The following example shows a simplified version of how our 19c software is stored in Artifactory. We have the base release, which includes the main software distribution, then quarterly subdirectories, each with the appropriate OPatch and RU Combo Patch for that quarter. It’s a good idea to pull down the latest autoupgrade.jar each quarter, but I’m a bit lazy and I only tend to do that for quarters where there is some upgrade activity.
+--- 19c
| +--- 2023-04
| | +--- p35370174_190000_Linux-x86-64.zip
| | +--- p6880880_190000_Linux-x86-64.zip
| +--- 2023-10
| | +--- p35742413_190000_Linux-x86-64.zip
| | +--- p6880880_190000_Linux-x86-64.zip
| +--- 2024-01
| | +--- p36031426_190000_Linux-x86-64.zip
| | +--- p6880880_190000_Linux-x86-64.zip
| +--- 2024-04
| | +--- p36209492_190000_Linux-x86-64.zip
| | +--- p6880880_190000_Linux-x86-64.zip
| +--- 2024-07
| | +--- p36522340_190000_Linux-x86-64.zip
| | +--- p6880880_190000_Linux-x86-64.zip
| +--- LINUX.X64_193000_db_home.zip
Not all updates are released on a quarterly cycle, which may alter how we choose to store them. For example, APEX patches come out at various times through the year, but we only patch APEX on a quarterly cycle along with our databases, so we follow the same approach. We take the latest patch set available at that patching quarter. We’ve only just moved to APEX 24.1, so this is what we would see.
+--- apex
| +--- 24.1
| | +--- 2024-07
| | | +--- p36695709_2410_Generic.zip
| | +--- apex_24.1_en.zip
An alternative would be to capture every patch set and have a subdirectory for every patch set.
+--- apex
| +--- 24.1
| | +--- 24.1.2
| | | +--- p36695709_2410_Generic.zip
| | +--- 24.1.3
| | | +--- p36695709_2410_Generic.zip
| | +--- apex_24.1_en.zip
Pick which approach works for you and your patching cycles.
When do you clean up?
It really depends on how much storage you have available. One option is to keep everything. For my home software repository I have stuff dating back to Oracle 8i. I doubt I could even install that anymore. 🙂
The main thing to remember is you need all active software, and anything that may be necessary to recover from backups. Beyond that it is a judgement call.
Conclusion
I suspect many of you have some method of storing your software and patches already, but if you don’t, it’s worth taking a little time and putting something together. At some point you will need it, and you will thank yourself for being organised.
Cheers
Tim…
