Database Journal
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum

» Database Journal Home
» Database Articles
» Database Tutorials
MS SQL
Oracle
DB2
MS Access
MySQL
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» Sitemap
Free Newsletters:
DatabaseDaily  
News Via RSS Feed


follow us on Twitter
Database Journal |DBA Support |SQLCourse |SQLCourse2
 

Featured Database Articles

Oracle

Posted Jan 2, 2004

DBA Call to Action: New Year Resolutions

By James Koopmann

This article looks at some ways you might want to plan your New Year resolutions around your current DBA roles and responsibilities.

It is that time of year again where everyone feels the need to get their house in order and make a few plans to change their way of life for the New Year. It should be no different when you analyze your current work environment and determine what it is you want to change for the coming year. When evaluating what you as a DBA have been doing and the things that you want to do you should really first understand what are the true duties and responsibilities of a DBA. It never ceases to amaze me the confusion there is in the database world as to what a DBA really does or should do. You could ask most upper management or managers of DBAs on what it is their DBA is doing or should be doing and more often than not you will get a blank look. Not only that but you could peek around many cubical walls and look at your DBA and quickly determine that they too are not fully aware of what it is they should be doing. More often than not, he/she will be searching for something to do.

Where do DBAs spend their time

When a DBA is actually doing work, it work can typically be divided into 6 major categories that I have listed in Table 1. This breakdown of hours worked will definitely fluctuate depending on how your particular shop operates but there are a few key areas that I would like to point out within the graph that should dictate how you operate in the New Year. First of all, performance tuning is drastically lower when compared to the amount of monitoring being done. In addition, there is typically twice as much Fire Fighting than actual tuning or making changes to our databases. To me, this indicates a great need for us to work smarter and start streamlining database operations and taking hold of how access to our data occurs. Secondly, there is typically little time within the week for us as DBAs to plan for the growth of our systems and ensure that they are being backed up properly and are able to be recovered. If there is one area that I would think we all need to change, it is our ability to predict the future on how our databases will be used. With the ever-increasing amount of growth our systems are asked to handle, you should put this one area on the top of your list. Thirdly, Development Support has a good amount of time being spent within it. This is a great area for us to spend our time, as it can drastically reduce the amount of time in those categories where we should reduce our time. Last of all, you should notice that there is no category for learning, which I personally think you should spend at least 3-5 hours per week on. There is no way you can improve the performance of your systems if you are not learning of new techniques and technology. Oh Yes! It is a typical 45-hour workweek.

Table 1.

Categories of work for DBAs

 

 

Task

 

Hours Per Week

Percent of Total Work

Fire Fighting

10

22%

Monitoring

15

33%

Performance Tuning / Change Management

5

12%

Development Support

15

33%

Planning for Growth

0

0

Backup / Recovery Planning

0

0

When should a DBA get involved

If there is one thing I know for sure, it is that the typical DBA is more of an introvert, and does not always initiate those areas of improvement that should be undertaken. Take this New Year to make a pact with yourself that you will begin to take the initiative and make changes happen within your organization. With that being said, it is somewhat hard at times to actually zero in on those areas where you as a DBA should be taking the initiative. I have listed a few of the areas I have found, that cry out for a DBA to take the lead.

1. When you learn that a new application is being considered, do not sit back and wait to be invited to a meeting. Most application people only think of a database as being a repository to hold the data and not a vital part of the performance and architecture of the application. It is your duty to the information within the organization to learn first hand the true data requirements and flow of information so that you may integrate the new system into the existing corporate data.

2. Likewise, if you detect a new feature or function to an existing application, make sure you are a part of the effort to define the validity of the structures to be changed. While there are many developers that are good data modelers, it is still your responsibility to finalize any designs.

3. Whenever a change is suggested, it is your responsibility to perform an impact analysis and stress testing.

4. When questions of data ownership come to the forefront, it is the database administrator's responsibility to step forward as the ultimate owner of all data and make a determination of who may be granted the use of the data.

