SID,PID,SPID,UID.....咋这么多ID...

 

今天Kill Session时查找的对这几个id一些研究
SID:是Oracle 实例的标识,不同的SID 对应不同的内存缓冲(SGA)和不同的后台进程。
SPID:system process id ,表示server process 在 os 中的process id.
PID:oracle process id,oracle自己用的id
kill session时用的是v$process.spid或v$session.sid+v$session.serial#


 

我们知道,在Oracle数据库中,可以通过kill session的方式来终止一个进程,其基本语法结构为:

alter system kill session 'sid,serial#' ;

被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.


我们发现当一个session被kill掉以后,该session的paddr被修改,如果有多个session被kill,那么多个session
的paddr都被更改为相同的进程地址:

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR SID SERIAL# PADDR USERNAME STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C 11 314 542B70E8 EYGLE INACTIVE
542E5044 18 662 542B6D38 SYS ACTIVE


SQL> alter system kill session '11,314';

System altered.

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR SID SERIAL# PADDR USERNAME STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C 11 314 542D6BD4 EYGLE KILLED
542E5044 18 662 542B6D38 SYS ACTIVE


SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR SID SERIAL# PADDR USERNAME STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C 11 314 542D6BD4 EYGLE KILLED
542E2AA4 14 397 542B7498 EQSP INACTIVE
542E5044 18 662 542B6D38 SYS ACTIVE

SQL> alter system kill session '14,397';

System altered.

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR SID SERIAL# PADDR USERNAME STATUS
-------- ---------- ---------- -------- ------------------------------ --------
542E0E6C 11 314 542D6BD4 EYGLE KILLED
542E2AA4 14 397 542D6BD4 EQSP KILLED
542E5044 18 662 542B6D38 SYS ACTIVE

在这种情况下,很多时候,资源是无法释放的,我们需要查询spid,在操作系统级来kill这些进程.

但是由于此时v$session.paddr已经改变,我们无法通过v$session和v$process关联来获得spid

那还可以怎么办呢?

我们来看一下下面的查询:

SQL> SELECT s.username,s.status,
2 x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
3 decode(bitand (x.ksuprflg,2),0,null,1)
4 FROM x$ksupr x,v$session s
5 WHERE s.paddr(+)=x.addr
6 and bitand(ksspaflg,1)!=0;


USERNAME STATUS ADDR KSLLAPSC KSLLAPSN KSLLASPO KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
542B44A8 0 0 0
ACTIVE 542B4858 1 14 24069 0 1
ACTIVE 542B4C08 26 16 15901 0 1
ACTIVE 542B4FB8 7 46 24083 0 1
ACTIVE 542B5368 12 15 24081 0 1
ACTIVE 542B5718 15 46 24083 0 1
ACTIVE 542B5AC8 79 4 15923 0 1
ACTIVE 542B5E78 50 16 24085 0 1
ACTIVE 542B6228 754 15 24081 0 1
ACTIVE 542B65D8 1 14 24069 0 1
ACTIVE 542B6988 2 30 14571 0 1

USERNAME STATUS ADDR KSLLAPSC KSLLAPSN KSLLASPO KSLLID1R KS D
------------------------------ -------- -------- ---------- ---------- ------------ ---------- -- -
SYS ACTIVE 542B6D38 2 8 24071 0
542B70E8 1 15 24081 195 EV
542B7498 1 15 24081 195 EV
SYS INACTIVE 542B7848 0 0 0
SYS INACTIVE 542B7BF8 1 15 24081 195 EV

16 rows selected.

我们注意,红字标出的部分就是被Kill掉的进程的进程地址.


简化一点,其实就是如下概念:

SQL> select p.addr from v$process p where pid <> 1 2 minus 3 select s.paddr from v$session s;
ADDR
--------
542B70E8
542B7498

Ok,现在我们获得了进程地址,就可以在v$process中找到spid,然后可以使用Kill或者orakill在系统级来杀掉这些进程.

实际上,我猜测:

当在Oracle中kill session以后, Oracle只是简单的把相关session的paddr 指向同一个虚拟地址.

此时v$process和v$session失去关联,进程就此中断.

然后Oracle就等待PMON去清除这些Session.所以通常等待一个被标记为Killed的Session退出需要花费很长的时间.

