DBA Call to Action: New Year Resolutions

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

James Koopmann
James Koopmann
James Koopmann has fourteen years of database design, development and performance tuning experience. In addition, he has extensive database administration experience in Oracle and other relational databases in production environments, specializing in performance tuning of database engines and SQL based applications. Koopmann is an accomplished author with several technical papers in various Oracle related publications such as Oracle Magazine, Oracle Professional and SQL>UPDATE_RMOUG. He is a featured author and database expert for DatabaseJournal, a member of the editorial review committee for Select Journal (The Magazine for the International Oracle Users Group), an Oracle Certified Professional DBA and noted speaker at local Oracle User Groups around the country.

Latest Articles