Oracle DBA Checklist

Index I. Daily Procedures

* * *

A. Verify all instances are up

B. Look for any new alert log entries C. Verify DBSNMP is running

* * * *

D. Verify success of database backup

E. Verify success of database archiving to tape

F. Verify enough resources for acceptable performance G. Read DBA manuals for one hour II. Weekly Procedures


* * * *

A. Look for objects that break rules

B. Look for security policy violations

C. Look in SQL*Net logs for errors, issues D. Archive all Alert Logs to history E. Visit home pages of key vendors III. Monthly Procedures

* *

* *

A. Look for Harmful Growth Rates B. Review Tuning Opportunities C. Look for I/O Contention D. Review Fragmentation




usually $ORACLE_BASE/<SID>/bdump. go to the background dump destination.log. Make sure to look under each managed database's SID. Daily Procedures B. References * I. Use 'telnet' or comparable program. The recovery log is in <file>. Log into each instance and run daily reports or test scripts. B. Log on to each managed machine to check for the 'dbsnmp' process. use the Unix ‘tail’ command to see the alert_<SID>. II. Project Performance into the Future F. restart DBSNMP. If any ORA-errors have appeared since the previous time you looked.E. Verify success of database archiving to tape D. or otherwise examine the most recent entries in the file. o o o Look for any new alert log entries Connect to each managed system. Verify DBSNMP is running 1. For Unix: at the command line. At the prompt. Some sites may wish to automate this. Perform Tuning and Maintenance IV. Daily Procedures A. Optional implementation: use Oracle Enterprise Manager's 'probe' event. For each managed instance. . note them in the Database Recovery Log and investigate each one. Weekly Procedures V. There should be two dbsnmp processes running. If not. o o A. type ps –ef | grep dbsnmp. Verify enough resources for acceptable performance 1. Verify free space in tablespaces. B. Verify success of database backup C. Verify all instances are up Make sure the database is available. Appendix * * * * * A.

As of <date>.sql b. Identify bad growth projections. Compare to the minimum free MB for that tablespace. if any object reached 200 as the number of current extents. That view’s STATUS field is less accurate than V$ROLLSTAT. upgrade the max_extents to unlimited.sql to check percentage free in tablespaces. a. verify that enough free space exists in each tablespace to handle the day’s expected growth. Then we can use ALTER TABLESPACE <tablespace> COALESCE. and average daily growth can be calculated. For example. except in some cases you may have a special rollback segment for large batch jobs whose normal status is OFFLINE. Look for segments in the database that are running out of resources (e. If we get such object. as it lacks the PENDING OFFLINE and FULL statuses. Space-bound objects’ next_extents are bigger than the largest extent that the tablespace can offer. To check current extents. first need to investigate the situation. extents) or growing at an excessive rate. then the minimum free space should be at least <time to order. Go to each instance. run space. Note any low-space conditions and correct. 2. Go to each instance. and install more disks> days’ data growth. not OFFLINE or FULL. a. For storage parameters and names of ALL rollback segment. the minimum free space for <repeat for each tablespace>: [ < tablespace > is < amount > ]. run free. 3. Verify rollback segment. get. Query growth trends 4.g. Or add another datafile. Status should be ONLINE. Note any lowspace conditions and correct. Query current table sizing information d. Identify space-bound objects. query on V$ROLLSTAT.For each instance. b. b. When incoming data is stable. query on DBA_ROLLBACK_SEGS. run daily_01. Compare to the minimum percent free for that tablespace. however. For current status of each ONLINE or FULL rollback segment (by ID not by name). showing these as OFFLINE and ONLINE respectively. Space-bound objects can harm database operation.sql to check free mb in tablespaces. Optional: each database may have a list of rollback segment names and their expected statuses. . Query current index sizing information e. run nr_extents. The storage parameters of these segments may need to be adjusted. To gather daily sizing information.sql c. c. a.

