Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Peter.

Asked: May 31, 2024 - 6:07 pm UTC

Last updated: February 17, 2025 - 7:53 am UTC

Version: 19.19.0.0

Viewed 1000+ times

You Asked

Hi TOM,

Sorry for asking this basic question (After two hours of searching, I am unable to find the answer)

Let's say I have run opatch in an ora19 home to patch the binaries.
But then I "forgot" to run datapatch.

Is there any dictionary view to tell me that I "forgot"?

BR
Peter

and Connor said...

Check out DBA_REGISTRY_SQLPATCH

SQL> select patch_id, status
  2  from DBA_REGISTRY_SQLPATCH;

  PATCH_ID STATUS
---------- -----------------------
  34110698 SUCCESS
  34468137 SUCCESS
  35681617 SUCCESS
  35962857 SUCCESS

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

datapatch

Mikhail Velikikh, June 06, 2024 - 10:16 am UTC

> But then I "forgot" to run datapatch.
> ...
> Check out DBA_REGISTRY_SQLPATCH

datapatch populates DBA_REGISTRY_SQLPATCH. If it was not run, you will have nothing there.
SQL> !$ORACLE_HOME/OPatch/opatch lspatches
36233263;Database Release Update : 19.23.0.0.240416 (36233263)
35926646;OJVM RELEASE UPDATE: 19.22.0.0.240116 (35926646)
35967489;OCW RELEASE UPDATE 19.22.0.0.0 (35967489)

OPatch succeeded.

SQL>
SQL> select patch_id, status from dba_registry_sqlpatch;

  PATCH_ID STATUS
---------- -------------------------
  35926646 SUCCESS
  35943157 SUCCESS

SQL>
SQL> select patch_id, description, sql_patch
  2    from xmltable('InventoryInstance/patches/*'
  3                   passing dbms_qopatch.get_opatch_lsinventory
  4           columns
  5             patch_id int path 'patchID',
  6             description varchar2(255) path 'patchDescription',
  7             sql_patch varchar2(10) path 'sqlPatch')
  8  /

  PATCH_ID DESCRIPTION                                                            SQL_PATCH
---------- ---------------------------------------------------------------------- ----------
  36233263 Database Release Update : 19.23.0.0.240416 (36233263)                  true
  35926646 OJVM RELEASE UPDATE: 19.22.0.0.240116 (35926646)                       true
  35967489 OCW RELEASE UPDATE 19.22.0.0.0 (35967489)                              true


To determine whether you need to run datapatch, pass the prereq argument to it (datapatch -prereq), or compare DBA_REGISTRY_SQLPATCH against your binary registry as it is demonstrated above. For example, patch 36233263 is an SQL patch which is not in DBA_REGISTRY_SQLPATCH. Hence, it needs to be applied by datapatch.
Connor McDonald
June 10, 2024 - 6:51 am UTC

Nice input

Datapatch - When you are not DBA, but something else

A reader, June 07, 2024 - 6:57 pm UTC

Thanks Mikhail,

You have given valuable input - And sort of confirmed that this is not straight forward

I've been asked to "confirm" that all databases are at a certain patch level, and that all data patches have been applied, also. Let's just say I am auditor without much knowledge on the subject (I am actually Developer crossing certain lines)

I will work from your valued input, thanks!

//Peter

Privileges for using DBMS_QOPATCH

Narendra, January 30, 2025 - 4:11 pm UTC

Hello Chris/Connor,

Hope you are doing well.
Would you know whether DBMS_QOPATCH is NOT intended to be used by normal users? The documentation for 19c https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_QOPATCH.html#GUID-10BC18AA-EC71-44B7-A3E7-2E4D06FA2DC4 appears to suggest that only SYS can use this.
If I am honest, just like those V4 views for accessing trace file contents, this package looks like harmless but very useful.
Would you know
a) whether EXECUTE privilege on DBMS_QOPATCH is enough to use its subprograms to get patching details &
b) whether there is any Risk/vulnerability in giving access to DBMS_QOPATCH to normal (non-admin) users?

Thanks in advance
Connor McDonald
February 14, 2025 - 5:30 am UTC

The SYS security reasons behind DBMS_QOPATCH are simple.

