Your options for cloning are the same as any other database that resides in ASM. RMAN duplicate works as normal.

Once you have the DB running on the test env (on non-Exadata storage), you'll have to migrate the EHCC tables to uncompressed or some other compression method that works on non-Exadata storage. This can be done with "alter table <tab> move ..." on the non-Exadata environment. You'll need plenty of CPU power (decompression will be done with DB CPUs) and plenty of space. This could be done on a partition-by-partition basis if the EHCC table is partitioned (to reduce the overall space requirements).

Also see Considerations for Instantiating or Duplicating a Database on Exadata (Doc ID 1206603.1) for some other thoughts.

There is not a snapshot feature available and if you were going from one storage type to another, your current snapshot technique wouldn't apply in that case either.

If you have room in Exadata, you can maintain an image copy and apply incremental backups to that image copy to keep it current. This is the closest technique to snapshot that I know of today. However, that won't address cloning the DB to another system using different storage.

If you consider datagaurd for DR and place your standby on the XIV storage you should be able to continue cloning that database to test using XIV snapshots. Do you think that would work DAN ? Downside is you need dataguard licenses, upside is you have a DR option.

You should carefully consider using a non-Exadata standby as DR when using EHCC, as during a disaster you will need to uncompress all of your EHCC data before you can use it. With 10TB of active data that could be a looooong process.

finally works ? or not ?

U did uncompression ?

Give us some details.

Dear Yoav,

Please share the testings in detail as we have a similar requirement where we need to move 20TB of Exadata DB to non-Exadata server as DR.

Kindly let me know the points which need to be taken care for smooth operation.

Thanks,
Saurabh