标签：出现 状态 lte memory 日志文件 分析 位置 数值 天才
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日志找得到相关的操作记录吗？
标签：出现 状态 lte memory 日志文件 分析 位置 数值 天才
原文地址：https://www.cnblogs.com/myheart-new/p/11751188.html
