I'm sure that most of us who work with Metalink/MyOracleSupport have similar experiences. For instance, recently I have been with Oracle Database Appliances--sort of a one-stop for clustered servers/hardware, firmware, storage, OS and database software. We don't patch components individually on ODAs. Instead, Oracle releases interoperable bundle patches (firmware to database software), which have ranged in my experience 2 to 5 months between releases. This is unlike the usual quarterly critical patch updates with prescheduled releases.And of course CPU's for ODA's have to be integrated into interoperability testing, so there's usually a modest implementation delay. Unlike for CPU's, I don't get email notifications for new ODA patches, basically Doc Id 888888.1 tells us to check release notes via an ODA release page for new versions. On a recent release, I couldn't find the patch through the general patch portal and later found the patch hyperlinked in a subsequent section of the release notes. So I was literally having to check the release notes daily for months between patches. Contacting Support wasn't much better. When I tried to open up a Service Request on the latest patch, the analysts were in a state of denial that the software had been released; one guy accused me of filing a ticket on a beta release.
Command line interface documentation is sadly lacking in a number of respects; for example in dealing with ODA patches, you have to use oakcli; on the other hand, if you run into a hardware issue (say, a defective redundant power supply), you have to use a different CLI in logging into ILOM, e.g., in getting diagnostic logs for filing a hardware SR with Oracle. The CLI command syntax is not as fleshed out as you might expect, e.g., in Oracle database command documentation. For example, I once had to shut down a service on ILOM. I only found one passing example of syntax to start up the service in question.
I once ran into an issue on a Windows backserver for Oracle. (Luckily, this was not a production server but a testbed). I had upgraded the server (and my 3 databases) from 12.1 to 12.2. The bottom line is our vulnerability scanner showed the old Oracle home was not running the April 18 CPU, and I had to uninstall the old home. So of course I started up OUI, and it told me I had to run a certain utility at the command line. In the command sequence, it asks for a list of databases. Why? None of my databases were running on that home. There wasn't any warning, say, that it would not only go out and drop the database but also any related backups in FRA. This totally ignores Usability 101: design for human error, i.e., you make users jump through hoops in order to do something catastrophic like drop a database. (And that's what the prompt option did.) I don't mind if Oracle provides a separate data utility, but I didn't expect it in a deinstall utility. I lost a database before I realized what was happening.
On the same Windows server. I ran into some issues running datapatch -verbose (the utility you run during the second phase of opatch, applying the new patch against the database in startup upgrade mode), Long story short, the problem had to do with an xml_file.xml file, which needs to be deleted but was being held by certain Windows processes (in my case, a set of cmd processes). So my solution was to delete those cmd processes in Windows task manager (and then said xml file). At that point, expected functionality returned to datapatch.
