Company Vision
Databases have always been an essential part of any sufficiently large organization. With the continuing surge in data retention and increased inter-systems connectivity a non-working database is in most cases for business purposes a single point of failure. Such an important system should be closely monitored and protected against changes that may impact functionality or performance. Good database administration in itself is not difficult, it just requires an strict attitude to want to do things right combined with a matching level of technical competence.
In my experience every customer I have work with needed to regain control over it’s systems after a period of hectic changes. Due to understandable pressures of delivery deadlines, management overrides, system failures and lack of documentation loss of control sneaks in. The end result is in almost all cases an systems architecture that is undocumented, not performing and highly unstable when changes are applied.
The database administration department is often the first department that is contacted when a problem arises or someone does not know an application. Because the databases interfaces with most business critical applications the DBA in general has a very good idea of the systems landscape and problem area’s. It is highly surprising that the DBA department is many times the last department to be contacted on new projects or systems. First involvement of the DBA during a pre-production test is not uncommon in my experience.
It is essential for the DBA department to be involved from the very start of a project. Depending on project methodologies used it is advised to contact the DBA even in the project definition part. The problem the project will be attempting to find a solution for may already be fully or partially available in another system or interface. Also in many cases non Oracle insiders like architects or technical designers lack essential information on what is possible within the database. In 99.95% of the cases use of internal Oracle Stored Procedures will outperform ANY other programming language or solution. Still many devolpment teams will start to code immensely complicated pieces of code in Java because they lack knowledge of PL/SQL or (more sadly) do not know of it's existence. Additionally issues like prevention of redundancy of information or security issues may impact the project in it’s definition phase which can be identified as early as possible by involving a DBA.
Concerning technical setup of database systems there are a set of simple rules that need to be followed:
Any DBA department that adheres strictly to these rules will be able to perform pro-active preventive database maintenance which will lower the maintenance cost considerably. My experience is that a correctly setup of the database and it’s monitoring will result in a DBA just spending 20% of his time on maintenance and 80% on analyses of changes or projects.
A major part in becoming a successfull DBA is really understanding that this is a Profession, not just something you can learn in a couple of weeks. Really understanding Oracle's inner workings requires continuous effort by reading and testing things out. A big part of it is also experience that you can only attain in the field. A real DBA should be able to rescue a system using only telnet, because you will see that when the is trouble all the nice "click" tools will be unoperative and the generation of click and drag DBA's are completely useless. As you can imagine I am firmly in the command line DBA camp.