在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提供网络服务检查网络连接是否正常
●检查操作系统的资源使用情况是否正常
●检查数据库服务器有没有硬件故障如磁盘内存报错
