A database administrator is responsible for the day-to-day management and maintenance of information on a computer server.
International companies, small businesses and NGOs (non-government organisations) around the world rely on effective data management to be able to run their operations. Data is typically stored on a central database (or collection of databases) which are hosted on a server. In large international organisations, the server could be a considerable installation consisting of hundreds of interlinked data storage and access devices. In the case of a small business, it may be a single computer feeding information to other workstations. Regardless of the size of the concern, the database administrator is tasked with ensuring that data storage, retrieval and access to and from the service is provided effectively and securely.
Tasks include fully backing up (and restoring) the system and data archive, ensuring the system runs smoothly, minimising errors and disasters and ensuring data throughput is conducted at the best possible level. The most common system used for database administration is MySQL, (“Structure Query Language”), a type of relational database management system, and the common ‘language’ of the database administrator.
The average salary for London-based MySQL administrators is around £45,000 for 2012, based on ITJobsWatch’s survey of 1851 professional respondents this year. That average has increased over the average salary for 2011, which was £43,500, a rise of 3.4%. The freelance market is very healthy at the moment, with a variety of organisations using well-remunerated freelancers in the post-recession period to handle their database requirements over a six or twelve month period.
- Maintaining the availability of MySQL servers
- Securing the data against unauthorised access (both external and internal)
- Ensuring that there is a regular, tested database backup
- Working with development teams to ensure suitable schemata and queries
- Processing of the “slow query” log to tackle potential bottlenecks before they become serious
- Ad-hoc query writing
- Providing advice to development teams
- Overcome data performance issues (“My website has started to run really slowly”)
- Manage disaster recovery (“My server crashed and now I can't get my database to work!”)
- Handle all tasks in a time-critical environment
- Prioritise high importance and high impact workload
A formal qualification in software coding or database administration to at least GNVQ2 is the absolute minimum requirement, although an increasing number of “gorilla” developers (self-taught individuals with new ideas but no formal qualifications) are becoming more prevalent in the DIY app age. Development experience is also immensely useful as it makes it easier for the DBA to talk to development teams “in their own language”, providing example code and being able, in some cases, to deal with problems directly. According to interviews with well established DBAs, experience can be just as good as a formal qualification. Oracle offers MySQL certification, which should be an absolute requirement for DBA roles, and should be strongly encouraged for developer roles.
- Attention to detail
- A careful and methodical approach
- A cool head under pressure and scrutiny
- Remain steadfast to priority tasks, even with people “encouraging” faster work rates.
- Be highly accurate as much of the DBA’s work does not offer an “undo” function
- Have a good understanding of the language used by coding teams
- Be an excellent communicator
- Get things right first time, every time
Much of this work centres around the “mundane” management tasks which go largely unnoticed in large organisations. Much like the football goalkeeper, it is only when things go wrong than people notice the role of the DBA, and these can be highly-pressured situations. Effective disaster mitigation is the result of two things: effective disaster planning and correct maintenance of disaster mitigation routines; both of these tasks fall at the feet of the DBA.
Many database administrators begin as “coders” – software designers and developers who could be working on a variety of database, software, programme, environment or hardware implementation roles. Whilst both types of job require a methodical approach, it is the database administrator who has less opportunity to “try things out,” making it a more engaging (or some may say stressful) job role.
Large organisations often employ database managers to supervise the administrator and sub-teams of coders, so this can be a natural progression. Full-time DBAs should also bear in mind that some of the highest earning administrators in the UK are freelance, and travel around the country on ad-hoc placements as required.
As virtually every company over the size of 25 people will require a centralised database of some sort, then it follows that virtually all SMEs (small-medium enterprises) and above would have a need for a database administrator. For this reason, there are no major employers as such.
Richard Wallman is a highly respected database administrator working in the south-east of England, and is a thought leader on MySQL development in the UK.
What made you decide or choose to get into this sort of career?
I believe, like many other MySQL DBAs, that I kind of “evolved” into the role. There's a tendency for one person in a development team to take on more and more of the database work, becoming the de-facto MySQL DBA for the organisation. It's a highly portable skill, and there's enough work at all levels (from junior roles with single databases to “big data” organisations) to make a good career.
What do you like most about the job?
It's always full of surprises – some good, some bad. Each job tends to bring new challenges, so it's like a constant workout for the brain: sometimes applying a standard pattern for a common challenge, sometimes working around anti-patterns that have already been built into the system, and sometimes having to come up with something new.
In some cases, the results are satisfyingly drastic – a struggling system suddenly springing back into life, or seemingly small changes making big improvements to performance. The people I'm working for are usually extremely grateful, having learned the hard way how important their database system really is to their organisation.
What do you like least about the job?
Probably the fact that by the time I'm called in, it's already too late. There is a tendency for smaller organisations (and in particular, start-ups) to avoid the “cost” of a DBA during the planning phase of their projects. As a result, most of my work is of a reactionary, fire-fighting nature – trying to get overloaded or damaged systems back online, where I know that had I been called in from the start the problems could have been greatly mitigated, if not avoided completely.
There's also a tendency to believe that server problems are solvable with “tuning,” that there's some magical switch or configuration option that just needs changing to sort everything out. Most of the work I do isn't actually with the MySQL server at all (although sub-optimal schema design usually forms a part) but with the applications using it. This is where things get slow and expensive. Changing a system that's already populated with data and in daily use is a lot more intricate and prone to introducing regressions, and so can take up considerable developer and DBA time.
What is the starting salary, and how does this increase over time with promotion?
As MySQL DBAs tend to evolve from developers, there's no starting salary as such. I've also found it quite difficult to get people to accept the justifications for salary increases. Although the database may be one of the single most important parts of an organisation, it's something that isn't really noticed until there's a problem – you get no credit for keeping it running, but plenty of attention when there's an issue!
It's a sad fact that a lot of organisations don't recognise the value of having an experienced DBA on the team (even in a freelance or consultant basis) and tend to take the development team's word that they “know MySQL”, resulting in sub-optimal designs that require careful (and hence slow and expensive) changes later on. Having said that, this attitude can drastically change the first time things go seriously wrong, and the value of a DBA is made clear.
What advice do you have for someone who is looking to get into this as a career?
Beware of common ignorance, as there is plenty of misinformation and “best practices” that are actually far from being the best. Developers tend to overestimate their database abilities, leading to the use of anti-patterns and other sub-optimal artefacts in a system. Always keep a test system on hand, don't be afraid to do experiments on it to find out for yourself rather than rely on what you're told. There are so many variables involved in making a high performance database system that what may work for one dataset may have little or no (or even worse, a negative) effect on another dataset.
What are the most important qualities an applicant must and should possess?
Attention to detail, a careful and methodical approach, and a cool head under pressure. When you're dealing with a website that's been offlined (by disaster, traffic or otherwise) then there's plenty of eyes on what you're doing and voices “encouraging” you to work faster. However, DBAs work without the safety-nets that developers enjoy – there's no “undo” function when modifying a database, and rolling back to a previous version is not as easy as just checking out a previous code commit, so DBAs are required to get things right first time, every time.
Any closing questions, comments or additional advice?
There's no real need for a MySQL DBA to actually be on-site. Provided they can remotely access the physical server that the MySQL database server is running on, this is usually sufficient for them to do their work. This has several advantages, not least of all with less office space/equipment required. A remote MySQL DBA may be able to respond to emergencies quicker (working from their home, rather than having to travel to an office), and securing the services of a remote DBA from a different country can provide out-of-hours support without the usual high fees associated with “unsocial hours” working (the time-zone differences can work in an organisation's favour).