sqlplus uid/pwd@//servername.domain.com/service_nameDocumentation for the Net Services Administrator's Guide can be found here
Minimalistic Oracle contains a collection of practical examples from my encounters with Oracle technologies. When relevant, I also write about other technologies, like Linux or PostgreSQL. Many of the posts starts with "how to" since they derive directly from my own personal experience. My goal is to provide simple examples, so that they can be easily adapted to other situations.
Friday, May 17, 2024
Easy Connect syntax
Wednesday, May 8, 2024
syntax for dropping a temporary file from a temporary tablespace
For future reference, here is how to drop and recreate a temporary file in an existing temporary tablespace, but with a changed path:
If applicable, set the container:
alter session set container=pdb1;Drop the current tempfile, and recreate it in the desired location. Make it autoextensible:
alter database tempfile '/data/oradata/db01/temp1.dbf' drop including datafiles; alter tablespace TEMP1 add tempfile '/data/oradata/db02/temp1.dbf' size 1G; alter database tempfile '/data/oradata/db02/temp1.dbf' autoextend on next 1G maxsize unlimited;
Monday, May 6, 2024
How to solve errors like "Interim patch num/num (DATAPUMP BUNDLE PATCH 19.21.0.0.0): Not installed in the CDB but installed in the PDB"
After running autoupgrade, I was left with the following message in the logfile $ORACLE_BASE/cfgtoollogs/upgrade/auto/status/status.log:
datapatch when executed is trying to apply Release update in the PDB database first but is not applying in CDB$ROOT .
Solution is to execute datapatch individually in each of the containers, starting with CDB$ROOT :
[Stage Name] NONCDBTOPDB [Status] FAILURE [Start Time] 2024-05-06 14:29:45 [Duration] 0:05:33 [Log Directory] /u01/oracle/txs01/101/noncdbtopdb Cause:AutoUpgException [After running noncdb_to_pdb.sql, the pdb was closed or was opened in restricted mode] Reason:None Action:None Info:None ExecutionError:Yes Error Message:AutoUpgException [After running noncdb_to_pdb.sql, the pdb was closed or was opened in restricted mode]A query against the database shows that there are errors in the pdb_plug_in_violations view:
SELECT TIME,NAME,CAUSE,STATUS,MESSAGE FROM PDB_PLUG_IN_VIOLATIONS; TIME NAME CAUSE STATUS MESSAGE ------------------- ----- --------- -------- ------------------------------------------------------------------------------------------------------------------------------ 06.05.2024 15.23.20 TXS01 SQL Patch PENDING Interim patch 35926646/25513953 (OJVM RELEASE UPDATE: 19.22.0.0.240116 (35926646)): Installed in the CDB but not in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch PENDING Interim patch 36092868/25496280 (DATAPUMP BUNDLE PATCH 19.22.0.0.0): Installed in the CDB but not in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch PENDING Interim patch 35648110/25365038 (OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110)): Not installed in the CDB but installed in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch PENDING Interim patch 35787077/25410019 (DATAPUMP BUNDLE PATCH 19.21.0.0.0): Not installed in the CDB but installed in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch PENDING '19.22.0.0.0 Release_Update 2401040239' is installed in the CDB but '19.21.0.0.0 Release_Update 2309301519' is installed in the PDBSolution is in Doc ID 2604940.1 "Datapatch precheck failed : Release update is BEING installed to PDB but is not installed in CDB$ROOT.This will cause a patch mismatch between this PDB and CDB$ROOT":
datapatch when executed is trying to apply Release update in the PDB database first but is not applying in CDB$ROOT .
Solution is to execute datapatch individually in each of the containers, starting with CDB$ROOT :
datapatch -verbose -pdbs CDB\$ROOT datapatch -verbose -pdbs TXS01 sqlplus / as sysdba alter session set container=PDB$SEED; alter session set "_oracle_script"=TRUE; alter pluggable database pdb$seed close immediate instances=all; alter pluggable database pdb$seed OPEN READ WRITE; select open_mode from v$database; exit datapatch -verbose -pdbs PDB\$SEED sqlplus / as sysdba alter session set "_oracle_script"=FALSE;You should now see that the status has changed from PENDING to RESOLVED:
TIME NAME CAUSE STATUS MESSAGE ------------------- ----- --------- -------- ------------------------------------------------------------------------------------------------------------------------------ 06.05.2024 15.23.20 TXS01 SQL Patch RESOLVED Interim patch 35926646/25513953 (OJVM RELEASE UPDATE: 19.22.0.0.240116 (35926646)): Installed in the CDB but not in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch RESOLVED Interim patch 36092868/25496280 (DATAPUMP BUNDLE PATCH 19.22.0.0.0): Installed in the CDB but not in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch RESOLVED Interim patch 35648110/25365038 (OJVM RELEASE UPDATE: 19.21.0.0.231017 (35648110)): Not installed in the CDB but installed in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch RESOLVED Interim patch 35787077/25410019 (DATAPUMP BUNDLE PATCH 19.21.0.0.0): Not installed in the CDB but installed in the PDB 06.05.2024 15.23.20 TXS01 SQL Patch RESOLVED '19.22.0.0.0 Release_Update 2401040239' is installed in the CDB but '19.21.0.0.0 Release_Update 2309301519' is installed in the PDBYou may now clear the errors:
SYS@cdb>SQL>exec DBMS_PDB.CLEAR_PLUGIN_VIOLATIONS( pdb_name => 'TXS01'); PL/SQL procedure successfully completed. SYS@cdb>SQL>select time,name,cause,status,message from PDB_PLUG_IN_VIOLATIONS order by name; no rows selected
Subscribe to:
Posts (Atom)