July 27, 2001 at 12:40 pm
Here is my reponse:
There are lots of different duties for a DBA and there is not good "job description". I actually started an article on this, but it got too long and I dropped it for now. From what I have
seen, there are a few basic types of DBAs:
1. Administrative DBA - Work on maintaining the server and keeping it running. Concerned with backups, security, patches, replication, etc. Things that concern the actual server software.
2. Development DBA - works on building queries, stored procedures, etc that meet business needs. This is the equivalent of the programmer. You primarily write T-SQL.
3. Architect - Design schemas. Build tables, FKs, PKs, etc. Work to build a structure that meets the business needs in general. The design is then used by developers and development DBAs to implement the actual application.
4. Data Warehouse DBA - Newer role, but responsible for merging data from multiple sources into a data warehouse. May have to design warehouse, but cleans, standardizes, and scrubs data before loading. In SQL Server, this DBA would use DTS heavily.
5. OLAP DBA - Builds multi-dimensional cubes for decision support or OLAP systems. The primary language in SQL Server is MDX, not SQL here.
Being a DBA (in general) is tedious. You have to plan for the future, anticipate places where your schema will be bent or stretched. Plan for growth and make very, very few mistakes. It's not like C development where you will fly by the seat of your pants when building this application. Your decisions affect data that has far reaching effects. Also, since you work in a set-oriented environment, you can make mistakes quickly that affect more items. Unlike a class or structure where you have a small set of data (i.e., one customer), a single line in SQL can affect all customers in a structure.
System Upgrades: Varies. In general, in smaller companies, the DBA might perform all the roles above and apply service packs, upgrades, etc. In larger shops, the DBA might not do anything on the NT/UNIX side and only handle the application (SQL/Oracle/DB2, etc.). In my company, I handle all SQL related items, including service packs for SQL. NT/2000 service packs and patches are applied by the sysadmin. HE also replaces/adds hard drives, memory, etc. Performs tape backups. I merely ensure SQL Server keeps running and let him know if I need something.
I can't really speak about Oracle, since I have only developed applications against the DB and then through ODBC (many years ago). Oracle in general, from my limited knowledge, requires more of a hand's on, command line approach to management (which is a good thing, IMHO). So shell programming can really help you here. It's tough to decide if you want to be a DBA. On one hand it can be boring if everything runs well (for me its kind of boring now). But when something breaks, there is tremendous pressure and stress. Not something you can simulate in school.
I'd learn about relational and database theory. Read about it and see what people think. IMHO, there is no "right" way, but lots of trade-offs in any design. Learn as much as you can and then make a decision that fits your situation. I have a broad range of experience in networking as well as software development and I think that really helps me. I understand how to build an operating system, so I have a feel for what occurs inside the machine. Knowing how networks move data also helps to design a better system as well as troubleshoot problems. In today's world, I think understanding how networks connect is very important. In the MS world, I think systems programming is only required if you want to be a systems programmer. In the *nix world, knowing how to develop system utilities is helpful, but I don't think it's required.
Steve Jones
July 27, 2001 at 12:40 pm
I got the following questions from a reader and was hoping to get some responses from the world out there.
At this moment in time, i'm pursuing a bachelors in computer science
and i would like to know what's it like working as a DBA? what is the
entry level at which u join a particular company? what sort of things
fall under the DBA's domain? like is he responsible for system
upgrades and stuff like that or just concerned only with the database
leaving all else with the system admin? what sort of things one
should do to prepare oneself for a career in databases these
days...in terms of oracle certification? subjects in school
(networking, database subjects)?
one last query is that do you have to know system programming like C,
C++ to be a database developer or administrator coz i read in some
book that system's programming is a prereq for being a dba. i
understand that you need a good understanding of operating systems
environments like win nt and unix but do u have to know how they are
built...like the C++ behind it!
Steve Jones
July 27, 2001 at 9:13 pm
Steve covered a lot of good stuff, I've only got a little to add.
One of the best things you can do as an undergrad is excel to the point where you get noticed by your instructors. What this does is open up co-op opportunities or summer internships. A good friend of mine has co-op'ed with a networking company, and that networking company tends to hire like 90% of its co-op students. Another friend of mine is currently a graduate student who happens to be a summer intern at my organization. He's had the opportunity to get some hands on with SQL 2000, do data analysis, database design, etc., all in the period of about 2 months. We've thrown him into the crucible to see what's he capable of, and he's smoking all the tests.
As for DBA work, while system programming is nice, probably the best discipline you can bring in addition to DBA skills is systems administration as you've pointed out. You have to understand how the OS works with the database. You need to know how network communications is handled. And you've got to understand what the OS is capable of and where you can leverage it to help you. This is true whether you're dealing with MS SQL Servers on NT/Win2K or Oracle/Sybase/Informix servers on Unix. This isn't necessarily at a code level. Understanding programming and how programs interface with the database is important as well, because a lot of what I do as a DBA is assist developers with their use of my database servers. Simple things like ADO best practices, connection pooling, network protocols, etc. can make a big difference in how an application performs.
K. Brian Kelley
K. Brian Kelley
@kbriankelley
July 30, 2001 at 8:58 am
...and now that we have all the technical aspects of this job title defined, a DBA must be the type of person that is approachable above all things to be successful. As a DBA you are required to share information about database design, server performance, network performance, application programming with a myriad of people in your organization. If you are first not capable of communicating on those levels(see previous two posts on knowledge base necessary) and second able to do it in a manner that is non-demeaning and threatening then you will not be highly successful.
Detail oriented, consistent, even picky but encouraging and friendly. Is this combination possible? Meet some DBA's and find out.
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
December 28, 2001 at 2:34 pm
Great definitions!
I would like to add just a few things:
Administrative/Operational DBAs are SAs in Development, Test, and Production. They spend some amount of time trouble shooting production system SQL Agent job failures and other issues. This type of DBA has broad responsibility and generally is funded out of a pool fund.
Development DBAs can be SAs in Development depending on their skill level and the size and requirements of their project. This type of DBA can spend a year or more on just one project, but generally they work on more than one thing. They tend to work on just what they are funded to do.
Project DBAs are assigned to a specific project. Sometimes they also wear the Development DBAs hat. For a project to get a dedicated DBA it generally is a large and complex system. Some COTS examples would be project DBAs that support SAP or PeopleSoft implementations.
December 28, 2001 at 4:27 pm
January 2, 2002 at 12:15 pm
I enjoy being a DBA/SQL Programmer. For the most part I don't find my job tedious (otherwise I'd have found another one by now). I mostly create and modify DTS packages and stored procedures, but also set up security accounts, correct data at times and even analyze data. My official job title is SQL Programmer, however I do many administrative tasks. I develop and modify queries and stored procedures and move them from development to staging and then from staging to production as needed. I have encountered people that were hesitant to approach me because of their belief (based on previous experience) that a DBA doesn't like to be bothered. I quickly dispel that belief as I feel a DBA should be ready to help with database problems and coordinate project efforts. I often coordinate development of stored procedures with our Cold Fussion Programmers and our VB Programmers.
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
January 2, 2002 at 3:18 pm
Funny, but my group and boss have the same belief that I am too busy to be bothered with many things. I consider myself approachable and usually can fix issues within a day, but for some reason people think I am too busy to be bothered. Oh well...
Steve Jones
January 3, 2002 at 8:26 am
Often it is beneficial that people think I am busy as I can then focus on a task and complete it. However, I am always able to break away from any task and focus on another and then go back. As part of my responsibilities include our production site, this means I must drop everything at the slightest error, slowness, or other problem with our production servers and focus on investigating and fixing the problem.
Robert Marda
SQL Programmer
bigdough.com
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply