Ansible for Oracle Database Clones

Ansible LogoA frequent job requirement of all Oracle DBA’s is cloning a database or entire application for development or testing purposes. In previous years, many DBA’s performed manual clones by cutting and pasting commands they stored in text documents. Craftier DBA’s learned that their time was better spent automating the task with shell scripts. While better than manual cloning, shell scripts were usually not consistent or did not handle errors very well. These days, there are several configuration and orchestration tools that can be leveraged to perform environment clones or refreshes. One such tool is Ansible®, and using Ansible for Oracle Database clones is very intuitive for the typical DBA or sysadmin mindset.

Shadandy has been using Ansible to clone databases for years. It can be used to clone standalone on-premises databases as well as Amazon RDS for Oracle instances. It can also clone entire Oracle E-Business Suite environments spanning multiple nodes.

In one instance, Shadandy was able to help a customer who was having problems with the DBA resources provided by one of the huge offshore/outsourcing companies. We will not say which one, but our experience with dealing with any of the offshore companies has been similar. The offshore DBA’s were manually executing clone steps that had been spoon fed to them, but the environment refreshes were never performed consistently. Why automate when you can bill more hours to sit there and cut-n-paste? Then get paid to do it again when things were not done correctly the first time.

Our solution was to remove the offshore DBA’s from the equation by automating all the steps they were cutting and pasting into a single, cohesive Ansible playbook. Do the playbooks require upkeep and maintenance? Yes. Does maintaining the Ansible playbooks require as much time as watching a database clone for hours on end? No. Are environment refreshes performed in a more timely and consistent manner? Yes. Can they be scheduled to execute automatically? Yes. What’s not to like, unless you are an offshore company getting paid for time a butt is in a seat?

Our typical Ansible automation framework starts with a host inventory file for each environment. A separate inventory file for each environment avoids mistakenly running a command against all the environments at the same time. An example inventory file for an OADEV1 EBS environment is something like this:








The inventory allows the Ansible playbook to perform different operations for internal web nodes, external web nodes, concurrent manager nodes, and the database server. If your environment contains other 3rd party applications such as Kofax MarkView, the inventory can be crafted to handle them.

Additional group configuration files drive what Ansible does as it connects to each node. For an OADEV1 environment, the Ansible playbook reads variables from the following files:


Every environment will be a little different, but you can see the flexibility of storing configurations for each environment. An added perk is that Ansible provides the ansible-vault utility to encrypt sensitive files.

While we are not going to provide the exact playbook code, an EBS environment refresh can be broken down into individual playbooks and/or tasks. Here is an example ebs_autoconfig_all.yml playbook that calls a task to run Autoconfig on all application nodes:

- include: ebs_autoconfig_ext.yml
- include: ebs_autoconfig_web.yml
- include: ebs_autoconfig_ccm.yml

Breaking down the playbook above, the ebs_autoconfig_web.yml playbook runs Autoconfig on all internal web nodes:

- name: Playbook used to run Autoconfig on the internal web nodes of an environment.
hosts: "oa_all_web"
any_errors_fatal: true
user: "{{ appl_os_user }}"
apps_pass: "{{vault_ebs_environment[env_name|lower]['database']['credentials']['apps']}}"
- include: tasks/ebs_app_run_autoconfig.yml

The actual tasks/ebs_app_run_autoconfig.yml Autoconfig task is:

- name: Run Autoconfig.
shell: '. ~/.profile; . {{ appl_shared}}/apps/apps_st/appl/APPS{{ env_name }}_{{ ansible_hostname }}.env;perl ${AD_TOP}/bin/ contextfile=${CONTEXT_FILE} appspass={{ apps_pass }} -parallel'
no_log: True

To execute the Autoconfig playbook, a DBA can simply execute a single command:

ansible-playbook -i hosts.oadev1 ebs_autoconfig_all.yml

Similar tasks and playbooks can be executed for SQL scripts, RMAN duplicates, SAN snapshots, and all other operations required to perform a database or application clone in your environment. Leveraging Ansible for automation, Shadandy was able to reduce a 10-node EBS environment refresh from one or more days (if done correclty the first time) to 3-4 hours. We even used Ansible to fully automate their database and EBS code deployments.

If your company requires database or EBS environment configuration or clone automation, please contact Shadandy to see how we can be of assistance.

Using Proxmox and Spice with a Windows 8.1 VM





If you are a small remote support provider, you know how difficult it can be to connect to multiple different customers using different VPN technologies. Not many companies will setup a dedicated VPN tunnel for you, so you are often at the mercy of the customer’s IT policies and staff.

To work around some of the issues around connecting to multiple customer VPNs at the same time, we have been creating separate Proxmox virtual machines for each customer. Most VPN software will not work through Remote Desktop, so we have been using the Spice protocol for virtual desktops.

Up until this time, Spice only supported Windows XP through Windows 7. Every few months I do a little research to see if Windows 8 support has been baked into SPICE, and today I came across a way to get it up and running. It’s a little clunky, and automatic desktop resolution does not work, but it is a start. We can only hope it will improve over time.

1. Create a Windows 8.1 VM for Proxmox. I will not go into the details of creating a Proxmox VM, but here’s a link to the best practices.

2. Using the VNC display, log into the Windows 8 VM and download the following files:

3. Extract the file, and open a command prompt as Administrator.

cd qxlwddm-0.11\Win8\x64

pnputil -i -a qxldod.inf

4. Extract the spice-guest-tools-0.100.exe file. Do not execute it, just right-click and extract it with 7-Zip. Once extracted, open a command prompt as Administrator.

cd spice-guest-tools-0.100\64

vdservice install

5. Double-click the virtio-win-0.1-100.iso file, and open a command prompt as Administrator.

D: (or whatever your mounted ISO drive letter is)

cd WIN8\AMD64

pnputil -i -a VIOSTORE.INF

6. Once the drivers have been installed, stop the Windows 8 VM.

7. In Proxmox, set the VM’s Display to SPICE.

Proxmox Spice Display

8. Start the VM, and launch SPICE from the Proxmox console.

Proxmox Launch Spice

You should now be able to use SPICE to access the Windows 8 VM and work away…