Training & Conditioning
Training:
No person is born already knowing how to perform ORACLE database administration. Likewise, system or network administrators typically do not already have the necessary skills to professionally manage an ORACLE database, nor do application developers. ORACLE database administration is not the same work as network or operating system administration, nor is it the same work as application development: it is a completely different set of tasks and required skills. Mentoring persons to an effective level of practical ORACLE database administration expertise typically requires a combination of formal training, experience, experimentation with unfamiliar concepts, independent study using various ORACLE documentation and third-party guides, attendence to educational conferences, and participation in local user groups.
Cross-training between DBA's, system or network administrator's, and lead application developers is very beneficial. A database administrator cannot perform in an exceptional manner without a working knowledge of the operating system and application development models and architectures in use in that organization. Likewise, system administrator's and application developers benefit from at least a working knowledge of the overlapping sections of the database technology that is applicable to their areas of responsibility. For instance, a network administrator should clearly understand why an open database cannot be backed-up in the same manner as a file system. An application developer should understand how constraints, triggers, and stored procedures can improve the quality of an application. Budget spent on developing the necessary skills to professionally manage this complicated technology is money well-spent. Technology changes over time, improving in it's robustness, but becoming ever more complicated. Training is, like performance tuning, an iterative process. The availability (and other measureable characteristics) of the ORACLE instances will generally improve as the expertise of these personnel (especially the DBA's) increase.
For a listing of knowledge development resources available on the Internet, please see the Resources section of this site.
Conditioning:Desktop PC's and Intel-based server equipment running Microsoft Windows-based operating systems share many similarities. Rebooting a desktop workstation typically impacts only one person: the user working on the desktop workstation. Rebooting a server running ORACLE on NT, however, may impact 100 or more users. Essentially, an Intel/NT-based database server is a "souped-up PC", but it must be acknowledged that it is "not JUST a souped-up PC anymore"; it provides business data to a potentially large number of end-users. Unlike more typical activities such as file services obtained from an NT server, user applications are not automatically reconnected to the ORACLE instance after the machine has completed rebooting (unless a fail-safe or clustered solution is in use or the application has been explicitly programmed to retry reconnection after being unexpectedly disconnected). Depending upon the configuration of the ORACLE instance, the database instance may need to be restarted manually after the reboot as well. Regardless, any uncommitted work in progress by users when the interruption occurred is lost (unless the application explicitly performs it's own buffering and tracking of logical units of work). It is important for administrative and operational personnel to understand these types of issues characteristic of a database server's specialized purpose. A dedicated database server cannot be rebooted on a whim; in fact, it's reboot procedure can require specialized steps that are not necessary with a simple file-server. An understanding that non-ORACLE software must be tested for conflicts before installation on a production database server is essential. A sense of understanding and cooperation between the DBA's, system administrators, and application developers should be established by clearly defining where responsibilities begin and end. The perspective must be established that ORACLE/NT database servers are to be managed in the same manner as an IBM mainframe or midrange, UNIX database server, or any other mission-critical database machine would be managed, and not in the same manner that a simple NT or Novell file-server would be managed.
1) Establish accountability. For instance, an operator may be responsible for physically loading tapes and executing a backup, but a DBA should be held accountable for insuring that this task is done in a manner that insures recoverability.
2) Establish perspective. A database server (regardless of the operating system and database technology) should be viewed as a mission-critical component of the infrastructure containing business data the loss of which would have a measurable negative effect on the organization's bottom line, and managed the way that any other mission-critical component of the infrastructure would be managed.
3) Establish testing procedures. For instance, before starting an upgrade and migration from ORACLE7 to ORACLE8 of a production instance, perform that upgrade on a test box. Document the steps required, any errors encountered, and the solutions to the errors. Perfect the upgrade procedure on the test box before performing the upgrade to the production server. Since a copy of the database to be upgraded is needed on the test box, take advantage of this opportunity by performing a recovery test of the production database to setup the copy on a different machine. Any upgrades, installation or modification of software, administration tasks with unknown risk factors, etc., should be tested on a copy of the target database first.
4) Establish formal change control. Information obtained by testing technical changes should be reviewed by and agreed upon by a committee of experienced administrative personnel before enactment on production, and confined to a regular change window that minimizes impact to business functions. The same change control committee should review and approve any technical changes needing to be performed outside of the regular change window prior to implementation, after having been briefed on test results and impact analysis. Finally, records of changes implemented should be kept. The records can be reviewed when necessary to identify possible cause and effect relationships regarding any new difficulties that are encountered after any particular technical change.