oraclemch 2019-10-28
2 参数文件
2.1 参数文件的获取
oracle的初始化参数可以通过查询v$parameter视图得到,在SQL*PLUS中,可以用过show parameter命令来显示某些参数的设置值。
2.2 参数文件
初始化参数文件:pfile
服务器参数文件:spfile
视图v$spparamter记录spfile参数的设置。
没啥好说的,直接学习一下案例分析。
2.3 诊断案例
问题描述:数据库在重新启动时无法正常启动,检查发现undo表空间丢失。
2.3.1 检查alert日志文件
警报日志文件由按时间排序的消息和错误的记录组成。下列信息会记录在警报日志文件中:
(1)内部错误和块损坏
(2)影响数据库结构和参数的操作
(3)例程启动时所有非缺省的初始化参数值
控制警报日志文件位置的初始化参数为:background_dump_dest,缺省文件名为alertorcl.log
查看oracle错误含义:oerr ora 30012(今天才发现oracle错误可以这么查,授人以鱼不如授人以渔啊)
检查警报日志,发现报错原因ora-30012:undo表空间不存在。
2.3.2 尝试重新启动 数据库,检查问题是否仍然存在
startup
启动失败,问题仍然存在
2.3.3 检查数据文件,看undo表空间是否存在
ls -ltr
undotbs.dbf
文件存在
2.3.4 启动数据库到mount状态,检查系统参数
select * from v$datafile;
show parameter undo;
show parameter spfile;
发现系统没有使用spfile,而初始化参数设置的undo表空间为undotbs1,数据库中登记的undo文件为undotbs2.dbf。
2.3.5 检查参数文件
检查pfile文件中的设置
vi initorcl.ora
发现undo表空间参数设置的是undotbs1,参数设置可能和数据库的实际情况不符。
2.3.6 再次检查alert文件
警告日志文件中记录了对于数据库重要操作的信息,可以从中查找undo表空间的操作。
(1)创建数据库时的信息
(2)发现创建undotbs02的记录信息
(3)新的undo表空间被应用
alter system set undo_tablespace=‘UNDOTBS2‘ scope=memory;
可以发现问题就在这里,创建了新的undo表空间以后,因为使用的是pfile文件,切换表空间的修改只对当前实例生效,操作人员忘记了修改pfile文件。
(4)删除了undotbs1的信息
这样再次重新启动数据库的时候,问题出现了,pfile中定义的undotbs1找不到了,而且操作是在很久以前,没人能回忆起来。
2.3.7 修正pfile
修改pfile参数文件,就可以启动数据库。
2.3.8 启动数据库
重新启动数据,启动成功。
第二章完
这个案例发生的比较早,现在没人会用pfile去修改参数吧,也很少从pfile启动数据库吧。不过既然是很久以前的操作,alert日志找得到相关的操作记录吗?