One of the key advantages of Autonomous Database on Shared Exadata Infrastructure (ADB-S) is to be able to provision or clone a database with the click of a button. This is especially important in the context of agile development and testing (DevTest) in which the teams often need a fresh copy of the production environment in order to make sure the new projects, enhancements, or bug fixes solve the existing problems and don’t cause new issues in the production environment. Many ADB-S customers do this by frequently cloning their production databases for their DevTest teams because cloning an ADB-S instance requires very little effort and fits perfectly in the agile development lifecycle. In this blog post, we are going to explore how to further accelerate this cycle with the help of a new ADB-S capability that enables you to rename your existing ADB-S instance.

Let’s put aside this new feature for a moment and see how several ADB-S customers used to take advantage of the cloning capability to keep their DevTest environments up-to-date until today. For the following example, let’s assume I have a production database called adwsales and a test database called adwsalestest. In order to create a new clone of adwsales that shares the same name as adwsalestest, I will need to first terminate adwsalestest. Here’s why… My new clone has to share the same name as the old one because I don’t want to change the connection string in my application code, and I have to terminate the old clone first because I cannot have two databases with the same name in the same region and tenancy. This has been a valid use case for many of our customers. However, creating a new clone and having access to your DevTest environment are serialized operations with no overlap in this approach.

This is where the new rename capability comes into play. You probably can already tell how it can help improve this use case but to further explain, we can now start the new clone preparation with an intermediate name (e.g. adwsalesstage) in parallel while the old clone is still being used. Once the new clone is ready, we can rename it after terminating the old one. Again, the main motivation behind using the same name for every new clone is to avoid any application changes. The key difference between the two scenarios is that the rename capability allows replacing your existing DevTest database with a fresh copy of your production database thanks to a quick and simple metadata operation.If we go with the example above, when our new clone adwsalesstage is ready, we can terminate adwsalestest and use its name to rename adwsalesstage. Now it’s time to demonstrate it in a few simple steps:

  • Download the regional wallet and have the production and test instances ready (adwsales and adwsalestest)
  • Insert some data in the production (Now we need a new copy for DevTest!)
  • Create a new clone of the production instance (adwsalesstage)
  • Terminate the old test instance (adwsalestest)
  • Rename adwsalesstage to adwsalestest
  • Connect to adwsalestest

Download the regional wallet and have the production and test instances ready (adwsales and adwsalestest)

In this demonstration, I have two ADB-S instances: adwsales is my production database and adwsalestest is my test database that I cloned from adwsales. We are going to first download our regional wallet. The reason for using the regional wallet instead of the instance wallet is to avoid downloading a new wallet every time we create a new clone of the production since regional wallet serves all the instances that belong to the same tenancy in a given region.

Let’s connect and run a simple query in our production and test instances:

 
ctuzla-mac:instantclient_19_3 ctuzla$ ./sqlplus ADMIN/************@adwsales_low

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 13 15:40:50 2020
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Thu Aug 13 2020 15:32:06 -07:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.5.0.0.0

SQL> select count(*) from sales;

  COUNT(*)
----------
	19


 
ctuzla-mac:instantclient_19_3 ctuzla$ ./sqlplus ADMIN/************@adwsalestest_low

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 13 16:29:57 2020
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Thu Aug 13 2020 15:32:06 -07:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.5.0.0.0

SQL> select count(*) from sales;

  COUNT(*)
----------
	19

Insert some data in the production (Now we need a new copy for DevTest!)

As we covered earlier, production databases may evolve rapidly and it’s important to have an up-to-date development and test environment. In order to simulate this scenario, let’s insert some data into our production database:

 
SQL> insert into sales select * from sh.sales where rownum<60 order by time_id desc;

59 rows created.

SQL> commit;                   

Commit complete.

SQL> select count(*) from sales;

  COUNT(*)
----------
	78

Create a new clone of the production instance (adwsalesstage)

Since we want to maintain a fresh copy of our production database, let’s create a new clone called adwsalesstage, soon to be our new test database:

Terminate the old test instance (adwsalestest)

After verifying our new clone has been successfully created, we can terminate adwsalestest:

Rename adwsalesstage to adwsalestest

Now that the old clone is successfully terminated, we can go ahead and rename adwsalesstage to adwsalestest. We are doing this to avoid any connect string changes in the application code:

Connect to adwsalestest

Let’s connect to our new test database and run the same query. Please note that the connect string hasn’t changed and the query result reflects the insert operation we performed couple steps above:

 
ctuzla-mac:instantclient_19_3 ctuzla$ ./sqlplus ADMIN/************@adwsalestest_low

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 13 17:48:53 2020
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Last Successful login time: Thu Aug 13 2020 16:31:04 -07:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.5.0.0.0

SQL> select count(*) from sales;

  COUNT(*)
----------
	78

It’s important to note that in this demonstration I didn’t even have to download a new wallet after creating my second clone since I’m using a regional wallet and the service names for the test database stay the same after the rename operation.

To summarize, ADB-S offers quick and easy provisioning which is an integral part of agile development and testing. In this blog post, we have seen how the rapid provisioning combined with the new database rename capability can further improve the DevTest lifecycle. If you would like learn more about the rename feature, you can check out the documentation here.