I wasn't sure where to put this thread, so I hope this is an appropriate area. I'm just starting to study the DBA side of Teradata. I have some books and the V2R6.1 Demo CD to practice with, but I also wanted some input from people who actually work as DBAs and perform DBA tasks and functions. Anyways, I was wondering if I could get some input from people on tasks you actually do as a DBA in the real world so I can focus my studies on those areas. A top 10 task list would be great if possible.
Hi Newbie, I have read this from another Forum site (I tried but could not locate the URL now) and stored in my notes. I reproduce for your benefit.
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. 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)
Teradata DBA's are responsible for:
1. Table design and index selection 2. Table implementations, maintenance, and backup 3. Problem support 4. Workload monitoring and control 5. Policies, procedures and guidelines that govern the teradata environment 6. SQL code review 7. Developer and user support and training 8. Capacity planning 9. System software testing and benchmarking 10. Support and coordination during hardware upgrades
Read these books for generalized picture.
"Building the Data Warehouse", W. H. Inmon "The Data Warehouse Toolkit", Ralph Kimball "Data Warehousing For Dummies", Alan R. Simon