RE: Upgrade from 10g1 to latest 19c

I have mostly only been involved when the move was “bigger than a bread box,” so my viewpoint is probably skewed.  

Figuring out how much down time is allowed between “I was on x” and “Now I am on y” compared to various sizes of existing databases (and whether multiple databases are being consolidated into the destination [and whether source databases will be variously adjacent PDBs in the one container or some source databases will be merged into a single PDB in the destination]) is a determination that will either allow multiple trivial competing methods in the easy extreme or require careful planning and a roadmap in the difficult extreme.  

One hint is that before any attempt at a permanent cutover is made, testing whether all feeding systems can feed the new destination with correct results.  

For disjoint pluggable databases, it *MAY* be possible to build a way station CDB at a version that can accept the old pluggable and from which the way station pluggable can be plugged into the desired destination. (As with some moves of sql*NET substrate, this *MAY* require multiple versions of way station CDB.) IF lossless plugging can get you from x to y via x’ [x’’, x’’’, …] then that *MAY* be the case that is the fastest thing to do. One of the goals of PDB was in fact to be able to seamlessly “promote” existing databases efficiently to a newer CDB.  

Of course if the source is not Oracle *lots* more comes into play, frequently including the consideration of whether an empty string is considered to be a NULL value rather than a known value of a zero length string. (C programmers may kindly shut up. I wrote a subset of a C compiler. Your knee jerk that an empty string and a NULL pointer in C are the same is quaint. That insistence is the informational equivalent of insisting that the NULL numeric value is equal to zero.) Many various database systems do accommodate the difference between a NULL valued string and a string known to be of zero length. The shortest example I know of is that some folks have a zero length middle name, which is entirely different from a NULL value and it was hilarious to see some circa 1984 forms insist on filling in the value of the middle name when the correct zero length string had been input.  

Risk analysis may require than some of the databases and data paths undergo parallel testing. That is beyond the scope of this note, but is very interesting to me. (If you want a real high wire act, consider that in some time scales of cutover, you may have to accommodate new column definitions and feeds to the source database, accommodate there being no existing values for new columns in history, and so forth.)  

Anyway, IF this is bigger than a breadbox, you probably need serious professional help.  

I suspect that the request is somewhat more mundane. I don’t particularly disagree with anything so far on the thread. The chain of plug moves may be sufficient, including the first move being changing from a non-container database to a container database with a single PDB.  

Good luck,  

mwf  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Jared Still Sent: Monday, August 12, 2024 12:05 PM
To: gogala.mladen_at_gmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: Upgrade from 10g1 to latest 19c  

Hi Mladen,  

For many small businesses, maybe medium size ones as well, I tend to shy away from GG due to the onerous license cost.  

That Shareplex info is good to know, thanks.  

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Principal Consultant at Pythian

Oracle ACE Alumni

Pythian Blog http://www.pythian.com/blog/author/still/

Github: https://www.pythian.com/blog/technical-track/author/jared-still <https://github.com/jkstill>

Personality: http://www.personalitypage.com/INTJ.html    

On Sun, Aug 11, 2024 at 12:45 PM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

On 8/11/24 3:12 PM, Jared Still wrote:

I believe the upgrade method requires upgrading to another version first, such as 11.2.0.4.  

From there, a direct upgrade to 19c is possible.  

But, there is no single-hop route to 19c bliss from 10g via database upgrade methods  

Depending on the size of the database, you may want to go the datapump route, as it results in a 'cleaner' database.  

There will be no extra baggage from whatever has been done to that database the past few years.  

That said, the datapump method requires more effort and planning, as there may be related schemas, public synonyms and other objects that are not in the schema.  

This is the route we have taken in just this same situation with a client recently.  

Only by using DP did we discover the app has created required objects in SYS (oh my!)    

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Principal Consultant at Pythian

Oracle ACE Alumni

Pythian Blog http://www.pythian.com/blog/author/still/

Github: https://www.pythian.com/blog/technical-track/author/jared-still <https://github.com/jkstill>

Personality: http://www.personalitypage.com/INTJ.html

Did Oracle 10g support SECUREFILES LOBs? I forgot. If it didn't, you may end up with BASICFILES LOB columns, which may not be what the users want. There are very significant changes from Oracle 10g --> Oracle 19c. Another method would be to use Golden Gate or Quest SharePlex and replicate the data into the pre-created 19c schema. That would also minimize the downtime, because the source database can remain active during the replication.

Speaking of the choice between GG and SharePlex, I would go with the latter because it's significantly cheaper. Also, Quest is very flexible with the licenses and can "rent" you a license for 6 months or so, until your task is done.

Regards    

--

Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com

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

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