维护论坛警惕Oracle数据库操作高压线.doc

维护论坛——警惕Oracle数据库操作高压线 2005第三期 　　摘要：Oracle数据库在BOSS、客服、彩铃、短消息等产品都有广泛的应用。本文深入分析几则由于人为操作不当造成的数据库事故，并根据案例总结归纳出操作高压线和维护规则，用以指导工程师正确维护Oracle数据库，减少人为事故的发生。　　背景:在日常的数据库技术支持工作中，会发现相当部分的数据库事故和人为操作不当有直接的关系。每次的新员工培训，也会用真实案例来说明和强调正确操作习惯的重要性。在强调职业化，推行可服务性的大环境下，了解数据库操作的高压线，掌握维护规则绕开雷区，就显得格外刻不容缓。为此我特别总结过去一两年中的突出数据库案例，罗列出常见的违规操作，希望借此能够尽可能的减少人为事故，从而提高用户对职业化服务的满意度。哲人说，不要被同一块石头绊倒两次，那么希望通过这篇文章能够避免同样人为事故的再次发生。内容： 　　高压线一：不要随意删除/opt/oracle目录下的任何文件。　　咋看这个标题，看官们第一反应可能是我怎么会去删除数据库文件呢？实际上最近三个月，产品线已经发生过几次数据库日志文件部分或者全部被删，导致数据库宕机的严重事故。究其表面原因，是小局点数据库文件建立在本地磁盘，日志文件的后缀又是.log，因此被维护工程师当成无用的垃圾日志删除。深究其实质原因，是维护工程师对数据库缺乏基本常识，不了解什么是数据库文件，从而碰了数据库操作的高压线。我们先来了解这个案例的来龙去脉。 　　典型案例: 某地系统数据库意外删除所有log file文件 　　办事处工程师到现场解决性能问题，发现Rootvg快满了，决定清除日志文件。工程师使用find –name *log，尽管800工程师在支持电话中警告不能删除数据库文件，现场工程师还是删除了数据库的所有在线重做日志文件（文件后缀为.log）。 　　数据库在删除文件数分钟后宕机，重新启动数据库报错： 　　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后台进程写文件失败，数据库宕机。尝试重新启动数据库失败，错误为： 　　ORA-01110: data file 446: /ICTdata10/oradata