Richard Jones, a DBA in the UK, asked in with a question, and rather than giving my own opinion, I thought it’d be better to ask it here to get everybody’s opinion in the comments:
The DB team that I am a member of are about to take control of a number of SQL Server boxes from the Apps Support team (don’t ask why they’ve got control of them in the first place, ok). I’m trying to put together a checklist of things we need to get out of them during the handover and was wondering if you had any ideas of what I might have missed from my initial thoughts?? So far I have:
- Usernames/schemas and passwords
- Instance/Server names and whether it’s Dev/Test or Prod
- Number of users each box has (roughly)
- What app runs on each box and the criticality of it
- Backup schedules/maintenance plans/scheduled jobs
- Where the backups are written to
- Recovery model
- 3rd party contact details for support where applicable
What else would you add?
13 Comments. Leave new
Windows scheduled tasks
Data access scheme (sprocs, views, ad hoc, programs that access)
Purpose of server/data (seems silly, but it’s important to understand *why* people want the data outside of the name of an app)
I’d also emphasize Jeremiah’s data access scheme. You’ll probably be surprised (dismayed?) at how many people are accessing the databases via Access/Excel/Query Analyzer/SSMS or something else and consider it an integral part of a critical business process.
– Benchmark of performance. They might not have it, but it would be good to know what “average” performance is. I might set this up before the handover and have them verify this is correct.
– Jobs, any scheduled jobs, Agent or otherwise
– ETL stuff, linked servers, network paths accessed, any files that are imported. Need dependencies here on network items.
Perhaps it may be pertinent to find out the type of data being stored or processed. There may be compliance considerations to be addressed for example, or encryption technologies to be aware of.
Are there any current known issues with any of the platforms.
Report of what outages have occured recently and why. Any recent h/w or s/w changes. What their indexing strategy was and why.
I would also ask them who the stakeholders are in the database (application that it supports) and what the POCs are, if available.
Sometimes it’s obvious who the stakeholders are in the data the DB stores and the application it supports, but often times it isn’t. You might want to introduce yourself to those stakeholders and let them know that you will be taking over maintenance of their database. You also want to know who to notify about scheduled maintenance windows, unscheduled outages, and so forth.
– Documentation of any current development initiatives that involve the databases.
– Frontend apps – stored proc mappings
List of which internal systems are linked to each other and why. Is server A is getting data from a table in server B and how often.
These comments are all awesome, and I’m glad I didn’t try to answer this with just my own experience. You can tell by reading ’em who has suffered through specific problems recently. Ouch!
If there are any SSIS packages saved on that instance of SQL Server/SSIS Package Store?
– Any Source Control information
– Logs of the past X number of months of support calls
– Logs of the past X backups
– Last time the recovery plan was tested and its outcome
I would think that knowing what the network addresses are and how the boxes are attached to the network would be important to know for security reasons. I would also want to know what network hardware the servers are attached to and who to contact regarding the network hardware. Jerimiah also brought up a good point about Windows services I would hope that the database is hosted on its own server.
UNC Links to the networkshares of the server log, DB files and backups.
I always share these folders to have access without any tool.