November 15, 2011 at 11:11 am
Our lucky DBA group gets to support a wide variety of 3rd party applications/systems in addition to some internal ones. We have minimal input into what third party stuff is brought in-house and very often we don't know until the last minute that it will require our resources. We are working on plans to improve this process and as part of it, we're coming up with a checklist/questionnaire for the business to fill out when they do bring in a new (or modified) solution.
I can find all kinds of checklists online for installing or designing a new DB but not one that really addresses this. So I've come up with one and would appreciate feedback.
Brief note on our setup without getting too technical: The SQL Server DB applications are either in-between two other systems or are for customer-facing solutions (web portals mostly). The "main" system in-house is a DB2 "warehouse" from which many of our SQL Server-based applications pull data and to which they send data. These systems are very interconnected / interdependent and ETL of various sorts is a large part of our job.
So here's the basic checklist:
(Note that this is specific to SQL Server requirements, the infrastructure takes care of the networking, server, etc. questions.)
What are the minimum hardware and software requirements for this solution. Has this been verified against our company's minimum standards?
If using an existing database:
external or internal users
Read and/or write access
New groups
New security requirements
Estimate of increased traffic level
Any changes to existing structures
New DB’s:
Purpose
External/internal users
Security requirements
Estimated amount of data growth
Data retention policy
Estimated usage level
What are your reporting needs?
Will information from another system (i.e. the DB2 warehouse) need to be loaded?
Will it need to be maintained/updated? At what frequency?
Will information from this system need to be loaded/transferred to any other systems?
Will it need to be maintained/updated? At what frequency?
Will this involve technology such as mirroring, replication, log shipping, Analysis Services, Reporting Services, Integration services?
Thanks!
(We'll be coming up with a completely different checklist for changes to other systems which may impact SQL Server. But that's more of an internal thing)
November 15, 2011 at 11:55 am
That seems like a reasonable start. I'm not sure I'd trust my end/business users to know about what administrative technologies they'll need though. It's not really their job to know if a mirrored snapshot or transactional replication would be better for their requirements, that's our job.
One of the things, particularly with 3rd party apps, that you can't address until the system's in use is network and spindle traffic. Horribly designed, poorly indexed vendor apps that thrash around your server like drunken eels will never let you estimate properly.
One of the things we used to do was setup virtual 'staging' servers for new apps as they came online. They'd get themselves a dedicated server and hard monitoring for the first week or two. Once we had that baseline for real usage and expectations, we'd know which, if any, of our existing hard servers we'd bring that database into so it wouldn't cause an accidental overload on existing systems.
Other than that, you might want to inquire about expected SLAs. Is this a 24/7 app, or a workday only app. This helps you nail down maintenance windows and job failure priorities.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
November 15, 2011 at 12:03 pm
Thanks, Craig. SLA's are handled in the main IT intake form. We're just expanding the database part. And yes, when we can (which isn't always possible due to the last-minute inclusion of us DB folks), we do indeed mandate a full deploy cycle with full testing - development, integration, acceptance and production.
I'm explicit on the additional technologies (replication, log shipping, etc.) because we've been burned before by vendor-supplied solutions mandating certain tech. (One idiot vendor mandated clustered virtual servers amongst other horrors.) The sooner we know about this, the sooner we can address the issues.
November 15, 2011 at 12:06 pm
Pam Brisjar (11/15/2011)
Thanks, Craig. SLA's are handled in the main IT intake form. We're just expanding the database part. And yes, when we can (which isn't always possible due to the last-minute inclusion of us DB folks), we do indeed mandate a full deploy cycle with full testing - development, integration, acceptance and production.I'm explicit on the additional technologies (replication, log shipping, etc.) because we've been burned before by vendor-supplied solutions mandating certain tech. (One idiot vendor mandated clustered virtual servers amongst other horrors.) The sooner we know about this, the sooner we can address the issues.
Ah hah! Sorry bout that, didn't realize this was also for vendors to dictate requirements. Then yes, I'd leave that part in. You might make sure the language explains to your internal business folks when requesting a DB to be put into play that they speak with a technician if they are unsure if this form is to be generic.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
November 18, 2011 at 11:16 am
Some items imposed on us by third-party apps that have caused trouble:
1. Is your application able to connect to a named instance?
2. What are your network protocol requirements? TCP/IP, Named Pipes, etc.
3. Does your application create new databases as part of its normal operations? If so, please provide the template you use for creating new databases (e.g. AUTO_CLOSE ON/OFF, AUTO_SHRINK ON/OFF, Collation, etc.)
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
November 18, 2011 at 11:22 am
Good questions. Don't think I'll put these on the questionnaire given the tech skills (or rather lack thereof) of the audience but they're definitely good ones to keep in mind.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply