Why you should implement GUIs/ drop the history

I was chatting today with a colleague today about my frustration at the Oracle dbas not implementing (or having a standard) on GUI deployment on server builds. Some use the Java based Enterprise Manager, some use the command line and some (occasionally) use Grid Control. My point here is that from server to server the environment determines what you can use rather than you as the dba determining to use the appropriate tool for the task in hand. In my opinion for each server setup (10g or 11g) the database should be setup to be administered by either Grid Control or Database Control (since the Java gui is now in 11g phased out and also runs into various DMZ accessibility issues) but in my environment that is unfortunately not the case.

One of the reasons I offered as to why we as the dba should be determining to use the best tool for the job in hand whether it be GUI or command line is the scenario of dropping a database. What is the difference between dropping a database via the GUI or via the command line? Well when the GUI is used, an attempted drop of the database will first perform the drop and then attempt to clear down backup job history. Image if the history has not been maintained and needs to be done so at a later date due to the size. In this scenario the GUI will just hang for an excessive amount of time until it either completes OR the spid of the drop operation is killed. If it is killed the the database will still have been dropped. Therefore the best tool in this situation would have been the DROP database statement in the command line since this does not attempt clean-up and simply and quickly drops this database. However should you require clean-up the conversely the gui would be far more desirable for you to achieve your goal.

This entry was posted in Oracle, SQL, SQLServerPedia Syndication and tagged , , . Bookmark the permalink.