如果此时被Kill的process,重新尝试执行任务,那么马上会收到进程中断的提示,process退出,此时Oracle会立即启动PMON
来清除该session.这被作为一次异常中断处理.

<think>好的,我现在需要处理用户关于“transaction check wait for pid 1872 to finish”的问题。用户提到他们遇到了事务检查等待,具体涉及进程PID 1872,想要了解原因和解决方法。首先,我需要回忆相关的数据库知识,特别是关于事务恢复和进程状态的部分。 首先,用户引用了两个站内引用:引用[1]提到会话在事务恢复期间等待撤销记录,引用[2]则涉及会话处于KILLED状态但操作系统SPID仍然存在的情况。这可能意味着用户的数据库正在经历事务恢复,而某个进程(PID 1872)可能阻塞了这一过程,导致检查点等待。 接下来,我需要分析可能的原因。根据引用[1],事务恢复可能需要访问撤销记录,如果某个进程持有锁或资源,可能导致恢复受阻。另外,引用[2]提到进程被标记为KILLED,但操作系统层面的进程仍然存在,这可能是因为进程未能正确释放资源,导致数据库无法继续恢复操作。 可能的解决方法包括检查进程状态,强制终止进程,分析事务日志,以及调整数据库参数。需要注意直接终止进程可能导致数据不一致,所以需要谨慎操作。 此外,用户的问题可能涉及Oracle数据库,因为引用中提到了SPID和undo记录。因此,解决步骤可能需要使用Oracle的工具如v$session、v$process等视图来诊断进程状态,以及使用ALTER SYSTEM KILL SESSION命令终止会话。 还需要考虑事务恢复的具体机制。在Oracle中,事务恢复通常涉及前滚和回滚阶段,如果某个进程在恢复过程中阻塞,可能需要检查是否有长时间运行的事务或未提交的更改。 最后,生成相关问题时要围绕事务恢复、进程阻塞、性能优化等方面展开,帮助用户进一步理解问题的背景和解决方法。</think>### 进程PID 1872导致事务检查等待的原因及解决方法 #### 1. **问题原因分析** - **事务恢复阻塞**:事务检查(如检查点或恢复过程)需等待进程PID 1872释放资源或完成操作。可能因该进程持有未提交的锁、未完成的撤销操作(undo record)或长时间运行的事务导致阻塞[^1]。 - **进程状态异常**:进程可能处于僵死(Zombie)或挂起状态(如被标记为KILLED但未释放资源),导致系统无法完成事务恢复[^2]。 - **资源争用**:PID 1872可能占用大量I/O、CPU或内存资源,拖慢事务恢复进度。 #### 2. **诊断步骤** - **检查进程状态** 通过数据库系统视图(如Oracle的`v$session`、`v$process`)或操作系统命令(如`ps -ef | grep 1872`)确认进程是否活跃或僵死。 ```sql -- Oracle示例:查询会话状态 SELECT s.sid, s.serial#, s.status, p.spid FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE p.spid = '1872'; ``` - **分析事务日志** 检查数据库日志(如`alert.log`)或事务恢复相关的跟踪文件,定位具体等待事件(如`wait for undo record`)。 - **查看锁和资源争用** 使用锁检测工具(如Oracle的`v$locked_object`)确认PID 1872是否持有阻塞其他操作的锁。 #### 3. **解决方法** - **强制终止进程** 若进程无响应,通过数据库命令或操作系统终止: ```sql -- Oracle中终止会话 ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; ``` ```bash # Linux终止进程 kill -9 1872 ``` **注意**:强制终止可能导致事务回滚或数据不一致,需评估风险。 - **优化事务恢复** - 调整撤销表空间(undo tablespace)大小,避免因撤销记录不足导致等待[^1]。 - 缩短长事务执行时间,减少检查点等待。 - **检查系统资源** 监控CPU、内存、I/O使用率,确保资源充足。例如,使用`top`或`vmstat`分析系统负载。 #### 4. **预防措施** - 定期清理僵死进程。 - 配置资源管理策略(如Oracle的Resource Manager),限制单个进程的资源占用。 - 启用自动检查点调优(如Oracle的`FAST_START_MTTR_TARGET`)。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值