#Database part 2 how to#
#Database part 2 archive#

#Database part 2 how to#

She explains why they are important and how to think about them when you are creating an Elastic Job. Remove from ev monitoring tools, backup management, statistics collection, central management, repositories etcĭepending on company requirements, you should probably do some form of archiving or handover to system owners etc. In the second part of this two-part video series, Kate Smith discusses what two things you should understand before beginning with Azure SQL Database Elastic Jobs: Idempotence, and Credentials.Make a final DB backup, save it down for archiving along with the above script.Script out any sql jobs, replication, mirroring and other things related to the database.Script out logins (use Microsoft's Transfer logins script and passwords will be included).a month, we should proceed according to the list below:

#Database part 2 archive#

However, may also affect other accesses to other databases that should not be decommissioned.ĭelete and archive database and associated objectsĪfter the database has been closed or in restricted access mode for some time, e.g.

Delete/disable logins linked to users in the database.

2 6.1 Introduction to Database At the end of. Allows access only to the db_owners and sysadmin/db_creator server roles. 1 TOPIC 6 DATABASE 6.1 Introduction to Database 6.2 Basic Concept of Database 6.3 Database Object DATABASE 2.

Set the database to RESTRICTED_USER mode.

The database is completely closed, not accessible until it is put ONLINE again. There are a few different ways we can restrict access but still get the database up and running quickly if we need to: Don't forget to remove the database from the monitoring, statistics and backup management tools so that it doesn't flash red at colleagues unnecessarily. In the documentation/CMDB a note should be made that the database will be decommissioned shortly. We will also remove these later so it's just as well to document everything like that now, also take the opportunity to inform everyone involved about the timetable for the decommissioning. When we have established with one or more of the methods in part 1 or otherwise that the database is not being used, we probably want to shut down the database or restrict access for a few weeks, important that we also look at what objects outside the database are related, eg logins, sql jobs, replication, mirroring etc and shut these down.

The routine should also fit in with the company's backup and archiving procedures. One tip is to have ready-made routines, or processes as they are so nicely called these days, that fit in with the customer or organisation you are working with. Usually no one is very keen to take responsibility for what happens if the database is actually used, even if only once a year, etc. I find decommissioning databases quite boring myself, you have to look for the right people, nag and remind. In part 1 we looked at some different techniques to see if the database was being used, now we will move on to look at different practices to decommission the database in a good way. SQL Server - Decommissioning a database part 2