(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 184.108.40.206.180717, hoping this can help someone somewhere 🙂 I will update this post later if I encouter new issues.
(Picture by Tiia Monto [CC BY-SA 3.0], via Wikimedia Commons)
As explained in my previous blog post, in an attempt to develop a solid script to handle ACE (who says I am a quibbler ?), I also played with Data Pump to export and import ACE/ACL in Oracle 12cR1.
I found out that
OBJECT_PATH=NETWORK_ACL exists in
database_export_objects. I could not get many information about that, so I got confirmation from My Oracle Support that
NETWORK_ACL was the right OBJECT_PATH to use.
This blog post consists in a quick reminder on how to export and import ACE/ACL with Data Pump.
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.
I am currently in the process of migrating a 150 Gb Oracle 10g database to 12c. Due to some limitations I won’t discuss here, I have to do it with Datapump.
As I encountered different problems during the import, I had to launch it several times. It took 2 hours to import a 120 Gb table. I knew I had to rerun the import anyway to fix other issues, so I decided to get rid of the data of this big table temporarily.
I scratched my head for a few minutes, because I can be lazy and I did not want to run impdp twice just to exclude the content of the big table and include its metadata.