October 12, 2010 at 12:25 pm
Hi,
I work in a shop that did not document servers, instances, databases and other objects. I'm trying to make it a little easier to work around here by creating documentation that will be beneficial for:
Moves - moving a database from old to new servers requires knowing all of the client objects that it supports (both input and output). Reports, Applications, Linked Servers, app to app interfaces. This is a real pain without some type of maintained registry.
Upgrades - database changes that could affect other apps or reports.
Decommission - Core application no longer needed - delete/clean up all processes that provided or relied on its data.
Replacement - Application being replaced - many reports, jobs, applications that are served may be incorporated in the replacement and others would need to be changed.
It seems like there should be a standard or best practice way of doing this. We're thinking of either having a relational database that connects all objects one way or another with the expectation that we always keep this DB up to date or we simply have a "registration" document for each database and server and require these documents to be kept up to date.
Clearly this becomes an issue for everyone and I was wondering if you had suggestion or better yet - know of any software that could purchase that would help us manage this.
Thanks.
October 13, 2010 at 12:43 am
We've never found any software that could do the trick, so we made a repository DB with all the info we could gather.
We try to make all the info gathering and updating as automatic as possible so the only thing we have to fill are new server name, new DB owner (email/phone) and dependance between DBs.
October 13, 2010 at 4:30 am
Thanks for the reply. I'm well into developing the same thing - a database having all physical servers and vm, all instances, all databases, all applications. I have SSRS reports that allow you to select an app and it shows server (App, file, SQL) dependencies. SQL physical file and backup locations blah blah blah. Then I ran into linked server surprises and orphaned Stored Procedures and started thinking about tracking them as well and my head exploded. Sounds like it might be the only way.
Sometimes I think I've gotten a little obsessed until I run into a problem when doing an upgrade or move and wish I had this information. We only have about 10 instances and probably less than 100 databases so when I think about some of the companies having 100's of servers and dozens of developers I figure this problem may have been solved commercially.
Guess I'll continue.
Thanks again
October 13, 2010 at 7:39 am
I work in a company with 100's of sql server and no comercial application solves all the problem, we always end up making our own procedures (repository, monitoring, alerting).
Even the big ones like Idera or Msft have massive flaw that make them totaly unusable in any big and secure environment.
And once you have enough servers it's just plain cheaper to make it yourself than buying it.
October 13, 2010 at 4:28 pm
This sounds similar to what MS wants to do with data-tier applications in SQL 2008 R2.
Understanding Data-tier Applications
Joie Andrew
"Since 1982"
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply