远程快速杀死session!

本文记录了一次解决Oracle数据库中因大量数据插入导致的死锁问题的过程。通过使用SQL命令和特定参数,成功解锁被卡住的会话,恢复正常数据库操作。
今天有一个开发的哥们A(不方面透露信息,暂叫A),在群里发问:
表中插入大数据量的时候卡住了,一查发现是锁住了,已经kill session,但是总是解锁不了,状态是killed,释放不了锁,并且删除操作的表,也不行,提示资源正忙。
当时只是草率的说:
去os中 直接  kill  -9  spid
后来这位哥们给我发该怎么弄:
我让他查:
 select  spid,username,terminal,program from  v$process where addr in (select  paddr from  v$session  where username=XXX) ;

A给的截图:

s elect object_name,machine,s.sid,s.serial# 
from v$locked_object l,dba_objects o ,v$session s
where l.object_id = o.object_id and l.session_id=s.sid;

他同时给我找个截图:

然后让他在os下执行:
kill  -9  spid;(LINUX)
orakill 实例  thread (Windows)
这时他说他是远程数据库,而且不能ssh登陆服务器主机,这个是挺头疼的!
我让他再一次:
alter system kill session '428,310';

alter system kill session '727,862';

alter system kill session '304,365';
此时还没有解决问题:



这时A说已经解决了:
 alter system kill session '727,862' immediate; 
加了一个强制immediate


一般情况下,在杀死一个session时,直接alter  system  kill  session  ‘sid,serial#'
当session还是active的时候,这是将session标识为killed或者pseudo,并不会释放session所持有的资源,所以会话一直存在( The ALTER SYSTEM  statement does not implicitly commit the current transaction.)
官方网站上:(http://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_2014.htm#SQLRF00902
If the session is performing some activity that must be completed, such as waiting for a reply from a remote database or rolling back a transaction, then Oracle Database waits for this activity to complete, marks the session as terminated, and then returns control to you. If the waiting lasts a minute, then Oracle Database marks the session to be terminated and returns control to you with a message that the session is marked to be terminated. ThePMON  background process then marks the session as terminated when the activity is complete.
IMMEDIATE  Specify  IMMEDIATE  to instruct Oracle Database to roll back ongoing transactions, release all session locks, recover the entire session state, and return control to you immediately.
通过上面学习了如何远程快速杀死session,平时习惯于依赖os命令,正好今天上了一课!同时也感谢A!
在处理数据库连接回滚时遇到的“Unexpected error when rolling back database connection”错误,通常与事务处理、连接状态或底层数据库资源的释放相关。该错误可能出现在多种场景中,例如数据库连接池异常、事务未正确提交或回滚、数据库驱动不兼容、底层资源泄漏等。 ### 数据库连接回滚失败的常见原因及处理方式 1. **连接池配置不当** 当使用连接池(如 HikariCP、C3P0、DBCP)时,若连接未正确归还给连接池,或连接池内部状态不一致,可能导致回滚失败。 - **解决方案**:检查连接池配置,确保最大连接数、超时时间、空闲超时等参数合理。启用连接池的健康检查和泄漏检测机制,确保连接在使用后正确关闭[^1]。 2. **事务未正确开启或已提交** 如果尝试回滚一个未开启事务的连接,或者事务已经被提交,数据库驱动可能会抛出异常。 - **解决方案**:在执行回滚前,检查连接是否处于活动事务中。可以通过 `Connection.getAutoCommit()` 方法判断当前是否处于事务中。 3. **数据库驱动版本不兼容** 使用过时或不兼容的 JDBC 驱动可能导致在事务处理过程中出现不可预期的异常,尤其是在升级数据库版本后未同步驱动版本的情况下。 - **解决方案**:确保使用与数据库版本兼容的 JDBC 驱动。定期更新驱动以获取最新的 bug 修复和性能优化。 4. **网络中断或数据库连接异常** 在事务执行过程中,若数据库连接因网络问题中断,回滚操作可能失败。 - **解决方案**:实现连接断开后的自动重连机制,并在捕获异常时进行重试处理。确保事务具有幂等性以便在重连后重新执行。 5. **资源泄漏或未释放的 Statement/ResultSet** 未关闭的 `Statement` 或 `ResultSet` 可能导致连接资源未被释放,从而在回滚时引发异常。 - **解决方案**:使用 try-with-resources 语法确保所有数据库资源在使用后自动关闭。 ### 示例代码:安全地执行回滚操作 ```java try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement()) { conn.setAutoCommit(false); // 执行数据库操作 stmt.executeUpdate("INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com')"); // 模拟异常 if (true) { throw new RuntimeException("Simulated error"); } conn.commit(); } catch (SQLException | RuntimeException e) { if (conn != null && !conn.isClosed() && !conn.getAutoCommit()) { conn.rollback(); } e.printStackTrace(); } ``` ### 日志与调试建议 - **启用 JDBC 驱动的详细日志**:有助于追踪连接和事务的生命周期,识别异常发生的准确位置。 - **使用 AOP 或日志框架记录事务状态**:例如 Spring AOP 可用于记录事务开始与结束的状态,帮助排查回滚失败的原因。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值