|
; "Is there a rule of thumb regarding the proper staff size to
; support an RDB shop? What parameters are involved in sizing
; the staff ie. number of transactions, size of database,
; criticality, etc."
; Does anyone know of an article or whitepaper regarding Db
; staffing. Something written by Gartner, Seybold, or in
; Datamation etc would help out alot.
Although your customer obviously has a poor understanding of their
situation from defining their problem in those terms, I still have
to give them credit for recognizing this and looking for assistance
from credible sources. As you expected it is not a simple question.
The answer depends largely upon the demands of the shop and the
capabilities of those in the support role and is determined by a
number of factors.
1. TECHNOLOGY. Keep in mind that capabilities are not only defined
by the training and experience of the individuals involved, but also
their access to technology. I am a resident supporting Rdb on-site at
a Fortune 500 company and I can do far more today with a few workstations
and x-terminals dedicated to support funcions with the appropriate software
than I could five years ago with just a single-threaded piece of glass
like a VT-220.
For example, if one is doing a stress test you can have multiple VMS
MONITOR, RMU/SHOW statistics, SHOW PROCESS/STATISTICS, DECps, DECtrace
Monitor, etal. sessions all going at once in a dozen windows and get
to the bottom of problems that teams of normal people would miss after
weeks of transaction analysis at a desk. Link that up with outstanding
tools like a DECtrace feed into RdbExpert, or being able to whip things
up with InstantSQL or the Graphical Schema Editor and the right
individual can literally be more productive than a team of 5-6 good
people just a few years ago.
For this reason any article you find that is just a few years old will
be COMPLETELY irrelevant. Likewise since other vendors don't have this
kind of technology -- either Rdb with things like dynamic query
optmization, or its associated (and patented) tools, counsulting groups
aren't going to look at this as an industry phenomemon or actually do
this kind of work to realize the performance gain, and their value will
be severely underestimated.
Even people who have been average "Rdb programmers" for as long as five
years normally don't have the relevant experience to become database
administrators since they're generally slopping SQL on a deadline and
not worried about database design, performance, or administration.
Likewise a database that is well-designed requires significantly less
effort to maintain than a poorly-designed one. People ineffectively
tune who do not have the required understanding or appropriate tools.
Likewise even experienced people in command of technology and understanding
hampered by trying to do an analysis with RdbExpert, etc. on a sold-out,
older processor with no system resources avaialble like a over-used
VAX 8650.
More variables to consider are:
2. TRAINING specifically on Rdb. This can significantly reduce the
learning curve since people will be able to recognize what's important
and where to attack the problems at hand from a good training course.
3. EXPERIENCE specifically on Rdb. Even good people can only assimilate
so much information so fast, or may apply what they've learned in training,
and seasoned people who focus on the appropriate Rdb task will have an
applied knowledge that can be used to solve problems in minutes or hours
that commonly take less Rdb-experienced people days or weeks.
4. CHARACTER. People with training and experience have the knowledge and
confidence to act on what they know as a force for good proactively,
whereas there are plently of people (who are in the majority) who know what
they need to do but are afraid to do it because "something" might go wrong.
For example I have dozens and dozens of my customers who know they need to
implement a hashed index, have read the manual and sized it correctly, etc.
generally but are deathly afraid of the implications of maybe screwing up
and more specifically their ability to fix it at that point. A seasoned
person generously sizes the mixed area, leaves a sorted index in reserve,
scheduled a database area reload a couple of weeks out based on a sample
run they did in batch the night before -- all of this before even
implementing the index in production and even knowing that it might need
tuning at all. Instead of sitting on a maybe for six months and taking
six months to make a half-hearted attempt at tuning, performance triples
imeediately and is tuned to optimum by the end of the month (until it
needs re-tuning).
5. AGE and ADAPTABILITY. In his 1991 report "Building the Open Master
Platform" Wes Melling of the Gartner Group said (0.8 probablity): "Don't
Trust Anyone Over 30." From my own experiences as an instructor I can
tell you that it is amazing how two applications programmers with roughly
the same IQ can hear completely different things when one of them is a
26-year old of a couple years experience and the other is a 25-year
IBM and COBOL veteran. The latter group consistently has lower test
scores on an open-book post-course evaluation and when you go over it
with the veteran the problem is that their pattern-recognition algorithm
in their head short-circuited the meanings into old and subsequently
wrong definitions. As long as the people are "trapped by their experience"
it won't work against them (i.e. although I am also a PDP-11 programmer
and know TECO and could still code some of these kids into the ground
using a 64Kbyte RAM RT-11 system, I am not functioning virtually in that
environment today using exclusively TECO and writing Fortran-IV code).
In my town we represent this by saying "a good programmer can write
"Fortran" in *any* computer language." Likewise the quality of
adaptability may have nothing to do with age, i.e. Dave Cutler is one
of the primary visionaries behind NT and he is 50 (although Cutler's
vision may have been the same 20 years ago and Digital just never got
around to following through, there is no doubt that his opinions were
at least refined by things like the PRISM or VAXeln).
6. SOFTWARE DESIGN. If the problem isn't clearly defined and understood
you can have people who meet all of the above criteria and still be
completely ineffective. If the project management doesn't include people
who can properly design the system it is not an "Rdb problem" per se and
will fail using any vendors platforms and databases.
Technology, training, experience, character, age and adaptability and
software design all SEVERELY impact the question at hand. If you have
people who are very strong in all of those areas 2-3 people can get as
much or more done as a team of 20-30 who are uniformly weak in these
areas (ask me about government work sometime). Any model or article
that reduces these factors to a simplistic rule of thumb is making
very dangerous assumptions and will be inaccurate.
I hope this give you some insight into the problem.
Regards,
rcs
|