DBA*Robot

DBA*Robot - runs Oracle sql scripts in a simple and easy way. Usually one uses Oracls's SQL*Plus to run db migration scripts. DBA*Robot is optimized for this task and therefore much more adequat. In an ideal case an installation may run completely unattended. The maintenance of databases in tight maintenance windows is stressful enough. DBA*Robot reduces the risks and relieves the database administrator. Make use of this important improvements to enhance the stability and security of your Oracle database! DBA*Robot is written in Java and mostly platform independent. Required is a Java runtime 5.0 (1.5) or later.

The interactive password entry at schema changes is one of the most error-prone and annoying tasks during the run of a script. The hardcoding of a passwords is a security risk. State of the art is the use an variable in the code:

connect myAccount/&&myAccountPassword@db

The dba sees a prompt and has to enter the password at runtime. First he has to know everey necessary password, then he is not allowed to make any mistake and last but not least he has to stay arround during the whole processing time, to be availlable for any necessary database entry.

DBA*Robot provides fully automatic logins! Demo..

SQL*Plus is not able to distinguish between non-critical and critical errros. You may catch every exception or ignore them all. We know nobody, who takes the effort to adapt the error handling for every statement. Many exceptions during the run of script are ignorable, others not, especially when you run a script several times (what is recommended during development and testing). DBA*Robot knows about the non-critical exceptions (e.g. when you try to drop an object, which does no more exist) and ignores them. Critical exception stop the processing immediatly. Demo..

When database objects are modified dependent prozedures, view or triggers may become invalid. DBA*Robot performs any necessary recompilations in the correct order. Any inconstistencies or coding errors will become obvious immediately.

If dedicated accounts should be ignored for the recompilation task, you may achieve this by the -i switch or an according entry in the property file.

DBA*Robot produces a nice and easy readable logfile. Demo..

In productional environments one should revoke the 'create session' privilege from schema accounts to protect them against any modifiactions. DBA*Robot grants/revokes this privilege automatically, whenever the according option is selected. Demo..

One often puts a database in the restricted session mode during migrations to avoid collisions with user transactions and avoid any connects during the maintenance window. DBA*Robot grants the 'create restricted session' privilege needed in this situation automatically.

In the property file one may configure relations betwween hosts and databases and restrict the connection to a database to a defined group of servers.

instance.allow.hostdeva = devdba,devdbb,devdbc
instance.allow.hostdevb = devdba,devdbb,devdbc
instance.allow.hostprod = proddb

or

instance.disallow.hostdeva = proddb
instance.disallow.hostdevb = proddb

or

instance.allow.hostprod = proddb
instance.disallow.* = proddb

Demo..

You may store an encrypted connectstring of the master account in the property file. This may be usefull to run fully automatic installations e.g. as step of a package install. In this case you have to protect the access to the program by operating system features. Demo..