ORACLE死锁故障排查的一般性手法的备忘录
oracle常见故障处理手册
oracle常见故障处理手册一、数据库启动与关闭故障1.数据库启动失败原因：可能是由于Oracle数据库配置不正确、系统环境变量设置不正确、初始化参数设置不正确等原因导致。
解决方法：检查数据库日志文件，查看错误信息，根据错误信息进行相应的修复。
2.数据库关闭失败原因：可能是由于数据库事务未完成、数据库锁未释放等原因导致。
解决方法：检查数据库日志文件，查看错误信息，根据错误信息进行相应的修复。
二、连接故障1.连接不成功原因：可能是由于网络连接问题、数据库用户名或密码错误、数据库实例名错误等原因导致。
解决方法：检查网络连接是否正常，检查数据库用户名和密码是否正确，检查数据库实例名是否正确。
2.连接断开原因：可能是由于网络不稳定、数据库服务器异常等原因导致。
解决方法：检查网络连接是否正常，检查数据库服务器是否正常。
三、数据恢复故障1.数据丢失原因：可能是由于数据库损坏、磁盘故障等原因导致。
解决方法：根据数据丢失的原因，选择相应的恢复方法，如使用备份恢复数据或使用日志文件恢复数据。
2.数据不一致原因：可能是由于数据修改不一致、数据复制不一致等原因导致。
解决方法：检查数据修改和复制的日志文件，找到不一致的数据并修复。
四、性能优化故障1.性能下降原因：可能是由于CPU占用过高、内存占用过高、磁盘IO过大等原因导致。
解决方法：优化数据库配置参数，如增加内存、优化磁盘IO等。
2.查询速度慢原因：可能是由于查询语句不优化、表没有建立索引等原因导致。
解决方法：优化查询语句，为表建立索引等。
五、存储管理故障1.存储空间不足原因：可能是由于磁盘空间不足、表空间不足等原因导致。
解决方法：清理磁盘空间，增加磁盘空间，调整表空间大小等。
2.数据文件丢失或损坏原因：可能是由于磁盘故障、人为误删除或修改等原因导致。
解决方法：使用备份恢复数据文件或修复损坏的数据文件。
六、网络连接故障1.网络连接中断原因：可能是由于网络设备故障、网络连接线故障等原因导致。
死锁问题排查
死锁问题排查1. 现象，队列报警开启依赖，充斥⼤量报警，⼤志显示死锁：2. 抓取最近⼤次死锁记录，核⼤截图：3. 分析死锁本来是个⼤常简单的问题，只要保证并发内部顺序性，就能避免⼤部分，但是这个看起来似乎有点不⼤样，单个表同样的操作(全表扫描)死锁(理论上不应该)tmp⼤表，记录较少，transaction 1 、2暴漏语句均⼤可⼤索引，全表记录锁定( n-key)⼤志显示transaction 2 等待被锁定锁，transaction 1 等待被transaction 2锁定记录，造成死锁但是问题是针对同⼤张表的顺序扫描加锁，为什么会死锁，百思不得姐，⼤度怀疑5.7版本加⼤了垃圾特性，根据现象看似乎是进⼤了锁表过程中的已加锁条⼤的跳跃，然后回来继续加锁，加剧了死锁可能，但是经过⼤晚上的求证也没发现该特性的踪迹开始怀疑是⼤志展现的不全，还有别的因素加⼤，早上过来翻看代码，重新整理了场景：transaction 1⼤先执⼤(看id)，锁定原有tmp记录transaction 2 开始执⼤，⼤先进⼤了插⼤操作(⼤增，新插⼤的在后⼤)，锁定后半部分transaction 2 继续执⼤update操作，从头开始全表扫描，尝试锁定前半部分记录transaction 1 继续执⼤，尝试锁定后半部分记录此时1持有前部分，尝试获取后半部分锁，2持有后半部分(插⼤获得)，尝试获取前半部分锁，互不相让，形成僵持innodb检查锁定graph 1->2->1->2 形成环，确认死锁，报deadlock，查找回滚成本最低的transaction 1进⼤回滚，保证transaction 2的顺利进⼤4. 解决问题核⼤根源是a. 全表锁定，极容易造成死锁b. 表内锁定的⼤顺序性破坏其⼤可以解决，简单办法，在条件上加索引，基本能保证不会锁定同样的记录5. 总结a. 根据某个点熟悉问题，排查验证可能性b. 很多时候不可⼤，需要回过头来，根据上⼤的熟悉，从宏观上再看问题c. 技术问题，特别是极端技术问题⼤多和具体业务强关联，要弄清楚具体业务场景。
oracle 查死锁
结果如下(以我的库为例)：
saddr sid serial# paddr username status
--------------------------------------------------------------------------------------------------------
其中sid用死锁的sid替换。
exit
ps -ef|grep spid
其中spid是这个进程的进程号，kill掉这个Oracle进程。
------------
(1)查看用户的连接状况
select username,sid,serial# from v$session
------------------------------------------
如下结果：
username sid serial#
----------------------------------------
NETBNEW 513 22974
NETBNEW 514 18183
由此可见，WUZHQ这个用户的session已经被杀死。此时可以安全删除用户。
如：你要删除用户'WUZHQ',可以这样做：
alter system kill session'532,4562'
(3)删除用户
--------------------------------------------
drop user username cascade
2）kill掉这个死锁的进程：
alter system kill session ‘sid,serial#’; （其中sid=l.session_id）
死锁的排查方法
死锁的排查方法
死锁的排查主要有以下几种方法：
1. 资源分级：对系统中的各种资源（如CPU、内存、磁盘等）进行分级，
优先分配高级别的资源给进程。
2. 请求和保持：当一个进程在等待一个资源时，如果该资源被其他进程占用，则该进程请求其他空闲资源，并保持对已分配资源的占有，防止释放可能引起死锁的资源。
3. 饥饿策略：当一个进程等待时间过长而无法获得需要的资源时，由系统自动收回其已占有的资源，并在一段时间内不再分配给该进程。
4. 死锁检测与恢复：定期检测系统中是否存在死锁，如果存在则采取相应措施（如回滚、重试等）来解除死锁。
5. 避免死锁：通过一些算法（如银行家算法、避免循环等待等）来避免死锁的发生。
以上方法各有优缺点，实际应用中需要综合考虑各种因素选择适合的方法。
数据库死锁问题的排查与解决方法
数据库死锁问题的排查与解决方法引言:数据库死锁是在多个并发事务同时访问共享资源时经常会遇到的一个问题。
当两个或多个事务相互等待对方释放资源时，系统进入了死锁状态。
这导致事务无法继续执行，对生产系统的性能和可用性造成了严重影响。
因此，排查和解决数据库死锁问题对于确保系统的稳定运行至关重要。
本文将重点介绍数据库死锁问题的排查和解决方法。
一、什么是数据库死锁？数据库死锁是指两个或多个事务相互等待对方释放资源而无法继续执行的状态。
其中，每个事务都持有一部分资源，并且等待其他事务释放它们需要的资源。
当死锁发生时，没有任何一个事务能够继续执行，只能通过干预来解锁资源，打破死锁循环。
二、数据库死锁原因分析导致数据库死锁的原因通常可以归结为以下几个方面：1.事务并发性高：并发事务的同时访问和修改共享资源，容易导致死锁。
2.事务等待资源：当一个事务需要的资源已被其他事务占用时，会进入等待状态，如果等待的资源得不到释放，容易导致死锁。
3.资源争抢：不同事务之间竞争有限的资源，若资源分配不当，容易形成死锁。
三、数据库死锁排查方法1.使用数据库的死锁监控工具：现代数据库管理系统（DBMS）通常提供了监控死锁的工具。
通过使用这些工具，可以查看当前死锁的详细信息，如死锁链条和被锁定的资源等。
根据这些信息，可以定位死锁发生的位置，并进一步分析原因。
2.分析系统日志：通过分析数据库系统的日志，可以追踪事务的执行过程，查找是否有死锁相关的错误信息。
系统日志也会记录死锁发生时的相关信息，帮助我们了解死锁的原因。
3.使用性能监控工具：通过监控数据库系统的性能指标，如锁等待时间、阻塞的事务数量等，可以发现是否存在潜在的死锁问题。
这些工具可以帮助我们分析事务之间的竞争关系，进一步找到导致死锁的根本原因。
四、数据库死锁解决方法1.减少事务并发度：降低并发事务的数量，可以减少死锁的发生。
对于一些读写频繁、修改操作较多的事务，可以考虑对其进行优化，减少对共享资源的争抢。
Oracle常见死锁发生的原因以及解决方法
Oracle常见死锁发生的原因以及解决方法死锁是指在并发程序中，两个或多个进程因为争夺系统资源而陷入无限等待的状态，从而无法继续执行下去。
在Oracle数据库中，死锁是一个非常常见的问题，它会导致系统性能下降，甚至造成系统崩溃。
本文将详细介绍Oracle常见死锁发生的原因以及解决方法。
一、死锁发生的原因1.竞争资源：当多个进程同时请求相同的资源时，可能会导致死锁的发生。
例如，如果两个进程同时请求一个表的写锁，那么它们就会陷入死锁状态。
2.锁的顺序：当多个进程按照不同的顺序请求锁时，可能会导致死锁的发生。
例如，如果进程A先请求资源X，再请求资源Y，而进程B先请求资源Y，再请求资源X，那么它们就会陷入死锁状态。
3.锁的持有时间：当一个进程持有一个锁，并且在等待其他资源时继续保持该锁，可能会导致死锁的发生。
例如，如果进程A持有资源X的锁，并且在等待资源Y时继续保持该锁，而进程B持有资源Y的锁，并且在等待资源X时继续保持该锁，那么它们就会陷入死锁状态。
二、死锁的解决方法1. 死锁检测和解除：Oracle数据库提供了死锁检测和解除的机制。
当一个进程请求一个资源时，数据库会检查是否存在死锁。
如果存在死锁，数据库会选择一个进程进行回滚，解除死锁状态，并且通知其他进程重新尝试获取资源。
2.超时设置：为了避免死锁的发生，可以设置超时时间。
当一个进程请求一个资源时，如果在指定的超时时间内无法获取资源，那么就放弃该请求，并且释放已经持有的资源。
这样可以防止死锁的发生，但是会增加系统的开销。
3.锁的顺序：为了避免死锁的发生，可以规定所有进程按照相同的顺序请求锁。
例如，可以规定所有进程按照资源的名称进行排序，然后按照顺序请求锁。
这样可以避免死锁的发生，但是可能会影响系统的性能。
4.锁的粒度：为了避免死锁的发生，可以尽量减小锁的粒度。
例如，可以将一个大的锁分解成多个小的锁，这样可以减少锁的冲突，降低死锁的概率。
但是需要注意的是，锁的粒度过小可能会导致系统的性能下降。
oracle死锁的处理剖析
查看有哪些表被锁住select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects bwhere b.object_id = a.object_idselect ername,b.sid,b.serial#,logon_timefrom v$locked_object a,v$session bwhere a.session_id = b.sid order by b.logon_time杀进程中的会话alter system kill session 'sid,serial#';e.galter system kill session '29,5497';如果有ora-00031错误，则在后面加immediate;alter system kill session '29,5497' immediate；如何杀死oracle死锁进程１.查哪个过程被锁:查V$DB_OBJECT_CACHE视图:SELECT * FROM V$DB_OBJECT_CACHE WHERE OWNER='过程的所属用户' AND CLOCKS!='0';2. 查是哪一个SID,通过SID可知道是哪个SESSION:查V$ACCESS视图:SELECT * FROM V$ACCESS WHERE OWNER='过程的所属用户' AND NAME='刚才查到的过程名';3. 查出SID和SERIAL#：查V$SESSION视图:SELECT SID,SERIAL#,PADDR FROM V$SESSION WHERE SID='刚才查到的SID';查V$PROCESS视图:SELECT SPID FROM V$PROCESS WHERE ADDR='刚才查到的PADDR';4. 杀进程：(1)先杀ORACLE进程:ALTER SYSTEM KILL SESSION '查出的SID,查出的SERIAL#';(2)再杀操作系统进程:KILL -9 刚才查出的SPID或ORAKILL 刚才查出的SID 刚才查出的SPID。
Oracle死锁分析过程详解
Oracle死锁分析过程详解Oracle死锁分析过程详解Oracle死锁分析关于死锁一般3种处理方式1、事前预测2、资源分级3、事后检测释放我知道的ORACLEMYSQL都是采用第三种在行锁级别上的话。
这里分析一个ORACLE死锁，首先一个死锁肯定会生成一个TRACE文件，这里会记录很多信息如：Deadlockgraph:---------Blocker(s)-----------------Waiter(s)---------ResourceNameprocesssessionholdswaitsprocesssessionhold swaitsTX-0058000f-0000b4736491204X6511252XTX-0019001c-0004e0b06511252X6491204X这里给出了进程和会话idRowswaitedon:Session1204:obj-rowid=0003D942-AAA9lCAAEAADgaNAAI (dictionaryobjn-252226,file-4,block-919181,slot-8) Session1252:obj-rowid=0003D942-AAA9lCAAEAADgaNAAa (dictionaryobjn-252226,file-4,block-919181,slot-26)这里给出导致死锁的行同时给出了最后触发死锁会话1252的语句-----InformationfortheOTHERwaitingsessions----- Session1252:sid:1252ser:35883audsid:7170593user:235/FEECORESV flags:(0x100045)USR/-flags_idl:(0x1)BSY/-/-/-/-/-flags2:(0x40009)-/-/INCpid:651O/Sinfo:user:oracle,term:UNKNOWN,ospid:13035 image:oracle@oratest11clientdetails:O/Sinfo:user:sky,term:unknown,ospid:1234machine:autobotsprogram:JDBCThinClientapplicationname:JDBCThinClient,hashvalue=2546894660currentSQL:UPDATE-----EndofinformationfortheOTHERwaitingsessions-----InformationforTHISsession:-----CurrentSQLStatementforthissession(sql_id=3vh5sc7pgtrjy)-----UPDATE那么到这里我们大概能够分析出A:1204拿到AAA9lCAAEAADgaNAAa行锁B:1252拿到AAA9lCAAEAADgaNAAI行锁C:1204需要AAA9lCAAEAADgaNAAI则等待D:1252需要AAA9lCAAEAADgaNAAa则触发死锁1204回滚那么随后trace给出1204C这一步等待时间和事物信息SO:0xee1fcd10,type:4,owner:0xf031e750,flag:INIT/-/-/0x00if:0x3c:0x3proc=0xf031e750,name=session,file=ksu.hLINE:12624,pg=0(session)sid:1204ser:2443trans:0xe9221180,creator:0xf031e 750flags:(0x100045)USR/-flags_idl:()BSY/-/-/-/-/-flags2:(0x40009)-/-/INCDID:,short-termDID:txnbranch:(nil)oct:6,prv:0,sql:0xf25d2278,psql:0xc4346788,user:235/FEECO RESVksuxdsFALSEatlocation:0servicename:SYS$USERSCurrentWaitStack:0:waitingfor''enq:TX-rowlockcontention''name|mode=0x54580006,usn<<16|slot=0x19001c,sequence=0x4e0b0wait_id=33seq_num=34snap_id=1waittimes:snap=3.001739sec,exc=3.001739sec,total=3.0017 39secwaittimes:max=infinite,heur=3.001739secwaitcounts:calls=1os=1in_wait=1iflags=0x15a0随后给出了导致他等待会话的等待信息，这里不给出。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ORACLE死锁故障排查的一般性手法的备忘录
故障现象：
两个Java写的后台批处理同时执行时，发生了死锁现象。
排查手法：
通过查询视图，找到被锁住的对象v$locked_object，根据其locked_mode，判断其锁类型查询SQL语句：
select l.xidusn, l.object_id, o.owner, o.object_name,
l.session_id, l.oracle_username, l.os_user_name, l.process,
decode(l.locked_mode, 0, '',
1, 'NULL',
2, '(SS)',
3, '(SX)',
4, '(S)',
5, '(SSX)',
6, '(X)',
'???') locked_mode
from v$locked_object l, dba_objects o
where l.object_id= o.object_id
判断查询结果，发现两个Session对同一个表的数据行进行了排他。
用以下的语句对视图v$sqltext进行查询，可以得到当前正在执行的SQL语句，以及执行SQL 语句的session
select username, osuser, machine, terminal, program,
sid, serial#, status, sql_address, sql_text
from v$session ss, v$sqltext sq
where type ='USER'
and ss.sql_address = sq.address
order by ss.sid, ss.serial#, sq.piece
可以发现对同一表中的同一数据行进行更新的两条SQL语句。
通过这两条SQL语句，可以定位Java程序中导致问题的代码。
问题原因分析：
对Java代码进行分析后，发现有一个按照数据行主键，逐行循环处理的操作。
不幸的是，循环前，从KeySet（）生成的主键列表没有进行排序，导致每次循环的执行顺序都是随机的。
例如，假设两个session都想要对数据行A,B,C,D进行处理，很有可能session1先处理了A,B，而此时session2刚好处理完了C,D。
这样，session1想要继续处理的C,D由于正被session2给锁住，所以无法继续执行。
session2想要处理的A,B也被session1给锁着，session2也无法继续，两个session最终都没有办法终止。
借助于ORACLE的TRACE文件
Oracle发现死锁后，会在alert_[SID].log文件中输出如下的警告信息：ORA-00060: Deadlock detected.
并提示去查看相应的*.trc文件。
通过分析*.trc文件可以看到死锁的详细情况，
下面是一个*.trc文件的例子:
*** 2012-01-09 20:11:22.379
DEADLOCK DETECTED ( ORA-00060 )
[Transaction Deadlock]
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:
---------Blocker(s)-------- ---------Waiter(s)---------
Resource Name process session holds waits process session holds waits TX-000a0006-0000f48f 65 101 X 64 102 X
TX-0007000f-0000d8a3 64 102 X 65 101 X
session 101: DID 0001-0041-00000002 session 102: DID
0001-0040-00000002
session 102: DID 0001-0040-00000002 session 101: DID
0001-0041-00000002
这里明确指出了发生死锁的两个session的ID
Rows waited on:
Session 101: obj - rowid = 0008915A - AACJFaAAFAAEwq1AAA
(dictionary objn - 561498, file - 5, block - 1247925, slot - 0)
Session 102: obj - rowid = 0008915A - AACJFaAAFAAEwq1AAI
(dictionary objn - 561498, file - 5, block - 1247925, slot - 8)
----- Information for the OTHER waiting sessions -----
Session 102:
sid: 102 ser: 2 audsid: 25260645 user: 87/USR_BAT flags: 0x41
pid: 64 O/S info: user: ora_1, term: UNKNOWN, ospid: 5915
image: oracle@pcXX
client details:
O/S info: user: root, term: unknown, ospid: 1234
machine: pcXX program: JDBC Thin Client
application name: JDBC Thin Client, hash value=2546894660
current SQL:
UPDATE XXXX SET XXXX 这里是导致死锁的SQL语句1
----- End of information for the OTHER waiting sessions -----
Information for THIS session:
*** 2012-01-09 20:11:22.530
----- Current SQL Statement for this session (sql_id=b0qn65w78t10b) -----
UPDATE XXXX SET XXXX 这里是导致死锁的SQL语句2
================================================== =
※log文件和trc文件的存放路径，取决于Oracle的安装路径，可以借助于文件检索功能。