February 18, 2008 at 6:18 am
Will be meeting with a Vendor tomorrrow ... I am installing a new 64 bit 2005 Enterprise Instance for their product but they havent' given any documentation yet.. this is what I've come up with so far...
Does the Application need a Named Instance or will a Default Instance suffice?
(if Named, is there a preferred name?)
Type of account needed to connect to the Database from the Application? (SQL or NT Authenticated)
Type of Permissions needed to the Database with the connect account?
Preferred Recovery Model? Standard for most of our SQL Server Databases is Full Recovery with Daily Full Backups and Frequent TLOG backups
Are users authenticated at the Application or will each user need SQL Server credentials?
Approximate size of the Database(s)
What else would I need to ask??????????????
February 18, 2008 at 6:26 am
Don't know if it is applicable in your case, but I would ask about any linked servers that database might require. 64bit oledb drivers can be a pain..
...and your only reply is slΓ inte mhath
February 18, 2008 at 9:33 am
That's a good list. I'd ask if you can change indexes or how well they've done work with indexes. Many vendors seem to fall short here.
I'd definitely quiz them on 64-bit. If you need to connect back to 32 bit servers, there can be problems. If they use packages, etc., sometimes there are 64-32 bit issues.
February 18, 2008 at 11:30 am
all of these are good Questions, but you should know most of them, vendors for the most part do not care how the data is kept or how big the log files are, the questions you need to ask are from the developer stand point of view and the user stand point of view, then from the point of administrations. example do I need to install and odbc driver on the server to accomodate the application, does the application reside on the same box as SQL Server, does the client require ODBC? how many connections do I have to have per client, how are locks resolved? what special user rights are required from the user stand point of view.is there a supperuser with in the software and what are their functions, what about security with in the application, can the user truncate or delete records in bulk, etc........
hope this help.
"We never plan to Fail, We just fail to plan":)
February 18, 2008 at 12:45 pm
Good list, like everyone else said. Just no hair in the list...
I'd first ask them if they've actually tested their code on a 64 bit machine. I'd want to know some things like what scale they tested at and how they load tested using multiple connections and concurrency and the like. I'd also ask how well their "reports" stood up to large scalability after years of data accumulation.
Next thing I'd ask is if you could do a code review on some of the stored procedures... looke for RBAR in the form of correlated subqueries, triangular joins, while loops, cursors, etc.
Doesn't matter how good the server is, cruddy code will drag it down.
And, yeah... like the others, I'd want some really good proof that their software plays nice-nice on 64 bits and with other links.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 18, 2008 at 3:07 pm
Along with the size of the database, I'd ask about growth rates as well.
With authentication, make sure the application is not storing the password in plain-text in a config file somewhere (had that recently with a web app using SQL Authentication, managed to change it to use Windows Authentication).
Will it be using the older SQL 2000 ODBC client or does it support SQL Native Client? Of special interest if you want to implement things like mirroring - which is another question to ask. Does the app handle database mirroring (failover)?
MARCUS. Why dost thou laugh? It fits not with this hour.
TITUS. Why, I have not another tear to shed;
--Titus Andronicus, William Shakespeare
February 18, 2008 at 5:35 pm
awesome! Thanks for all of the good stuff! I've got A starting point, some reading to do and some serious questions to ask
February 18, 2008 at 5:54 pm
Heh... do be a bit careful... my questions, although certainly appropriate, are likely to be taken as a high insult. π I know this because new vendors I try to bring on board are subjected to those same questions... they're always insulted, at first.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 18, 2008 at 7:22 pm
Jeff Moden (2/18/2008)
Heh... do be a bit careful... my questions, although certainly appropriate, are likely to be taken as a high insult. π I know this because new vendors I try to bring on board are subjected to those same questions... they're always insulted, at first.
All due respect, but for the money I've seen shelled out on POS'es (and no - I didn't mean Point Of Service there...:)) - they can answer some questions. I mean - if there's at least high five digits on the check, then they'd BETTER answer some questions.
I usually start low - like -
- what is Normalization (40% of the systems I've seen aren't even close, so it's not as silly a question as you think). If you get a confused look back - don't walk - RUN AWAY. Also the "it's a pain in the A$$ thingie a DBA we fired used to talk about" answer is not a good sign.
- what process do you have in place to keep this database tuned ("the data tunes itself" is a really BAD answer).
- How does this play with Reporting services/external feeds? Is there a Data Dictionary (yes - the mainframe term) available describing what the tables do?
- How do you maintain DRI? (again - confused looks or "we don't" or "our Code does that" aren't the right answers)
I mean - the rest is nice and all - but I "get" to support any of the POS's that get through, so I should at least know....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 18, 2008 at 9:50 pm
These are some of the questions I would ask:
What collation should be used?
Any unicode columns?
Anything that will interfere with replication or require a certain setup?
What is required in the way of database security? (exec rights on procs, reader/writer rights, application roles, login ids etc).
What processes are there in the event of you finding poor code or having performance problems?
Are there any scheduled SQL jobs?
Are there recommendations for maintenance, filegroups, hardware setup?
How often are updates / patches released?
I'm sure there are plenty more.
Try to get a technical contact with the vendor and eliminate the need to go through half a dozen people for each simple question.
February 19, 2008 at 7:46 am
Also, do not give them the SA account. You can create an account with the required rights for this.
just my $0.02
February 19, 2008 at 7:50 am
One last thing I'd say is that you should push to get your questions answered now. Once the check is written, technical information might be hard to get.
February 19, 2008 at 8:33 am
I agree with Steve here. Before the Check is signed, you might (Might is stressed here) be able to change the user permissions on the objects. There are times when the Vendor will say that the user that connects to the Database should be the DB Owner. And I have big big issues with that. I wouldnt even want to give rights to select from table directly for that user.
-Roy
February 19, 2008 at 8:59 am
Matt Miller (2/18/2008)
Jeff Moden (2/18/2008)
Heh... do be a bit careful... my questions, although certainly appropriate, are likely to be taken as a high insult. π I know this because new vendors I try to bring on board are subjected to those same questions... they're always insulted, at first.All due respect, but for the money I've seen shelled out on POS'es (and no - I didn't mean Point Of Service there...:)) - they can answer some questions. I mean - if there's at least high five digits on the check, then they'd BETTER answer some questions.
I usually start low - like -
- what is Normalization (40% of the systems I've seen aren't even close, so it's not as silly a question as you think). If you get a confused look back - don't walk - RUN AWAY. Also the "it's a pain in the A$$ thingie a DBA we fired used to talk about" answer is not a good sign.
- what process do you have in place to keep this database tuned ("the data tunes itself" is a really BAD answer).
- How does this play with Reporting services/external feeds? Is there a Data Dictionary (yes - the mainframe term) available describing what the tables do?
- How do you maintain DRI? (again - confused looks or "we don't" or "our Code does that" aren't the right answers)
I mean - the rest is nice and all - but I "get" to support any of the POS's that get through, so I should at least know....
Here I am, trying to practice some of those fancy-dancy soft skills that my company has been trying to drill into my head, and you just come right out and say exactly what I wanted to say in the first place π
I absolutely agree and it's a bloody shame we're not actually working on the same team, Matt.
You an ex submarine sailor by any chance? π
--Jeff Moden
Change is inevitable... Change for the better is not.
February 19, 2008 at 9:02 am
I'll agree with some things that have already been said.
Ask them whether their app support 64 bit and SQL Server 2005. I have old 2000 servers that I cannot convert either because some of my third party vendors won't support 2005 or 64 bit or both. Using them anyways, though they may technically work, may violate your support contract.
I agree with letting nothing run under sa. It is insecure and can make server maintenance a pill.
I also get really pissy if they want their application ids to have dbo privileges in production. If they aren't actually creating objects on the fly as apart of their application then there is no reason for it.
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply