I ran across an article from 2013 from Straight Talk on Agile Development by Alex Kuznetsov and it reminded me how long we’ve been battling for easier ways of doing agile in a RDBMS environments.
Getting comfortable with a virtualized environment can be an odd experience for most DBAs, but as soon as you recognize how similar it is to a standard environment, we stop over-thinking it and it makes it quite simple to then implement agile with even petabytes of data in an relational environment without using slow and archaic processes.
The second effect of this is to realize that we may start to acquire secondary responsibilities and take on ensuring that all tiers of the existing environment are consistently developed and tested, not just the database.
A Virtual Can Be Virtualized
Don’t worry- I’m going to show you that its not that difficult and virtualization makes it really easy to do all of this, especially when you have products like Delphix to support your IT environment. For our example, we’re going to use our trusty AWS Trial environment and we have already provisioned a virtual QA database. We want to create a copy of our development virtualized web application to test some changes we’ve made and connect it to this new QA VDB.
From the Delphix Admin Console, go to Dev Copies and expand to view those available. Click on Employee Web Application, Dev VFiles Running. Under TimeFlow, you will see a number of snapshots that have been taken on a regular interval. Click on one and click on Provision.
Now this is where you need the information about your virtual database that you wish to connect to:
- You will want to switch from provisioning to the source to the Linux Target.
Currently the default is to connect to the existing development database, but we want to connect to the new QA we wish to test on. You can ssh as delphix@<ipaddress for linuxtarget> to connect to and gather this information.
2. Gathering Information When You Didn’t Beforehand
I’ve created a new VDB to test against, with the idea, that I wouldn’t want to confiscate an existing VDB from any of my developers or testers. The new VDB is called EmpQAV1. Now, if you’re like me, you’re not going to have remembered to grab the info about this new database before you went into the wizard to begin the provisioning. No big deal, we’ll just log into the target and get it:
[delphix@linuxtarget ~]$ . 11g.env [delphix@linuxtarget ~]$ echo $ORACLE_HOME /u01/app/oracle/product/22.214.171.124/db_1 [delphix@linuxtarget ~]$ ps -ef | grep pmon delphix 14816 1 0 17:23 ? 00:00:00 ora_pmon_devdb delphix 14817 1 0 17:23 ? 00:00:00 ora_pmon_qadb delphix 17832 1 0 17:32 ? 00:00:00 ora_pmon_EmpQAV1 delphix 19935 19888 0 18:02 pts/0 00:00:00 grep pmon
I can now set my ORACLE_SID:
[delphix@linuxtarget ~]$ export ORACLE_SID=EmpQAV1
Now, let’s gather the rest of the information we’ll need to connect to the new database by connecting to the database and gathering what we need.
[delphix@linuxtarget ~]$ lsnrctl services LSNRCTL for Linux: Version 126.96.36.199.0 - Production on 10-FEB-2017 18:13:06 Copyright (c) 1991, 2013, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) Services Summary... Service "EmpQAV1" has 1 instance(s). Instance "EmpQAV1", status READY, has 1 handler(s) for this service...
Provision Your VFile
Fill in all the values required in the next section of the provisioning setup:
Click Next and add any requirements to match your vfile configuration that you had for the existing environment. For this one, there aren’t any, (additional NFS Mount points, etc.) Then click Next and Finish.
The VFile creation should take a couple minutes max and you should now see an environment that looks similar to the following:
This is a fully functional copy of your web application, created from another virtual copy that can test against a virtual database, ensuring that all aspects of a development project are tested thoroughly before releasing to production!
Why would you choose to do anything less?