Oracle 日常维护

 

ORACLE数据库管理员应按如下方式对ORACLE数据库系统做定期监控：
  
(1). 每天对ORACLE数据库的运行状态,日志文件,备份情况,数据库的空间使用情况,系统资源的使用情况进行检查,发现并解决问题。  
(2). 每周对数据库对象的空间扩展情况,数据的增长情况进行监控,对数据库做健康检查,对数据库对象的状态做检查。  
(3). 检查表空间碎片,提出下一步空间管理计划。对ORACLE数据库状态进行一次全面检查。  
====================
★每天的工作★  
====================
(1).确认所有的INSTANCE状态正常.登陆到所有数据库或例程,检测ORACLE后台进程:  
$ps –-ef|grep ora 

(2). 检查文件系统的使用（剩余空间）。如果文件系统的剩余空间小于20%，需删除不用的文件以释放空间。
对于太平洋业务交易生产系统,要特别关注: /u01  和  数据库日志归档目录,当空间不足,请急时清理. 
$df -k  
$df -h
(3). 检查日志文件和trace文件记录alert和trace文件中的错误.连接到每个需管理的系统  
※ 使用’telnet’  
※ 对每个数据库,cd 到bdump目录,通常是$ORACLE_BASE/admin/<SID>/bdump  
※ 使用 Unix ‘tail’命令来查看alert_<SID>.log文件  
※ 如果发现任何新的ORA- 错误,记录并解决 

(4). 检查数据文件的状态记录状态不是“online”的数据文件，并做恢复。  
Select file_name from dba_data_files where status=’OFFLINE’  
(5). 检查表空间的使用情况  
--如果有表空间大于90%的就应该在当天清算前,增大该表空间,但对于(temp,undo)表空间除外,
--重点关注HS_HIS_data 和 HS_HIS_IDX 这两个表空间.
SELECT d.tablespace_name, SPACE "SUM_SPACE(M)", blocks sum_blocks,
       SPACE - NVL (free_space, 0) "USED_SPACE(M)",
       ROUND ((1 - NVL (free_space, 0) / SPACE) * 100, 2) "USED_RATE(%)",
       free_space "FREE_SPACE(M)"
  FROM (SELECT   tablespace_name, ROUND (SUM (BYTES) / (1024 * 1024),
                                         2) SPACE, SUM (blocks) blocks
            FROM dba_data_files
        GROUP BY tablespace_name) d,
       (SELECT   tablespace_name,
                 ROUND (SUM (BYTES) / (1024 * 1024), 2) free_space
            FROM dba_free_space
        GROUP BY tablespace_name) f
WHERE d.tablespace_name = f.tablespace_name(+)
UNION ALL                                                   --if have tempfile
SELECT d.tablespace_name, SPACE "SUM_SPACE(M)", blocks sum_blocks,
       used_space "USED_SPACE(M)",
       ROUND (NVL (used_space, 0) / SPACE * 100, 2) "USED_RATE(%)",
       NVL (free_space, 0) "FREE_SPACE(M)"
  FROM (SELECT   tablespace_name, ROUND (SUM (BYTES) / (1024 * 1024),
                                         2) SPACE, SUM (blocks) blocks
            FROM dba_temp_files
        GROUP BY tablespace_name) d,
       (SELECT   tablespace_name,
                 ROUND (SUM (bytes_used) / (1024 * 1024), 2) used_space,
                 ROUND (SUM (bytes_free) / (1024 * 1024), 2) free_space
            FROM v$temp_space_header
        GROUP BY tablespace_name) f
