Archives of the TeradataForum
Message Posted: Mon, 20 Jan 2003 @ 23:28:21 GMT
Every shop is setup somewhat differently, however, I have seen several where the responsibilities were roughly as follows:
Responsible for disaster recovery
Responsible for implementation coordination for new releases, hardware upgrades, patchs, Teradata client software as well as DBMS
Responsible for overall capacity planning - works with NCR to determine correct overall system size/performance
Determines overall architecture of databases, ownerships, rights, etc. They see the big picture.
Tests new releases
Keeps historical performance measures for regression testing of new releases
Responsible for "gatekeeping" changes being installed for application DBAs
Responsible for communicating with NCR on any unplanned outages
Responsible for opening and following up on many, but not all, incidents with NCR
Determine - or at least part of a team which determines overall system standards
Assists application DBA with SQL problems/spool problems, resolution of DBMS errors
Rarely works directly with users
Maintains performance tuning and security parameters that are system wide
Performs data discovery prior to physical data modeling (check out the data in detail - make sure it is what the users think it is, and that it meets all business rules they claim it does)
Application physical data modeling - sometimes have to do the logical model as well - depends on the size of the shop. Many have a separate data modeling group.
Code DDL, possibly triggers, procedures, macros - at minimum assist application developers in this area as a "consultant".
Maintains an application physical data model in a tool such as Erwin Possibly user maintenance/setup/rights - may be farmed out to a separate security group
Performance tuning that is specific to applications - solve spool out and long running query issues
May code load jobs, data maintenance jobs as assistance to application developers/ETL developers otherwise act as consultant to them
Insure that there is an adequate backup/recovery capability, coordinated with data maintenance schedule
Assists users with queries - data sourcing - acts as a consultant to users
And in some shops there is a separate production job support / help desk / team that takes the first corrective steps when a job goes down. They may do little more than call the production support or responsible application DBA to determine the correct next steps or turn over the problem to them, or may have an experienced person who is fully qualified on the utilities. They insure that jobs are run on time, if failures occur determine if it is due to late data feeds, DBMS problems, etc. They are first line of defense against not having data ready when users arrive.
Hope that helps, but of course there is always a little more too it than that. There are many variations of the above depending upon staff size. The smaller the staff the more overlap you will have. The larger the staff the more compartmentalized things become (and the less each person knows about the overall operation) Yes, I'm biased to having the big picture, and not having lots of narrow towers of "expertise".
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|