网站建设专员,公司网站建设需要什么科目,番禺区核酸检测点,奥创工作手机微信管理系统在日常的数据库技术支持工作中#xff0c;会发现相当部分的数据库事故和人为操作不当有直接的关系。每次的新员工培训#xff0c;也会用真实案例来说明和强调正确操作习惯的重要性。在强调职业化#xff0c;推行可服务性的大环境下#xff0c;了解数据库操作的高压线#…在日常的数据库技术支持工作中会发现相当部分的数据库事故和人为操作不当有直接的关系。每次的新员工培训也会用真实案例来说明和强调正确操作习惯的重要性。在强调职业化推行可服务性的大环境下了解数据库操作的高压线掌握维护规则绕开雷区就显得格外刻不容缓。为此我特别总结过去一两年中的突出数据库案例罗列出常见的违规操作希望借此能够尽可能的减少人为事故从而提高用户对职业化服务的满意度。哲人说不要被同一块石头绊倒两次那么希望通过这篇文章能够避免同样人为事故的再次发生。高压线一不要随意删除/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 2004Errors in file /home/oracle/app/oracle/admin/ora8/bdump/pmon_21062_ora8.trc:ORA-00482: LMD* process terminated with errorThu Nov 11 12:54:57 2004PMON: terminating instance due to error 482Instance 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_planSYSTEM_PLAN SCOPEMEMORY;ALTER SYSTEM SET resource_manager_planINTERNAL_QUIESCE SCOPEMEMORY SID*;
怀疑是有人使用oracle的资源管理器resource manager)将数据库置为停顿模式QUIESCED),导致数据库无法访问。远程紧急尝试各种方法连接数据库执行ALTER SYSTEM SET resource_manager_plan SCOPEMEMORY; 取消系统当前的资源管理计划。数据库在几分钟内恢复正常业务恢复。经过仔细检查发现SYS用户下还有两个定时job是这两个job发出了利用资源计划将数据库设为停顿的命令。为消除隐患现场将这两个定时任务删除。 总结停顿是一个9i的新特征使得DBA可以完成一些数据库处于受限模式才能完成的一些操作。当使用oracle的资源管理器向数据库发出停顿命令后因为当前数据库还有大量活动事务故数据库一直处于要想停顿但还要等待活动的运行事务完成此时数据库可能会启动很多垃圾连接来阻止新用户登陆造成业务中断数个小时。这是一个典型的使用图形工具发出错误指令造成严重后果的案例。典型案例某地因SELECT FOR UPDATE造成同步中断某地割接后第二天中午12点突然发现一个子节点的同步异常刷新组的job中断近一个小时。发现日志中报错QUOTE:ORA-12012: error on auto execute of job 23ORA-12008: error in materialized view refresh pathORA-02049: timeout: distributed transaction waiting for lockORA-06512: at SYS.DBMS_SNAPSHOT, line 803ORA-06512: at SYS.DBMS_SNAPSHOT, line 860ORA-06512: at SYS.DBMS_IREFRESH, line 683ORA-06512: at SYS.DBMS_REFRESH, line 195ORA-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以及收录产品线原创好文的主机空间涵盖了数据库日常维护的方方面面包括知识点、操作命令维护经验和注意事项等等内容希望工程师能够好好的使用这些资料提高维护技能。只要我们掌握维护规则避开数据库操作的高压线就能够有效的减少外购件的人为事故。
