警惕Oracle DB操作高压线

        在日常的数据库技术支持工作中，会发现相当部分的数据库事故和人为操作不当有直接的关系。每次的新员工培训，也会用真实案例来说明和强调正确操作习惯的重要性。在强调职业化，推行可服务性的大环境下，了解数据库操作的高压线，掌握维护规则绕开雷区，就显得格外刻不容缓。为此我特别总结过去一两年中的突出数据库案例，罗列出常见的违规操作，希望借此能够尽可能的减少人为事故，从而提高用户对职业化服务的满意度。哲人说，不要被同一块石头绊倒两次，那么希望通过这篇文章能够避免同样人为事故的再次发生。

    高压线一：不要随意删除/opt/oracle目录下的任何文件。

    咋看这个标题，看官们第一反应可能是我怎么会去删除数据库文件呢？实际上最近三个月，产品线已经发生过几次数据库日志文件部分或者全部被删，导致数据库宕机的严重事故。究其表面原因，是小局点数据库文件建立在本地磁盘，日志文件的后缀又是.log，因此被维护工程师当成无用的垃圾日志删除。深究其实质原因，是维护工程师对数据库缺乏基本常识，不了解什么是数据库文件，从而碰了数据库操作的高压线。

    典型案例: 某地系统数据库意外删除所有log file文件

    办事处工程师到现场解决性能问题，发现Rootvg快满了，决定清除日志文件。工程师使用find name *log，尽管800工程师在支持电话中警告不能删除数据库文件，现场工程师还是删除了数据库的所有在线重做日志文件（文件后缀为.log）。

    数据库在删除文件数分钟后宕机，重新启动数据库报错：


QUOTE:
ORA-313 signalled during: alter database open...
Sat Apr 2 02:20:49 2005
Errors in file /usr/oracle/admin/ora7/udump/ora_27520.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00449: background process "LGWR" unexpectedly terminated with error 313
ORA-00313: open failed for members of log group of thread
ORA-01092: ORACLE instance terminated. Disconnection forced
问题处理过程：

    删除了数据库的所有在线重做日志文件是很严重的事故，而且现场没有任何数据库备份，如果不能恢复后果不堪设想。在经历10个小时的紧急恢复后，数据库终于正常运行。

    总结：

    本案例中的数据库历经紧急恢复得以正常运行，而另一个地方就没有这么幸运，最终是重建库然后导入历史数据。最近已有数起删除日志文件导致的人为事故，尤以举例的事故最为严重，删除了所有的日志文件，希望工程师尤其是新员工引以为戒。

    删除数据库文件是非常严重的人为事故，数据库文件的缺失将直接导致数据库宕机和数据的丢失。那么如何避免删除数据库文件呢？我们需要了解数据库的组织结构，以Oracle来举例，每一个ORACLE数据库是由三种类型的文件组成：数据文件、日志文件、控制文件，缺一不可。另外参数文件、密码文件、归档日志文件也是重要的数据库文件。如果不使用裸设备，这些文件通常存放在oracle用户软件目录/opt/oracle中。如果不清楚文件的作用和来源，就不要随意动/opt/oracle目录下的任何文件。

    高压线二：不能移除表空间的任何数据文件

    一个常见的错误频繁出现在新员工中直接删除表空间的物理数据文件，这个错误多半发生在测试环境或者是新开局。通常的情况是，工程师发现表空间的数据文件建错路径或者无用文件，就手工删除数据文件，导致数据库宕机或者无法启动。

    典型案例：用rm命令物理删除表空间的数据文件

    某地工程师为表空间增加数据文件，后发现文件路径给错，直接用rm命令物理删除了此文件。10分钟后数据库dbw0后台进程写文件失败，数据库宕机。尝试重新启动数据库失败，错误为：


