Job description and Role of Oracle DBA

 Job description and Role of Oracle DBA

I found this Article long back hope sharing with you this is amazing work for the people who wants to know the job description and role of Oracle DBA

How many of you began your IT career with a job where you (or you were a pmi of as mall team that) "designed" tables to hold data and wrote SQL statements to manipulate (Insert, Update or Delete) or query the data? Without reference to potential future needs for "enhancements"? Without considering how data integrity would be enforced? Without a strategy to backup and recover the data? Did you say "The DBA will handle schema changes? The DBA will enforce integrity. The DBA will guarantee that all the data can be restored (from backups he creates) at any time."?

Introduction

This paper is an attempt to define what the DBA does. And what he does not do. It will make for much better clarity when his Manager reviews the DBAs actions and value to the organisation. Development teams and Users (I hope!) will better appreciate and understand his position.

Responsibilities

You would have read the many listings of "Responsibilities" (particularly in job ads?) which include

1. Install    Oracle RDBMS Software   (and, sometimes,   any other     "packaged" software)

2. Create the Database, Maintain Database Accounts, Maintain Table spaces and Free Space

3. Implement Auditing, Generate Audit Reports, possibly even Review Audit Reports and Monitor the Database Instance for “Performance" and "Availability"

4. "Tune" the Database (and this phrase has so many different connotations!)

5. Create Backups and Maintain Backup Catalogs (how many definitions include "Test Restoration and Recoverability Scenarios?")

6. Work with Developers, Work with Analysts, Work with Managers --- to define and configure database objects, extract information, implement changes

7. Install Patches, Upgrade Databases, Migrate Databases, Clone Databases

                                                                                                .... And the list goes on....

Similarly,  the  ''Tasks  of  a  Database  Administrator " in  the  Oracle  documentation

