Post reply

Retiring DB

  • October 16, 2011 at 8:34 pm

    #246660

    I tried to find article on retiring DBs, but couldn't anything good... Any suggestion please? Any checklist that I can take a look for retiring the DB? Thanks!

  • October 17, 2011 at 2:26 am

    #1395178

    what do you mean by retiring?

  • October 17, 2011 at 2:55 am

    #1395192

    It's my checklist. Please feel free to add your points.

    •Create a FULL backup of database.

    •Create scripts for relevant Jobs, Logins etc

    •Take database offline, for some time. (You will find that someone will comeback & ask for the database :-D).

    •Once satisfied, declare ‘the database is officially retired (& will be deleted)’ to team members & management.

    •Give yourself some more time and then DROP the database.

  • October 17, 2011 at 3:36 am

    #1395203

    @dev: what is the use of doing that, is this means DB tiring?

  • October 17, 2011 at 3:45 am

    #1395205

    Please clarify what is the purpose of retiring a database?

    You couldn't find anything related on the web, because it's not common thing.

    Upgrade, Migration are the things people do.

    Usually keeping backups of old database helps.

  • October 17, 2011 at 3:59 am

    #1395209

    ghanshyam.kundu (10/17/2011)

    @DEV: what is the use of doing that, is this means DB tiring?

    I assume OP requested the steps to be followed before making a database unavailable (on PROD box) to users / applications.

  • October 17, 2011 at 4:04 am

    #1395210

    Please clarify what is the purpose of retiring a database?

    You couldn't find anything related on the web, because it's not common thing.

    Agree it's not a common term. But my BOSS uses it quite often. :hehe:

  • October 17, 2011 at 8:34 am

    #1395370

    Dev @ +91 973 913 6683 (10/17/2011)

    It's my checklist. Please feel free to add your points.

    •Create a FULL backup of database.

    •Create scripts for relevant Jobs, Logins etc

    •Take database offline, for some time. (You will find that someone will comeback & ask for the database :-D).

    •Once satisfied, declare ‘the database is officially retired (& will be deleted)’ to team members & management.

    •Give yourself some more time and then DROP the database.

    I think this is the best route. The key is to make sure that you can get it back to its original state easily when someone realizes that they weren't really ready to retire it. 🙂

    Thanks,

    Jared

    Jared
    CE - Microsoft

  • October 18, 2011 at 1:22 am

    #1395718

    You might want to search for "decommission" or "decommissioning" as well. After a merger last year we had a few systems to retire/decommission and one aspect to consider were legal requirements and requirements from tax authorities. Depending on the type of data you are obliged to keep it for several years (retention period) and this pretty much defines the technical options you have.

    Here my search which should give you some ideas: http://tinyurl.com/6db3qkx

  • October 18, 2011 at 1:30 am

    #1395719

    Here my search which should give you some ideas: http://tinyurl.com/6db3qkx

    Caution: The link is suspicious.

  • October 18, 2011 at 2:02 am

    #1395732

    Are you kidding me? The link might be suspicious but the intention isn't :alien:

    You'll end up here: http://www.google.com/search?btnG=1&pws=0&q=%27decommission+database%27

  • October 19, 2011 at 6:53 am

    #1396609

    I like Dev's checklist. By setting a database offline, you are able to quickly get it back in place if you overlooked something and it is still needed.

    The first time that we set a database offline, I found out that my backup script failed when it tried to take a backup of an offline database. Now my backup script checks that the database is online first.

  • October 19, 2011 at 8:22 am

    #1396662

    I like Dev's checklist.

    Thank You.

  • October 19, 2011 at 10:21 am

    #1396774

    I think that Dev has a good list. The thing I might do as well is take the script you have for jobs/logins/etc and stick it in an admin table before the backup. Use a single table, a varchar(max) col. I'd also stick a column for @@Version and store that in there as well.

    Over time it's easy to lose track of supporting items.

  • October 20, 2011 at 12:12 pm

    #1397599

    Sending out a broadcast email asking if it's OK to retire a database is good, but depending on the size and organization of the IT department, it's entirely possible for BI contractors, legacy applications or ETL processes sitting in the basement somewhere who are still hitting the database but won't receive or respond to the email.

    So, run a SQL Profiler trace on the login event for a few weeks to confirm who's really using that database.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic. Login to reply