針對oracle日常維護

針對dba日常維護

這裡主要針對執行日誌及表空間的使用情況進行監控

一、Oracle警告日誌檔案監控
jlyb01:/opt/app/oracle/admin/JLSIMIS/bdump$tail -500f alert_JLSIMIS1.log

Oracle在執行過程中，會在警告日誌檔案(alert_SID.log)中記錄資料庫的一些執行情況:
●資料庫的啟動、關閉，啟動時的非預設引數;
●資料庫的重做日誌切換情況，記錄每次切換的時間，及如果因為檢查點(checkpoint)操作沒有執行完成造成不能切換，會記錄不能切換的原因;
●對資料庫進行的某些操作，如建立或刪除表空間、增加資料檔案;
●資料庫發生的錯誤，如表空間不夠、出現壞塊、資料庫內部錯誤(ORA-600)
DBA應該定期檢查日誌檔案，根據日誌中發現的問題及時進行處理。

問題處理：
啟動引數不對檢查初始化引數檔案
因為檢查點操作或歸檔操作沒有完成造成重做日誌不能切換如果經常發生這樣的情況，可以考慮增加重做日誌檔案組;想辦法提高檢查點或歸檔操作的效率;
有人未經授權刪除了表空間檢查資料庫的安全問題，是否密碼太簡單;如有必要，撤消某些使用者的系統許可權
出現壞塊檢查是否是硬體問題(如磁碟本生有壞塊)，如果不是，檢查是那個資料庫物件出現了壞塊，對這個物件進行重建
表空間不夠增加資料檔案到相應的表空間
出現ORA-600根據日誌檔案的內容檢視相應的TRC檔案，如果是Oracle的bug，要及時打上相應的補丁

二、資料庫表空間使用情況監控(字典管理表空間)

 

 

資料庫執行了一段時間後，由於不斷的在表空間上建立和刪除物件，會在表空間上產生大量的碎片，
DBA應該及時瞭解表空間的碎片和可用空間情況，以決定是否要對碎片進行整理或為表空間增加資料檔案。

/* Formatted on 2010/08/19 09:18 (Formatter Plus v4.8.8) */
SELECT   tablespace_name, COUNT (*) chunks,
         MAX (BYTES / 1024 / 1024) max_chunk
    FROM dba_free_space
GROUP BY tablespace_name;

其中，CHUNKS列表示表空間中有多少可用的空閒塊(每個空閒塊是由一些連續的Oracle資料塊組成)，
如果這樣的空閒塊過多，比如平均到每個資料檔案上超過了100個，那麼該表空間的碎片狀況就比較嚴重了，
可以嘗試用以下的SQL命令進行表空間相鄰碎片的接合:

alter tablespace 表空間名 coalesce;
 
然後再執行檢視錶空間碎片的SQL語句，看錶空間的碎片有沒有減少。如果沒有效果，
並且表空間的碎片已經嚴重影響到了資料庫的執行，則考慮對該表空間進行重建。

MAX_CHUNK列的結果是表空間上最大的可用塊大小，
如果該表空間上的物件所需分配的空間(NEXT值)大於可用塊的大小的話，
就會提示ORA-1652、ORA-1653、ORA-1654的錯誤資訊，DBA應該及時對錶空間的空間進行擴充，以避免這些錯誤發生。

對錶空間的擴充對錶空間的資料檔案大小進行擴充套件，
或向表空間增加資料檔案，具體操作見“儲存管理”部份。

三、檢視資料庫的連線情況
DBA要定時對資料庫的連線情況進行檢查，看與資料庫建立的會話數目是不是正常，
如果建立了過多的連線，會消耗資料庫的資源。
同時，對一些“掛死”的連線，可能會需要DBA手工進行清理。

以下的SQL語句列出當前資料庫建立的會話情況:

select sid,serial#,username,program,machine,status
from v$session;

其中，SID為 會話(session)的ID號; SERIAL# 會話的序列號，和SID一起用來唯一標識一個會話;
USERNAME 建立該會話的使用者名稱; PROGRAM 這個會話是用什麼工具連線到資料庫的; STATUS 當前這個會話的狀態，
ACTIVE表示會話正在執行某些任務，INACTIVE表示當前會話沒有執行任何操作; 如果DBA要手工kill掉某個會話，則執行:

alter system kill session 'SID,SERIAL#';

注意，上例中SID為1到7(USERNAME列為空)的會話，是Oracle的後臺程式，不要對這些會話進行任何操作。

select sid,serial#,username,program,machine,status
from v$session;

四、控制檔案的備份

在資料庫結構發生變化時，如增加了表空間，增加了資料檔案或重做日誌檔案這些操作，都會造成Oracle資料庫控制檔案的變化，
DBA應及進行控制檔案的備份，備份方法是:

執行SQL語句:

alter database
backup controlfile to '/home/backup/control.bak';
或執行如下語句:
alter database
backup controlfile to trace;
 
這樣，會在USER_DUMP_DEST(初始化引數檔案中指定)目錄下生成建立控制檔案的SQL命令。

五、檢查資料庫檔案的狀態

DBA要及時檢視資料庫中資料檔案的狀態(如被誤刪除)，根據實際情況決定如何進行處理，檢查資料檔案的狀態的SQL如下:

select file_name,status
from dba_data_files;

如果資料檔案的STATUS列不是AVAILABLE，那麼就要採取相應的措施，如對該資料檔案進行恢復操作，或重建該資料檔案所在的表空間。

六、檢查資料庫定時作業的完成情況

如果資料庫使用了Oracle的JOB來完成一些定時作業，要對這些JOB的執行情況進行檢查:

select job,log_user,last_date,failures
from dba_jobs;

如果FAILURES列是一個大於0的數的話，說明JOB執行失敗，要進一步的檢查。

七、資料庫壞塊的處理

當Oracle資料庫出現壞塊時，Oracle會在警告日誌檔案(alert_SID.log)中記錄壞塊的資訊:

ORA-01578: ORACLE data block corrupted (file # 7, block # )

ORA-01110: data file : '/oracle1/oradata/V920/oradata/V816/users01.dbf'
 
其中， 代表壞塊所在資料檔案的絕對檔案號， 代表壞塊是資料檔案上的第幾個資料塊。
出現這種情況時，應該首先檢查是否是硬體及作業系統上的故障導致Oracle資料庫出現壞塊。
在排除了資料庫以外的原因後，再對發生壞塊的資料庫物件進行處理。

1.確定發生壞塊的資料庫物件

SELECT tablespace_name,
segment_type,
owner,
segment_name
FROM dba_extents
WHERE file_id =
AND
between block_id AND block_id+blocks-1;
 
2.決定修復方法

如果發生壞塊的物件是一個索引，那麼可以直接把索引DROP掉後，再根據表裡的記錄進行重建;

如果發生壞塊的表的記錄可以根據其它表的記錄生成的話，那麼可以直接把這個表DROP掉後重建;

如果有資料庫的備份，則恢復資料庫的方法來進行修復;

如果表裡的記錄沒有其它辦法恢復，那麼壞塊上的記錄就丟失了，只能把表中其它資料塊上的記錄取出來，然後對這個表進行重建。

3.用Oracle提供的DBMS_REPAIR包標記出壞塊

exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(' ','');

4.使用Create table as select命令將表中其它塊上的記錄儲存到另一張表上
create table corrupt_table_bak
as
select * from corrupt_table;
 
5.用DROP TABLE命令刪除有壞塊的表
drop table corrup_tatble;
6.用alter table rename命令恢復原來的表
alter table corrupt_table_bak
rename to corrupt_table;
7.如果表上存在索引，則要重建表上的索引

八、作業系統相關維護

DBA要注意對作業系統的監控:

●檔案系統的空間使用情況(df -k)，必要時對Oracle的警告日誌及TRC檔案進行清理

●如果Oracle提供網路服務，檢查網路連線是否正常

●檢查作業系統的資源使用情況是否正常

●檢查資料庫伺服器有沒有硬體故障，如磁碟、記憶體報錯

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13726712/viewspace-671356/，如需轉載，請註明出處，否則將追究法律責任。