( http://download.oracle.com /docs/cd/E1188201/server.112/e17120/dba002.htm#i10062.Qi ) is old-school.  That list is far from complete.

The DBA's role in an organisation may evolve, grow and mature over time. The DBA's role may vary with the type of application and project he supports - particularly when working with packaged applications or with Consultant/Vendor implementations. If the DBA is in an outsource team he may be providing only Operational support and no Design and/or Performance Tuning support.

How else can we define the DBA's role?

DB "A" for AVAILABILITY.   If there are flaws in the Infrastructure which impinge on database availability, it is his job to highlight them (and we expect him to be skilled enough to identify them first!). However, it is incumbent on him to first implement or recommend implementation of infrastructure, protocols  and  SLAs  that  define Availability. Availability is about Data Accessibility, System  (database/application) Uptime and System (database/application) Performance, in that order.

DB "A" for ADMINISTRATION. 

Administration is not about using the Oracle Enterprise Manager GUI. It is about knowing how Oracle works and how the database facilitates meeting user requirements via the application. Just as your Office Administrator knows which forms are to be used for Sick Leave applications and how to file and follow up on Taxi Claims, should the Database Administrator know the elements that make up the Database Infrastructure and how to make use of them or query them? If there is a need to determine why reports run slow, he must be familiar with the sequence of operations that cause report requests to be submitted, extracts from the database to be executed and reports to be generated in the required layout. He must be able to use his knowledge of the data flows and logic to identify and resolve issues and/or recommend and implement improvements.

Skills

How does the DBA get skilled? The "OCP" 'degree' seems to be very popular - and employers are looking for Certified DBAs. I would advocate that *formal training* be complemented by apprenticeship. (And, yes, very unfortunately, many OCPs aren't even formally trained?) Just as a Chartered Accountant or a Doctor, has to gain "hands-on" experience as a junior to a mentor/senior/trainer before he receives his qualification should an OCP be required to have "on-the-job learning" before he receives his Certificate. Why?

Because

OC "P" for PROFESSIONAL.     The word  "Professional"  is badly  abused  in the context of the "OCP" "Certificate". A  Professional is a member of a vocation which mandates specialized education and training and requires him/her to follow strict  ethical  and moral codes. Ethics are very important.  More so when you  are managing and/or have access to data that you do not personally  own.  DBA  Managers  *must* review  DBA  backgrounds and  behaviors.

Honesty and Ethics go with Professionalism. When I read of the opinion many employers and consultants have about "Certified DBAs" I cringe. Many of us are not Professionals. Database Professionals owe a higher duty to protect the employers I clients’ interests (the "D" in Data!) then, say, PreSales Consultants and, even, Project Managers. If a project is using or implementing methods (such as discarding controls over data access OR eliminating backups), the DBA must step up and not stand down. The Clients/Users Data is paramount and cannot be compromised.

Another aspect of Professionalism is (to pick an element from other fields): Continuous [Self] Improvement. Lawyers must ensure that they know  current  Case  Law. Professional DBAs must ensure that they know available options, best I good practices. A DBA cannot force an upgrade to I l g but he would be lacking in his responsibilities if he is not prepared for 11g and does not help his organization prepare for 1 1g. There are numerous ways to "keep in touch" with current technology --- the standard documentation, available online, User Groups (such as AIOUG), SIGs (Special Interest Groups), Technology Days and Seminars, forums  Email  Discussion  lists Newsgroups and Oracle Technology Network and Oracle Magazine. There are numerous blog and feed aggregators as well that collect information. And there are numerous "free" sites where you can learn (Oracle Learning Library is a very  good  collection  of tutorials). And, most important of all: MyOracleSupport. If your organization doesn't give you access to Oracle Support, complain and complain and complain again. Once you do get access, make sure that you "surf ' the Knowledge Base frequently.

Oracle University and other institutes do provide standard training. However, the best learning is experience. If you don't have the experience, you can learn from the experiences of others. See the Resources list in the  Appendix  for  sites I discussion groups I online learning options -most of which are free.

A Professional  doesn't just  "take" but  also "shares".  Share your knowledge  with  others at any of these forums/sites/lists and you will see that you learn more yourself as you interact with others.

And, finally, Attitude is part of Professionalism. Attitude does not merely mean Confidence.     Attitude *also* means being Careful and Complete when reviewing, modifying or fixing an issue.

Work

With Developers/Consultants/Implementers: You, as the DBA must make  yourself familiar with the schema and how data is inputted/loaded and retrieved/extracted from the database he administers. This requires InterPersonal Skills besides  Technical Knowledge. A "Superior than Thou" ("I am right, you are wrong") attitude is very harmful and limits the DBA's ability to perform later when he needs co-operation from the same people that he has irritated.

With your Manager: You must keep your manager aware of what you are working on. A DBA's actions may not be visible, particularly in the context of operations of a production database. Yet, you must identify at least one notable action I change I discussion I recommendation that you have initiated or participated in and document it each day. Your Manager is not interested in a daily list but may need to ask for a "DBA Actions" list on occasion --- particularly as each employee's position in the organization has to be justified.  Your documentation would be invaluable in proving his worth.

With the Database: Each database configuration, control and process must be documented. Whether there is a centralized Change Management System or not, you must be able to identify and retrieve details of each change that has been implemented. This requires documentation. Email trails are haphazard documentation.  Copy the contextual information (and names of stakeholders) from emails into a document if you do not have a Change Management System that captures all the details.

In fact, Change Management is underutilized.  Not adequate detail is captured   in   the system as  DBAs  and  Managers  are  in  a  hurry  to  get  a  Change  Sign-Off  Yet,  this  very hurry  can  bite  them  later.  I  have  seen  a  number  of  occasions  when   the   DBA   and Developer  could  not  identify  all  the  changes  that   had   been   implemented   or,   worse, pointed to the wrong set of changes when a  Review  - particularly  in  the  context  of  an Incident  - is  required.  Do NOT include your own biases   when   documenting   and presenting   Changes for a Review.    State the facts in the documentation

Database Reviews and Tuning

A DBA must grasp the importance of the different datatypes, DDL definitions, SQL syntax options, database binaries and configuration files and control processes.  Needless to say, different Backup and Recovery must be practiced frequently.

You must develop the skills to understand Execution Plans, know how Bind Variables are to be handled when  attempting Explain Plan, know many of the key database instance parameters that relate to performance and backu p and recovery, know how to identify important messages in alert.log and trace files. As I've pointed out earlier, the DBA can learn from the experiences of others.

Alerts for thresholds (for space and performance) are a valid expectation of the DBA. A DBA who does not look out for warnings and alerts and/or ignores them is failing in his responsibilities.

Over time, the DBA is expected to understand the "behaviour" of each database  he manages (which database generates higher redo, how do redo rates, user session counts, IIO rates fluctuate during the day/night/weekends/monthends, which reports are critical to business, which are the most important business hours etc). The ability to identify trends from statistics and from charts (where charts are possible!) is an important advantage a DBA can possess...

Backup and Recovery

Although I have touched on "Availability'', Backup and Recovery deserves special mention again. A DBA that cannot restore and recover the database is failing in his

Most basic duties. If your organization doesn't help you setup adequate resources to provide for protection for the data, make it an issue and raise it with senior management. At the end of the day, if the database needs restoration and recovery, it is the DBA who as to execute the task. Practice Backup and Recovery scenarios. Oracle documentation provides a list of scenarios. The Resources listed in the Appendix have many other write-ups and exercises and experiences on Backup and Recovery.

If you are managing a RAC database, a Standby database configuration, a database

with Streams I Golden Gate for data replication or a database using Storage based replication, make sure that you understand how these work. Ask for training and documentation if implementation has been done by Consultants or Vendors.

Communication

The DBA has to, over time, communicate with Developers, Infrastructure, Managers, Users, Consultants and Vendors. The DBA needs to express himself (or his viewpoint) frequently: in writing when defining issues/requirements/resolutions and orally when negotiating with Managers, Users and Vendors.

Manager' s Expectations

 What should the DBA's manager expect of him?

1.     The 3 basic rules are: Attitude, Attitude and Attitude. A *positive* attitude towards his responsibilities. Does the DBA want to learn? Does he learn? Is he interested in his role, expanding his role?  Will he share his knowledge with other  junior DBAs? (this is important!)

 2.      What contributions has the DBA made to the project? In areas of sizing, logical and/or physical design, infrastructure specifications, scripting for administration, proactive monitoring, scripting alerts, automated and manual fixes, performance tuning, problem diagnosis and communicating issues/designs/diagnosis.

3.      How frequently or infrequently are calls referred to the DBA? Calls by users and developers. Is the DBA able to identify the cause of the issue? Far too often, a call is sent to the DBA when it should be owned by someone else. Is the DBA able to define ownership of a call by isolating the cause?

4.     Is he cautious? An adventurous DBA might not be good for the organization.  A DBA who attempts multiple changes just because he "saw a recommendation on the Internet" and who relies more on Google than on the official documentation may be less than safe.

5. Does he spend time ("invest") in "getting a feel" of the databases that he manages? Can he tell you when the database is ''busiest" (high transaction rates, high 1/0 rates, high CPU usage), when peaks and troughs occur in database activity, how long do the daily I weekly backups take to run, how large the database is and how much it has grown in the last month,  3 months,6 months, year ? 

What does a DBA *not* do?

What are the actions that a DBA should not do?

1. Blame without Factual Evidence. A DBA may speculate that the hardware is underperforming but he needs to gather factual evidence (IO rates, wait times, CPU usage statistics) before actually putting the blame on hardware.

2.      [Blindly] Use advice from Google. A DBA does not use a web document that he found doing a Google search until and unless he has either a) tested and validated it b) discussed it  with senior  DBAs I colleagues c) checked with well-known authorities d) checked with official Oracle Support.

