應按如下方式對Oracle數據庫系統做定期監控：
?
(1). 天天對ORACLE數據庫的運行狀態,日志文件,備份情況,數據庫的空間使用情況,系統資源的使用情況進行檢查,發現并解決問題。
(2). 每周對數據庫對象的空間擴展情況,數據的增長情況進行監控,對數據庫做健康檢查,對數據庫對象的狀態做檢查。
(3). 每月對表和索引等進行Analyze,檢查表空間碎片,尋找數據庫性能調整的機會,進行數據庫性能調整,提出下一步空間治理計劃,對ORACLE數據庫狀態進行一次全面檢查。
天天的工作:
(1).確認所有的INSTANCE狀態正常。
登陸到所有數據庫或例程,檢測ORACLE后臺進程:
$ps –efgrep ora
(2). 檢查文件系統的使用（剩余空間）。假如文件系統的剩余空間小于20%，需刪除不用的文件以釋放空間：
$df –k
(3). 檢查日志文件和trace文件記錄alert和trace文件中的錯誤。
連接到每個需治理的系統:
使用'telnet'
對每個數據庫,cd到bdump目錄,通常是$ORACLE_BASE/bdump
使用 Unix 'tail'命令來查看alert_.log文件,假如發現任何新的ORA-錯誤,記錄并解決。
(4). 檢查數據庫當日備份的有效性。
對RMAN備份方式:
檢查第三方備份工具的備份日志以確定備份是否成功。
對EXPORT備份方式:
檢查exp日志文件以確定備份是否成功
對其他備份方式:
檢查相應的日志文件
(5). 檢查數據文件的狀態記錄狀態不是“online”的數據文件，并做恢復:
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). 監控數據庫性能:
運行bstat/estat生成系統報告,或者使用statspack收集統計數據;
(9). 檢查數據庫性能，記錄數據庫的cpu使用、IO、buffer命中率等等;
使用vmstat,iostat,glance,top等命令。
(10). 日常出現問題的處理。
每周的工作:
(1). 監控數據庫對象的空間擴展情況:
根據本周天天的檢查情況找到空間擴展很快的數據庫對象,并采取相應的措施
-- 刪除歷史數據
--- 擴表空間
alter tablespace add datafile‘xxxx.dbf’ size 10M;
--- 調整數據對象的存儲參數
next extent
pct_increase
(2). 監控數據量的增長情況
根據本周天天的檢查情況找到記錄數量增長很快的數據庫對象,并采取相應的措施
-- 刪除歷史數據
--- 擴表空間
alter tablespace add datafile ‘xxx.dbf’ size 100M;?
(3). 系統健康檢查
檢查以下內容:
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). 檢查無效的數據庫對象:
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). 檢查表空間碎片
根據本月每周的檢查分析數據庫碎片情況,找到相應的解決方法。
(3). 尋找數據庫性能調整的機會
比較天天對數據庫性能的監控報告,確定是否有必要對數據庫性能進行調整
(4). 數據庫性能調整
如有必要,進行性能調整
(5). 提出下一步空間治理計劃
根據每周的監控,提出空間治理的改進方法
Oracle DBA 日常治理
目的：這篇文檔有很具體的資料記錄著對一個甚至更多的ORACLE 數據庫天天的，每月的,每年的運行的狀態的結果及檢查的結果，在文檔的附錄中你將會看到所有檢查，修改的SQL和PL/SQL 代碼。
目錄
1.日常維護程序
A． 檢查已起的所有實例
B． 查找一些新的警告日志
C． 檢查DBSNMP 是否在運行
D． 檢查數據庫備份是否正確
E． 檢查備份到磁帶中的文件是否正確
F． 檢查數據庫的性能是否正常合理，是否有足夠的空間和資源
G． 將文檔日志復制到備份的數據庫中
H． 要?？碊BA 用戶手冊
2.晚間維護程序
A．收集VOLUMETRIC 的數據
3.每周維護工作
A． 查找那些破壞規則的OBJECT
B． 查找是否有違反安全策略的問題
C． 查看錯誤地方的SQL*NET 日志
D． 將所有的警告日志存檔
E． 經常訪問供給商的主頁
4.月維護程序
A． 查看對數據庫會產生危害的增長速度
B． 回顧以前數據庫優化性能的調整
C． 查看I/O 的屏頸問題
D． 回顧FRAGMENTATION
E． 將來的執行計劃
F． 查看調整點和維護
5.附錄
A． 月維護過程
B． 晚間維護過程
C． 周維護過程
?
一．日維護過程
A．查看所有的實例是否已起
確定數據庫是可用的，把每個實例寫入日志并且運行日報告或是運行測試
文件。當然有一些操作我們是希望它能自動運行的。
可選擇執行：用ORACLE 治理器中的‘PROBE’事件來查看
B．查找新的警告日志文件
1. 聯接每一個操作治理系統
2. 使用‘TELNET’或是可比較程序
3. 對每一個治理實例，經常的執行$ORACLE_BASE//bdump 操
作，并使其能回退到控制數據庫的SID。
4. 在提示下，使用UNIX 中的‘TAIL’命令查看alert_.log,或是用其他方式檢查文件中最近時期的警告日志。
5. 假如以前出現過的一些ORA_ERRORS 又出現，將它記錄到數據庫恢復日志中并且仔細的研究它們，這個數據庫恢復日志在〈FILE〉中。
C．查看DBSNMP 的運行情況
檢查每個被治理機器的‘DBSNMP’進程并將它們記錄到日志中。
在UNIX 中，在命令行中，鍵入ps –ef grep dbsnmp,將回看到2個DBSNMP 進程在運行。假如沒有，重啟DBSNMP。
D．查數據庫備份是否成功
E．檢查備份的磁帶文檔是否成功
F．檢查對合理的性能來說是否有足夠的資源
1. 檢查在表空間中有沒有剩余空間。
對每一個實例來說，檢查在表空間中是否存在有剩余空間來滿足當天
的預期的需要。當數據庫中已有的數據是穩定的，數據日增長的平均
數也是可以計算出來，最小的剩余空間至少要能滿足天天數據的增 長。
A） 運行‘FREE.SQL’來檢查表空間的剩余空間。
B） 運行‘SPACE.SQL’來檢查表空間中的剩余空間百分率
2. 檢查回滾段
回滾段的狀態一般是在線的，除了一些為復雜工作預備的專用 段，它一般狀態是離線的。
a) 每個數據庫都有一個回滾段名字的列表。
b) 你可以用V$ROLLSTAT 來查詢在線或是離線的回滾段的現在狀 態.
c) 對于所有回滾段的存儲參數及名字，可用
DBA_ROLLBACK_SEGS 來查詢。但是它不如V$ROLLSTAT正確。
3. 識別出一些過分的增長
查看數據庫中超出資源或是增長速度過大的段，這些段的存儲參 數需要調整。
a） 收集日數據大小的信息， 可以用'ANALYZE5PCT.SQL'。假如你收集的是每晚的信息，則可跳過這一步。
b） 檢查當前的范圍，可用‘NR.EXTENTS.SQL’。
c） 查詢當前表的大小信息。
d） 查詢當前索引大小的信息。
e） 查詢增長趨勢。
4. 確定空間的范圍。
假如范圍空間對象的NEXT_EXTENT 比表空間所能提供的最大范圍還要大，那么這將影響數據庫的運行。假如我們找到了這個目標，可以用‘ALTER TABLESPACE COALESCE’調查它的位置，或加另外的數據文件。
A）運行‘SPACEBOUND.SQL’。假如都是正常的，將不返回任何行。
5. 回顧CPU，內存，網絡，硬件資源論點的過程
A）檢查CPU的利用情況，進到x:.htm =>system
metrics=>CPU 利用頁，CPU 的最大限度為400，當CPU 的占用保持
在350 以上有一段時間的話，我們就需要查看及研究出現的問題。
G．將存檔日志復制到備用數據庫中
假如有一個備用數據庫，將適當的存檔日志復制到備用數據庫的期望
位置，備用數據庫中保存最近期的數據。
H. 經常查閱DBA 用戶手冊
假如有可能的話，要廣泛的閱讀，包括DBA 手冊，行業雜志，新聞 組或是郵件列表。
-------------------------------------------------------------
二．晚間維護過程
大部分的數據庫產品將受益于每晚確定的檢查進程的運行。
A. 收集VOLUMETRIC 數據
1. 分析計劃和收集數據
更準確的分析計算并保存結果。
a） 假如你現在沒有作這些的話，用‘MK VOLFACT.SQL’來創建測定體積的 表。
b） 收集晚間數據大小的信息，用‘ANALYZE COMP.SQL’。
c） 收集統計結果，用‘POP VOL.SQL’。
d） 在空閑的時候檢查數據，可能的話，每周或每個月進行。
我是用MS Excel 和ODBC 的聯接來檢查數據和圖表的增長
-------------------------------------------------------------
三．每周維護過程
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） 查找那些主鍵是沒有發揮作用的，可用'DIS_PK.SQL'。
c） 所有作索引的主鍵都要是唯一的，可用'NONUPK.SQL'來檢 查。
3. 所有的索引都要放到索引表空間中。運行‘MKREBUILD_IDX。SQL’
4. 不同的環境之間的計劃應該是同樣的，非凡是測試環境和成品環境之間的計劃應該相同。
a） 檢查不同的2 個運行環境中的數據類型是否一致，可用'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．查看對數據庫會產生危害的增長速度
1. 從以前的記錄或報告中回顧段增長的變化以此來確定段增長帶來危害
B． 回顧以前數據庫優化性能的調整
1. 回顧一般ORACLE 數據庫的調整點，比較以前的報告來確定有害的發展趨勢。
C． 查看I/O 的屏頸問題
1. 查看前期數據庫文件的活動性，比較以前的輸出來判定有可能導致屏頸問題的趨勢。
D． 回顧FRAGMENTATION
E． 計劃數據庫將來的性能
1. 比較ORACLE 和操作系統的CPU，內存，網絡，及硬盤的利用率以此
來確定在近期將會有的一些資源爭奪的趨勢
2. 當系統將超出范圍時要把性能趨勢當作服務水平的協議來看
F． 完成調整和維護工作
1.使修改滿足避免系統資源的爭奪的需要，這里面包括增加新資源或使預期的停工。
----------------------------------------------------------------
五．附錄
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;
?
