SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


9 Things to Do When You Inherit a Database


9 Things to Do When You Inherit a Database

Author
Message
cy-dba
cy-dba
Ten Centuries
Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)Ten Centuries (1K reputation)

Group: General Forum Members
Points: 1011 Visits: 963
Good article. I would also add having an updated data dictionary helps too.
stevecurtis3
stevecurtis3
Old Hand
Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)Old Hand (303 reputation)

Group: General Forum Members
Points: 303 Visits: 59
But doing the delet in two stages does reduce the risk a bit doesn't it??
Thomas-282729
Thomas-282729
SSC-Enthusiastic
SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)

Group: General Forum Members
Points: 113 Visits: 482
I must say that from a maintenance point of view, one of the hardest skills to teach developers is the skill of removing obsolete code. Many developers simply comment old code even if it is in source control or leave it because doing an analysis of whether it is still in use takes more effort. However, from a maintenance standpoint, removing obsolete code is crucial to having a well maintained system.

In SQL Server, unfortunately, all stored procedures are effectively scoped public which makes determining obsolescence difficult. It would be nice if there were a simple way of scoping a procedure such that it could only be executed from another stored procedure and not from the outside.
Andy DBA
Andy DBA
SSC Veteran
SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)SSC Veteran (246 reputation)

Group: General Forum Members
Points: 246 Visits: 762
John Gregory (6/22/2009)

...
It sounded like you suggested deliberately causing a problem to get buy-in from your users (...sending out hundreds of thousands of emails). Perhaps I misunderstood this bit. Abusing trust is never a good long-term strategy.
...


I didn't get that impression at all. I got the impression that it might help in cost justification or work policy discussions to mention horror stories from past experiences either with the newly inherited system or other systems where development occurred against production. If it's been going on for any length of time at all, it's very likely a blunder was made at some point that upper level management wishes they could forget.
This point ties in well with mzak's point about reviewing security policies. If developers have no rights on the production system, they won't be tempted to run that poorly tested "quick fix" when nobody's looking.

Good overview article and follow-up discussion.



Jon Monahan
Jon Monahan
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3625 Visits: 162
Sylvia - nice article to get started with. I also like to look at performance monitor to get an idea of peak load on the CPU, Memory, Disk utilization, etc. And I'm a big fan of the idea of renaming objects - and keeping them for a year (if you just inherited the database and/or server). Too many objects get used for one tiny, but critical, app that gets run once per year... No point in taking any chances. After the year is up - feel free to delete all of those renamed objects.
tom.groszko
tom.groszko
Grasshopper
Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)Grasshopper (24 reputation)

Group: General Forum Members
Points: 24 Visits: 187
You said nothing about checking security. I still find SQL servers with a default blank password. Everybody who ever worked there has full access to the server.

Tom Groszko
Rick Sline
Rick Sline
Forum Newbie
Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)Forum Newbie (8 reputation)

Group: General Forum Members
Points: 8 Visits: 12
A good list. The article states - assuming you're a developer and not a dba, so the tuning issues are more on a dba's plate.

What keeps many of us up at night is not having our heads around the db well enough to understand what's going on. Performance tuning while important is not mission-critical unless there are serious user complaints.

The concept of (potentially) obsolete elements is another issue. The need to delete them is rarely mission critical, deleting something that's still needed becomes that. Yes, there can be issues with available space (large tables no longer needed) and it's a pain to wade through a bunch of no longer needed SP's, etc. My recommendation is document as many of the objects as you can where used, etc. - may take weeks or months. Anything not obviously used can get the XXX prefix treatment (or copied to an archive location) for at least a year.
Jeff Gray
Jeff Gray
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1247 Visits: 389
I would suggest verifying that the recovery model is in line with how the backups are being taken. All too often I have taken over a server that is set to the full recovery model, while there are no transaction log backups being made.
Steve Jones
Steve Jones
SSC Guru
SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)SSC Guru (62K reputation)

Group: Administrators
Points: 62266 Visits: 19102
It's a good list, though like others, I think deletion is hard one.

I'm for renaming the objects for 13 months, give time for an end of year process to come, and then roll them off month by month after that. If no one's complained in that time period, it's likely not being used. Could it be? sure, but you can script the code, include it in a backup, or even leave it in a folder on the server. Not the world plan in trying to keep a clean system over time

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
ppcx
ppcx
SSC-Addicted
SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)SSC-Addicted (443 reputation)

Group: General Forum Members
Points: 443 Visits: 437
I'd like to see this kind of article geared towards DBA's rather than developers. The Backups one would be a definite for both though.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search