5. Make sure that you are aware of any applications performing poorly before someone comes to you. You should be aware of acceptable response times and be able to simulate that response. If you detect degradation in performance, it is your responsibility to seek the cause. After all, it is your database that is being impacted by the poorly performing application.

6. You should be able to detect when database structures are performing poorly or require re-orges or re-building.

In addition to getting involved within your company, there are also typical tasks, responsibilities, duties and general things you should know to excel as a DBA. I have provided a few categories and put a quick list of things that I think you as a DBA should be doing or plan to do in the New Year. If you find yourself going through the list and saying, yea I know that stuff, great. However, if you find yourself saying, wow! I should learn that, then start a small list, put some dates around it and get going in the New Year.

Configuration

  • Do you know how to install, upgrade, and configure the Oracle Server and host system?
  • You should be devising a backup and recovery strategy for enterprise wide database servers plus the validation of archived data for the recovery mechanism.
  • You should be planning for learning how to implement the allocation of system resources such as disk, memory, CPU and network bandwidth.
  • Do you know how to recover a file system?
  • Be determining the best physical design for your database such as disk, tablespace and object layouts.
  • Devise an SLA and be validate that the databases and applications are available for your particular SLA.
  • Can you patch a database?
  • Does your database automatically startup and shutdown with your operating system?
  • Are you checking for core dumps and trace files?
  • Are you checking your different log files for the Oracle server?
  • Are you ready for RAC if someone asks you?

Database Design

  • Are you fully aware of all the options with the creation of tables, views, indexes, procedures, triggers, etc. that make up the objects used by applications?
  • Do you have a handle on modification routines to ensure that changes are implemented in accordance with release schedules?
  • Do you have a line of communication with application developers that signals you that application changes are coming down the pipe?
  • Do you know all the options of creating users, giving them privileges and granting them resources?
  • Monitor usage patterns and resource consumption by user.
  • Are you in compliance with all software license agreements?
  • Do you know how to monitor the performance of all applications using the database?
  • Can you follow through with technical issues with Oracle support and other application and hardware vendors?
  • Do you have a disaster recovery plan?
  • Do you understand how the operating system security policies map to Oracle security?

Miscellaneous

  • Have you documented your procedures for everything you do so someone else can take over if you were to die?
  • Do you need to improve your SQL and PL/SQL skills?
  • Can you produce shell scripts?
  • Have you read your manuals lately for new features to exploit?
  • Can you monitor the operating system along with database monitoring?
  • If you have third party software, do you understand the loopholes in security that it might have?
  • Do you know the impact to the bottom line if the database is unavailable?
  • Do you understand budgetary constraints on the database?
  • Can you install the operating system if need be?
  • Do you know why you are using the hardware that is particular to your database?
  • You should be evaluating different hardware for future growth.
  • Are you able to issue system level commands?
  • Do you know the system / kernel parameters available for tuning the host system?
  • Do you understand the different storage options and file system intricacies?

If you are like me, and most of you are, your list of things to do has gotten longer and longer with no end in site for completing even one fourth of your list. This is a good time of year to revisit that list, take items off and add new items to it. It is my personal observation that DBAs need to be aware that the list we end up with should allow us to grow and provide benefit to our companies. Please also be aware that since trends still seem to be towards scaling down IT staff and coupled with the fact of the not quite perceived benefits DBAs provide to an organization, we should take an 'in-the-face' attitude towards getting things done within our organizations. This means that searching within the nooks and crannies of our database engines for a .00001% increase in performance might just not be worth the effort. Please make your list wisely and check it twice.

» See All Articles by Columnist James Koopmann



Oracle Archives

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 




Latest Forum Threads
Oracle Forum
Topic By Replies Updated
Oracle Data Mining: Classification jan.hasller 0 July 5th, 07:19 AM
Find duplicates - Unique IDs Lava 5 July 2nd, 08:30 AM
no matching unique or primary key rcanter 1 April 25th, 12:32 PM
Update values of one table based on condition of values in other table using Trigger Gladiator 3 February 29th, 06:01 PM