数据库故障处理应急方案Word文档下载推荐.docx
- 文档编号:22158744
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:17
- 大小:22.24KB
数据库故障处理应急方案Word文档下载推荐.docx
《数据库故障处理应急方案Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《数据库故障处理应急方案Word文档下载推荐.docx(17页珍藏版)》请在冰豆网上搜索。
copy数据文件至目标位置
ALTERDATABASECREATEDATAFILE'
源文件'
AS'
目标文件'
4、恢复数据文件
5、将数据文件改为在线状态
6、将错误的本地数据文件移到其他路径,避免“/oracle”文件系统使用比率达到告警值。
7、确认数据库告警日志无报错。
(场景三)解决方法:
1、除了恢复,没有太好的方法。
需要备份、归档都在。
(场景四)解决方法:
1、检查本地存在的数据文file_id.<
==模糊查询/oracle目录下的数据文件
SQL>
selectfile_name,file_idfromdba_data_fileswherefile_namelike'
/oracle%'
FILE_NAMEFILE_ID
-------------------------------------------------------------------------------------------------
/oracle/products/oracle/dbs/WPS_CEIDB_cei_ts_extended25
2、使用本地数据文件脱机
alterdatabasedatafile25offline;
3、使用asmcmd命令copy数据文件至ASM目录
ASMCMD>
cdESOPMDDG/esopmddb/datafile/<
===该路径为数据文件的路径
cp/oracle/products/oracle/dbs/WPS_CEIDB_cei_ts_baseWPS_CEIDB_cei_ts_base.dbf
4、rename数据文件路径
alterdatabaserenamefile'
/oracle/products/oracle/dbs/WPS_CEIDB_cei_ts_base'
to'
+ESOPMDDG/esopmddb/datafile/WPS_CEIDB_cei_ts_base.dbf'
5、recoverdatafile25;
<
=这个时候会报错,提示找不到其他节点的的归档文件.
ORA-00308:
cannotopenarchivedlog'
/arch01/esopmddb1/2_88_790625996.dbf'
6、将另外一个节点的归档复制一份
rcp2_88_790625996.dbforacle@s1-esop-db-ng:
/arch01/esopmddb1
7、recoverdatafile25;
恢复成功。
8、使文件联机
alterdatabasedatafile25online;
二.服务切换应急处理
场景一:
当我们在进行服务切换时,无法从一个节点切换到另外一个节点。
一般包含以下几种:
A、目标节点实例异常,服务无法切换。
B、持有服务节点无法释放,服务无法切换
C、BUG
解决方法:
(场景一)解决方法:
1.首先使用srvctlstartservice-d<
db_name>
[-s<
service_name>
[-i<
inst_name>
]]命令切换。
例如:
srvctlstartservice-dfsdb-ssmm–ifsdb1
2.当上面命令,可以使用以下命令进行强制服务切换:
altersystemsetservice_names=‘s1,s2’;
例如:
altersystemsetservice_names='
sfs,smm'
scope=memorysid='
FSDB1'
然后查看是否注册成功:
showparameterservice
NAMETYPEVALUE
-----------------------------------------------------------------------------
service_namesstringsfs,smm
3.检查监听并测试连接测试是否生效
$lsnrctlservice
$sqlplussys/oracle@node_vip:
1521/service_name
4、如果连接不成功,按照以下命令排查.
检查实例启动时间:
selectinstance_number,status,startup_timefromgv$instance;
检查数据库状态:
selectinst_id,open_modefromgv$database;
检查alert.log日志:
Completed:
ALTERDATABASEOPEN(是否完成)
检查服务运行情况:
srvctlstatusservice-d<
检查服务配置情况:
srvctlconfigservice-d<
-a
三.'
TX,TM,DX'
锁应急处理
数据库大量锁异常等待,系统资源消耗高,cpu负载高(针对大量'
等类型的锁造成的大量异常等待)
多个事务争用造成。
解决方法
以下语句列出是谁造成了阻塞
columneventformata30
columnsessformata20
setlinesize250
setpagesize0
breakonid1skip1
selectdecode(request,0,'
Holder:
'
'
Waiter:
)||s.inst_id||'
:
||s.sid||'
||s.serial#sess,
id1,id2,lmode,request,l.type,ctime,s.username,s.sql_id,s.event
--,s.service_name
fromgv$lockl,gv$sessions
where(id1,id2,l.type)in
(selectid1,id2,typefromgv$lockwhererequest>
)
andl.sid=s.sid
andl.inst_id=s.inst_id
orderbyid1,ctimedesc,request
/
按照这个语句多查询几次,如果Holder不变,则KILL掉。
操作前记录相关日志
四.Latchfree应急处理
数据库大量latchfree等待,系统资源消耗高,cpu负载接近100%
1.手动执行hang查杀脚本:
/usr/bin/ksh/home/oracle/auto_hang_analyze.sh
观察几分钟,如果latchfree等待事件一直没有下降,则执行第二步。
2.查询当前active的会话模块:
selectusername,machine,count(*)fromv$sessionwherestatus='
ACTIVE'
havingcount(*)>
6groupbyusername,machineorderby1;
将会话数量过多的模块通知开发商,让他们切换部分业务到另外一个节点
然后进行系统资源监控和数据库监控
五.Cachebufferchains应急处理
数据库大量cachebufferchains等待,系统资源消耗高,cpu负载高
A.低效的SQL语句是发生cachebufferschains(热块争用),锁存器争用的最重要原因。
B.多个进程同时扫描大范围的索引或表时,可能广泛引发cachebufferschains锁存器争用。
C.应用程序打开执行相同的低效率SQL语句的多个并发会话,并且这些SQL语句都设法得到相同的数据集,这种情景十分普遍。
1.查看latch:
cachebufferschains事件相关的会话信息;
selectsid,username,machine,program,p1raw,sql_id,logon_time,last_call_etfromv$sessionwhereevent='
latch:
cachebufferschains'
使用ora命令oraget_kill_sh&
sql_id&
username进行查杀.
查杀后记录该sql语句,丢给相应的开发商处理
2、查看哪个SQL执行的次数最多
selectsql_id,count(*)fromv$sessionwhereevent='
groupbysql_idorderby2;
六.Librarycachelock应急处理
数据库大量librarycachelock等待,系统资源消耗高,cpu的idle为0
librarycachelock出现的情况比较复杂,例如:
A、大量对某个对象访问;
B、sharedpool有问题;
1、看看是不是某条SQL引起
librarycachelock'
然后分析SQL中的对象和执行计划等,再跟开发商确认,用oraget_kill_sh进行杀
2、sharedpool的内部结构造成,再开一个窗口用topas监控系统资源,然后清理sharedpool
altersystemflushsharedpool;
(该操作需要向直属领导确认)
七.gcbufferbusy应急处理
一般的现象为CPU较高,IO较忙,处理方法与cachebufferchains应急处理一样
gcbufferbusy出现在RAC中,出现概率并不高,因为BOSS是对业务做了分离的,是由于多节点同时大量访问某些数据块引起的
gcbufferbusy'
gcbufferbusy'
八.连接不上数据库
数据库无法连接
客户报连接不上数据库,例如:
1、连接数达到上限;
2、监听有问题;
1、看看连接数
showparametersession;
selectcount(*)fromv$session;
若我们用sqlplus/assysdba也无法连接,则先KILL掉几个LOCAL=NO的会话,然后再进去分析是哪个模块的连接较多,然后通知开发商处理
ps-ef|grepLOCAL=NO--找出PID,KILL掉几个
selectmachine,program,count(*)fromv$sessiongroupbymachine,programorderby3;
--找出较多的模块
2、查看监听
lsnrctlstatus
看看状态是不是ready,或者reload一次,看看故障是否能恢复
九.IO非常高
数据库登陆缓慢,或者根本不可用,无法登陆数据库进行查询等操作。
表空间满或者文件系统满了一般情况下不会发生,因为我们有监控告警。
这里主要是针对异常sql引起数据库hang的情况
分析IO高的原因,例如:
A、大量的并行;
B、长事务;
C、物理读高
在操作系统使用命令:
ps-ef|grepLOCAL=NO|awk'
{print$2}'
|xargskill-9
kll所有非本地进程,然后检查系统资源状态,检查数据库状态
十.PGA使用过大
影响SQL执行的效率
PGA使用过大
1、查询当前PGA使用大小:
selectsum(pga_alloc_mem)/1048576/1024size_gb
fromv$process;
2.查询使用PGA较大的具体进程
例如以下语句可以查出具体占用内存大于100m的进程信息:
(例如)
setline180
colMACHINEfora10
colPROGRAMfora25
colUSERNAMEfora15
selects.sid,s.serial#,s.username,s.machine,s.program,s.process,s.sql_id,p.pga_alloc_mem/1048576size_m,p.spid
fromv$sessions,v$processpwheres.paddr=p.addr
andp.pga_alloc_mem>
104857600orderby7desc;
3.咨询开发商可以删除语句
altersystemkillsession'
sid,serial#'
十一.数据库HANG异常处理
现象描述:
数据库无法登陆
A、大量异常阻塞
B、资源耗尽
1.进行HANG分析,查找顶级阻塞的会话。
普通的HANG分析:
参考业支脚本.
全局的HANG分析:
oradebugsetmypid(oradebugsetospid3188)
oradebugunlimit
oradebugsetinstall
oradebug-gdefhanganalyze3
oradebugtracefile_name
2.紧急情况下,在操作系统使用命令:
kill所有非本地进程,然后检查系统资源状态,检查数据库状态
十二.CPU使用过高应急处理
usr%使用率达到90以上
影响因素:
CPU使用过高,一般表现在以下几点:
A、不良SQL造成的大量等待事件
B、大量的短连接造成CPU负载高,BOSS外围系统曾出现过。
1、当CPU出现高负载的时候,首先我们要检查当前的数据库里是否有大量异常等待,例如:
latchfree,librarycachelock/pin等待事件。
selectevent,count(*),wait_classfromv$sessiongroupbyevent,wait_classorderby2;
如果有,根据相关等待事件分析问题。
也可以通过HANG分析,进行阻塞源头会话定位。
2、当CPU出现高负载的时候,检查发现当前数据库并无任何异常等待事件,我们就要参考平时的CPU使用率指标,然后通过会话、事务量来衡量。
3、当CPU出现高负载的时候,检查发现当前数据库并无任何异常等待事件,当前活动SQL语句与平时差别很大,我们可以关闭监听,检查是否由于连接造成的。
十三.SYSAUX表空间爆满没有存储扩容应急处理
如果SYSAUX表空间不可用时,数据库的核心功能还是可以继续运行的。
只是一些存放在SYSAUX表空间里的功能收到限制,比如OEM。
A、业务表被放在SYSAUX表空间
B、一些辅助表的数据量太大
检查SYSAUX中的对象,是哪个对象占用了大量空间.检查时业务表还是辅助表,确认该对象是否可以清理.
colsegment_nameformata30
colsegment_typeformata30
setlinesize300
selectOWNER,SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024/1024GB
fromdba_segments
whereTABLESPACE_NAME='
SYSAUX'
orderby4;
十四.文件系统使用率达到或超过95%应急处理
使用df命令查看文件系统使用率达到95%
备份文件、dump文件、trace文件等大量产生造成.
检查相关文件系统下面的文件大小:
查看/u01目录下每个子目录的大小
du-sh/u01/*
根据需求进行清理.
十五.高资源消耗进程应急处理
某个oracleprocessCPU使用率非常高。
某个oracleprocessMEM使用率非常高。
暂无
1、使用TOPAS观察哪个进程CPU使用率高,找出相关进程号,通过以下命令定位数据库SID号.Selectsid,sql_id,event,statusfromv$sessionwherepaddrin(selectaddrfromv$processwherespid=&
进程号);
2、使用以下命令查看oracle会话使用内存超过100M的用户
3、对相关进程和会话进行分析,决定是否kill.
十六.实例CRASH应急处理
RAC环境单节点crash,RAC环境所有节点crash
暂无,CRASH问题涉及到的问题比较复杂,以后将逐步更新。
遇到实例crash之后,首先看是否能重启启动:
1、能重新启动的情况下,知会相关领导,事后分析重启原因。
2、不能重启的情况下:
A、RAC之单节点无法重启,通知相关领导,评估正常节点负载,应用切换至正常节点。
相关技术人员进行故障处理。
B、RAC之全节点无法重启,通知相关领导,考虑是否切换应急库。
十七.“cursor:
pinSwaitonX”事件应急处理
1、常见硬解析
2、HighVersionCounts
3、BUG
1、查找等待事件的阻塞者:
selectp2raw,to_number(substr(to_char(rawtohex(p2raw)),1,8),'
XXXXXXXX'
)sidfromv$sessionwhereevent='
cursor:
pinSwaitonX'
2、查看阻塞者在做什么:
selectsid,serial#,SQL_ID,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,EVENT
fromv$sessionwhereSID=31;
3、根据阻塞者的SQL分析产生原因。
十八.主机HANG应急处理
十九.SQL执行计划变化应急处理
一个SQL的执行计划的不稳定,
常见原因包含以下两种:
1、统计信息的变化
2、SQL语句的变化
1、通过SQL_ID确认统计信息是否一致(该语句会将AWR中所有的信息查找出来)
setlines155
colexecsfor999,999,999
colavg_etimefor999,999.999
colavg_liofor999,999,999.9
colbegin_interval_timefora30
colnodefor99999
breakonplan_hash_valueonstartup_timeskip1
selectss.snap_id,
ss.instance_numbernode,
begin_interval_time,
sq
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 故障 处理 应急 方案