應按如下方式對Oracle數(shù)據(jù)庫系統(tǒng)做定期監(jiān)控：?(1). 天天對ORACLE數(shù)據(jù)庫的運行狀態(tài),日志文件,備份情況,數(shù)據(jù)庫的空間使用情況,系統(tǒng)資源的使用情況進行檢查,發(fā)現(xiàn)并解決問題。 (2). 每周對數(shù)據(jù)庫對象的空間擴展情況,數(shù)據(jù)的增長情況進行監(jiān)控,對數(shù)據(jù)庫做健康檢查,對數(shù)據(jù)庫對象的狀態(tài)做檢查。 (3). 每月對表和索引等進行Analyze,檢查表空間碎片,尋找數(shù)據(jù)庫性能調整的機會,進行數(shù)據(jù)庫性能調整,提出下一步空間治理計劃,對ORACLE數(shù)據(jù)庫狀態(tài)進行一次全面檢查。 天天的工作: (1).確認所有的INSTANCE狀態(tài)正常。登陸到所有數(shù)據(jù)庫或例程,檢測ORACLE后臺進程: $ps –efgrep ora (2). 檢查文件系統(tǒng)的使用（剩余空間）。假如文件系統(tǒng)的剩余空間小于20%，需刪除不用的文件以釋放空間：$df –k(3). 檢查日志文件和trace文件記錄alert和trace文件中的錯誤。連接到每個需治理的系統(tǒng):使用'telnet'對每個數(shù)據(jù)庫,cd到bdump目錄,通常是$ORACLE_BASE/bdump使用 Unix 'tail'命令來查看alert_.log文件,假如發(fā)現(xiàn)任何新的ORA-錯誤,記錄并解決。(4). 檢查數(shù)據(jù)庫當日備份的有效性。對RMAN備份方式: 檢查第三方備份工具的備份日志以確定備份是否成功。對EXPORT備份方式: 檢查exp日志文件以確定備份是否成功 對其他備份方式: 檢查相應的日志文件(5). 檢查數(shù)據(jù)文件的狀態(tài)記錄狀態(tài)不是“online”的數(shù)據(jù)文件，并做恢復:Select file_name from dba_data_files where status='OFFLINE';(6). 檢查表空間的使用情況:SELECT tablespace_name,max_m,count_blocks free_blk_cnt,sum_free_m,to_char(100*sum_free_m/sum_m, '99.99') '%' AS pct_free FROM (SELECT tablespace_name,sum(bytes)/1024/1024 AS sum_m FROM dba_data_files GROUP BY tablespace_name),(SELECT tablespace_name AS fs_ts_name, max(bytes)/1024/1024 AS max_m,count(blocks) AS count_blocks,sum(bytes/1024/1024) AS sum_free_m FROM dba_free_space GROUP BY tablespace_name) WHERE tablespace_name=fs_ts_name; (7). 檢查剩余表空間: SELECT tablespace_name,sum(blocks) as free_blk,trunc(sum(bytes)/(1024*1024)) as free_m, max(bytes)/(1024) as big_chunk_k,count(*) as num_chunks FROM dba_free_space GROUP BY tablespace_name; (8). 監(jiān)控數(shù)據(jù)庫性能: 運行bstat/estat生成系統(tǒng)報告,或者使用statspack收集統(tǒng)計數(shù)據(jù); (9). 檢查數(shù)據(jù)庫性能，記錄數(shù)據(jù)庫的cpu使用、IO、buffer命中率等等; 使用vmstat,iostat,glance,top等命令。 (10). 日常出現(xiàn)問題的處理。 每周的工作:(1). 監(jiān)控數(shù)據(jù)庫對象的空間擴展情況: 根據(jù)本周天天的檢查情況找到空間擴展很快的數(shù)據(jù)庫對象,并采取相應的措施 -- 刪除歷史數(shù)據(jù) --- 擴表空間alter tablespace add datafile‘xxxx.dbf’ size 10M;--- 調整數(shù)據(jù)對象的存儲參數(shù) next extent pct_increase (2). 監(jiān)控數(shù)據(jù)量的增長情況 根據(jù)本周天天的檢查情況找到記錄數(shù)量增長很快的數(shù)據(jù)庫對象,并采取相應的措施 -- 刪除歷史數(shù)據(jù) --- 擴表空間 alter tablespace add datafile ‘xxx.dbf’ size 100M;?(3). 系統(tǒng)健康檢查檢查以下內容: init.ora controlfile redo log file archiving sort area size tablespace(system,temporary,tablespace fragment) datafiles(autoextend,location) object(number of extent,next extent,index) rollback segment logging &tracing(alert.log,max_dump_file_size,sqlnet) (4). 檢查無效的數(shù)據(jù)庫對象:SELECT owner, object_name, object_type FROM dba_objects WHERE status='INVALID';(5). 檢查不起作用的約束 SELECT owner, constraint_name, table_name,constraint_type,status FROM dba_constraints WHERE status = 'DISABLED’ AND constraint_type = 'P'(6). 檢查無效的trigger SELECT owner,trigger_name,table_name,status FROM dba_triggers WHERE status ='DISABLED’;每月的工作(1). Analyze Tables/Indexes/Cluster analyze table estimate statistics sample 50 percent; (2). 檢查表空間碎片 根據(jù)本月每周的檢查分析數(shù)據(jù)庫碎片情況,找到相應的解決方法。 (3). 尋找數(shù)據(jù)庫性能調整的機會比較天天對數(shù)據(jù)庫性能的監(jiān)控報告,確定是否有必要對數(shù)據(jù)庫性能進行調整 (4). 數(shù)據(jù)庫性能調整 如有必要,進行性能調整 (5). 提出下一步空間治理計劃 根據(jù)每周的監(jiān)控,提出空間治理的改進方法 Oracle DBA 日常治理 目的：這篇文檔有很具體的資料記錄著對一個甚至更多的ORACLE 數(shù)據(jù)庫天天的，每月的,每年的運行的狀態(tài)的結果及檢查的結果，在文檔的附錄中你將會看到所有檢查，修改的SQL和PL/SQL 代碼。 目錄 1.日常維護程序A． 檢查已起的所有實例B． 查找一些新的警告日志 C． 檢查DBSNMP 是否在運行 D． 檢查數(shù)據(jù)庫備份是否正確 E． 檢查備份到磁帶中的文件是否正確 F． 檢查數(shù)據(jù)庫的性能是否正常合理，是否有足夠的空間和資源 G． 將文檔日志復制到備份的數(shù)據(jù)庫中 H． 要?？碊BA 用戶手冊 2.晚間維護程序 A．收集VOLUMETRIC 的數(shù)據(jù) 3.每周維護工作 A． 查找那些破壞規(guī)則的OBJECT B． 查找是否有違反安全策略的問題 C． 查看錯誤地方的SQL*NET 日志 D． 將所有的警告日志存檔 E． 經常訪問供給商的主頁 4.月維護程序 A． 查看對數(shù)據(jù)庫會產生危害的增長速度 B． 回顧以前數(shù)據(jù)庫優(yōu)化性能的調整 C． 查看I/O 的屏頸問題 D． 回顧FRAGMENTATION E． 將來的執(zhí)行計劃 F． 查看調整點和維護 5.附錄 A． 月維護過程 B． 晚間維護過程 C． 周維護過程 ?一．日維護過程 A．查看所有的實例是否已起 確定數(shù)據(jù)庫是可用的，把每個實例寫入日志并且運行日報告或是運行測試 文件。當然有一些操作我們是希望它能自動運行的。 可選擇執(zhí)行：用ORACLE 治理器中的‘PROBE’事件來查看 B．查找新的警告日志文件 1. 聯(lián)接每一個操作治理系統(tǒng) 2. 使用‘TELNET’或是可比較程序 3. 對每一個治理實例，經常的執(zhí)行$ORACLE_BASE//bdump 操 作，并使其能回退到控制數(shù)據(jù)庫的SID。 4. 在提示下，使用UNIX 中的‘TAIL’命令查看alert_.log,或是用其他方式檢查文件中最近時期的警告日志。 5. 假如以前出現(xiàn)過的一些ORA_ERRORS 又出現(xiàn)，將它記錄到數(shù)據(jù)庫恢復日志中并且仔細的研究它們，這個數(shù)據(jù)庫恢復日志在〈FILE〉中。 C．查看DBSNMP 的運行情況檢查每個被治理機器的‘DBSNMP’進程并將它們記錄到日志中。 在UNIX 中，在命令行中，鍵入ps –ef grep dbsnmp,將回看到2個DBSNMP 進程在運行。假如沒有，重啟DBSNMP。 D．查數(shù)據(jù)庫備份是否成功 E．檢查備份的磁帶文檔是否成功 F．檢查對合理的性能來說是否有足夠的資源 1. 檢查在表空間中有沒有剩余空間。 對每一個實例來說，檢查在表空間中是否存在有剩余空間來滿足當天 的預期的需要。當數(shù)據(jù)庫中已有的數(shù)據(jù)是穩(wěn)定的，數(shù)據(jù)日增長的平均 數(shù)也是可以計算出來，最小的剩余空間至少要能滿足天天數(shù)據(jù)的增 長。 A） 運行‘FREE.SQL’來檢查表空間的剩余空間。 B） 運行‘SPACE.SQL’來檢查表空間中的剩余空間百分率 2. 檢查回滾段 回滾段的狀態(tài)一般是在線的，除了一些為復雜工作預備的專用 段，它一般狀態(tài)是離線的。 a) 每個數(shù)據(jù)庫都有一個回滾段名字的列表。 b) 你可以用V$ROLLSTAT 來查詢在線或是離線的回滾段的現(xiàn)在狀 態(tài). c) 對于所有回滾段的存儲參數(shù)及名字，可用 DBA_ROLLBACK_SEGS 來查詢。但是它不如V$ROLLSTAT正確。 3. 識別出一些過分的增長 查看數(shù)據(jù)庫中超出資源或是增長速度過大的段，這些段的存儲參 數(shù)需要調整。 a） 收集日數(shù)據(jù)大小的信息， 可以用'ANALYZE5PCT.SQL'。假如你收集的是每晚的信息，則可跳過這一步。 b） 檢查當前的范圍，可用‘NR.EXTENTS.SQL’。 c） 查詢當前表的大小信息。 d） 查詢當前索引大小的信息。 e） 查詢增長趨勢。 4. 確定空間的范圍。 假如范圍空間對象的NEXT_EXTENT 比表空間所能提供的最大范圍還要大，那么這將影響數(shù)據(jù)庫的運行。假如我們找到了這個目標，可以用‘ALTER TABLESPACE COALESCE’調查它的位置，或加另外的數(shù)據(jù)文件。 A）運行‘SPACEBOUND.SQL’。假如都是正常的，將不返回任何行。 5. 回顧CPU，內存，網絡，硬件資源論點的過程 A）檢查CPU的利用情況，進到x:.htm =>system metrics=>CPU 利用頁，CPU 的最大限度為400，當CPU 的占用保持 在350 以上有一段時間的話，我們就需要查看及研究出現(xiàn)的問題。 G．將存檔日志復制到備用數(shù)據(jù)庫中 假如有一個備用數(shù)據(jù)庫，將適當?shù)拇鏅n日志復制到備用數(shù)據(jù)庫的期望 位置，備用數(shù)據(jù)庫中保存最近期的數(shù)據(jù)。 H. 經常查閱DBA 用戶手冊 假如有可能的話，要廣泛的閱讀，包括DBA 手冊，行業(yè)雜志，新聞 組或是郵件列表。 ------------------------------------------------------------- 二．晚間維護過程 大部分的數(shù)據(jù)庫產品將受益于每晚確定的檢查進程的運行。 A. 收集VOLUMETRIC 數(shù)據(jù) 1. 分析計劃和收集數(shù)據(jù) 更準確的分析計算并保存結果。 a） 假如你現(xiàn)在沒有作這些的話，用‘MK VOLFACT.SQL’來創(chuàng)建測定體積的 表。 b） 收集晚間數(shù)據(jù)大小的信息，用‘ANALYZE COMP.SQL’。 c） 收集統(tǒng)計結果，用‘POP VOL.SQL’。 d） 在空閑的時候檢查數(shù)據(jù)，可能的話，每周或每個月進行。 我是用MS Excel 和ODBC 的聯(lián)接來檢查數(shù)據(jù)和圖表的增長 ------------------------------------------------------------- 三．每周維護過程 A． 查找被破壞的目標 1. 對于每個給定表空間的對象來說，NEXT_EXTENT 的大小是相同的，如12/14/98，缺省的NEXT_EXTENT 的DATAHI 為1G，DATALO 為500MB， INDEXES 為256MB。 A） 檢查NEXT_EXTENT 的設置，可用‘NEXTEXT。SQL’。 B） 檢查已有的EXTENTS，可用‘EXISTEXT。SQL’。 2. 所有的表都應該有唯一的主鍵 a） 查看那些表沒有主鍵，可用‘NO_PK.SQL’。 b） 查找那些主鍵是沒有發(fā)揮作用的，可用'DIS_PK.SQL'。 c） 所有作索引的主鍵都要是唯一的，可用'NONUPK.SQL'來檢 查。 3. 所有的索引都要放到索引表空間中。運行‘MKREBUILD_IDX。SQL’ 4. 不同的環(huán)境之間的計劃應該是同樣的，非凡是測試環(huán)境和成品環(huán)境之間的計劃應該相同。 a） 檢查不同的2 個運行環(huán)境中的數(shù)據(jù)類型是否一致，可用'DATATYPE.SQL'。 b） 在2 個不同的實例中尋找對象的不同點，可用'OBJ_COORD.SQL'。 c） 更好的做法是，使用一種工具，象尋求軟件的計劃治理器那樣的工具。 B． 查看是否有危害到安全策略的問題。 C． 查看報錯的SQL*NET 日志。 1. 客戶端的日志。 2. 服務器端的日志。 D．.將所有的警告日志存檔 E．.供給商的主頁 1. ORACLE 供給商 http://www.oracle.com http://technet.oracle.com http://www.oracle.com/support http://www.oramag.com 2. Quest Software http://www.quests.com 3. Sun Microsystems http://www.sun.com ---------------------------------------------------------------- 四．月維護過程 A．查看對數(shù)據(jù)庫會產生危害的增長速度 1. 從以前的記錄或報告中回顧段增長的變化以此來確定段增長帶來危害 B． 回顧以前數(shù)據(jù)庫優(yōu)化性能的調整 1. 回顧一般ORACLE 數(shù)據(jù)庫的調整點，比較以前的報告來確定有害的發(fā)展趨勢。 C． 查看I/O 的屏頸問題 1. 查看前期數(shù)據(jù)庫文件的活動性，比較以前的輸出來判定有可能導致屏頸問題的趨勢。 D． 回顧FRAGMENTATION E． 計劃數(shù)據(jù)庫將來的性能 1. 比較ORACLE 和操作系統(tǒng)的CPU，內存，網絡，及硬盤的利用率以此 來確定在近期將會有的一些資源爭奪的趨勢 2. 當系統(tǒng)將超出范圍時要把性能趨勢當作服務水平的協(xié)議來看 F． 完成調整和維護工作 1.使修改滿足避免系統(tǒng)資源的爭奪的需要，這里面包括增加新資源或使預期的停工。 ---------------------------------------------------------------- 五．附錄 A. 日常程序 -- free.sql --To verify free space in tablespaces --Minimum amount of free space --document your thresholds: -- = m SELECT tablespace_name, sum ( blocks ) as free_blk , trunc ( sum ( bytes ) / (1024*1024) ) as free_m, max ( bytes ) / (1024) as big_chunk_k, count (*) as num_chunks FROM dba_free_space GROUP BY tablespace_name;1. Space.sql -- space.sql -- To check free, pct_free, and allocated space within a tablespace -- 11/24/98 SELECT tablespace_name, largest_free_chunk , nr_free_chunks, sum_alloc_blocks, sum_free_blocks , to_char(100*sum_free_blocks/sum_alloc_blocks, '09.99') '%' AS pct_free FROM ( SELECT tablespace_name , sum(blocks) AS sum_alloc_blocks FROM dba_data_files GROUP BY tablespace_name ) , ( SELECT tablespace_name AS fs_ts_name , max(blocks) AS largest_free_chunk , count(blocks) AS nr_free_chunks , sum(blocks) AS sum_free_blocks FROM dba_free_space GROUP BY tablespace_name ) WHERE tablespace_name = fs_ts_name 2. analyze5pct.sql -- analyze5pct.sql -- To analyze tables and indexes quickly, using a 5% sample size -- (do not use this script if you are performing the overnight -- collection of volumetric data) -- 11/30/98 BEGIN dbms_utility.analyze_schema ( '&OWNER', 'ESTIMATE', NULL, 5 ) ; END ; / 3. nr_extents.sql -- nr_extents.sql -- To find out any object reaching -- extents, and manually upgrade it to allow unlimited -- max_extents (thus only objects we *expect* to be big -- are allowed to become big) -- 11/30/98 SELECT e.owner, e.segment_type , e.segment_name , count(*) as nr_extents , s.max_extents , to_char ( sum ( e.bytes ) / ( 1024 * 1024 ) , '999,999.90') as MB FROM dba_extents e , dba_segments s WHERE e.segment_name = s.segment_name GROUP BY e.owner, e.segment_type , e.segment_name , s.max_extents HAVING count(*)> &THRESHOLD OR ( ( s.max_extents - count(*) ) ORDER BY count(*) desc 4. spacebound.sql -- spacebound.sql -- To identify space-bound objects. If all is well, no rows are returned. -- If any space-bound objects are found, look at value of NEXT extent -- size to figure out what happened. -- Then use coalesce (alter tablespace coalesce . -- Lastly, add another datafile to the tablespace if needed. -- 11/30/98 SELECT a.table_name, a.next_extent, a.tablespace_name FROM all_tables a, ( SELECT tablespace_name, max(bytes) as big_chunk FROM dba_free_space GROUP BY tablespace_name ) f WHERE f.tablespace_name = a.tablespace_name AND a.next_extent> f.big_chunk B. 每晚處理程序 1. mk_volfact.sql -- mk_volfact.sql (only run this once to set it up; do not run it nightly! ) -- -- Table UTL_VOL_FACTS CREATE TABLE utl_vol_facts ( table_name VARCHAR2(30), num_rows NUMBER, meas_dt DATE ) TABLESPACE platab STORAGE ( INITIAL 128k NEXT 128k PCTINCREASE 0 MINEXTENTS 1 MAXEXTENTS unlimited ) / -- Public Synonym CREATE PUBLIC SYNONYM utl_vol_facts FOR &OWNER..utl_vol_facts / -- Grants for UTL_VOL_FACTS GRANT SELECT ON utl_vol_facts TO public / 2. analyze_comp.sql -- -- analyze_comp.sql -- BEGIN sys.dbms_utility.analyze_schema ( '&OWNER','COMPUTE'); END ; / 3. pop_vol.sql -- -- pop_vol.sql -- insert into utl_vol_facts select table_name , NVL ( num_rows, 0) as num_rows , trunc ( last_analyzed ) as meas_dt from all_tables -- or just user_tables where owner in ('&OWNER') -- or a comma-separated list of owners / commit /　C. 每周處理程序 1. nextext.sql -- -- nextext.sql -- -- To find tables that don't match the tablespace default for NEXT extent. -- The implicit rule here is that every table in a given tablespace should -- use the exact same value for NEXT, which should also be the tablespace's -- default value for NEXT. -- -- This tells us what the setting for NEXT is for these objects today. -- -- 11/30/98 SELECT segment_name, segment_type, ds.next_extent as Actual_Next , dt.tablespace_name, dt.next_extent as Default_Next FROM dba_tablespaces dt, dba_segments ds WHERE dt.tablespace_name = ds.tablespace_name AND dt.next_extent !=ds.next_extent AND ds.owner = UPPER ( '&OWNER' ) ORDER BY tablespace_name, segment_type, segment_name 2. existext.sql -- -- existext.sql -- -- To check existing extents -- -- This tells us how many of each object's extents differ in size from -- the tablespace's default size. If this report shows a lot of different -- sized extents, your free space is likely to become fragmented. If so, -- this tablespace is a candidate for reorganizing. -- -- 12/15/98 SELECT segment_name, segment_type , count(*) as nr_exts , sum ( DECODE ( dx.bytes,dt.next_extent,0,1) ) as nr_illsized_exts , dt.tablespace_name, dt.next_extent as dflt_ext_size FROM dba_tablespaces dt, dba_extents dx WHERE dt.tablespace_name = dx.tablespace_name AND dx.owner = '&OWNER' GROUP BY segment_name, segment_type, dt.tablespace_name, dt.next_extent 3. No_pk.sql -- -- no_pk.sql -- -- To find tables without PK constraint -- -- 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. disPK.sql -- -- disPK.sql -- -- To find out which primary keys are disabled -- -- 11/30/98 SELECT owner, constraint_name, table_name, status FROM all_constraints WHERE owner = '&OWNER' AND status = 'DISABLED’ AND constraint_type = 'P' 5. nonuPK.sql -- -- nonuPK.sql -- -- To find tables with nonunique PK indexes. Requires that PK names -- follow a naming convention. An alternative query follows that -- does not have this requirement, but runs more slowly. -- -- 11/2/98 SELECT index_name, table_name, uniqueness FROM all_indexes WHERE index_name like '&PKNAME%' AND owner = '&OWNER' AND uniqueness = 'NONUNIQUE' SELECT c.constraint_name, i.tablespace_name, i.uniqueness FROM all_constraints c , all_indexes i WHERE c.owner = UPPER ( '&OWNER' ) AND i.uniqueness = 'NONUNIQUE' AND c.constraint_type = 'P' AND i.index_name = c.constraint_name 6. mkrebuild_idx.sql -- -- mkrebuild_idx.sql -- -- Rebuild indexes to have correct storage parameters -- -- 11/2/98 SELECT 'alter index ' index_name ' rebuild ' , 'tablespace INDEXES storage ' ' ( initial 256 K next 256 K pctincrease 0 ) ; ' FROM all_indexes WHERE ( tablespace_name ! = 'INDEXES' OR next_extent != ( 256 * 1024 ) ) AND owner = '&OWNER' / 7. datatype.sql -- -- datatype.sql -- -- To check datatype consistency between two environments -- -- 11/30/98 SELECT table_name, column_name, data_type, data_length, data_precision, data_scale, nullable FROM all_tab_columns -- first environment WHERE owner = '&OWNER' MINUS SELECT table_name, column_name, data_type, data_length, data_precision, data_scale, nullable FROM all_tab_columns@&my_db_link -- second environment WHERE owner = '&OWNER2' order by table_name, column_name 8. obj_coord.sql -- -- obj_coord.sql -- -- To find out any difference in objects between two instances -- -- 12/08/98 SELECT object_name, object_type FROM user_objects MINUS SELECT object_name, object_type FROM user_objects@&my_db_link;?