水电站监控系统Oracle数据库异常问题分析及处理

林 放

(四川明星电力股份有限公司，四川 遂宁 629000)

Oracle RDBMS是一款关系型数据库管理软件，该软件在数据库领域一直处于领先地位，是目前世界上最流行的关系型数据库管理系统[1]。Oracle数据库具有可移植性好、使用方便、功能强大的特点，因此常用于水电站、水电集控站等场所。目前国内外针对Oracle数据库的使用研究较为成熟[2]，但对应用在水电行业，结合水电站、水电集控站实际情况的研究和问题处理研究较少。因此本文结合水电站、水电集控站的实际情况，通过案例介绍Oracle数据库在集控站后台数据管理中的一些异常处理方法。

1 案例背景

发电分公司由四个梯级水力发电站和一个梯级调度集控中心组成，各梯级子站向集控中心实时传输遥测、遥信数据，同时接受集控中心的遥控和遥调。集控中心使用TJK8600监控软件平台，在已投运的四个梯级发电站中有两座水电站与集控中心软件配置相同，另一座水电站使用的是NC2000监控平台(见表1、图1)。

图1 网络连接拓扑结构图

表1 后台软件配置

2 Oracle数据库常见问题案例分析

Oracle数据库在水电站集控后台运行了三年多，但其间也有不少异常及故障发生，下面分析Oracle数据库在该水电站集控监控系统遇到的一些具体案例。

2.1 报表数据不能正常显示

2.1.1 故障现象

集控中心工程师兼报表工作站报表数据突然不能正常显示，表格内容显示为空白，没有任何字符，同等级的其他工作站如操作员站显示都正常。

2.1.2 排查过程

报表数据消失，应从以下几个方面按顺序进行考虑：首先查看硬件连接是否中断。经过现场检查数据服务器和工作站两端网卡接口数据收发指示灯闪烁正常，表明硬件连接良好。其次，检查底层软件协议部分。用ping命令检查操作系统提供的网络服务是否正常，在终端窗口键入PING ××.×××.×××.×(实时服务器1实际地址)和PING ××.×××.×××.×(历史服务器1实际地址)后，系统回执“××.×××.×××.× is alive”(实时服务器1实际地址)和“××.×××.×××.× is alive”(历史服务器1实际地址)，表明Oracle的客户端和服务端操作系统层面连接正常。最后，从应用和数据服务层面考虑。将应用软件退出运行，重新启动计算机，成功登录后再次启动报表服务和报表软件，打开后故障依然存在，历史报表能查到某一固定时间前的内容，之后的无法查阅，用ps-ef命令检查进程启动情况和用pview l命令查看服务加载情况都没有问题。查询历史报文，发现一条磁盘空间不足的信息“no space left on device”(空间不够用)，但之后就没有再出现，也没有其他故障发生，画面数据显示和简报窗口信息全部正常，Oracle故障日志中也找到了相关的故障代码记录，使用df-h命令查看磁盘空间，OPT分区全满。

2.1.3 故障原因的具体分析及解决方案