QUOTE:
ORA-01110: data file 446: "/ICTdata10/oradata/ICT/data/ict_restored_data081.dbf"
ORA-01115: IO error reading block from file 446 (block # 1)
ORA-27063: skgfospo: number of bytes read/written is incorrect
SVR4 Error: 6: No such device or address
问题处理过程：

    1. 使用下述命令脱机删除已经丢失的数据文件：


QUOTE:
ALTER DATABASE DATAFILE /ICTdata10/oradata/ICT/data/ict_restored_data080.dbf OFFLINE DROP;
2.启动数据库：alter database open;
    3.删除或者重建表空间

    总结：

    Oracle的原则是一旦一个数据文件被加入到表空间中，那么除非这个表空间被删除，否则不能够将任何数据文件从表空间移除。ALTER DATABASE DATAFILE OFFLINE DROP命令并不是允许移除数据文件，它只是说明有立刻删除这个数据文件所在表空间的意图。因此启动数据库后，必须马上删除或者重建表空间，否则会继续在alert_SID.log中发现上述报错。

    高压线三：数据库软件所在目录不能满

    /opt/oracle通常是数据库软件所在目录，也有局点用/home/oracle。这个目录塞满的后果如同root用户根目录塞满，维护工程师需要时刻留意/opt/oracle有可用空间。开局指导书一般要求安装前/opt/oracle有6G，甚至12G的空间，就是为这个目录留有足够多的空间，避免影响Oracle程序的正常运行，引发灾难性后果。

    典型案例：一节点/opt/oracle满导致RAC另一节点宕机某地发生RAC的一个节点oracle1宕机事故，alert_SID.log报错如下：


QUOTE:
    Thu Nov 11 12:54:57 2004
    Errors in file /home/oracle/app/oracle/admin/ora8/bdump/pmon_21062_ora8.trc:
    ORA-00482: LMD* process terminated with error
    Thu Nov 11 12:54:57 2004
    PMON: terminating instance due to error 482
    Instance terminated by PMON, pid = 21062
问题处理过程：

    LMD* process 是服务于RAC环境的后台进程，ORA-00482的错误表明DLM （Distributed Lock Manager）重新配置没有在规定的等待时间内完成，导致instance crash。该节点宕机由对方节点引起的，任何异常比如网络断开等都有可能，这种异常通称是由Hardware-/OS-issue引起的。

    据现场反馈，事故发生前有刚进行过IBM巡检，IBM工程师发现用户将数据库备份到ORACLE_HOME造成目录满的问题，但没有整改。因此这次事故中oracle2的ORACLE_HOME满和oracle1宕机有直接关联，甚至是直接原因。因此，我们给出exp压缩和磁带的备份方法，并告知注意备份不要保存在ORACLE_HOME目录，以免影响ORACLE的正常运行。

    尽管问题已经定位，但事情并没有就此结束。由于没有及时整改，10天之后工程师反馈由于备份保存在ORACLE_HOME目录造成目录满，RAC中的一台再次意外宕机。

    总结：

    小型机上根目录满会造成各种各样的异常，比如：TELNET失败，执行命令HANG住或者失败，甚至宕机的严重后果。对于数据库也是如此，如果数据库软件所在目录满，也将扰乱Oracle程序的正常运行，造成严重后果。现场工程师需要经常使用df –k观察各目录的空间使用情况。

    此外，在备份指导书中，明确要求备份不要保存在数据库软件所在目录，而是单独为备份文件划分专用的备份目录。在执行exp备份命令时file参数使用全路径，也能够避免上述问题。

    高压线四：正确使用图形工具和第三方工具

    Oracle的图形化工具：企业管理器，DBA Studio等，第三方工具：PL/SQL Developer, TOAD等，因其图形化界面，功能强大，使用方便而广泛流行。但是，这些工具就像“双刃剑”，一方面不用记忆繁琐的命令和数据库对象，加快维护效率，另一方面由于操作简单，如果使用不当则破坏力强大，造成人为事故。

    典型案例：某地因设置数据库停顿模式造成应用中断

    某地数据库突然在业务高峰无法使用，总是得到ora-00020 maximum number of processes (%s) exceeded "。此时连接到oracle的用户已经达到了150（达到参数上限），而数据库平常的连接一般不超过100。现场尝试停止部分应用，减少连接数等措施，均无效。

    问题处理过程：

    检查alert_web.log文件，发现当天有人执行：


QUOTE:
   ALTER SYSTEM SET resource_manager_plan=SYSTEM_PLAN SCOPE=MEMORY;
    ALTER SYSTEM SET resource_manager_plan=INTERNAL_QUIESCE SCOPE=MEMORY SID=*;
怀疑是有人使用oracle的资源管理器（resource manager)将数据库置为停顿模式（QUIESCED),导致数据库无法访问。
    远程紧急尝试各种方法连接数据库，执行ALTER SYSTEM SET resource_manager_plan="" SCOPE=MEMORY;
    取消系统当前的资源管理计划。数据库在几分钟内恢复正常，业务恢复。经过仔细检查，发现SYS用户下还有两个定时job，是这两个job发出了利用资源计划将数据库设为停顿的命令。为消除隐患，现场将这两个定时任务删除。

    总结：

    停顿是一个9i的新特征，使得DBA可以完成一些数据库处于受限模式才能完成的一些操作。当使用oracle的资源管理器向数据库发出停顿命令后，因为当前数据库还有大量活动事务，故数据库一直处于要想停顿，但还要等待活动的运行事务完成，此时数据库可能会启动很多垃圾连接来阻止新用户登陆，造成业务中断数个小时。这是一个典型的使用图形工具发出错误指令，造成严重后果的案例。

    典型案例：某地因SELECT FOR UPDATE造成同步中断

    某地割接后第二天中午12点突然发现一个子节点的同步异常，刷新组的job中断近一个小时。发现日志中报错：


