I really appreciated Esri's response to the impact of this critical patch update at:
When arriving at a customer site recently, this was a BIG topic to discuss. Whether to apply the patch or not was non-negotiable with the system admins and database administrators. Security is security, and business is business. Unpatched databases bring vulnerabilities, potential profit loss, and liabilities. This business site has many, many Oracle databases with multiple databases sharing the same Oracle Home. It wasn't going to mean much if I went in there and told them that Esri, one of their many software vendors, needed a special exception to their policy. They would just have to carry out a tedious workaround - institute a separate, carefully scrutinized database, separate Oracle Home. Additionally, this was going to cause a ripple effect in their Esri server baseline, as in, additional Esri servers (this may not seem intuitive, but it's legit, and it's not worth the additional detail to explain why). Nobody would be impressed.
We were able to test the 2 simple actions explained these two technical articles:
and assure the customer the big, bad crash-causing CPU patch would impact ArcGIS clients.
The two simple actions were:
- Run the provided script to insert a new OPEN_CURSOR parameter record in the SDE.SERVER_CONFIG table
(I cheated and made a manual insert myself, after seeing the desired result from the longish script)
- GRANT SELECT ON v_$parameter TO < SDE and all ArcGIS users> -- don't omit the underscore in v_$parameter
The seasoned, lead DB gave his requisite look of consternation about such a grant, but really found this workaround to be entirely acceptable.
No tedious workaround, no ripple effect, Esri rolls with the punches from the patch. Looking good.
Thanks to the authors of the technical articles!