Im sure this has been asked, but times change and so do SQL preferences etc… I figure this place would be the best place to ask this im sure many DBA's come here.
But what do I need to know starting off. Im graduating this December with my B.S. in Computer Science, I took two Database classes as well as built my own Database driven music store for one of them (it was basic, but worked well and looked quite nice).
Anyways Im not sure what Database most companies use. I know there is Mysql (but thats usually web stuff which im not interested in), Oracle , and then MS-SQL server, along with a few others.
The path for certifications seems to make MS-SQL server a tad easier (2008) and less expensive, Oracle seems quite….."wanted" as far as jobs go, but I also see my fair share of MSSQL too.
Also….are the differences even THAT big? as far as actual coding goes. And how about the job market for a DBA? good? bad? seen better days?
What should I be doing next to make sure I can land a decent job, whats the right path? Any answers are helpful answers!
thanks
Best Answer
What do you need to know about databases to be a DBA? Everything (or at least most things, and where to look for answers to everything else).
Seriously though, there is always a market for good DBAs. If you want to become a good DBA the best advice I can give you is:
If your "databases class" didn't get into the theory behind the relational model & relational algebra you may want to pick up a good book on the subject. Understanding the theory underlying the systems you aim to manage will be useful later in subtle and interesting ways.
Design and implement some kind of database-backed system.
You already did this, but you said the store was "simple" -- Expand on it.
Load huge amounts of data into your system and see where the performance breaks down - then fix the problem.
(In my experience as a DBA that will probably be your most common task: "X is slow. Make X not be slow.")
Find a company that is looking for junior DBAs or junior administrators. Apply there.
It doesn't matter what DBMS they're using (though if it's one you know or one you want to work with in the future that's great).
Absorb as much knowledge from their DBA staff as you can.
Ask questions. Sit in on design meetings. Bring the folks troubleshooting performance problems coffee and listen to their conversation.
Take training/certification classes (especially if you can get work to pay for them!).
While these aren't particularly useful without some real-world experience to back them up they often expose nooks and crannies of database systems that you may not see often in the real world. Many are also task-oriented, covering the common stuff like setting up database backups.
At some point in those 5 steps people will start asking you questions, or throwing problems at you and asking you to solve them. At that point you are a DBA (or at least a resource the DBAs trust enough to give work to with the expectation that you won't break anything :-)