Database Analyst/Adminstration and support

Question

This may seem a bit "green" of me to ask this question, but I was wondering as a DBA (not quite sure what the difference between an adminstrator and analyst are), is "on call support" always a necessity?
Currently I am working as a programmer, but always have been drawn to databases and always perk up at the chance at writing some SQL or PL/SQL.
I am considering making the jump to be a DBA but dont know any "real life" DBA's to really question (they are in a totally different office)
I was wondering
Do all DBAs HAVE to be on call? As they are the ones that do support and maintain the up time of the server. This is one thing that has always caused me to steer away from tech support, is the on call. While if i were younger and without family and a young buck no problem, but I already get very little sleep with a child.

Answer 1

It depends. Everything can wrong. I can't begin to give you a list of what can go wrong because pretty everything has during my DBA career - ranging from the sublime to the harmless to the absolutely ridiculous.
I disagree with Aman when he says that on-call is mostly for Remote DBA companies. Any company who has vital data that they administer in house will have on-call for their Production DBAs. Not being able to get to the data is vital to companies from SMEs to multinationals. As SB rightly says, it's the medium-sized businesses that are really tough to be a DBA at most of all. You are often the ONLY guy and you have no-one to turn to when you get the alert that says your DB is down at stupid o'clock. Yes, you will be called when you're on vacation and expect the worst crisis to happen when it's most inconvenient to you (think family weddings, kids' school plays). It's just the way it is. In the UK, we called it 'sod's law'.
If your business needs access to its data, that's when a DBA will be expected to be on-call, whether it's 9-to-5, 8-to-8 or 24/7/365. A lot of companies can also tell you exactly what they're losing for each minute of downtime - something that's fun to know whenever you're doing your best to try and think clearly about a mind-boggling problem at 2.30am on a Saturday morning.
There are different types of DBAs, though. A lot of people consider database developers to be DBAs. Personally, I disagree with that classification, but in all but one company I've worked for, that's been the case. I would suggest that 'DBAs' refer to 'Production DBAs' or 'System DBAs' mostly. 'Development DBAs' are not on-call as often, but when they are, they're expected to provide on-call support to the Production DBA for code, business logic, etc.
If you can't put up with the on-call, then I would advise you to avoid being a DBA. Another thing you might not like is that, if there's a problem and your database is down or you need to restore it, it can feel like the entire company is resting on your shoulders - because it is. Being on-call is a pain, but the toughest part is the stress. If you can't get your database back, that will have serious and permanent ramifications for your business. When the worst is happening, you have to be strong enough not to let thoughts like 'if I don't get this right, a hundred/thousand people might be out of work in the morning' enter your mind.
It's a good job. It's very challenging and it's well-paid, but it's not for most people and I don't say that to dissuade you, but so you know the pitfalls. It can get very tough at times, but there's a lot of really smart people out there who you can enjoy 'debating' the finer points with when you get on your way to being an expert. If you like problem-solving and analysis, it might be for you, but you have to take the good with the bad.