One thing you stated you can not do a consistent export but seems like you are passing the SCN parameter for your export that would be considered a consistent export.
To clarify I use parameter consistent=Y in export and it gives ORA-1555 error unless no application users are on the system. When application users are using the system export does not work with CONSISTENT=Y or without it.
Could never figure out how to get rid of this error duing export other than doing export during monthly maintenance when users are off the system. My database size is only 200GB.
I will be eaglery looking for your blog on this topic. What is URL for your blogs.
I put the url in the last reply why can you don an inconsistent export?
I do not see any URL regarding consistent/inconsistent export in your reply, please provide again?
I did more checking into the UNDO in multitenant environment and the UNDO can only be create in CDB$ROOT and I do not see that there is anyway to control the amount of undo segments that each PDB can use. I can see that the TEMP can be created for each PDB or can share from the CDB$ROOT.
I feeling is as we would do the same in a non-CDB we will need to test and adjust the UNDO as needed to handle the required UNDO segments.
I will try to do some testing with the UNDO in a multitenant 12C database.
My blog is below where I have several post on Multitenant Configuration.
As most of the views in 12c, v$undostat contains a con_id column showing the ID of the container to which the data pertains.
This can be a resource to check the undo space required for the current workload. The view contains data for 4 day cycle.
Also, for temporary tables, in 12c we can set TEMP_UNDO_ENABLED to TRUE which will separate undo for temporary tables from undo for persistent ones.
The benefits are immediate:
- reducing the size of redo log;
- less undo in the UNDO tbs;