Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what are the problems of upgrading Oracle11.2.0.4 to Oracle 19C with DBUA". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Briefly record the holes in the upgrade process:

Requirements: migrate the ORACLE 11.2.0.4 library to a new machine and upgrade to 19C.

Preliminary work:

Install 11g on the new machine under the directory / u01/app/oracle/product/11.2.0/home_1

19C is installed at / u01/app/oracle/product/19.3.0/home_1

The full RMAN library is backed up on the old server, the backup directory NFS is shared to the new server, and the shared directory is mounted on the new server to complete the recovery. There is no problem for 11G to open the library normally.

Then there are five preparations for the library to be upgraded.

1. Clear OLAP Catalog:$ORACLE_HOME/olap/admin/catnoamd.sql

2. Clear apex:$ORACLE_HOME/apex/apxremov.sql

3. To delete 11G DB control, you need to use 19C $ORACLE_HOME/rdbms/admin/emremove.sql.

4. Empty the Recycle Bin

5. Perform utlrp.sql recompilation

Check to see if there are any failed objects. To be on the safe side, I deleted all the failed objects.

First, the first pit:

Setup / etc/oratab orcl:/u01/app/oracle/product/19.3.0/home_1:N

This is the setting that fell into the first pit.

Using the 19C DBUA upgrade, you should have started the library with 11G when you started the execution process. As a result, 19C started the 11G library, booted to upgrade mode, and then went wrong. Then switch back to 11G and report control file version 19.0.0.0.0 incompatible with ORACLE version 11.2.0.4. Can not start again, the upgrade failed, had to delete the library, a new restore operation, do it all over again.

Second, the second pit

During the DBUA process, I was asked to choose the recovery model in which the upgrade failed, and I chose to use flashback to create the recovery point.

As a result, during the DBUA upgrade process, it is found that the card is there all the time. Open the background to read the alarm alert log, and find that the db recovery directory is full. Quickly use alter system set to set the db recovery directory to a larger value. After that, the operation continues to fill the db recovery directory and constantly expand the db recovery directory. The operation, which I thought would not take long, took several hours. In the future, you can no longer choose to use flashback to create recovery points.

Third, the third pit

When you reach the post stage, if you fail, report the following error

Unable to obtain current patch information due to error: 20001, ORA-20001: Latest xml inventory is not loaded into table

ORA-06512: at "SYS.DBMS_QOPATCH", line 2327

ORA-06512: at "SYS.DBMS_QOPATCH", line 854

ORA-06512: at "SYS.DBMS_QOPATCH", line 937

ORA-06510: PL/SQL: unhandled user-defined exception

ORA-06512: at "SYS.DBMS_QOPATCH", line 932

ORA-29913: error in executing ODCIEXTTABLEFETCH callout

ORA-29400: data cartridge error

KUP-04095: preprocessor command / u01/app/oracle/product/19.3.0home_1/QOpatch/qopiprep.bat encountered error "locale: Cannot set LC_CTYPE to default locale: No such file or directory

Locale: Cannot set LC_MESSAGES to default locale: No such file or directory

Locale: Can "

ORA-06512: at "SYS.DBMS_QOPATCH", line 919

ORA-06512: at "SYS.DBMS_QOPATCH", line 2286

ORA-06512: at "SYS.DBMS_QOPATCH", line 817

ORA-06512: at "SYS.DBMS_QOPATCH", line 2309

=

Dumping current patch information

=

Unable to obtain current patch information due to error: 20001

Search patiently on MOS and find a solution:

Make this setting: export LC_ALL=en_US.UTF-8

Problem solved.

Fourth, the fourth pit

After the upgrade, the library failed to start to mount with the following error:

Control file version 19.0.0.0.0 incompatible with ORACLE version 11.2.0.4.

After careful inspection, it was found that compatible='11.2.0.4', modified the parameter file in the startup parameters.

Change compatible='11.2.0.4' to compatible='19.3.0'. Reboot, boot successfully.

Check the status of the component:

Select COMP_ID,VERSION, STATUS from dba_registry

COMP_ID VERSION STATUS

-

CATALOG 19.0.0.0.0 VALID

CATPROC 19.0.0.0.0 VALID

JAVAVM 19.0.0.0.0 VALID

XML 19.0.0.0.0 VALID

CATJAVA 19.0.0.0.0 VALID

APS 19.0.0.0.0 VALID

RAC 19.0.0.0.0 OPTION OFF

OWM 19.0.0.0.0 VALID

CONTEXT 19.0.0.0.0 VALID

XDB 19.0.0.0.0 VALID

ORDIM 19.0.0.0.0 VALID

COMP_ID VERSION STATUS

-

SDO 19.0.0.0.0 VALID

XOQ 19.0.0.0.0 VALID

13 rows selected.

RAC component is not normal, fortunately, it is stand-alone, does not apply RAC, does not do processing.

The last step is to change ORACLE_HOME from 11G directory to 19C directory.

This is the end of the content of "what are the problems of upgrading Oracle11.2.0.4 to Oracle 19C with DBUA". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.