As soon as fixed price DBA determines that "it is not DB", client is on their own trying to correct an issue where a DBA could be invaluable in diagnosis and building a plan for corrective action.

Fixed pricing estimates are high. They are high on a per hour basis and on an hours spent basis. This is because fixed-price contractors have to back their estimate for a year. You are paying for risk that they have estimated another account improperly and need to make it up on yours. You are also paying for risk that you may develop chronic problems—and so they charge for that in advance whether it happens or not.

Once year is out, best case scenario is that you have managed to be a "problem account" for them and have actually received some bang for your buck. Now that they know what kind of hours it takes to manage your account, you will receive a new estimate that will be calculated as follows: (yearly hours)*(markup for risk)*(200/hr)/12=(monthly rate). You will most likely not be told this formula but I guarantee that it exists. You can never beat it. You will always pay premium rates, even if you make it through first year fighting for attention.

Fixed pricing never goes down, and it usually goes substantially up after first year. Whatever price is, fixed price contractor always has an hourly rate in mind, like $200/hour. Ask. If you have already hired a fixed rate contractor, ask for a monthly report of how many hours they spend on you. Ask. You will most likely be denied since hourly rate can be astronomical if they have successfully avoided doing work, but definitely ask.

And what happens if your technical needs are much greater than anticipated? At end of year, your fixed rate will be increased based on your hourly usage in previous year so that you are back at their target profitability level (which they will still not share with you). Since you can never know how many hours they are really spending, you will never know what you are buying.

No matter how good it might seem at outset, fixed pricing never adds up. You can never truly get best deal—and you may be putting valuable data at risk. Because with a fixed-price model, if it ain't broke, they won't fix it.

So how do you find truly qualified DBAs in an OCP World? Put them to work—in interview, that is. Create real world situations where candidates are allowed full use of any familiar online resources, and see what they can do. Some examples:

Want to check out their data modeling skills? Give candidates a hypothetical business that everyone understands, like a video rental store, and a basic set of business requirements. Put them in front of a white board and let them create a model that meets stated requirements. You play role of a subject-matter expert who is decidedly non-technical, and have them walk you through results.

Wondering how they handle troubleshooting? Set up a database with various performance anomalies such as poorly written queries, missing indexes, and internal resource contention. Have applicants deal with issues and walk you through their methodology. They can't use automated tools. The Oracle Data Dictionary and OS basic facilities must suffice.

Want to see if they know how to minimize downtime? Pretend you're a client who wants to upgrade a 500GB database from version X to version X+1. It's a 24/7 environment and each hour of downtime costs $10,000. There will be downtime regardless, but DBA should be able to generate scenarios to keep it at a minimum.

Whatever skills you're looking to assess, make sure you test candidates in situations they can't prepare for and can't fake. The new interview process isn't quite as easy as those trusty old 200 questions. It requires more up-front planning and often more time in interview room. But if it saves you from having to fire incapable employees who wreaked havoc on your database, it's probably worth it. A little advance preparation can save a whole lot of time, money, and hassle down road. And isn't that all we're looking for in this crazy, mixed-up OCP world?