Re: Sanity Check regarding database migration OJVM target server newer version 19c

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Tue, 11 Jul 2023 15:03:53 -0400
Message-ID: <CAP79kiRnzL3CEKm9iGWB1u9smyuLhgUt2sNToWb2OjmhUbD=+w_at_mail.gmail.com>



> I am replying is to ask why you don't just remove OJVM from the PDB
before you migrate it, since you wrote that you don't need it. MOS Doc id 2314363.1
<https://support.oracle.com/epmos/faces/DocContentDisplay?id=2314363.1> has the removal procedure. OJVM is a security liability in any database that doesn't actually use it

Well, that is a good question really. I'll check out that note and see if our db is a candidate for OJVM removal. The problem is, I get very wary of touch OJVM as Oracle is awful bad about creating hooks that aren't obvious until it breaks something.

Chris

On Tue, Jul 11, 2023 at 2:57 PM Andy Wattenhofer <watt0012_at_umn.edu> wrote:

> Assuming you're just migrating a PDB to the target container, the 19.17
> patch is already applied to the target CDB and you just need to run
> datapatch to bring the migrated PDB software patch level up to 19.17.
> Should work without issue. But the real reason I am replying is to ask
> why you don't just remove OJVM from the PDB before you migrate it, since
> you wrote that you don't need it. MOS Doc id 2314363.1
> <https://support.oracle.com/epmos/faces/DocContentDisplay?id=2314363.1>
> has the removal procedure. OJVM is a security liability in any database
> that doesn't actually use it.
>
> Andy
>
>
> On Tue, Jul 11, 2023 at 1:41 PM Chris Taylor <
> christopherdtaylor1994_at_gmail.com> wrote:
>
>> For some reason, our 19.17 home on SOURCE server still has the 19.14 OJVM
>> software binaries/version.
>>
>> Our TARGET server (ExaCS) has 19.17 with 19.17 OJVM.
>>
>> If I migrate a database to this new server & 19.17 OJVM libraries, will
>> it affect my database if my database doesn't use the JVM normally?
>>
>> I'm "thinking" 19.14 OJVM database internals should be ok with 19.17 OJVM
>> binaries *but* I seem to remember running into a problem with that in the
>> past if there were java classes used inside the database.
>>
>> I guess worse case scenario (which I'm going to test) is to patch the
>> OJVM on the TARGET once I migrate it (active duplicate) and open it over
>> there.
>>
>> Does anyone know off the top of their head if OJVM difference are going
>> to cause me any heartburn in this scenario?
>>
>> Thanks,
>>
>> Chris
>>
>>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 11 2023 - 21:03:53 CEST

Original text of this message