This document describes the process for making changes to database. This policy has to be observed for all DBCs on production databases.
The following actions qualify as a DBC:
· Any change to any schema segment, sequence, database or user on a database (alter, drop, create)
· Changing a database parameter
· Flushing or calculating segment statistics
The DBC contents will contain the nature of changes and their frequency. e.g. if one table was being altered, two created, a users password changed and an index being created the DBC Contents would be:
ALTER TABLE 1
ALTER USER 1
CREATE TABLE 2
CREATE INDEX 1
Details of the changes will be made available on a need to know basis.
· Senior DBA
· Network Engineer
· System Administrator
· Manager of System Development (usually the one that requested the change)
· QA Manager
To facilitate the scheduling of DBCs there will be certain time windows during which DBCs will normally be scheduled. All teams involved in a DBC Cycle will be responsible to ensure that they have the minimum amount of resources from their team available during these windows. Due to lower traffic it is safer to set these windows earlier in the day, so the DBC windows will be set as follows:
Monday 1000 - 1100
Tuesday 1000 - 1100
Wednesday 1000 - 1100
Thursday 1000 - 1100
Friday 1000 - 1100
1. The DBA Team will send out an email to schedule a DBC, the subject of the email will be DBCID - SCHEDULE where the DBCID is composed of the date, time and DBC number for that day. e.g. the third DBC on Jan 1 2001 at 4pm would have a DBC ID of 20010101-1600-03. This email will contain a short description of the nature of the DBC. It should also contain any possible problems that might arise, if any are known.
2. The DBA Team will ensure that all parties required respond to the schedule email and confirm. The parties required to reply are the people required for a DBC. The reply should contain confirmation for the schedule, asserting that they would be present for the DBC. E.g. only one Network Engineer needs to confirm since thats the minimum number of Network Engineers required for a DBC. The reply should be only to the sender of the schedule email.
3. Upon receipt
4. The DBA Team will send out another email with an ETA, the subject of this email will be DBCID - ETA where the ETA will not be greater than 5 minutes. The email will also contain an approximate time it would take to complete the changes.
Note: An ETA of five minutes would imply that changes would start in five minutes. The email will include an approximate time it would take to complete the changes
5. Upon receiving the ETA email all parties will reply to the email confirming that they have started monitoring all systems closely
6. The DBA Team will make the DBC at the appointed time
7. The DBA Team will send out an email informing everyone of the success or failure of the change, the subject of the email will be DBCID - RESULT
8. All parties should closely monitor all systems for at least 15 minutes after the DBC
9. QA manger should QA site
10. 15 minutes after the DBC all parties[1] should send email verifying that no problems were found. The subjects of the emails should be as follows:
DBA Team DBCID SIGNOFF DBA
Network Eng. DBCID SIGNOFF NETENG
Sys. Admin. DBCID SIGNOFF SYSADMIN
Mgr. Sys. Dev. DBCID SIGNOFF APPDEV
QA DBCID SIGNOFF QA
11. DBA Team will ensure that all parties signoff
12. DBA Team will send out an email containing a summary of the DBC Cycle, the subject of the email will be DBCID SUMMARY
The summary email will contain the following information:
· Short Description of DBC
· People involved (names and group)
· Time of change
· Result of change (success or failure)
· Any problems that might have come up and what measures were taken to rectify them
1. A DBC is considered open starting with the ETA email until the SUMMARY email is sent out
2. Two DBCs should not be open at the same time
3. Schema Changes to the production databases should be scheduled at least one business day in advance