Tag Archives: migration

My favorite column ever: ORACLE_MAINTAINED #JoelKallmanDay

1 Reply
Photo by Eugeniya Belova on Unsplash

Even with all my good intentions, work and life challenges got in the way, and I have not been able to blog this year yet.
I still wanted to take part in the #JoelKallmanDay to honor Joel’s memory and to show my gratitude to the Oracle community.
In my (not so) new job at Oracle, I specialize in database migrations in the Cloud, with all sorts of databases and various migration strategies.
A quite common strategy is to use the powerful Oracle Data Pump utility. This blog post will not be about Data Pump, but rather about a very specific column in the dictionary views that I love very much, and that I use every minute of each of my work days (ok, I may be exaggerating a little): ORACLE_MAINTAINED

Continue reading →

Issues encountered after applying Database Proactive Bundle Patch + OJVM PSU 12.1.0.2.180717

2 Replies

(Picture by Jannes Glas, via Unsplash)

I have to admit that I always volunteer at work when a patching has to be done. I like patching. Not the patching process itself, but the learning process. Sometimes it even helps me get better at troubleshooting.
Today I just want to gather in one post a few things that came up after applying Database Proactive Bundle Patch + OJVM PSU 12.1.0.2.180717, hoping this can help someone somewhere 🙂 I will update this post later if I encouter new issues.

Continue reading →

Checklist to determine if an Oracle schema is self-contained

2 Replies

For a few months, I have been working on massive migrations of Oracle 10g/11g databases on Solaris to 12c on Linux. Most of these databases are highly consolidated with several schemas (no PDBs of course), and these schemas are used by different applications. These applications have supposedly nothing do to with each other. Of course, those applications being different, they follow different roadmaps. Knowing this, it was quite impossible to migrate the whole database at once, and schema-by-schema migration was relevant and comfortable for everybody.

I realized that the main challenge to address was not technical complexity, it was more about understanding the muddle between schemas that should be distinct.
Everytime I had to migrate another schema, I wondered : Is this particular schema “self-contained” ? Can I move it with Datapump from one database to another “as is”, with minimum work and error handling ?
I knew DBMS_TTS.TRANSPORT_SET_CHECK procedure could be helpful at tablespace level, but I needed information at schema level.

I still have no magic wand to separate dependant schemas, but at least I have a checklist to identify wether a schema is self-contained or not.

Continue reading →