核心业务系统数据库日常维护及紧急预案.doc

核心业务系统日常维护及紧急预案目录一：系统维护组工作职责3二：日常例行检查3三：日常监控431数据库方面432应用服务器方面5四核心业务系统数据服务器应急方案61.人为操作失误62.数据库系统崩溃63.主数据库服务器崩溃（但磁盘阵列正常）74.主数据库服务器崩溃（磁盘阵列不可用）7 一：系统维护组工作职责系统维护组的职责很就是维护业务系统的正常运作，在工作时间保证业务系统的正常使用。由于整个业务系统的正常运行，涉及到应用服务器(weblogic)，数据库(oracle)，网络，操作系统，服务器硬件等，其中任何一个环节不正常，都会导致整个应用系统无法正常使用。系统维护组主要有下面的几个工作职责1. 设计整个业务系统运行架构2. 安装操作系统，调优操作系统3. 安装新的应用服务器4. 安装数据库，调优数据库5. 调优应用服务器6. 监控系统的正常运行，包括操作系统，数据库，中间件，网络7. 监控一线操作人员登陆业务系统，业务使用系统情况二：日常例行检查对于每天业务系统正式使用前的例行检查，从整个业务系统来看，有下面几个方面具体监控检测方法详见核心系统日常监控操作说明1 网络是否通畅(ping服务器)，后期考虑从各个网段测试2 操作系统是否正常（做远程登陆测试）3 系统负载是否正常（cpu,ram,io,process），用top检查4 数据库运行是否正常（做登陆尝试）5 检查alert_SID.log文件,看是否有ora错误6 检查数据库容量以及剩余空间情况7 Apache是否正常（做http连接测试）8 应用服务器是否正常（做http连接测试）9 应用服务器和数据库连接是否正常（通过应用服务器做db测试）10 整个业务系统是否正常（做http登陆测试）11 检查磁盘空间是否足够（df）12 检查操作系统最后一次用户登陆(last)13 检查操作系统log情况(/var/log/ messages)14 检查普通用户su 为root情况（/var/log/ secure）三：日常监控具体监控检测方法详见核心系统日常监控操作说明31数据库方面1 定时做statspack统计，里面包含了很多的系统信息，基本足够用2 监控listener情况，看是否正常3 监控cpu负载情况4 监控内存使用情况，以及内存交换情况5 监控进程运行情况，是否有排队现象6 监控altert_SID.log文件，看是否有ORA错误7 监控网络流量8 监控磁盘io情况9 监控进程是否有长时间高cpu负载情况10 监控系统session等待事件11 监控是否有长时间锁对象情况12 监控是否及时归档13 监控data guard恢复情况14 检查备份是否可用32应用服务器方面 1 监控cpu负载情况2 控内存使用情况，以及内存交换情况3 控进程运行情况，是否有排队现象4 监控网络流量5 监控磁盘io情况6 监控jvm运行情况，主要是内存回收和分配情况，便于性能调优7 监控应用服务器数据库连接池情况8监控用户连接情况，从apache和应用服务器两方面监控四核心业务系统数据服务器应急方案 核心系统数据库主要会有以下几个方面的问题1.人为操作失误如drop table,truncate table等，或者update 语句没有写上正确的where 条件，导致系统数据出现问题 对于这种错误，首先要加强对系统维护人员的权限管理，做到在满足日常维护的情况下，尽量赋予少的权限，减少人工失误。还有需要加强对系统维护人员的专业技能培训，而且需要建立比较好的复查机制，减少人为的失误。对于这种事故的处理， 主要有下面的几种处理方法:通过备份数据恢复通过保留的归档日志恢复数据通过data guard如果data guard还没有恢复到事故点，可以通过以只读方式打开data guard恢复数据目前是设置了四个小时的延迟，所以在这种事故发生后，需要在最快的时间内通知到数据库管理员，发现的越早，恢复成本就越低2.数据库系统崩溃这种情况通常是数据库系统出现很严重的问题，如某个核心进程死掉，OS出现异常情况等。对于这种事故的处理，主要处理方法如下保存当前数据库状态，包括日志文件，数据文件，控制文件直接重起数据库，大多数情况下，数据库系统应该能够正常恢复如果不能正常起来，请参看后面通过data guard恢复主库3.主数据库服务器崩溃（但磁盘阵列正常）包括OS宕机，硬件故障等。由于我们的核心系统采用HA方案，在这种情况下，如果数据库本身没有问题，只是OS一级的问题导致宕机，HA会自动从备机启动数据库，恢复数据库系统的正常。然后再单独处理故障主机。4.主数据库服务器崩溃（磁盘阵列不可用）