Archives of the TeradataForum

Message Posted: Mon, 20 Jan 2003 @ 23:28:21 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Every shop is setup somewhat differently, however, I have seen several where the responsibilities were roughly as follows:

Support/Production DBA:

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

Application DBA:

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".

Sam Mosley

	<Prev	Next>		<<First	<Prev	Next>	Last>>