WHERE d.tablespace_name = f.tablespace_name(+);  
(6). 检查剩余表空间  
/* Formatted on 2007/03/01 15:56 (Formatter Plus v4.8.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;

(7). 监控数据库性能运行AWR生成系统报告或者使用statspack收集统计数据  
※注意:TOP-5事件
(8). 检查数据库性能，记录数据库的cpu使用、IO、buffer命中率等等  
使用vmstat,iostat,glance,top等命令  
(9). 日常出现问题的处理。

==================== 
★每周的工作★  
====================
(1). 监控数据库对象的空间扩展情况  
根据本周每天的检查情况找到空间扩展很快的数据库对象,并采取相应的措施
--- 重点关注HS_HIS_data 和 HS_HIS_IDX 这两个表空间  
--- 删除历史数据  
--- 扩表空间  
alter tablespace <name> add datafile ‘<file>’ size <size>;  
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO; 
(2). 监控数据量的增长情况  
根据本周每天的检查情况找到记录数量增长很快的数据库对象,并采取相应的措施  
--- 重点关注HS_HIS_data 和 HS_HIS_IDX 这两个表空间
--- 删除历史数据  
--- 扩表空间  
alter tablespace <name> add datafile ‘<file>’ size <size>;  
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;   
(3). 系统健康检查  
检查以下内容:  
init<sid>.ora  
controlfile  
redo log file  
archiving  
sort area size  
tablespace(system,temporary,tablespace fragment)  
datafiles(online/offline)  
object(number of extent,next extent,index)  
rollback segment  
logging &tracing(alert.log,max_dump_file_size,sqlnet)  
(4). 检查无效的数据库对象  
/* Formatted on 2007/03/01 16:04 (Formatter Plus v4.8.7) */ 
--look over invalid objects 
SELECT owner, object_name, object_type
  FROM dba_objects
WHERE status = 'invalid';  
(5). 检查不起作用的约束  
/* Formatted on 2007/03/01 16:07 (Formatter Plus v4.8.7) */
SELECT owner, constraint_name, table_name, constraint_type, status
  FROM dba_constraints
WHERE status = 'DISABLED' AND constraint_type = 'P' ; 
(6). 检查无效的trigger  
/* Formatted on 2007/03/01 16:08 (Formatter Plus v4.8.7) */ 
--look over triggers state 
SELECT owner, trigger_name, table_name, status
  FROM dba_triggers
WHERE status = 'DISABLED'; 
  
====================
★每月的工作★  
====================
(1). 检查表空间碎片  
根据本月每周的检查分析数据库碎片情况,找到相应的解决方法  
(2). 寻找数据库性能调整的机会  
比较每天对数据库性能的监控报告,确定是否有必要对数据库性能进行调整  
(3). 数据库性能调整  
如有必要,进行性能调整  
(4). 提出下一步空间管理计划  
根据每周的监控,提出空间管理的改进方法  
======================================
======================================
||   ★★★Oracle DBA 日常管理★★★ || 
======================================
======================================
目的：这篇文档有很详细的资料记录着对一个甚至更多的ORACLE 数据库每天的，每月的，每年的运行的状态的结果及检查的结果，在文档的附录中你将会看到所有检查，修改的SQL和PL/SQL 代码。  
-------------
★目录 ★ 
-------------
1.日常维护程序  
A． 检查已起的所有实例  
B． 查找一些新的警告日志  
C． 检查DBSNMP 是否在运行  
D． 检查数据库备份是否正确  
E． 检查备份到磁带中的文件是否正确  
F． 检查数据库的性能是否正常合理，是否有足够的空间和资源  
G． 将文档日志复制到备份的数据库中  
H． 要常看DBA 用户手册  
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． 周维护过程  
6.参考文献  
---------------------------------------------------------------  
==================
★一．日维护过程★  
==================
A．查看所有的实例是否已起  
确定数据库是可用的，把每个实例写入日志并且运行日报告或是运行测试文件。当然有一些操作我们是希望它能自动运行的。  
可选择执行：用ORACLE 管理器中的‘PROBE’事件来查看 

B．查找新的警告日志文件  
1). 联接每一个操作管理系统  
2). 使用‘TELNET’或是可比较程序  
3). 对每一个管理实例，经常的执行$ORACLE_BASE/<SID>/bdump 操作，并使其能回退到控制数据库的SID。  
4). 在提示下，使用UNIX 中的‘TAIL’命令查看alert_<SID>.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．查看对数据库会产生危害的增长速度  
>从以前的记录或报告中回顾段增长的变化以此来确定段增长带来危害  
B． 回顾以前数据库优化性能的调整  
>回顾一般ORACLE 数据库的调整点，比较以前的报告来确定有害的发展趋势。  
C． 查看I/O 的屏颈问题  
1. 查看前期数据库文件的活动性，比较以前的输出来判断有可能导致屏颈问题的趋势。  
D． 回顾FRAGMENTATION  
E． 计划数据库将来的性能  
>比较ORACLE 和操作系统的CPU，内存，网络，及硬盘的利用率以此来确定在近期将会有的一些资源争夺的趋势  
>当系统将超出范围时要把性能趋势当作服务水平的协议来看  
F． 完成调整和维护工作  
>使修改满足避免系统资源的争夺的需要，这里面包括增加新资源或使预期的停工。  
----------------------------------------------------------------  
==============
★五．附录★  
==============
===============
★A. 日常程序★  
===============
※做好每天的记录,总结分析表空间的增长幅度※
-★- Free.sql  
/* Formatted on 2007/03/06 16:54 (Formatter Plus v4.8.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 
-★- Space.sql  
-- To check free, pct_free, and allocated space within a tablespace   
/* Formatted on 2007/03/06 16:58 (Formatter Plus v4.8.7) */
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 
-★- 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)  
BEGIN  
dbms_utility.analyze_schema ( '&OWNER', 'ESTIMATE', NULL, 5 ) ;  
END ;  
/  
-★- nr_extents.sql  
-- To find out any object reaching <threshold>;  
-- extents, and manually upgrade it to allow unlimited max_extents (thus only objects we *expect* to be big are allowed to become big)  

/* Formatted on 2007/03/06 17:25 (Formatter Plus v4.8.7) */
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 (*)) < &&threshold)
ORDER BY COUNT (*) DESC  
-★- 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 <foo>; coalesce .  
-- Lastly, add another datafile to the tablespace if needed.  
/* Formatted on 2007/03/06 17:26 (Formatter Plus v4.8.7) */
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. 每晚处理程序★ 
===================
-★- 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  
/  
-★-analyze_comp.sql  
BEGIN  
sys.dbms_utility.analyze_schema ( '&OWNER','COMPUTE');  
END ;  
/  
-★-pop_vol.sql  
/* Formatted on 2007/03/06 17:28 (Formatter Plus v4.8.7) */
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  
-- 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.  
/* Formatted on 2007/03/06 17:30 (Formatter Plus v4.8.7) */
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  
-- 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.    
/* Formatted on 2007/03/06 17:31 (Formatter Plus v4.8.7) */
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  
-- To find tables without PK constraint  
/* Formatted on 2007/03/06 17:31 (Formatter Plus v4.8.7) */
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  
-- To find out which primary keys are disabled  
/* Formatted on 2007/03/06 17:32 (Formatter Plus v4.8.7) */
SELECT owner, constraint_name, table_name, status
  FROM all_constraints
WHERE owner = '&OWNER' AND status = 'DISABLED' AND constraint_type = 'P' 
5. 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.   
/* Formatted on 2007/03/06 17:33 (Formatter Plus v4.8.7) */
SELECT index_name, table_name, uniqueness
  FROM all_indexes
WHERE index_name LIKE '&KNAME%'
   AND owner = '&OWNER'
   AND uniqueness = 'NONUNIQUE'
UNION
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  
-- Rebuild indexes to have correct storage parameters  
/* Formatted on 2007/03/06 17:33 (Formatter Plus v4.8.7) */
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  
-- To check datatype consistency between two environments  
/* Formatted on 2007/03/06 17:34 (Formatter Plus v4.8.7) */
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 [email=all_tab_columns@&my_db_link]all_tab_columns@&my_db_link[/email]   -- second environment
   WHERE owner = '&OWNER2'
ORDER BY table_name, column_name ;
  
8. obj_coord.sql  
-- To find out any difference in objects between two instances  
/* Formatted on 2007/03/06 17:35 (Formatter Plus v4.8.7) */
SELECT object_name, object_type
  FROM user_objects
MINUS
SELECT object_name, object_type
  FROM [email=user_objects@&my_db_link]user_objects@&my_db_link[/email]
================
★六. 参考文献★
================ 
1. Loney, Kevin Oracle8 DBA Handbook  
2. Cook, David Database Management from Crisis to Confidence  
[ http://www.orapub.com/ ]  
3. Cox, Thomas B. The Database Administration Maturity Model

---------------------------------------------------其他文档

 在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。

 

一、 Oracle 警告日志文件监控

Oracle 在运行过程中，会在警告日志文件 (alert_SID.log) 中记录数据库的一些运行情况：

l         数据库的启动、关闭，启动时的非缺省参数；

l         数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点 (checkpoint) 操作没有执行完成造成不能切换，会记录不能切换的原因；

l         对数据库进行的某些操作，如创建或删除表空间、增加数据文件；

l         数据库发生的错误，如表空间不够、出现坏块、数据库内部错误 (ORA － 600)

 

DBA 应该定期检查日志文件，根据日志中发现的问题及时进行处理

问题	处理
启动参数不对	检查初始化参数文件
因为检查点操作或归档操作没有完成造成重做日志不能切换	如果经常发生这样的情况，可以考虑增加重做日志文件组；想办法提高检查点或归档操作的效率；
有人未经授权删除了表空间	检查数据库的安全问题，是否密码太简单；如有必要，撤消某些用户的系统权限
出现坏块	检查是否是硬件问题 ( 如磁盘本生有坏块 ) ，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建
表空间不够	增加数据文件到相应的表空间
出现 ORA-600	根据日志文件的内容查看相应的 TRC 文件，如果是 Oracle 的 bug ，要及时打上相应的补丁

 

二、 数据库表空间使用情况监控（字典管理表空间）

数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片， DBA 应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。

 

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 # <BLOCK>)

   ORA-01110: data file <AFN>: '/oracle1/oradata/V920/oradata/V816/users01.dbf'

 

其中，＜ AFN ＞代表坏块所在数据文件的绝对文件号， <BLOCK> 代表坏块是数据文件上的第几个数据块

出现这种情况时，应该首先检查是否是硬件及操作系统上的故障导致 Oracle 数据库出现坏块。在排除了数据库以外的原因后，再对发生坏块的数据库对象进行处理。

1． 确定发生坏块的数据库对象

SELECT tablespace_name,

segment_type,

owner,

segment_name

FROM dba_extents

WHERE  file_id = <AFN>

AND <BLOCK> between block_id AND block_id+blocks-1;

2． 决定修复方法

如果发生坏块的对象是一个索引，那么可以直接把索引 DROP 掉后，再根据表里的记录进行重建；

如果发生坏块的表的记录可以根据其它表的记录生成的话，那么可以直接把这个表 DROP 掉后重建；

如果有数据库的备份，则恢复数据库的方法来进行修复；

如果表里的记录没有其它办法恢复，那么坏块上的记录就丢失了，只能把表中其它数据块上的记录取出来，然后对这个表进行重建。

3． 用 Oracle 提供的 DBMS_REPAIR 包标记出坏块

exec DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('<schema>','<tablename>');

4． 使用 Create table as select 命令将表中其它块上的记录保存到另一张表上

create table corrupt_table_bak

 as

 select * from corrupt_table;

5． 用 DROP TABLE 命令删除有坏块的表

drop table corrupt_table;

6． 用 alter table rename 命令恢复原来的表

alter table corrupt_table_bak

 rename to corrupt_table;

7． 如果表上存在索引，则要重建表上的索引

 

八、 操作系统相关维护

DBA 要注意对操作系统的监控：

l  文件系统的空间使用情况（ df -k ），必要时对 Oracle 的警告日志及 TRC 文件进行清理

l  如果 Oracle 提供网络服务，检查网络连接是否正常

l  检查操作系统的资源使用情况是否正常

l  检查数据库服务器有没有硬件故障，如磁盘、内存报错