unzipPatch? OMSPatcher failed with error code = 238 EM12c
Hi,
while applying the patch 28491093 i got error code = 238 with “OMSPatcher finds that no sub-patch(es) can be applied to the OMS system.”
I assumed that i took the wrong one but emcli returns plug-in-Versions which match the patch.
I searched logs for a couple of days, but had to create a SR at Oracle.
During Webex-session the Support (Thank you!) found a log which Shows that a file is missing……..
I downloaded the patch again and used 7-zip…….and it works.
Command cp with asmcmd cannot use Wildcards.
Since Oracle 12.2 the backup of the ocr must be stored in ASM.
But i prefer having this on the local file system. This should be done with a scheduled task.
My batch:
set oracle_home=C:\gridhome
set oracle_sid=+asm1
cmd /c asmcmd ls +DATA/Oravirt12c/OCRBACKUP/ >> C:\ocrbkup\files_ocrbkup.txt
cmd /c for /f %%f in (C:\ocrbkup\files_ocrbkup.txt) do asmcmd cp +DATA/Oravirt12c/OCRBACKUP/%%f c:\ocrbkup\
del C:\ocrbkup\files_ocrbkup.txt
Installing EM13.2 agent from OMS-host which is running on Windows
Having a Windows-environment for our Oracle-RAC’s we decided to install OL 7.8 as OS for 19c.
So after i’ve finished installation i tried to push EM13.2CC-agent from the WIN-OMS to the new target-maschine.
Since only the agent for the platform the OMS was installed on is included by default i first added agent to the software-library by Self-Update.
It shows AVAILABLE so start deploying it via the GUI >> error
Seems to be an issue while trying to Unzip.
Ok, let’s try the command-line according to MOS-DOC 1360083.1.
emcli get_agentimage -destination= -platform=”
ends with
ERROR: Command C:\’PATH’\unzip.exe c:\’PATH’\13.2.0.0.0_Plugins_226.zip -d c:\’PATH’\13.2.0.0.0_Plugins_226.zip -d ‘PATH’ execution failed.
emcli get_supported_platforms returns
Version = 13.2.0.0.0
Platform = Linux x86-64
Platform = Microsoft Windows x64 (64-bit)
Platforms list displayed successfully.
emcli list_plugins_on_server
OMS name is OMS:Port_Management_Service
Plug-in Name Plugin-id Version [revision]
Oracle Cloud Framework oracle.sysman.cfw 13.2.2.0.0
Oracle Database oracle.sysman.db 13.2.2.0.0
Oracle Fusion Middleware oracle.sysman.emas 13.2.2.0.0
Systems Infrastructure oracle.sysman.si 13.2.2.0.0
Oracle Exadata oracle.sysman.xa 13.2.2.0.0
But when downloading the agent_image i notice that the plugin-zip has size of just 1k.
Found no solution, so i created a SR.
As per advice from MOS I did AgentPull.sh from target-side but still
…..
zip warning: missing end signature–probably not a zip file (did you
zip warning: remember to use binary mode when you transferred it?)
zip warning: (if you are trying to read a damaged archive try -F)
zip error: Zip file structure invalid (/u01/app/oracle/product/agent13c//plugin.zip)
ERROR: curl command:/usr/bin/curl https://OMS:Port/em/install/getAgentImage?user=sysman&platform=Linux x86-64&version=13.2.0.0.0&ignoreDiscoveryPlu gin=&script=download&host=Machine-name&type=pluginimage –insecure -o /u01/app/oracle/product/agent13c//plugin.zip -S –stderr /u01/app/oracle/product/agent13c//er ror.txt failed.
So, it seeems still an issue with the zip-file.
OK, so let’s take another machine outside the network and work with VM.
I tried to install EM 13.2 on a LINUX machine in order to get an agent from that machine, but Installation failed.
Seems to be described in DOC ID 2270676.1.
But file which is mentioned could not be found in MW-Home.
So still working on this.
Then tried to get a pre-built VM from Oracle, found
https://www.oracle.com/technetwork/server-storage/vm/documentation/readme-em-13200-20190114-5278095.txt
But it seems to me that only 13.4 is available now.
Ah, Doc ID 2315652.1 made it.
Installation OMS on Linux-VM was successful.
Then proceeded acc to 1360083.1. (with transferring agentCore.zip from VM to Target-Machine)
Oracle autoupgrade with Windows-Services and DataGuard 12.2 > 19c
As described in Oracle documentation the Windows-Service
has been deleted while upgrade and must be re-created with oradim afterwards.
It worked for the Primary DB but dgmgrl showed some errors regarding the connectivity
to the Standby-DB.
My colleagues and me found following solution:
Create the service without password-clause
then create pwd-file with compatibility-level
12.2
!! > This password-file had been copied to the Standby-Site and renamed (unique-DB-Name) !!
DataGuard works!
Autoupgrade to 19c ended with UPG-1401
Autoupgrade-log showed:
Fehler: UPG-1401
Datenbank XXXXXXX konnte nicht im Upgrademodus geöffnet werden
Ursache: Opening database for upgrade in the target home failed
Autoupgrade ended with ERROR
DATABASE NAME: XXXXXXX
CAUSE: ERROR at Line 1 in [Buffer]
REASON: SP2-0640: Nicht angemeldet
Alert-Log led us to the underlying issue:
ORA-00494: Enqueue [CF] zu lange (mehr als 900 Sekunden) von ”inst 1, osid 77576” gehalten
during “ALTER DATABASE OPEN MIGRATE”
Found
OK, we added
“_controlfile_enqueue_timeout”=1800
to the “init.ora-file” located in the DEFAULT location within the ORACLE_HOME-directory.
And once more……same error.
The section
“System parameters with non-default values:”
in the alert-log shows that the added line was not taken into account.
But then my colleague noticed the line above:
Using parameter settings in client-side pfile X:\APP\AUTOUPGRADE_20220822\XXXXXXXXXXX\XXXXXXXXXX\XXXXXXXX\104\DBUPGRADE\CATUPGRDXXXXXXXXXXXXXXXXXXX.ORA on machine XXXXXXXX
Adding the value to THIS file did it.
SQL Server c: runs out of space
I noticed that the c:\-partition of our SQL-Server ran out of space.
Found directory ‘Users\SSISScaleOutMaster150\AppData\Local\SSIS\ScaleOut\15\Master’ which contains the logs from SSISScaleOutMaster. The logs are written every minute, so we had ~30 GB of logs for ~ 3 years. The logs can be deleted 😉