On Thu, 02 Sep 2004 11:40:14 -0700, Ess Wiego wrote:
> I've managed development teams but this is an entirely different can
> of worms. I can find 5,000 posts on hit ratios but there seems to be
> very little discussion about "how DBA teams work" at different shops.
With all due respect, to get a correct answer to your question,
you would need to specify the type of business that your company is
in and the company size. You are a DBA manager. What is your exact
business function? How do your DBA employees contribute to the company's
business? How much is the company willing to invest in the process and
what are the risks? If your DBA people are only supervising production,
then there are the following things that you would want to have:
- Criteria for for alarm. Escallation procedure. How do you know that
something is wrong, and who do you tell that something is wrong.
Clarify the authority. Who can decide to bounce the database?
Who can call senior VP or COO on New Year eve, 3 minutes to midnight and
why?
- Who can decide to terminate a batch job, and who should be notified,
should that happen? What are priority policies? Who sets them? Do batch
jobs have priority over on-line users or vice versa? Does accounting
dept. jobs have priority over legal dept jobs or not?
- Reports. Particular importance should be paid to growth reports.
How many gigabytes of disks will you need, and when? Are you running out
of memory? How busy are your CPUs?
- Exception reports and auditing. Any suspicious events? Anyobody running
DDL in production? Any access patterns that look unusual?
- DR plans and procedures.
If you also have to work with development and if your company has a
significant in-house application development projects, then you should
make sure that the following stuff is in place:
- Criteria for the DBA team to demand improvement. At one point in my
career, I worked for company that didn't allow any SQL which would
perform more then 1500 db block gets to go in the OLTP production.
All programs were performance tested, and rejected from going live,
if necessary. That criteria was based on specific HW and the number
of concurrent users (~ 4000).Specification when a DBA can sign off the
application to proceed to next step. The usual place for the DBA review
is after the development and before QA.
- List of features that MUST NOT be used. If your company didn't buy the
partitioning license, you cannot allow designers to design applications
based on partitioning, period. If you are an OLTP shop, you don't want
to have bitmap indexes on your tables. If your company doesn't have Java
resources, you can't allow some bright kid to design apps around Java,
because nobody will be able to maintain the application.
- List of the stuff that must be present in all cases. Every table should
have the following columns: user who last modified the record, the date
of last modification, and the program used. Every table should have a
primary key. All columns that have foreign keys must be indexed. Table
can have only one trigger of the same type. There should be a naming
convention. Same data in different tables should be linked by foreign
keys and the columns containing the same data should have the same name.
Tables should be named in such a way that the name can be used to
decipher the application that uses them. Table names like "Fido" or
"Seabiscuit" are touchy but useless.,Uniqueness must be
ensured by design, and not by using "and rownum<2". Developers who write
things like " EXCEPTION WHEN OTHERS THEN NULL;" should be publicly
beheaded and the recording posted on the internet, as a warning to the
others.
- As DBA and developers usually have different ideas about application
development, there should be some procedure for conflict resolution. The
usual procedure is called peer review, when there is a sr. DBA and
senior tech leads discussing the application. If solution cannot be
found, when does the management get involved, and who from the
management gets involved?
- What resources are devoted to the whole project? Do you have a separate
development database, QA database and performance testing database? How
are they refreshed, and how frequently?
- Where is DBA team located in the organization? Who do you report to?
Do you report to the person who is in charge of application development,
or do you report to shared technology services manager?
- Last, but not least: what kind of team spirit you want to create, and
what type of discipline you want to establish? Is it crucial that
everybody's there at 08:30 AM, because users will start calling, and how
will you delegate, and what leeway will allow to your best employees?
How will you reward your people? What are the training schedules, and
who gets to go to the really hottest stuff, like Hotsos classes or
high-level internals classes, like the ones held by Scott Gossett? How
will you delegate, and what authority will you delegate to your
subordinates?
- How many people do you need? What are the costs, and how big is your
budget? Are you able to make the business case to your boss for the
number of people you have? You should know the list of business
processes that your department gets involved with, the number of hours
spent on each, and the cost and the benefits of your involvement in each
of those. What will you do if your boss asks you "can you do it cheaper"?
--
A city is a large community where people are lonesome together.
Received on Mon Sep 06 2004 - 00:12:51 CDT
