在Oracle數據庫運行期間DBA應該對數據庫的運行日志及表空間的使用情況進行監控及早發現數據庫中存在的問題
一Oracle警告日志文件監控
Oracle在運行過程中會在警告日志文件(alert_SIDlog)中記錄數據庫的一些運行情況:
●數據庫的啟動關閉啟動時的非缺省參數
●數據庫的重做日志切換情況記錄每次切換的時間及如果因為檢查點(checkpoint)操作沒有執行完成造成不能切換會記錄不能切換的原因
●對數據庫進行的某些操作如創建或刪除表空間增加數據文件
●數據庫發生的錯誤如表空間不夠出現壞塊數據庫內部錯誤(ORA)
DBA應該定期檢查日志文件根據日志中發現的問題及時進行處理
問題處理:
啟動參數不對檢查初始化參數文件
因為檢查點操作或歸檔操作沒有完成造成重做日志不能切換如果經常發生這樣的情況可以考慮增加重做日志文件組;想辦法提高檢查點或歸檔操作的效率
有人未經授權刪除了表空間檢查數據庫的安全問題是否密碼太簡單;如有必要撤消某些用戶的系統權限
出現壞塊檢查是否是硬件問題(如磁盤本生有壞塊)如果不是檢查是那個數據庫對象出現了壞塊對這個對象進行重建
表空間不夠增加數據文件到相應的表空間
出現ORA根據日志文件的內容查看相應的TRC文件如果是Oracle的bug要及時打上相應的補丁
二數據庫表空間使用情況監控(字典管理表空間)
數據庫運行了一段時間後由於不斷的在表空間上創建和刪除對象會在表空間上產生大量的碎片DBA應該及時了解表空間的碎片和可用空間情況以決定是否要對碎片進行整理或為表空間增加數據文件 以下為引用的內容
select tablespace_name
count(*) chunks
max(bytes//) max_chunk
from dba_free_space
group by tablespace_name;
上面的SQL列出了數據庫中每個表空間的空閒塊情況如下所示: 以下為引用的內容
TABLESPACE_NAME CHUNKS MAX_CHUNK
INDX
RBS
RMAN_TS
SYSTEM
TEMP
TOOLS
USERS
其中CHUNKS列表示表空間中有多少可用的空閒塊(每個空閒塊是由一些連續的Oracle數據塊組成)如果這樣的空閒塊過多比如平均到每個數據文件上超過了個那麼該表空間的碎片狀況就比較嚴重了可以嘗試用以下的SQL命令進行表空間相鄰碎片的接合:
alter tablespace 表空間名 coalesce;
然後再執行查看表空間碎片的SQL語句看表空間的碎片有沒有減少如果沒有效果並且表空間的碎片已經嚴重影響到了數據庫的運行則考慮對該表空間進行重建
MAX_CHUNK列的結果是表空間上最大的可用塊大小如果該表空間上的對象所需分配的空間(NEXT值)大於可用塊的大小的話就會提示ORAORAORA的錯誤信息DBA應該及時對表空間的空間進行擴充以避免這些錯誤發生
對表空間的擴充對表空間的數據文件大小進行擴展或向表空間增加數據文件具體操作見存儲管理部份
三查看數據庫的連接情況
DBA要定時對數據庫的連接情況進行檢查看與數據庫建立的會話數目是不是正常如果建立了過多的連接會消耗數據庫的資源同時對一些掛死的連接可能會需要DBA手工進行清理
以下的SQL語句列出當前數據庫建立的會話情況: 以下為引用的內容
select sidserial#usernameprogrammachinestatus
from v$session;
輸出結果為: 以下為引用的內容
SID SERIAL# USERNAME PROGRAM MACHINE STATUS
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
ORACLEEXE WORK ACTIVE
SYS SQLPLUSEXE WORKGROUP\WORK ACTIVE
DBSNMP dbsnmpexe WORKGROUP\WORK INACTIVE
注釋
SID 會話(session)的ID號
SERIAL# 會話的序列號和SID一起用來唯一標識一個會話
USERNAME 建立該會話的用戶名
PROGRAM 這個會話是用什麼工具連接到數據庫的
STATUS 當前這個會話的狀態ACTIVE表示會話正在執行某些任務INACTIVE表示當前會話沒有執行任何操作
如果DBA要手工斷開某個會話則執行:
alter system kill session SIDSERIAL#;
注意上例中SID為到(USERNAME列為空)的會話是Oracle的後台進程不要對這些會話進行任何操作
四控制文件的備份
在數據庫結構發生變化時如增加了表空間增加了數據文件或重做日志文件這些操作都會造成Oracle數據庫控制文件的變化DBA應及進行控制文件的備份備份方法是:
執行SQL語句: 以下為引用的內容
alter database
backup controlfile to /home/backup/controlbak;
或: 以下為引用的內容
alter database
backup controlfile to trace;
這樣會在USER_DUMP_DEST(初始化參數文件中指定)目錄下生成創建控制文件的SQL命令
五檢查數據庫文件的狀態
DBA要及時查看數據庫中數據文件的狀態(如被誤刪除)根據實際情況決定如何進行處理檢查數據文件的狀態的SQL如下: 以下為引用的內容
select file_namestatus
from dba_data_files;
如果數據文件的STATUS列不是AVAILABLE那麼就要采取相應的措施如對該數據文件進行恢復操作或重建該數據文件所在的表空間
六檢查數據庫定時作業的完成情況
如果數據庫使用了Oracle的JOB來完成一些定時作業要對這些JOB的運行情況進行檢查:
以下為引用的內容
select joblog_userlast_datefailures
from dba_jobs;
如果FAILURES列是一個大於的數的話說明JOB運行失敗要進一步的檢查
七數據庫壞塊的處理
當Oracle數據庫出現壞塊時Oracle會在警告日志文件(alert_SIDlog)中記錄壞塊的信息:
ORA: ORACLE data block corrupted (file # block # )
ORA: data file : /oracle/oradata/V/oradata/V/usersdbf
其中 代表壞塊所在數據文件的絕對文件號 代表壞塊是數據文件上的第幾個數據塊出現這種情況時應該首先檢查是否是硬件及操作系統上的故障導致Oracle數據庫出現壞塊在排除了數據庫以外的原因後再對發生壞塊的數據庫對象進行處理
確定發生壞塊的數據庫對象 以下為引用的內容
SELECT tablespace_name
segment_type
owner
segment_name
FROM dba_extents
WHERE file_id =
AND
between block_id AND block_id+blocks;
決定修復方法:
如果發生壞塊的對象是一個索引那麼可以直接把索引DROP掉後再根據表裡的記錄進行重建
如果發生壞塊的表的記錄可以根據其它表的記錄生成的話那麼可以直接把這個表DROP掉後重建
如果有數據庫的備份則恢復數據庫的方法來進行修復
如果表裡的記錄沒有其它辦法恢復那麼壞塊上的記錄就丟失了只能把表中其它數據塊上的記錄取出來然後對這個表進行重建
用Oracle提供的DBMS_REPAIR包標記出壞塊:
exec DBMS_REPAIRSKIP_CORRUPT_BLOCKS( );
使用Create table as select命令將表中其它塊上的記錄保存到另一張表上 以下為引用的內容
create table corrupt_table_bak
as
select * from corrupt_table;
用DROP TABLE命令刪除有壞塊的表 以下為引用的內容
drop table corrup_tatble;
用alter table rename命令恢復原來的表 以下為引用的內容
alter table corrupt_table_bak
rename to corrupt_table;
如果表上存在索引則要重建表上的索引
八操作系統相關維護
DBA要注意對操作系統的監控:
●文件系統的空間使用情況(df k)必要時對Oracle的警告日志及TRC文件進行清理
●如果Oracle提供網絡服務檢查網絡連接是否正常
●檢查操作系統的資源使用情況是否正常
●檢查數據庫服務器有沒有硬件故障如磁盤內存報錯
From:http://tw.wingwit.com/Article/program/Oracle/201311/17994.html
