Planning and Questions

From SQLServerPedia

Jump to: navigation, search

Contents

Not So Fast!

Many of you have been delivered something you don't understand and can't properly support. Perhaps it was a vendor application with no documentation and no adherence to best practices that is monopolizing your time. It is unfortunately more the norm for a DBA to get involved at the end of a deployment when it's time for the rubber to meet the road. This article can hopefully help provide one more tool in changing that paradigm by giving a list of questions to ask a vendor with a SQL Server back-end.

Get Involved Early

A DBA being involved early in the selection and initial planning phases of a new application with a significant database requirement is good for all parties. The DBA can properly plan and be prepared to set things up for the new server this way. Even more important - you can help make sure that you deal with possible best practice violations and make location decisions (possibly saving money by sharing hardware or instances) with time to make changes.

The Question List

What follows are some questions that the original author asks of potential vendors. Not all of the questions get asked and the important goal here is to drive a conversation and get answers to even unasked questions. This is a wiki article so it is hoped that you can add questions that you ask or wish you had asked. It's easy to contribute!

  • The Basic Questions
    • What Version/Service Pack Level - Find out if they support the latest, find out if they match your environment plan. Find out why they don't if not.
    • New SQL Service Pack/CU Protocol - Do they test the latest service packs? Are they aware of them? What is their policy if you want to apply them?
    • Instances/Clusters/Shared Server - Hopefully you have a plan for preventing SQL Server sprawl and have an idea of how you want to be setup. Do they support your particular situation? Why not, if not?
  • Security/Auditing
    • How Do You Connect To SQL - Do they rely on an account with Sysadmin rights? Do they rely on DBO rights? Do they support the more secure Windows Authentication?
    • How Do Upgrades & Support Calls Work - What kind of connections need to be made? Can I review your scripts during an upgrade?
  • Best Practices
    • Documentation - Can I see your documentation? Does your support have suggestions for recommended maintenance practices/frequency of jobs? (Hopefully you have your own plans but curious to see what they suggest, if anything). Any installation documentation?
    • Performance - Based on what you know about our requirements, are we a typical customer, bigger? smaller? What kind of hardware do you typically recommend for an installation like ours?
  • References - Can I speak to other DBAs or customers who you use as reference customers? Find out what kind of heartaches they dealt with during their deploys.
  • Backup/Recovery - What kind of SLA should this application fall under. (This is more of an internal question to the project team in charge of the deploy but make sure the vendor has no gotchas with your approach.)

The "Interview"

One approach to dealing with the above questions is a checklist approach. You can create a simple checklist with space for copious notes and start the conversation. As you begin the conversation with the vendor sales engineers (hopefully you can talk with someone in the technical pre-sales role) or even support departments the checklist helps ensure you cover the basics. Hopefully you will find yourself breaking off of the list and gaining a comfort (or "alarm") factor with the project and the application. The goals here are always to make sure that a deploy goes smoother, that you can properly support your users and that everyone has a positive experience.

The interview is the easy part, the tough part may be getting involved early enough in the process. If you are working at a company that doesn't notify you until its too late for these kind of questions you can hopefully share the question list and reasons behind them to change that status.

Author Credits

Mike Walsh

This wiki article was adapted from a blog post by Mike Walsh.

Mike is an experienced SQL Server professional who has worked almost exclusively with SQL Server in various capacities for nearly ten years. He has fulfilled the roles of DBA, developer, business analyst and performance team lead but he always works his DBA experience into each role. Most recently he is the Principal Database Administrator and SQL Server subject matter expert for a global insurance company. He also assists organizations with SQL problems through his consulting firm, StraightPath Solutions.

His online presences include: