select tablespace_name,
count(*) chunks ,
max(bytes/1024/1024) max_chunk
from dba_free_space
group by tablespace_name; 上面的SQL列出了數據庫中每個表空間的空閑塊情況,如下所示: TABLESPACE_NAME CHUNKS MAX_CHUNK
-------------------- ---------- ----------
INDX 1 57.9921875
RBS 3 490.992188
RMAN_TS 1 16.515625
SYSTEM 1 207.296875
TEMP 20 70.8046875
TOOLS 1 11.8359375
USERS 67 71.3671875 其中，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 SERIAL# USERNAME PROGRAM MACHINE STATUS
---- ------- ---------- ----------- --------------- --------
1 1 ORACLE.EXE WORK3 ACTIVE
2 1 ORACLE.EXE WORK3 ACTIVE
3 1 ORACLE.EXE WORK3 ACTIVE
4 1 ORACLE.EXE WORK3 ACTIVE
5 3 ORACLE.EXE WORK3 ACTIVE
6 1 ORACLE.EXE WORK3 ACTIVE
7 1 ORACLE.EXE WORK3 ACTIVE
8 27 SYS SQLPLUS.EXE WORKGROUP/WORK3 ACTIVE
11 5 DBSNMP dbsnmp.exe WORKGROUP/WORK3 INACTIVE
其中， SID 會話(session)的ID號; SERIAL# 會話的序列號，和SID一起用來唯一標識一個會話; USERNAME 建立該會話的用戶名; PROGRAM 這個會話是用什么工具連接到數據庫的; STATUS 當前這個會話的狀態，ACTIVE表示會話正在執行某些任務，INACTIVE表示當前會話沒有執行任何操作; 假如DBA要手工斷開某個會話，則執行: alter system kill session 'SID,SERIAL#'; 注重，上例中SID為1到7(USERNAME列為空)的會話，是Oracle的后臺進程，不要對這些會話進行任何操作。 四、控制文件的備份 在數據庫結構發生變化時，如增加了表空間，增加了數據文件或重做日志文件這些操作，都會造成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 # 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(' 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提供網絡服務，檢查網絡連接是否正常 ●檢查操作系統的資源使用情況是否正常 ●檢查數據庫服務器有沒有硬件故障，如磁盤、內存報錯 新聞熱點
疑難解答
