Checklist for Successful Implementation of DB Change
Checklists for Oracle Database change requests(CRs).
Pre-Implementation Checks
1) OS/Database/schema valid Backups to be taken before the activity
- Check if OS/Database/schema valid Backups have been taken (Y / N)
- follow the link to verify backups Query to display FULL and INCR backup details of DB
2) Take the preimage of the dbs./listeners/invalid objects/OS space usage/dbspace usage
script to verify oracle tablespace usage
- Check if pre-image has been taken? (Y/N)
- follow the link to verify the preimage Script for DB Services and ASM Disk info
3) Backup of cronjobs and oratab entries
- Has the backup of cronjobs and oratab entries completed? (Y/N)
4) run the pre-checks for the patching / upgrade and fix the errors if any
- Have the pre-checks been run? (Y/N)
5) Raise a pro-active SR when it is required.
- Has a pro-active SR been raised (in case of critical changes)? (Y/N).
Checks during Implementation
1) Check if the Change Request has been move to Scheduled state ? (Y/N)
Normally all techies start working on the change without checking the status and date and time . It is very important to check state and time of the change to avoid human errors.
2) Ensure the right software/patch/scripts is available in the directory
- Have the Patches/software/scripts with correct version with proper permissions were set ? (Y/N)
- Naming convention is very much important to avoid human errors. It is always better if someone shadowing in the same team for all the critical changes.
3) Set the Right environment for database/server
- Have the correct environment set for the Database ? (Y/N)
- Follow the link Command Prompts in Unix and Linux Operating systems to set the correct command prompt to avoid the human errors.
4) Change the settings/color of the Tools like Putty to RED for Production Environment
- Have the settings changed to identify the Right window for PRODUCTION BOX ? (Y/N).
- follow link to set different colors for putty Best practices/check list while doing DBA tasks
5) Use the correct passwords for server/database to avoid locking issues
- Are the right credentials used ? (Y/N)
6) Comment the backups prior to implementation
- Have the backups stopped during the major activity? (Y/N)
7) stop the OEM agent
- Have the OEM agent stopped properly during Major activities? (Y/N)
8) Suppress the alerts with blackouts/inform to monitoring team
- Have the backups blackouts enabled during the Activity for Suppressing the Incidents and other unnecessary alerts? (Y/N)
9) Monitor the logs carefully during the change execution
- Have the logs checked carefully ? (Y/N)
10) While implementing the change on one server/database, close the remaining unwanted putty sessions
- Have the other sessions closed which are not required? (Y/N)
- Especially while doing production change only putty session should be opened.
11) Ensure that change is executed in the scheduled time
- Has the change executed in scheduled time ? (Y/N)
Post Implementation Checks
1) DATABASE Availability
- Is the db and listeners are up and running fine? (Y/N)
2) Check any errors in alert logfile
- Are the logs clear from errors? (Y/N)
3) Remote database connectivity
- Is the database connecting Properly? (Y/N)
4) Uncomment backup jobs if any /Ensure that backups are happening properly
- Are the Backups Reenabled ?(Y/N)
5) Db OEM agent is up and running
- Is the OEM agent restarted? (Y/N)
6) OEM blackout disabling / Informing to the Monitoring team to resume the monitoring after the change is over
- Has the OEM blackouts and Monitoring enabled ? (Y/N)
7) Check the right version is reflected after patching/upgrade activity
- Has the validation done by checking the previous and current versions/output? (Y/N)
8) Check if that DBA validation has been completed? (Y/N)
9) Check if that application validation has been completed? (Y/N)
10) Check if the CR has been closed ? (Y/N)
See also