主要介紹了Oracle數據庫管理員在工作環境下的具體職責詳細內容請參考下文
Oracle數據庫管理員應按如下方式對Oracle數據庫系統做定期監控
() 每天對Oracle數據庫的運行狀態 日志文件 備份情況 數據庫的空間使用情況 系統資源的使用情況進行檢查 發現並解決問題
() 每周對數據庫對象的空間擴展情況 數據的增長情況進行監控 對數據庫做健康檢查 對數據庫對象的狀態做檢查
() 每月對表和索引等進行 Analyze 檢查表空間碎片 尋找數據庫性能調整的機會 進行數據庫性能調整 提出下一步空間管理計劃對Oracle數據庫狀態進行一次全面檢查
每天的工作
() 確認所有的 INSTANCE 狀態正常
登陸到所有數據庫或例程 檢測 ORACLE 後台進程 :
$ps –ef|grep ora
() 檢查文件系統的使用（剩余空間）如果文件系統的剩余空間小於 % 需刪除不用的文件以釋放空間
$df –k
() 檢查日志文件和 trace 文件記錄 alert 和 trace 文件中的錯誤
連接到每個需管理的系統
使用 telnet
對每個數據庫 cd 到 bdump 目錄 通常是 $ORACLE_BASE//bdump
使用 Unix tail 命令來查看 alert_log 文件
如果發現任何新的 ORA 錯誤 記錄並解決
() 檢查數據庫當日備份的有效性
對 RMAN 備份方式 :
檢查第三方備份工具的備份日志以確定備份是否成功
對 EXPORT 備份方式 :
檢查 exp 日志文件以確定備份是否成功
對其他備份方式 :
檢查相應的日志文件
() 檢查數據文件的狀態記錄狀態不是 online 的數據文件並做恢復
Select file_name from dba_data_files where status=OFFLINE
() 檢查表空間的使用情況
SELECT tablespace_name max_m count_blocks free_blk_cnt sum_free_mto_char(*sum_free_m/sum_m ) || % AS pct_free
FROM ( SELECT tablespace_namesum(bytes)// AS sum_m FROM dba_data_files GROUP BY tablespace_name)
( SELECT tablespace_name AS fs_ts_name max(bytes)// AS max_m count(blocks) AS count_blocks sum(bytes//) AS sum_free_m FROM dba_free_space GROUP BY tablespace_name )
WHERE tablespace_name = fs_ts_name
() 檢查剩余表空間
SELECT tablespace_name sum ( blocks ) as free_blk
trunc ( sum ( bytes ) /(*) ) as free_m
max ( bytes ) / () as big_chunk_k count (*) as num_chunks
FROM dba_free_space GROUP BY tablespace_name;
() 監控數據庫性能
運行 bstat/estat 生成系統報告
或者使用 statspack 收集統計數據
() 檢查數據庫性能記錄數據庫的 cpu 使用 IO buffer 命中率等等
使用 vmstatiostatglancetop 等命令
() 日常出現問題的處理
每周的工作
() 控數據庫對象的空間擴展情況
根據本周每天的檢查情況找到空間擴展很快的數據庫對象 並采取相應的措施
刪除歷史數據
擴表空間
alter tablespace add datafile size
調整數據對象的存儲參數
next extent
pct_increase
() 監控數據量的增長情況
根據本周每天的檢查情況找到記錄數量增長很快的數據庫對象 並采取相應的措施
刪除歷史數據
擴表空間
alter tablespace add datafile size
() 系統健康檢查
檢查以下內容 :
initora
controlfile
redo log file
archiving
sort area size
tablespace(systemtemporarytablespace fragment)
datafiles(autoextendlocation)
object(number of extentnext extentindex)
rollback segment
logging &tracing(alertlogmax_dump_file_sizesqlnet)
() 檢查無效的數據庫對象
SELECT owner object_name object_type FROM dba_objects
WHERE status= INVALID
(
)
檢查不起作用的約束
SELECT owner constraint_name table_name
constraint_type status
FROM dba_constraints
WHERE status = DISABLED AND constraint_type = P
() 檢查無效的 trigger
SELECT owner trigger_name table_name status
FROM dba_triggers
WHERE status = DISABLED
每月的工作
() Analyze Tables/Indexes/Cluster
analyze table estimate statistics sample percent;
() 檢查表空間碎片
根據本月每周的檢查分析數據庫碎片情況 找到相應的解決方法
() 尋找數據庫性能調整的機會
比較每天對數據庫性能的監控報告 確定是否有必要對數據庫性能進 行調整
() 數據庫性能調整
如有必要 進行性能調整
() 提出下一步空間管理計劃
根據每周的監控 提出空間管理的改進方法
Oracle DBA 日常管理
目的這篇文檔有很詳細的資料記錄著對一個甚至更多的 ORACLE 數據庫每天的每月的每年的運行的狀態的結果及檢查的結果在文檔的附錄中你將會看到所有檢查修改的 SQL和 PL/SQL 代碼
目錄
日常維護程序
A ． 檢查已起的所有實例
B ． 查找一些新的警告日志
C ． 檢查 DBSNMP 是否在運行
D ． 檢查數據庫備份是否正確
E ． 檢查備份到磁帶中的文件是否正確
F ． 檢查數據庫的性能是否正常合理是否有足夠的空間和資源
G ． 將文檔日志復制到備份的數據庫中
H ． 要常看 DBA 用戶手冊
晚間維護程序
A ．收集 VOLUMETRIC 的數據
每周維護工作
A ． 查找那些破壞規則的 OBJECT
B ． 查找是否有違反安全策略的問題
C ． 查看錯誤地方的 SQL*NET 日志
D ． 將所有的警告日志存檔
E ． 經常訪問供應商的主頁
月維護程序
A ． 查看對數據庫會產生危害的增長速度
B ． 回顧以前數據庫優化性能的調整
C ． 查看 I/O 的屏頸問題
D ． 回顧 FRAGMENTATION
E ． 將來的執行計劃
F ． 查看調整點和維護
一．日維護過程
A ．查看所有的實例是否已起
確定數據庫是可用的把每個實例寫入日志並且運行日報告或是運行測試文件當然有一些操作我們是希望它能自動運行的
可選擇執行用 ORACLE 管理器中的 PROBE 事件來查看
B ．查找新的警告日志文件
聯接每一個操作管理系統
使用 TELNET 或是可比較程序
對每一個管理實例經常的執行 $ORACLE_BASE//bdump 操作並使其能回退到控制數據庫的 SID
在提示下使用 UNIX 中的 TAIL 命令查看 alert_log 或是用其他方式檢查文件中最近時期的警告日志
如果以前出現過的一些 ORA_ERRORS 又出現將它記錄到數據庫恢復日志中並且仔細的研究它們這個數據庫恢復日志在〈 FILE 〉中
C ．查看 DBSNMP 的運行情況
檢查每個被管理機器的 DBSNMP 進程並將它們記錄到日志中
在 UNIX 中在命令行中鍵入 ps –ef | grep dbsnmp 將回看到 個DBSNMP 進程在運行如果沒有重啟 DBSNMP
D ．查數據庫備份是否成功
E ．檢查備份的磁帶文檔是否成功
F ．檢查對合理的性能來說是否有足夠的資源
檢查在表空間中有沒有剩余空間
對每一個實例來說檢查在表空間中是否存在有剩余空間來滿足當天的預期的需要當數據庫中已有的數據是穩定的數據日增長的平均數也是可以計算出來最小的剩余空間至少要能滿足每天數據的增 長
A ） 運行 FREESQL 來檢查表空間的剩余空間
B ） 運行 SPACESQL 來檢查表空間中的剩余空間百分率
檢查回滾段
回滾段的狀態一般是在線的除了一些為復雜工作准備的專用 段它一般狀態是離線的
a 每個數據庫都有一個回滾段名字的列表
b 你可以用 V$ROLLSTAT 來查詢在線或是離線的回滾段的現在狀 態
c 對於所有回滾段的存儲參數及名字 可用DBA_ROLLBACK_SEGS 來查詢但是它不如 V$ROLLSTAT 准確
識別出一些過分的增長
查看數據庫中超出資源或是增長速度過大的段這些段的存儲參 數需要調整
a收集日數據大小的信息 可以用
ANALYZEPCTSQL 如果你收集的是每晚的信息 則可跳過這一步
b檢查當前的范圍可用 NREXTENTSSQL
c查詢當前表的大小信息
d查詢當前索引大小的信息
e查詢增長趨勢
確定空間的范圍
如果范圍空間對象的 NEXT_EXTENT 比表空間所能提供的最大范圍還要大那麼這將影響數據庫的運行如果我們找到了這個目標可以用 ALTER TABLESPACE COALESCE 調查它的位置或加另外 的數據文件
A ）運行 SPACEBOUNDSQL 如果都是正常的將不返回任何行
回顧 CPU 內存網絡硬件資源論點的過程
A ）檢查 CPU 的利用情況進到 x:\web\phase\ =>system
metrics=>CPU 利用頁 CPU 的最大限度為 當 CPU 的占用保持在 以上有一段時間的話我們就需要查看及研究出現的問題
G ．將存檔日志復制到備用數據庫中
如果有一個備用數據庫將適當的存檔日志復制到備用數據庫的期望位置備用數據庫中保存最近期的數據
H 經常查閱 DBA 用戶手冊
如果有可能的話要廣泛的閱讀包括 DBA 手冊行業雜志新聞 組或是郵件列表
二．晚間維護過程
大部分的數據庫產品將受益於每晚確定的檢查進程的運行
A 收集 VOLUMETRIC 數據
分析計劃和收集數據
更准確的分析計算並保存結果
a ） 如果你現在沒有作這些的話用 MK VOLFACTSQL 來創建測定體積的 表
b ） 收集晚間數據大小的信息用 ANALYZE COMPSQL
c ） 收集統計結果用 POP VOLSQL
d ） 在空閒的時候檢查數據可能的話每周或每個月進行
我是用 MS EXCEL 和 ODBC 的聯接來檢查數據和圖表的增長
三．每周維護過程
A ． 查找被破壞的目標
對於每個給定表空間的對象來說 NEXT_EXTENT 的大小是相同的如// 缺省的NEXT_EXTENT 的 DATAHI 為 G DATALO 為 MB INDEXES 為 MB
A ） 檢查 NEXT_EXTENT 的設置可用 NEXTEXT SQL
B ） 檢查已有的 EXTENTS 可用 EXISTEXT SQL
所有的表都應該有唯一的主鍵
a查看那些表沒有主鍵可用 NO_PKSQL
b查找那些主鍵是沒有發揮作用的可用 DIS_PKSQL
c所有作索引的主鍵都要是唯一的可用 NONUPK SQL 來檢 查
所有的索引都要放到索引表空間中運行 MKREBUILD_IDX SQL
不同的環境之間的計劃應該是同樣的特別是測試環境和成品環境之間的 計劃應該相同
a檢查不同的 個運行環境中的數據類型是否一致可用 DATATYPESQL
b在 個不同的實例中尋找對象的不同點 可用 OBJ_COORDSQL
c更好的做法是使用一種工具象尋求軟件的計劃管理器那樣的 工具
B．查看是否有危害到安全策略的問題
C．查看報錯的 SQL*NET 日志
客戶端的日志
服務器端的日志
D ．將所有的警告日志存檔
E ．供應商的主頁
ORACLE 供應商
Quest Software
Sun Microsystems
四．月維護過程
A ．查看對數據庫會產生危害的增長速度
從以前的記錄或報告中回顧段增長的變化以此來確定段增長帶來危害
B ． 回顧以前數據庫優化性能的調整
回顧一般 ORACLE 數據庫的調整點比較以前的報告來確定有害的發展 趨勢
C ． 查看 I/O 的屏頸問題
查看前期數據庫文件的活動性比較以前的輸出來判斷有可能導致屏頸 問題的趨勢
D ． 回顧 FRAGMENTATION
E ． 計劃數據庫將來的性能
比較 ORACLE 和操作系統的 CPU 內存網絡及硬盤的利用率以此來確定在近期將會有的一些資源爭奪的趨勢
當系統將超出范圍時要把性能趨勢當作服務水平的協議來看
F ． 完成調整和維護工作
使修改滿足避免系統資源的爭奪的需要這裡面包括增加新資源或使預期的停工
From:http://tw.wingwit.com/Article/program/Oracle/201311/18809.html