安装操作系统时，会划分一个叫/opt的磁盘分区，该分区处于根路径下，用来安装应用软件，通常Oracle会自动安装到该路径下[3]，里面有很多目录和文件(见图2)，配置的数据库文件也会存放到该分区的“opt/data/ics8000/”路径下，随着数据增多，同时由于在/OPT/ORACLE/10.2.0/ADMIN/*/bdump(*号的内容根据你的实际数据库标示名而不同，在此处是ics8000)目录中之前留有大量解决问题后未及时删除的故障日志，opt分区的空间会越来越小，空间占用率接近100%时，就会报空间不足，如果不及时解决，就会持续在bdump和udump目录中继续大量产生报警代码日志文件，导致磁盘空间最终全满[4]。

图2 Oracle安装目录文件情况

由于TJK8600应用软件会在数据写满数据库的情况下将溢出的数据临时写入实时服务器磁盘的“/ICS8000/sql/HIS1”和“/ICS8000/sql/HIS2”目录中，待空间恢复后再写回，以确保数据的完整性，所以只要不将空间全满的服务器退出运行，实时服务器依然能够继续保证数据的正常处理和显示，这就是为什么报表无法显示而操作员站监视不受影响的原因。

磁盘空间全满之后就需要删除bdump和udump目录中的两类文件，一是名称为alert_*.log的日志文件(*号内容根据实际配置不同)，二是.trc后缀文件，该文件是oracle的系统跟踪文件(trace)，当系统启动或运行过程中出现错误、异常时，会自动产生故障跟踪文件到该目录，每个进程或者服务都会产生单独的一个trace文件，可以根据该文件分析异常产生的时间和原因。

使用ls-trc命令按产生时间顺序列出故障文件观察是否可删除，如果是可删除的，再用rm*.trc命令全部删除(有必要也可以备份后删除，但该文件非常零碎，使用‘tar cvf 包存放路径名称 需打包路径’的格式进行一次文件打包，然后使用‘compress 需压缩的包路径名称’格式进行压缩，完成后再用FTP上传备份 )，删除后opt下的空间扩大了不少，再启动报表服务程序显示正常，但之前存放在实时服务器上的数据还需要一段时间写回才能读出，不影响我们使用，至此该故障得以解决。

2.2 操作员站频繁报数据库表空间使用率高

2.2.1 故障现象

过军渡水电站操作员站频繁报数据库表空间使用率超过90%。

2.2.2 故障经过

过军渡水电站在正常运行过程中，监控后台简报窗口突然出现“数据库表空间使用率超过90%”的报文，且每隔一段时间重复出现。

2.2.3 排查过程

根据简报字面提示打开数据库查看，发现实际的用户表空间CBZ8600.DBF已经接近全满，符合简报告警内容，重新扩展新的表空间后，未再出现该报文提示。排查过程如下：首先，用Enterprise Manager Console(EMC)连接该数据库查看实际的空间情况(见图3)，CBZ8600.DBF就是我们当前的用户表空间文件，已经使用100% →退出EMC，并关闭所有的后台应用和数据连接，确保没有任何数据服务启动→使用PL/SQL的sysdba权限连接数据库，在SQL windows中输入命令(注意空格)alter tablespace CBZ8600 add datafile‘/opt/data/ics8000/CBZ860002.dbf’ size 32767M autoextend on next 1024M→使用F8键执行动作。等待一段时间后，系统结束动作，再次用EMC查看，已经有名称为CBZ860002.DBF的新用户表空间文件出现，启动实时数据已经可以连接，故障解决。

图3 EMC中查看的数据情况

2.2.4 故障分析

子站系统没有同集控中心一样独立配置历史服务器和磁盘阵列，历史和实时服务器合并在一起使用，经过几年运行，数据将历史服务器的表空间全部填满，导致数据没有存放的空间，如果不及时解决，当sql目录也被写满之后，可能导致数据因被覆盖而丢失，所以在数据库表空间不足时要及时扩展表空间，或者新增表空间，以防重要数据丢失。

2.3 服务器掉电后重启应用无法连接数据库

2.3.1 故障现象

小白塔水电站后台监控系统突然断电导致服务器得电重新启动后无法正常连接数据库，应用软件启动界面的用户名处没有任何用户可以选择，初步判断为未能读取到数据库内容。

2.3.2 故障经过

小白塔水电站切换厂用电时UPS装置未能及时动作切换电源，监控系统后台的所有服务器和工作站在正常运转过程中突然断电，在UPS恢复供电后监控系统主机自动重新启动，进入操作系统之后应用程序无法启动连接数据库，查看数据服务器发现服务显示窗口报错，数据库启动失败。

2.3.3 排查过程及分析

考虑到是突然断电导致的故障，基本锁定数据库在运行过程中受到断电影响，不但TJK8600应用软件无法连接，使用第三方的软件如PL/SQL也会报错，故障代码如下(见图4)。

图4 ORACLE报监听错误的界面

所有数据连接请求均会收到上述故障提示，依据故障提示代码查询oracle官方给出的说明文件和网上查阅该故障代码解决方案，都是要求检查listenter.ora 和tnsname.ora这两个配置文件是否正常。二者其中一个是监听配置文件，另一个是命名服务配置文件，也就是在netmgr中配置后生成的文件。打开这两个文件，监听配置文件内容见图5，命名服务配置文件内容见图6。

图5 监听配置文件内容

图6 命名服务配置文件内容

经过和正常的主机配置文件对比，发现没有任何问题，况且突然断电会造成配置文件被修改显然不太可能。

考虑到oracle数据库在故障时会有日志文件记录，打开案例一提到过的bdump目录，拷贝出该目录下的alert_ics8000.log日志文件到笔记本电脑上，使用ultraedit(文件内容较大，使用该软件能确保正确打开)查看日志，在alert_ics8000.log文件内的故障时间找到了ORA-00600的故障代码见图7。

图7 alert_ics8000.log日志文件中的故障代码

对于该故障，官方给出的解决方案见图8。

图8 故障代码说明

大体意思是这和回滚有关。回滚，即rollback，这也是一个命令，oracle采用的是事务管理机制，rollback命令就是进行回滚事务内的数据修改并结束事务[5]。当oracle正常运行时回滚段在自动管理undo表空间下是不能被offline和删除的，在参数配置文件spfile中该段配置是AUTO，可以先改成manual之后操作，我们知道undo表空间是用来存储数据被改之前的前镜像，如果出现问题，可以分两种情况来处理。

第一种情况：如果损坏的回滚段没有正在执行的事务，那问题还相对简单，可以直接删除掉该回滚段即可，并且没有数据丢失。

第二种情况：当损坏的undo 表空间的回滚段上还有活动的事务，这种情况就要强行提交这些事务，就会造成一些数据的丢失见图9。

图9 数据库中的回滚表空间

2.3.4 处理步骤

a.启动系统终端窗口，并将用户切换至oracle。

b.通过sqlplus /nolog命令加载sql解释器。

c.运行conn /as sysdba 连接到oracle管理员权限下。

d.使用startup mount启动一个数据库实例。

e.当实例加载成功后用alter system set undo_management="manual" scope=spfile 语句将参数配置中的回滚管理改为手动。

注意，当单独使用startup命令启动时会经历三个过程：startup nomount、alter database mount、alter database open。

f.最后一步执行成功会直接打开数据和日志文件。若数据库有异常，直接startup是无法成功的，所以需要先手动启动第一步，加载参数来修改，修改后要使用shutdown immediate一致性关闭数据库退出实例，再次按上述步骤加载数据库，最后直接startup启动数据库，成功可以看到如下显示(见图10)。

图10 成功启动后的数据库实例

g.oracle数据库成功加载后，实时数据连接就能够运行了，操作主机也能正常读取信息启动。但是不要忘了当前还是手动加载状态，如果重新启动还是需要手动启停，肯定不行。那么回到原点，核心问题是什么，那就是断电导致不能正确回滚，我们只需要用语句删除损坏的回滚表，并重建新的空白回滚表并启用，方法如下：

创建:

create undo tablespace “UNDOTBS02” datafile ‘/opt/oracle/oradata/ics8000/UNDOTBS02.DBF’size 835m reuse autoextend on next 10m maxsize 2048m;

生效:

alter system set undo_tablespace=UNDOTBS02 scope=spfile;

修改回滚为自动:

alter system set undo_management=auto scope=spfile;

删除异常回滚表:

drop tablespace UNDOTBS1 including contents and datafiles;

关闭数据连接:

shutdown immediate;

重启启动数据库:

startup;

3 结 语

Oracle是一款适合大型数据的管理软件，它与solaris操作系统的配合能够最大程度地发挥其性能，相对于其他类型的数据库管理软件，oracle的操作需要具备一定的专业知识，在海量数据的处理上Oracle更快，在数据库管理功能、完整性检查、安全性、一致性方面都有更良好的表现。

无论是什么数据库系统，尽量保证其运行的良好环境才是至关重要的，包括硬件环境和软件环境，平时要做好防失电措施，UPS的检查要定期做，做好数据的备份和垃圾清理，不要随意修改数据结构，不要随便删除不明白的内容，数据库操作时尽量考虑长远一些，不重要的修改最好是积累了多个之后一起处理，切忌频繁改动数据库。

数据库就像是数据的一个管家，有了它的良好运转，才能把数据安排得井井有条，查看调用数据时才不会有这样那样的意外发生，数据的自身才会更加健康有活力，这样的水电站监控系统才能运行得更加持续稳定。