oracle学习篇:二、参数文件

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日志找得到相关的操作记录吗?

相关推荐