A. Verify all instances are up
Make sure the database is available. Log into each instance and run daily reports or test scripts.
Make sure the database is available. Log into each instance and run daily reports or test scripts.
B. Look for any new alert log
entries
. Connect to each managed system.
. For each managed instance, go to the background dump destination, usually $ORACLE_BASE/ /bdump. Make sure to look under each managed database's SID.. If any ORA-errors have
C. Verify DBSNMP is running
D. Verify success of database backup
E. Verify success of database archiving to DR.
F. Verify enough resources for acceptable performance
. Connect to each managed system.
. For each managed instance, go to the background dump destination, usually $ORACLE_BASE/ /bdump. Make sure to look under each managed database's SID.. If any ORA-errors have
C. Verify DBSNMP is running
D. Verify success of database backup
E. Verify success of database archiving to DR.
F. Verify enough resources for acceptable performance
1. Verify free space in tablespaces.
For each instance, verify that enough free space exists in each tablespace to handle the day's expected growth. As of , the minimum free space for : [ < tablespace > is < amount > ]. When incoming data is stable, and average daily growth can be calculated, then the minimum free space should be at least days' data growth.
2. Verify rollback segment.
Status should be ONLINE, not OFFLINE or FULL, except in some cases you may have a special rollback segment for large batch jobs whose normal status is OFFLINE.
a) Optional: each database may have a list of rollback segment names and their expected statuses.
c) For storage parameters and names of ALL rollback segment, query on DBA_ROLLBACK_SEGS. That view's STATUS field is less accurate than V$ROLLSTAT, however, as it lacks the PENDING OFFLINE and FULL statuses, showing these as OFFLINE and ONLINE respectively.
3. Identify bad growth projections.
Look for segments in the database that are running out of resources (e.g. extents) or growing at an excessive rate. The storage parameters of these segments may need to be adjusted. For example, if any object reached 200 as the number of current extents, AND it's an object that is supposed to get large, upgrade the max_extents to unlimited.
Look for segments in the database that are running out of resources (e.g. extents) or growing at an excessive rate. The storage parameters of these segments may need to be adjusted. For example, if any object reached 200 as the number of current extents, AND it's an object that is supposed to get large, upgrade the max_extents to unlimited.
a) To gather daily sizing
information, run analyze5pct.sql. If you are collecting nightly volumetric,
skip this step.
b) To check current extents, run nr_extents.sql
c) Query current table sizing
information
d) Query current index sizing
information
e) Query growth trends
G. Copy Archived Logs to Standby Database and Roll Forward
G. Copy Archived Logs to Standby Database and Roll Forward
If you have a Standby Database, copy the appropriate Archived Logs to the expected location on the standby machine and apply those logs (roll forward the changes) to the standby database. This keeps the standby database up-to-date.
The copying of logs, the applying of them, or both, can in some cases be automated. If you have automated them, then your daily task should be to confirm that this happened correctly each day.
H. Read DBA manuals for one hour
Nothing is more valuable in the long run than that the DBA be as widely experienced, and as widely read, as possible. Readings should include DBA manuals, trade journals, and possibly newsgroups or mailing lists
No comments:
Post a Comment