3.      Implement a change without Testing I Validation. A DBA does not implement a change (whether from a vendor, a developer or as an "instruction" from a Manager) without reviewing the change, validating it and knowing the potential impact.

4.      Not reviewing alert.log or OEM alerts and trace files for messages.   These files I

      Messages should be checked periodically.

Common mistakes of DBAs and their Managers

Some common mistakes or shortcomings are:

1. Not capturing the correct Metrics. Metrics about execution  times  for  key jobs, database size, transaction volumes,  user  counts,  backup  durations,  restore  + recovery durations. You need such metrics to be able to report on the "health" of the database I server and for capacity planning.

2. Not planning for training and test environments. Formal product training would be advised at least every 2 versions (e.g. 9i to 11g) if not at every version.

3. Not planning for test environments. The DBA I team must have access to one or more test environments where they can install I backup I restore I clone I destroy I reconfigure. The manager should not expect his DBA to start testing restoration scenarios when the production server is really down, nor should he expect his DBA to attempt a restore + recovery method without having tested it! (And let me say this: Formal training at Oracle University is not adequate in the real­ world).

Appendix :  Resources for DBAs

Oracle Product Documentation:

Documentation:    http://www.oracle.com/technetwork /indexes/documentatio n/index.html

User Groups:

All India Oracle User Group:   http://www.aioug /org Independent Oracle Users Group:  http://www.ioug.org

International  Oracle Users Group Community:  http://www.iouc.org India Oracle Applications Users Group:  http://india.oaug.org

Oracle Applications Users Group:  http://www.oaug.org Quest International  Users Group:  http://www.questdirect.org

Special Interest Groups (SlGs): RACSIG:   http://www.oracleracsig.org BIWASIG:    http://www.oraclebiwa.org

Exadata SIG: http://www.oracleexadata.org

Events:

Oracle Events:  http://events.oracle.com

Forums:

Oracle Forums:  http://forums.oracle.com

Email Discussion Lists:

Oracle-L http ://www.freelists.org/oracle-l

NewsGroups:

GoogleGroups:  http://groups.google.com /group/comp.databases.oracle.server /topics

General Information:

Oracle Technology Network: http://otn.oracle.com OraFAQ:   http://www.orafag.org

OracleBase: http://www.oracle-ba se.com

Tutorials:

Oracle Learning Library:

http://apex.oracle.com /pls/apex/f?p=44785:1 :3520783489611662  ::::: (access it from http://otn.oracle.com )

Official Product Support:

MyOracleSupport:    https://support.oracle.com