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
David Wheeler's Yet Another SQL Deployment Strategy