Let's say a critical security bug arises and is patched by patch 12345.

Anyone with DBMS_QOPATCH access can now probe your database to see if that patch has been applied to decided quickly/efficiently if that database can be exploited.

If you really need things from it, I would create a wrapper around it which allows only those things you absolutely need exposed, and then grant access on the wrapper.

But I repeat - never give hackers a helping hand

Re: DBMS_QOPATCH

Narendra, February 17, 2025 - 12:18 am UTC

Hello Connor,

Appreciate your input on the impact on security.
My question was mainly focussed on how the privilege model works in the database. The documentation appears to suggest that user needs to have SYS level privileges in order to be able to use DBMS_QOPATCH APIs. However, I am able to grant only EXECUTE privilege on DBMS_QOPATCH to a local user and that user is able to access patch details.

First, without EXECUTE privilege on DBMS_QOPATCH, I get error as expected:

SQL> show user
USER is "NP"
SQL> select * from session_privs ;

PRIVILEGE
----------------------------------------
CREATE SESSION
ALTER SESSION
CREATE TABLE
SELECT ANY TABLE
CREATE SEQUENCE
CREATE PROCEDURE
MANAGE ANY QUEUE
ADMINISTER RESOURCE MANAGER
SELECT ANY DICTIONARY
GRANT ANY OBJECT PRIVILEGE
ANALYZE ANY DICTIONARY
ADVISOR
CREATE JOB
ADMINISTER SQL MANAGEMENT OBJECT

14 rows selected.

Elapsed: 00:00:00.16
SQL> select * from session_roles ;

ROLE
--------------------------------------------------------------------------------------------------------------------------------
SELECT_CATALOG_ROLE
HS_ADMIN_SELECT_ROLE
AQ_USER_ROLE
OEM_MONITOR

Elapsed: 00:00:00.08
SQL> set pagesize 0
SQL> set long 1000000 
SQL> select xmltransform(dbms_qopatch.get_opatch_install_info, dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual;
select xmltransform(dbms_qopatch.get_opatch_install_info, dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual
                                                          *
ERROR at line 1:
ORA-00904: "DBMS_QOPATCH"."GET_OPATCH_XSLT": invalid identifier


Elapsed: 00:00:00.02
SQL> select xmltransform(sys.dbms_qopatch.get_opatch_install_info, sys.dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual;
select xmltransform(sys.dbms_qopatch.get_opatch_install_info, sys.dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual
                                                              *
ERROR at line 1:
ORA-00904: "SYS"."DBMS_QOPATCH"."GET_OPATCH_XSLT": invalid identifier


Elapsed: 00:00:00.01


After granting EXECUTE on DBMS_QOPATCH, it works

SQL> select * from user_tab_privs where table_name = 'DBMS_QOPATCH' ;
NP                 SYS
DBMS_QOPATCH                SYS       EXECUTE
NO  NO NO  PACKAGE       NO


Elapsed: 00:00:01.71
SQL> select xmltransform(sys.dbms_qopatch.get_opatch_install_info, sys.dbms_qopatch.get_opatch_xslt) "Home and Inventory" from dual;

Oracle Home   : /opt/oracle/product/19c/dbhome_1
Inventory   : /opt/oracle/oraInventory


Elapsed: 00:00:27.86


I still believe that the above is correct behaviour and the responsibility should be with administrators to decide which users, if any, should be able to query patch inventory.
However, the documentation appears to be misleading and not in sync with the actual implementation.
What am I missing?

Thanks in advance
Connor McDonald
February 17, 2025 - 7:53 am UTC

We're probably quibbling semantics here. From the docs

"The DBMS_QOPATCH package is created as part of SYS schema and SYS is the only user who can execute these subprograms."

This is indeed true (out of the box).

However, once you grant EXECUTE you have indeed given the grantee SYS-level access to that package, ie, it runs with the same rights as SYS.


Re: DBMS_QOPATCH

Narendra, February 17, 2025 - 11:27 am UTC

Hello Connor,

Thank you for your time and response.
In addition to the potential risks that you have already mentioned, do you see any other potential risks in granting EXECUTE on DBMS_QOPATCH? I am hoping none as query able patch inventory has been promoted as a new feature but happy to listen to any concerns/issues.