B. C. Run spacebound. .sql. Run nonuPK. As of 12/14/98. trade journals. etc. I. run obj_coord. Read DBA manuals for one hour Nothing is more valuable in the long run than that the DBA be as widely experienced. c. To check settings for NEXT_EXTENT. as possible. Server side logs Archive all Alert Logs to history 3. a. II. which should match the tablespace default for NEXT_EXTENT. 400 is the maximum CPU utilization because there are 4 CPUs on phxdev and phxprd machine.html =>system metrics=>CPU utilization page.a. 5.sql.) have an automated check to verify that the policy is being followed. To check CPU utilization. a. To check existing extents.sql. E. To check other object consistency. and as widely read. and possibly newsgroups or mailing lists. run nextext. Weekly Procedures A. a. b. especially test and production. run disPK. DATALO is 500 mb (524288 bytes). All tables should have unique primary keys. Schemas should look identical between environments. 4. Look for objects that break rules For each object-creation policy (naming convention. Every object in a given tablespace should have the exact same size for NEXT_EXTENT.sql. Client side logs 2. D. Readings should include DBA manuals. zero rows will be returned. network or disk resources. b. b. default NEXT_EXTENT for DATAHI is 1 gig (1048576 bytes). go to x:\web\phase2\default. issues 1. All primary key indexes should be unique. Look for security policy violations Look in SQL*Net logs for errors. To check data type consistency. and INDEXES is 256 mb (262144 bytes).sql.sql 2.sql. To check disabled PK. Processes to review contention for CPU. run datatype. To check missing PK. run no_pk. run existext. a. Run mkrebuild_idx.sql to check. We need to investigate if CPU utilization keeps above 350 for a while. memory.sql. All indexes should use INDEXES tablespace. If all is well. storage parameters. 1.

Compare performance trends to Service Level Agreement to see when the system will go out of bounds III. 2. Review database file http://technet. 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 http://www. This may include scheduled down time or request for additional resources. C. Look for I/O Contention Perform Tuning and Maintenance 1. Compare to past output to identify trends that could lead to possible contention.). Review changes in segment growth when compared to previous reports to identify segments with a harmful growth rate. Review common Oracle tuning points such as cache hit ratio. row chaining.E.sun. E. Look for Harmful Growth Rates 1. Quest Software http://www. latch contention. Oracle Corporation http://www. Review Fragmentation 1. Sun Microsystems http://www. . Investigate fragmentation (e. D. Monthly Procedures A. etc. Project Performance into the Future 1. Compare reports on CPU. 3.quests. Make the adjustments necessary to avoid contention for system memory. IV. and other points dealing with memory management.oramag.g. Review Tuning Opportunities 1. Compare with past reports to identify harmful trends or determine impact of recent tuning adjustments. Visit home pages of key vendors 1. B.

sum ( blocks ) as free_blk . and allocated space within a tablespace --.Minimum amount of free space -. Free.To verify free space in tablespaces -.<tablespace_name> = <amount> m -SELECT tablespace_name.To check free.sql --. max ( bytes ) / (1024) as big_chunk_k. Daily Procedures 1.sql --. VI.sql --. largest_free_chunk .free. trunc ( sum ( bytes ) / (1024*1024) ) as free_m .sql --. Appendix count (*) as num_chunks FROM dba_free_space GROUP BY tablespace_name 2. Space. pct_free.11/24/98 SELECT tablespace_name.document your thresholds: -.

count(blocks) AS nr_free_chunks . max(blocks) AS largest_free_chunk . Daily_01. '09. sum_alloc_blocks.. ( SELECT tablespace_name AS fs_ts_name . . sum(blocks) AS sum_free_blocks FROM dba_free_space GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name 3. END . sum(blocks) AS sum_alloc_blocks FROM dba_data_files GROUP BY tablespace_name ) . to_char(100*sum_free_blocks/sum_alloc_blocks.To analyze tables and indexes --.daily_01.99') || '%' AS pct_free FROM ( SELECT tablespace_name . sum_free_blocks . 5 ) .11/30/98 BEGIN dbms_utility.sql --. 'ESTIMATE'.sql --.analyze_schema ( '&OWNER'. NULL. nr_free_chunks.

segment_name ./ 4.owner. dba_segments s WHERE e. nr_extents.sql --. s.segment_name GROUP BY e.90') as MB FROM dba_extents e . '999.To identify space-bound objects.segment_type . .nr_extents. no rows are returned.segment_name .count(*) ) < &&THRESHOLD ) ORDER BY count(*) desc 5. e. e. e.999. If all is well.max_extents HAVING count(*) > &THRESHOLD OR ( ( s. to_char ( sum ( e.spacebound. e. count(*) as nr_extents . s.owner.sql --.segment_name = s. and manually upgrade it to allow unlimited -.To find out any object reaching <threshold> -.sql -.max_extents (thus only objects we *expect* to be big -.sql --.11/30/98 SELECT e.bytes ) / ( 1024 * 1024 ) .extents.max_extents .segment_type .are allowed to become big) --. -- spacebound.max_extents .

next_extent > f. -.Lastly.tablespace_name = a.next_extent.-. --.tablespace_name AND a. look at value of NEXT extent -.big_chunk B. nextext. a. which should also be the tablespace's -. ( SELECT tablespace_name.11/30/98 SELECT a.If any space-bound objects are found. -.table_name. -.sql --.size to figure out what happened.To find tables that don't match the tablespace default for NEXT extent.use the exact same value for NEXT.default value for NEXT.The implicit rule here is that every table in a given tablespace should -. Weekly Procedures 1. add another datafile to the tablespace if needed.sql --. a.). max(bytes) as big_chunk FROM dba_free_space GROUP BY tablespace_name ) f WHERE f. -- .nextext.tablespace_name FROM all_tables a.Then use coalesce (alter tablespace <foo> coalesce.

ds.To check existing extents --.the tablespace's default size. your free space is likely to become fragmented.sql --. segment_type.existext. --.this tablespace is a candidate for reorganizing.next_extent as Actual_Next . existext.owner = UPPER ( '&OWNER' ) ORDER BY tablespace_name. dt.tablespace_name AND dt. --. dba_segments ds WHERE dt. -.sql --. segment_type. count(*) as nr_exts .tablespace_name = ds.12/15/98 SELECT segment_name. dt.next_extent AND ds.tablespace_name. If this report shows a lot of different -. If so.11/30/98 SELECT segment_name.sized extents. segment_type . segment_name 2.next_extent !=ds.next_extent as Default_Next FROM dba_tablespaces dt.-.This tells us what the setting for NEXT is for these objects today.This tells us how many of each object's extents differ in size from -.

next_extent as dflt_ext_size FROM dba_tablespaces dt.1) ) as nr_illsized_exts . dt.sql -- .sql --. disPK. dba_extents dx WHERE dt. segment_type. dt.0.tablespace_name.tablespace_name = dx.no_pk.dt.tablespace_name. sum ( DECODE ( dx.next_extent.bytes..To find tables without PK constraint --. dt.sql --.owner = '&OWNER' GROUP BY segment_name. No_pk. dt.next_extent 3.11/2/98 SELECT table_name FROM all_tables WHERE owner = '&OWNER' MINUS SELECT table_name FROM all_constraints WHERE owner = '&&OWNER' AND constraint_type = 'P' 4.tablespace_name AND dx.

To find tables with nonunique PK indexes.constraint_name.tablespace_name. but runs more slowly. i.sql --. uniqueness FROM all_indexes WHERE index_name like '&PKNAME%' AND owner = '&OWNER' AND uniqueness = 'NONUNIQUE' SELECT c.To find out which primary keys are disabled --. Requires that PK names -.-. An alternative query follows that -. nonuPK.uniqueness FROM all_constraints c . all_indexes i . table_name. constraint_name.disPK. table_name. status FROM all_constraints WHERE owner = '&OWNER' AND status = 'DISABLED’ AND constraint_type = 'P' 5. i.11/2/98 SELECT index_name.sql --.follow a naming convention. --.sql --.11/30/98 SELECT owner.does not have this requirement.nonuPK.

sql --.sql --.uniqueness = 'NONUNIQUE' AND c.WHERE c. 'tablespace INDEXES storage ( initial 256 K next 256 K ) .index_name = c.sql --.sql --.datatype.11/2/98 SELECT 'alter index ' || index_name || ' rebuild ' .constraint_type = 'P' AND i. datatype.Rebuild indexes to have correct storage parameters --. ' FROM all_indexes WHERE ( tablespace_name != 'INDEXES' OR next_extent != ( 256 * 1024 ) ) AND owner = '&OWNER' / 7.owner = UPPER ( '&OWNER' ) AND i.To check datatype consistency between two environments -- .mkrebuild_idx. mkrebuild_idx.constraint_name 6.

data_precision. column_name.second environment WHERE owner = '&OWNER2' order by table_name. nullable FROM all_tab_columns -. data_length. data_length. column_name. data_type. data_type.11/30/98 SELECT table_name. column_name .-. nullable FROM all_tab_columns@&my_db_link -. data_scale.first environment WHERE owner = '&OWNER' MINUS SELECT table_name. data_precision. data_scale.

object_type FROM user_objects@&my_db_link VII. Cox. David Database Management from Crisis to Confidence [http://www.8.europa. Cook.sql --. Thomas B. object_type FROM user_objects MINUS SELECT object_name.To find out any difference in objects between two instances --. The Database Administration Maturity Model . References 1.sql -. Loney. -- obj_coord. Kevin Oracle8 DBA Handbook 2.obj_coord.12/08/98 SELECT] 3.

Sign up to vote on this title
UsefulNot useful