Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12345»»»

9 Things to Do When You Inherit a Database Expand / Collapse
Author
Message
Posted Monday, June 22, 2009 7:26 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, August 17, 2011 7:09 AM
Points: 869, Visits: 963
Good article. I would also add having an updated data dictionary helps too.
Post #739362
Posted Monday, June 22, 2009 7:31 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 19, 2011 4:53 AM
Points: 299, Visits: 56
But doing the delet in two stages does reduce the risk a bit doesn't it??
Post #739365
Posted Monday, June 22, 2009 7:52 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, April 29, 2014 10:46 AM
Points: 89, Visits: 479
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.
Post #739384
Posted Monday, June 22, 2009 8:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, June 6, 2014 2:13 PM
Points: 147, Visits: 533
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.



Post #739394
Posted Monday, June 22, 2009 8:07 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Thursday, March 27, 2014 2:06 PM
Points: 2,608, Visits: 112
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.
Post #739395
Posted Monday, June 22, 2009 8:11 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, July 5, 2014 12:16 PM
Points: 9, Visits: 141
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
Post #739399
Posted Monday, June 22, 2009 8:19 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Sunday, December 20, 2009 12:54 PM
Points: 5, Visits: 8
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.
Post #739407
Posted Monday, June 22, 2009 8:23 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Sunday, June 22, 2014 6:53 PM
Points: 967, Visits: 388
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.

Post #739414
Posted Monday, June 22, 2009 8:39 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 10:25 PM
Points: 33,051, Visits: 15,160
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
Post #739441
Posted Monday, June 22, 2009 8:46 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: 2 days ago @ 9:52 AM
Points: 413, Visits: 392
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.
Post #739452
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse