In a previous life I got to spend at least one night a week deploying developer's scripts to production databases... Running scripts one by one got old and was error prone. I created DBDeployTool.pl to read a list of scripts and deploy the ones that hadn't been deployed yet. Basically it was a way to "catch up" schemas to a new version.

Since it worked incrementally it was as useful in dev/test as it was in prod. We could add scripts to be deployed, crank up the tool to get us to the new version.

Before Golden Gate had DDL support I also wrote into the script to handle coordination of scripts to a set of two databases at once, usually a "Source" DB where extract processes ran and a "Target" DB where replicat processes ran. The databases had different structures but this tool allowed me to share scripts if they happened to be receiving the same object.

  • Accept a list of scripts
  • Scripts can be run on Primary, Secondary, or Both Databases
  • DB Table is checked to find out if scripts have been run already
  • Scipt shells to SQL*PLUS to execute script
  • Script output captured to trap ORA- errors and SP2- errors

Prior/Related Art

David Wheeler's Yet Another SQL Deployment Strategy