Unintended consequences of DB conversion

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Sat, 30 Nov 2019 11:01:13 -0500
Message-ID: <5e776284-ac58-f6b3-119c-0db9c75e230f_at_gmail.com>

I've converted a 12.1.0.2 database from Windows to Linux for a client who decided that Windows Server is too expensive for them:

SQL> select * from v$version;

BANNER CON_ID

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production              0
PL/SQL Release 12.1.0.2.0 - Production 0 CORE    12.1.0.2.0 Production 0
_*TNS for Linux: Version 12.1.0.2.0 -
Production                                            0*_ NLSRTL Version 12.1.0.2.0 - Production 0

SQL> File names are definitely Linux, despite the funny uppercase letters:

SQL> select file_name from dba_data_files where file_id<4;

FILE_NAME

/data/oradata/DNADEMO/UNDOTBS01.DBF
/data/oradata/DNADEMO/SYSAUX01.DBF
/data/oradata/DNADEMO/SYSTEM01.DBF

The installed patches in the DB dictionary are what's really funny in the whole story:

SQL> select cast(action_time as date)
when_taken,bundle_series,description from dba_registry_sqlpatch order by action_time
/ 2

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

07152017
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.170418 (64bit):25590993

07152017 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.170418(64bit):25632533

11172017
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.170418 (64bit):25590993

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

11172017
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.171017 (64bit): 26792364

11172017 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.171017(64bit):26720785

02082018
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.171017 (64bit): 26792364

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

02082018
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.180116 (64bit): 27162998

02082018 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.180116(64bit):27162953

05182018
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.180116 (64bit): 27162998

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

05182018
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.180417 (64bit): 27650403

05182018 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.180417(64bit):27440294

02192019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.180417 (64bit): 27650403

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

02192019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.190115 (64bit): 28994063

02192019 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.190115(64bit):28810679

05152019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.190115 (64bit): 28994063

WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

05152019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.190416: 29447962 05152019 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.190416(64bit):29413116

08232019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.190416: 29447962 WHEN_TAK BUNDLE_SERIES

-------- ------------------------------

DESCRIPTION

08232019
WINDOWS ORACLE JAVAVM COMPONENT BUNDLE PATCH 12.1.0.2.190716: 29837393 08232019 PSU
WINDOWS DB BUNDLE PATCH 12.1.0.2.190716(64bit):29831650

20 rows selected.

SQL> Of course, Linux patches were installed too:

[oracle_at_middnademo ~]$ $ORACLE_HOME/OPatch/opatch lspatches 29774383;Database PSU 12.1.0.2.190716, Oracle JavaVM Component (JUL2019) 29494060;Database Patch Set Update : 12.1.0.2.190716 (29494060)

OPatch succeeded.

There aren't any negative consequences. July 2019 PSU was installed while the database was on Windows and, of course, July 2019 PSU was installed on Linux. October PSU is only available with an extended support contract. The next step is an upgrade to 19c which is planned for February 2020. The procedure was a bit more cumbersome because of the database size (+2TB):

Shut the database down on Winduhs.
Snap the LUN on Winduhs
Mount the snapshot in R/O mode to the newly minted Linux VM. Linux has to be equipped with NTFS fuse module and it has to be mounted as "oracle", not "root". That's achieved by uid/gid mount options. NTFS fuse module is available in the standard repository and installed by yum.
Run rman convert to Linux directory.
Re-create the control file
Open the database without resetlogs. Resetlogs is not necessary since the shutdown was normal. During the normal shutdown, there is a checkpoint and file headers are all updated with the same SCN, which means that the

Rman convert ran for around 3 hours but completed successfully and reported no errors. Frankly, I hoped to be done with RMAN convert within 1 hour but no such luck. July 2019 PSU was installed on the Oracle home before the conversion, in order to minimize downtime. I have done this before but I have never bothered to check what's in DB registry before. I had a pipe dream that RMAN convert should somehow convert the applied Windows patches to their Linux counterparts. Now, we have fully patched DB on Linux with all the patches having been applied on Winduhs. BTW, the Linux is Oracle Linux 7.7. It didn't create even the slightest problem.

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


--
http://www.freelists.org/webpage/oracle-l

Received on Sat Nov 30 2019 - 17:01:13 CET

This message: [ Message body ]
Next message: Jack Applewhite: "Re: Database Appliance"
Previous message: Noveljic Nenad: "RE: db_block_checking"

Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

Original text of this message