If you’re migrating ADW (Autonomous Data Warehouse) environments across tenancies, then there are a few things you want to consider to make it quicker and more secure. You may in your head be conceptualising the migration of moving your data out to Cloud storage in one tenancy; then moving it the other tenancy to then import into the second ADW instance. This is quite a logical way of thinking; almost like you were doing a classic data centre migration, object storage maybe like an SFTP location. In both instances you would be using DBMS_CLOUD and expdp/impdp to shift the data around with the latter requiring credentials to be setup in OCI with appropriate IAM policies to allow moving of the data in and out of object storage. You’re probably thinking this…
While there is nothing wrong with this approach, there is a quicker way of migrating the data; and a more secure way. Firstly once the data is exported out of the database there is nothing stopping you transferring it to any bucket within any Cloud; and if you can export data to any bucket you can also import data from any bucket; the key is not to think of Cloud storage and access to that tied to any particular tenancy. Now the simplest way to do that is using:
DBMS_CLOUD.PUT_OBJECT (
credential_name IN VARCHAR2,
object_uri IN VARCHAR2,
directory_name IN VARCHAR2,
file_name IN VARCHAR2);
For this you need a credential setup using DBMS_CLOUD but actually what you can also do is use a pre-authenticated bucket. This is a dedicated URL for object storage which enables the read and writing of files without setting up an IAM user. The command for DBMS_CLOUD.PUT_OBJECT doesn’t change; you just have a NULL for the credential name. Creating the pre-authenticated request is easy and can be done from the OCI cli or console. Similarly, when you are running the import request that can target any Cloud storage and also use pre-authenticated buckets.
The reason this is more secure (and quicker) is by using a pre-authenticated bucket request can avoid using your own credentials (which may be part of the admin group); setting up a new bucket specific policy (takes time and could be error prone) and quickly create and remove the pre-authenticated request. Furthermore, if you forget to remove it this will automatically expire; thus making it more fool proof rather than having to remember to remove the credentials once you’re done.
Conceptually it could look like this; or of course the bucket could remain in the source tenancy; it doesn’t matter. The other thing to note is that database size may influence if you use source or target and if you’re going across regions. Anyhow, the key thing to take away is don’t think migrations are like other you may have done on-premises; there are some very simple ways to make things more secure and quicker; which should be good news to everyone.
If you'd like to discuss Oracle Cloud Migration further, please contact us. We can organise a technical call with Phil, or a commercial call with one of our Oracle Cloud Migration experts.