Oracle DBA Checklist

Version 1.0 Generic

Index
I. DAILY PROCEDURES.............................................................................................................................2
A. VERIFY ALL INSTANCES ARE UP.......................................................................................................................2
B. LOOK FOR ANY NEW ALERT LOG ENTRIES..........................................................................................................2
II. NIGHTLY PROCEDURES......................................................................................................................4
A. COLLECT VOLUMETRIC DATA...................................................................................................................4
B. BACKUP TASKS .......................................................................................................................................4
C. DATA RESTORE/REFRESH.......................................................................................................................4
III. WEEKLY PROCEDURES.....................................................................................................................5
INITIATE OBJECT SANITY FOR PERFORMANCE...........................................................................................................5
LOOK IN SQL*NET LOGS FOR ERRORS, ISSUES......................................................................................................5
C. ARCHIVE ALL ALERT LOGS TO HISTORY........................................................................................................5
IV. MONTHLY PROCEDURES..................................................................................................................6
A. LOOK FOR HARMFUL GROWTH RATES............................................................................................................6
B. REVIEW TUNING OPPORTUNITIES....................................................................................................................6
C. LOOK FOR I/O CONTENTION..........................................................................................................................6
D. REVIEW FRAGMENTATION..............................................................................................................................6
E. PROJECT PERFORMANCE INTO THE FUTURE.......................................................................................................6
F. PERFORM TUNING AND MAINTENANCE.............................................................................................................6
G. UPSKILLING.................................................................................................................................................6
V. AD-HOC PROCEDURES.........................................................................................................................7
I. Daily Procedures
A. Verify all instances are up
Make sure the database is available. Log into each instance and run daily
reports or test scripts.
Eg: - Select name, status from v$database;

Future = To Use Oracle Enterprise Manager's 'probe' event.

B. Look for any new alert log entries

• Connect to each managed system.
• Use 'telnet' or windows login program.
• For each managed instance, go to the background dump destination,
usually $ORACLE_BASE/<SID>/bdump. Make sure to look under each
managed database's SID.
• At the prompt, use the UNIX ‘tail’ command to see the alert_<SID>.log,
or otherwise examine the most recent entries in the file.
• If any ORA-errors have appeared since the previous time you looked, note
them in the Database Recovery Log and investigate each one.

C. Verify enough resources for acceptable performance

• Verify tablespace utilization

For each instance, verify that enough free space exists in each tablespace
to handle the day’s expected growth. Run the orainfo.sql to check free
space
Act accordingly to over-ride any low space issues.
• Verify Space Bound Objects
Space-bound objects’ next_extents are bigger than the largest extent that
the tablespace can offer. Space-bound objects can harm database
operation. If we get such object, first need to investigate the situation.
Act accordingly to manage the growth by alternatively running
Alter Tablespace <Tablespace Name> COALESCE.
• Verify System performance
Monitor System performance for CPU, Memory and Disk utilization.
For Windows, initiate the performance logger.
For Unix, spool sar,glance,top etc utilities through the course of the day.

D. Incident Management
• Check inward request
The incident management tool has to be defined, once the request is
received via the tool or mail (whichever is the predefined method), the
 team would acknowledge the receipt of the request.

• Define level of criticality

Based on pre-defined SLA, the TAT for the request would be made
available to the requestor and criticality defined accordingly.
• Request Processing
The DBA specialist would then follow the documented steps and execute
the necessary activities.
• Notification/Reply
On completion of the task, the DBA specialist will inform the requestor on
the status of the process and location of file (incase it’s a output file
required)

E. Verify Backup status

Check the status of the scheduled backup, via logs and dump file size.

F. Verify transfer of data to Tape

Check the volume of data dumped on to tape against size of dump on disk.
Restore the backup set to disk (test server) to validate backup content.

G. Transfer of archive logs to Tape

Check and validate the archive logs to be backed to tape against the archive logs
ported over to the Standby server .
Make room on disk after the archive logs are moved on to tape.
II. Nightly Procedures
Most production databases (and many development and test databases) will benefit
from having certain nightly batch processes run. The jobs could be ad-hoc changes
via Change request (pre-defined downtime) or Data restore/refresh (no downtime
required).

A. Collect volumetric data

Analyze of Schemas and Collection of Data. The idea here is to use the more
time consuming and more accurate ANALYZE COMPUTE /ESTIMATE
command and save the results, which show up in the data dictionary, to a
more permanent store.
The output will be plotted for graphical representation of data growth and
would be used to validate procurement of disk /allocation of Logical volumes
via SAN.

B. Backup Tasks
Define the best practice for Backup of databases. The backup policy would
ideally be defined based on the recovery scenario and the availability of
media. Assuming User defined backup or RMAN is setup, the backup set
would be dumped on to a definite location on the disk.

C. Data Restore/Refresh
Based on pre-defined communication via ticket/email along with approvals,
DBA specialist to identify tape/backup dump in consultation with System
administrator along with allocated disk area for the job.
The activity/executed will be initiated via checklist follow up and on
completion of task the same would be intimated to the requestor or team for
verification.
III. Weekly Procedures

Initiate object sanity for performance

Post confirming the type of operations carried out by the client we would
run Oracle recommended operational checks to increase performance.

• Rebuild Indexes
Incase the application environment is a heavy OLTP one, then the DBA
specialist would initiate a dynamic script to Rebuild Index tree , thus
removing the dead leaves and increasing SQL performance.
• Collect Statistics
As most of the environments are running in CBO (9i onwards) mode
gathering statistical information is a key in reducing processing time and
increasing query response time.
• Object type consistency
Objects should ideally be placed in their respective repository so as to
provide better I/O. Indexes should be available in the Index tablespaces
and data tables should be in data tablepaces.We would ideally being
running the DBMS_UTILITY.COMPILE_SCHEMA packages to validate
packages if their statuses are invalid.

Look in SQL*Net logs for errors, issues

Investigate the SERVER side logs for any errors which would need
escalation or validation

C. Archive all Alert Logs to history

IV. Monthly Procedures
A. Look for Harmful Growth Rates
Review changes in segment growth when compared to previous reports to
identify segments with a harmful growth rate.

B. Review Tuning Opportunities

Review common Oracle tuning points such as cache hit ratio, latch contention,
and other points dealing with memory management. Compare with past
reports to identify harmful trends or determine impact of recent tuning
adjustments.

C. Look for I/O Contention

Review database file activity. Compare to past output to identify trends that
could lead to possible contention.

D. Review Fragmentation
Investigate fragmentation (e.g. row chaining, etc.).

E. Project Performance into the Future

Compare reports on CPU, memory, network, and disk utilization from both
Oracle and the operating system to identify trends that could lead to
contention for any one of these resources in the near future.

F. Perform Tuning and Maintenance

Make the adjustments necessary to avoid contention for system resources.
This may include scheduled down time or request for additional resources.

G. Upskilling
Log into the following sites for regular document review for new features
www.oracle.com/technology
www.metalink.oracle.com
V. Ad-hoc Procedures
• Incase there are any Ad-hoc activities like Hardware maintenance,
enhancements or upgrades the team would procure necessary approvals
indicating the time for downtime.
• For performance issues pertaining to database/instance changes, the
changes would be made effective on test environments and statistical data
would be provided accordingly before moving the changes on to
production (post approvals).
• Login to metalink.oracle.com incase of any tars that need to be escalated
to Oracle for product support.