QUOTE:
    ORA-12012: error on auto execute of job 23
    ORA-12008: error in materialized view refresh path
    ORA-02049: timeout: distributed transaction waiting for lock
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
    ORA-06512: at "SYS.DBMS_IREFRESH", line 683
    ORA-06512: at "SYS.DBMS_REFRESH", line 195
    ORA-06512: at line 1
维护人员尝试重新运行job但不成功，再次得到ORA-02049错误。因此重启数据库，又杀掉数据库中的一个一直存在的本地连接。此后job运行成功，同步恢复。

    问题原因分析：

    维护人员反馈曾将在主节点PL/SQL Developer下执行的更新语句直接拷贝到同步节点执行，语句如下：


QUOTE:
Select * from t_userinfo where phonenumber=’***’ for update;
发生问题的数据库是一个仅存放只读快照的数据库，也就是说这个库是不应该有任何DML操作的。ORA-02049表明同步写数据失败，问题原因是此语句对同步节点的只读快照加锁，直接修改/加锁了同步节点的物化视图，造成同步写失败，导致应用失常用户投诉。

    总结：

    如果使用PL/SQL Developer直接修改记录，那么会自动生成SELECT FOR UPDATE的语句。一个普通的SELECT操作不会对正处理的行执行任何锁定设置，但加上FOR UPDATE会在相关数据行上加互斥锁，直到整个事务被提交才释放。工程师拷贝执行了错误的语句，而且没有关闭命令窗口，事务一直没有提交或者回滚，造成此次事故。
    最近已经发生数起使用PL/SQL Developer更新用户表或者系统表，没有关闭命令窗口，事务一直没有提交或者回滚，造成锁等待影响数据库正常运行的事故。

    结语

    红灯停，绿灯行。只有遵守交通规则，才能避免安全事故。硬盘坏、数据库BUG造成数据库事故的是小概率事件。更多数据库事故是人为原因，该调的参数没有调，该日常巡检观察的没有检查，该注意的事项没有规避等等。近一两年发布的各种安装、维护、巡检、备份等系列指导书，专门归纳常见热点问题的数据库FAQ，以及收录产品线原创好文的主机空间，涵盖了数据库日常维护的方方面面，包括知识点、操作命令，维护经验和注意事项等等内容，希望工程师能够好好的使用这些资料，提高维护技能。只要我们掌握维护规则，避开数据库操作的高压线，就能够有效的减少外购件的人为事故。