As you probably know by now, I’m a consultant. By consultant I don’t mean a person who sits in meetings and talks all day (even though I like to talk), I mean a professional services guy who can do DBA tasks and can design and execute projects.
In many cases companies prefer to hire someone of their own and not rely on resources outside of the company. When I talk to people about it (friends from the software and IT areas or potential clients) they sometimes ask me why they should take me as a consultant and not hire someone. Well, there are several reasons for that, some are technical and some are not, so I’ll start with the non-technical first.
Non-Technical
There are several reasons to take me (or a consultant in general) instead of hiring someone, these are some of them:
- Short projects. For short projects companies won’t usually hire people, so consultants are a perfect match.
- They don’t need a full time DBA. Some companies, mainly small ones, need a DBA but not for a full time. This is perfect for consultants that look for several clients for part-time work.
- They need an expert but they can’t hire one. I’ll talk about expertise later on, but usually consultants are good DBAs, and sometimes companies need a good DBA but they can’t keep a good DBA for a long time (because the DBA might get bored after a while, his salary, etc.). So having a consultant for part time job might give them exactly what they need.
- Redundancy. I’m not alone, I have a company with quite a few DBAs. When a client hires me (or anyone else in my company) he gets the entire company. If a specific person goes on vacation, I can provide someone else. This can’t be done when the DBA is employee of the company itself.
- Fields of expertise. Since we are a company, the DBA for this specific client might be expert in certain areas. If and when the client needs an expert in other areas, we can provide it easily. For example a database security expert can come to this client instead of their regular DBA for a couple of days.
Technical
This is a little bit more interesting. As I said above, consultants are usually good DBAs. I’m not saying I’m better than other DBAs who work for a non-consulting company, definitely not. There are excellent DBAs out there, consultants or not. However, as a consultant I’ve seen a lot and did a lot. For example, I’ve installed and worked with all Oracle versions from 7 to 12c on Linux, Windows, Solaris, HP-UX and AIX. I even installed Oracle once on SCO/linux (wow that was a long time ago) and had the chance to work a little bit with Oracle on VMS. This is probably more versions and environments than a DBA working for a regular company worked with.
Of course, there are downsides of being a consultant as well. When I come to a client, the DBA there knows the application, the environment and the people, so they have a lot of power and knowledge that I don’t. But if you look from database experience, I was probably involved with more database upgrade projects than the average DBA, including more complex upgrades such as RAC upgrades, upgrades between different hosts, upgrades between different operating systems and even upgrade that included all three (I upgraded a RAC database from HP-UX to Linux servers). So again, I’m not the best DBA, but I’ve seen a lot, and I would like to tell a couple of stories here exactly about that.
Besides that, part of being a consultant is being out there, so consultants speak at conferences, instruct courses and so on. By that we learn new stuff all the time, and keep ourselves up to date.
Performance problem
About 10 years ago a client phoned me because they had a performance problem in their main ERP database. It was a large company with their own DBA team, and they couldn’t solve it. I arrived and as always I started asking questions in order to get information about the problem. It turned out that the problem started a day or two before and when I asked if they did any change they said that they simply moved from 32-bit Oracle to 64-bit Oracle but didn’t change the server or version or anything else.
My immediate reaction was “did you increase the shared pool size?”. They were not aware to the fact that changing the word size requires increasing the shared pool, so I showed them the MOS note that says so (62290.1, point 10). We increased the shared pool size and the problem was fixed.
Am I a better DBA than them? I don’t think so. They are quite a team (I know some of them personally). They are very experienced and knowledgeable, but they missed this tiny point of increasing the shared pool. I simply read about that and saw that in the past.
Failed RAC upgrade
Another example was probably about 4-5 years ago, when a colleague called me and ask me to help his friend with a RAC upgrade problem. It was a weekend evening and I was driving with my family in the car, but I called this guy. He was in the middle of a RAC upgrade from 11.2.0.1 to 11.2.0.2 and got all kind of errors running root.sh on the second node. I guided him to read me some logs (while I was driving, just imagine that) and realized that the nodes can’t communicate over the interconnect. It took about 10 minutes in total until the penny dropped, there was a change with multicast in 11.2.0.2 that caused interconnect problems (MOS note 1212703.1). I directed him to the right note and patch and he finished the upgrade successfully.
I happened to meet this guy years later, and even helped him to get a job for one of my clients (we made the connection to the call only after). I think he is a great DBA, but again, he was simply unfamiliar with this issue.
Summary
These are only two examples, I have quite a lot. Again, I don’t think I’m the best DBA, over the years I’ve learned a lot from other DBAs as well. But the fact that I’ve visited many companies and have seen many different versions and scenarios help me to understand more environments, more companies and with it, more “do’s and don’ts” and more troubleshooting experience.
If you agree or not or have anything to say, feel free to comment, I’d love to hear what you think.
Something an external consultant can bring is a new view. They lack the knowledge of the particular company and do not appreciate the history of the development, and they have no political or historical ties to the current systems (both a good and bad thing). A good consultant will take an impartial view and say “starting from this point and ignoring all effort to date” {which is the best position to take, IMHO} you might want to consider “These X Points”.
A top consultant will highlight where the in-house team has already raised these points and been ignored. As the aim of a top consultant is to leave the client in a better position after their visit (not to secure more work, which is a business short-term win and a long-term moral fail), which might be to listen to their own talent… But the external consultant might also have to highlight that the internal staff are failing the client… ohhh, quite a hard task.
In the end, the best you can expect from an external consultant is an Independent and honest input. I don’t think you usually get this from a Large Multinational Consultancy (my experience is such companies will stitch you up for a longer term, more lucrative engagement), you are more likely to get it from an individual guy or gal. I would say that of course, as that is my personal business model! But If I, as an individual, give you bad advice – I have no where to hide. You Will Blame Me. And that is how it should be.
Martin,
I agree about the honest and objective input, but it’s not always easy. On one hand you don’t want the company to feel that the in-house DBAs failed, on the other hand you need to justify your work. There is a lot of diplomacy here.
Thanks for your input.