We run a production Exadata x8 and a dev Exadata x8 that sit next to each other in our datacenter and share NFS mounts. When refreshing the lower environments, i.e prod --> dev, I simply run an export and import since the refreshes only need to have one schema refreshed. I have one DB that has one simple schema on the Exadata that is around 2TB in size. This client wants to run a weekly refresh of the dev environment. My export-->import script takes around 6 hours and most of this is on the import and he is good knowing that. I would like to speed it up. I started looking into the whole PDB clone idea but size seems to be an issue for me. What would you suggest? Stick with my script or have a RO PDB in production Exadata that is refreshed more frequently and then remote clone that PDB to my DEV Exadata? Thaks in advance.
Cloning at the datafile level is always going to be more efficient but .... there's always a but :-) a lot depends on your current setup/circumstances.
A few scenarios to consider
1) PDB clone. Easiest and simplest. If the schema you want to clone is 2TB and the entire PDB is 2.5TB then its a no brainer. You take a small space hit for simplicity and just clone the whole thing. But of course, if your PDB is 50TB and you only want that 2TB schema, then thats not really feasible.
2) Partial PDB clone. Touch more complexity and assume some reasonable tablespace separation. This lets us do
CREATE PLUGGABLE DATABASE ... FROM ... USER_TABLESPACES=('TS1',TS2');
Example of that here:
https://www.ludovicocaldara.net/dba/partial-pdb-cloning/ which could be useful if your schema is nicely self-contained in tablespace(s), or at least nearly so.
3) Transportable tablespaces. Useful but requires some read-only time which might not be feasiable for you
4) RMAN TSPITR. Use RMAN to grab a backup from production and restore a subset of tablespaces (or a PDB). I often like RMAN as an option because it can (sometimes) mean that Production resources are not consumed during the process.
All of these generally are preferred over standard export/import because export/import is *changing* the data distribution, so its no longer *really* a replica of production, which can be vital for things like performance testing.,