Re: Oracle 12.2 is junk!

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Mon, 21 Oct 2019 21:07:19 -0400
Message-ID: <c1c4997e-1242-00b7-7497-b5f6f8617f77_at_gmail.com>



I did that. The error is what I wrote it was. Also, there is no corruption here. The "datapatch" utility is a bug ridden piece of s...oftware which is unreliable and problem ridden. It will take some time for the  utility to stabilize.  Clients that don't have problems are not much of a comfort for me who do have a problem.

On 10/21/19 11:23 AM, dimensional.dba_at_comcast.net wrote:
>
> There are many of us who patch all the time for different clients and
> have no problems at all with datapatch, quarterly or one-offs.
>
> You definitely need to look at your log files as to what the specific
> error is.
>
> *From:*oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>
> *On Behalf Of *Noveljic Nenad
> *Sent:* Monday, October 21, 2019 7:06 AM
> *To:* gogala.mladen_at_gmail.com; oracle-l <oracle-l_at_freelists.org>
> *Subject:* RE: Oracle 12.2 is junk!
>
> Hi Mladen,
>
> The patching indeed became awkward since the good old sql upgrade
> scripts were replaced by datapatch. But I’m afraid, there is no way
> back, and leaving the databases unpatched isn’t a sustainable option.
>
> datapatch invokes “opatch lsinventory” which basically generates some
> shell scripts for loading the inventory.xml into the database to check
> what needs to be done. In the past, there have been concurrency
> problems, because the generated files weren’t unique (
> https://nenadnoveljic.com/blog/simultaneous-patching-not-possible-datapatch/
> ) . The files in
> /u00/oracle/orabase/product/12.2.0.x.x/cfgtoollogs/opatch/lsinv/
> should provide you more information about the error.
>
> What worked for me is to start the datapatch with -apply and –force
> options to bypass the opatch invocations. You can specify the patch
> numbers after –apply. I tested this on many releases for non-cdb and
> 18.7.0.0.190716 multi-tenant.
>
> Alternatively, if your database is multi-tenant, you could try
> patching the containers one by one – to avoid concurrency. (I haven’t
> tried this yet.)
>
> Best regards,
>
> Nenad
>
> *From:*oracle-l-bounce_at_freelists.org
> <mailto:oracle-l-bounce_at_freelists.org> <oracle-l-bounce_at_freelists.org
> <mailto:oracle-l-bounce_at_freelists.org>> *On Behalf Of *Mladen Gogala
> *Sent:* Montag, 21. Oktober 2019 01:36
> *To:* oracle-l <oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>>
> *Subject:* Oracle 12.2 is junk!
>
> I tried patching plain vanilla Oracle 12.2 on OL 7.7 and patch
> installation went fine. However "datapatch" part did not work:
>
> [oracle_at_ora122 30133625]$ $ORACLE_HOME/OPatch/datapatch -verbose
> SQL Patching tool version 12.2.0.1.0 Production on Sun Oct 20 19:19:07
> 2019
> Copyright (c) 2012, 2019, Oracle.  All rights reserved.
>
> Log file for this invocation:
> /oracle/cfgtoollogs/sqlpatch/sqlpatch_4981_2019_10_20_19_19_07/sqlpatch_invocation.log
>
> Connecting to database...OK
> Note:  Datapatch will only apply or rollback SQL fixes for PDBs
>        that are in an open state, no patches will be applied to closed
> PDBs.
>        Please refer to Note: Datapatch: Database 12c Post Patch SQL
> Automation
>        (Doc ID 1585822.1)
> Bootstrapping registry and package to current versions...done
>
> Queryable inventory could not determine the current opatch status.
> Execute 'select dbms_sqlpatch.verify_queryable_inventory from dual'
> and/or check the invocation log
> /oracle/cfgtoollogs/sqlpatch/sqlpatch_4981_2019_10_20_19_19_07/sqlpatch_invocation.log
> for the complete error.
> Prereq check failed, exiting without installing any patches.
>
> Please refer to MOS Note 1609718.1 and/or the invocation log
> /oracle/cfgtoollogs/sqlpatch/sqlpatch_4981_2019_10_20_19_19_07/sqlpatch_invocation.log
> for information on how to resolve the above errors.
>
> SQL Patching tool complete on Sun Oct 20 19:19:20 2019
>
> So, I did what the message suggests:
>
> [oracle_at_ora122 30133625]$ sqlplus / as sysdba
>
> SQL*Plus: Release 12.2.0.1.0 Production on Sun Oct 20 19:19:40 2019
>
> Copyright (c) 1982, 2016, Oracle.  All rights reserved.
>
>
> Connected to:
> Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit
> Production
>
> SQL> select dbms_sqlpatch.verify_queryable_inventory from dual;
>
> VERIFY_QUERYABLE_INVENTORY
> --------------------------------------------------------------------------------
> ORA-20001: Latest xml inventory is not loaded into table
>
> So, I went to Oracle Support and looked for the message above. No
> problems, I am not the first one to encounter this:
>
> datapatch Fails with "ORA-20001: Latest xml inventory is not loaded
> into table" due to Block Corruption "ORA-01578" (Doc ID 2364930.1)
>
> Here is the solution:
>
> a) Fix the corrupted blocks and validate SYSAUX datafile.
> Note: You need to restore from valid rman backups or datapump exp/imp.
>
> b) Re-run datapatch
>
> cd $ORACLE_HOME/OPatch
>
> ./datapatch -verbose
>
> So, I've had a fully functional Oracle DB, I install October patches
> and now I have to do recovery? What idiot got rid of catbundle PSU
> apply? I have been patching Oracle 11g for years and now I have all
> sorts of problems with Oracle 12.2 and Oracle 18.8? Do we really need
> a patching utility that causes unnecessary problems? I rolled back the
> patches and will not apply any more patches to 12.2 until Oracle comes
> up with the sure fire way to fix the "datapatch" problems and
> repopulate the tables from "lsinventory".
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>
> ____________________________________________________
>
> Please consider the environment before printing this e-mail.
>
> Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
>
>
> Important Notice
> This message is intended only for the individual named. It may contain
> confidential or privileged information. If you are not the named
> addressee you should in particular not disseminate, distribute, modify
> or copy this e-mail. Please notify the sender immediately by e-mail,
> if you have received this message by mistake and delete it from your
> system.
> Without prejudice to any contractual agreements between you and us
> which shall prevail in any case, we take it as your authorization to
> correspond with you by e-mail if you send us messages by e-mail.
> However, we reserve the right not to execute orders and instructions
> transmitted by e-mail at any time and without further explanation.
> E-mail transmission may not be secure or error-free as information
> could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete. Also processing of incoming e-mails cannot be guaranteed.
> All liability of Vontobel Holding Ltd. and any of its affiliates
> (hereinafter collectively referred to as "Vontobel Group") for any
> damages resulting from e-mail use is excluded. You are advised that
> urgent and time sensitive messages should not be sent by e-mail and if
> verification is required please request a printed version. Please note
> that all e-mail communications to and from the Vontobel Group are
> subject to electronic storage and review by Vontobel Group. Unless
> stated to the contrary and without prejudice to any contractual
> agreements between you and Vontobel Group which shall prevail in any
> case, e-mail-communication is for informational purposes only and is
> not intended as an offer or solicitation for the purchase or sale of
> any financial instrument or as an official confirmation of any
> transaction.
> The legal basis for the processing of your personal data is the
> legitimate interest to develop a commercial relationship with you, as
> well as your consent to forward you commercial communications. You can
> exercise, at any time and under the terms established under current
> regulation, your rights. If you prefer not to receive any further
> communications, please contact your client relationship manager if you
> are a client of Vontobel Group or notify the sender. Please note for
> an exact reference to the affected group entity the corporate e-mail
> signature. For further information about data privacy at Vontobel
> Group please consult www.vontobel.com <https://www.vontobel.com>.
>

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217


--
http://www.freelists.org/webpage/oracle-l
Received on Tue Oct 22 2019 - 03:07:19 CEST

Original text of this message