在使用并行的时候,总能看到进程中出现一些ora_p这样的进程。有时候查看问题的时候只看到并行进程在运行,却没有思路去查找倒底是哪些session在干些什么,下面简单分析一下。怎么去映射系统级的进程和数据库级的并行进程。
从系统进程中可以看到一些并行session在运行。
SQL> !ps -ef|grep ora_p|grep TESTDB
testdbuser 17422 1 0 Aug29 ? 00:04:56 ora_pmon_TESTDB
testdbuser 17425 1 0 Aug29 ? 00:01:12 ora_psp0_TESTDB
testdbuser 20847 26200 0 20:54 pts/1 00:00:00 /bin/bash -c ps -ef|grep ora_p|grep TESTDB
testdbuser 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
testdbuser 32543 1 2 10:09 ? 00:17:41 ora_p001_TESTDB
testdbuser 32545 1 2 10:09 ? 00:18:51 ora_p002_TESTDB
testdbuser 32547 1 2 10:09 ? 00:15:55 ora_p003_TESTDB
testdbuser 32549 1 3 10:09 ? 00:19:22 ora_p004_TESTDB
testdbuser 32551 1 3 10:09 ? 00:24:52 ora_p005_TESTDB
testdbuser 32553 1 3 10:09 ? 00:21:43 ora_p006_TESTDB
testdbuser 32561 1 3 10:09 ? 00:24:52 ora_p007_TESTDB
testdbuser 32563 1 1 10:09 ? 00:08:30 ora_p008_TESTDB
testdbuser 32565 1 1 10:09 ? 00:07:20 ora_p009_TESTDB
如果查看v$session,会发现program中有一些session是和并行相关的session。
SQL> select sid,username,program from v$session where sid in (select sid from v$px_session ) and username='TESTDB';
SID USERNAME PROGRAM
---------- ------------------------------ ------------------------------------------------
2738 testdb oracle@dbserver (P000)
666 testdb oracle@dbserver (P001)
1371 testdb oracle@dbserver (P002)
1590 testdb oracle@dbserver (P003)
2183 testdb oracle@dbserver (P004)
2671 testdb oracle@dbserver (P005)
3125 testdb oracle@dbserver (P006)
4084 testdb oracle@dbserver (P007)
3053 testdb sqlplus@dbserver (TNS V1-V3)
9 rows selected.
在并行中 3053 是相当于这个并行处理的代言人,协调者,其他的session都是在后台默默的工作着。各个并行进程对处理完的数据进行最后的合并都是由3053这个进程来最后完成,展现给用户。
有时候定义了并行度,想对并行的情况进行一个简单的监控,至少可以知道目前系统是否还有足够的资源。并行资源的使用情况等。
可以参考v$px_session, v$px_process,v$session,v$process,v$px_sesstat,v$pq_sesstat来完成。
简单举个例子来分析一下。
如果目前我运行一个脚本,设定的并行度为8,查看一下运行的并行度情况
select pxsess.sid,sess.username,pxsess.serial#,pxsess.qcsid,pxsess.qcserial#,pxsess.degree,pxsess.server#,pxsess.req_degree from v$px_session pxsess,v$session sess where pxsess.sid=sess.sid and sess.username='TESTDB';
这个例子显示了并行相关的session,列acsid就是对应的协调session,可以看到显示的都是6620.,可以通过字段degree,req_degree看到申请了8个进程,然后也得到了8个进程。server_set中可以看到
SID USERNAME SERIAL# QCSID QCSERIAL# DEGREE SERVER_SET REQ_DEGREE
---------- ------------------------------ ---------- ---------- ---------- ---------- ---------- ----------
4539 testdb 7255 6620 49463 8 1 8
4921 testdb 2967 6620 49463 8 2 8
5295 testdb 31077 6620 49463 8 3 8
5487 testdb 29109 6620 49463 8 4 8
5671 testdb 48021 6620 49463 8 5 8
5863 testdb 10191 6620 49463 8 6 8
6051 testdb 9337 6620 49463 8 7 8
6238 testdb 2979 6620 49463 8 8 8
6620 testdb 49463 6620
得到了基本的信息来看看对应的进程信息。
SQL> !ps -ef|grep ora_p|grep TESTDB
testdb 17422 1 0 Aug29 ? 00:04:56 ora_pmon_TESTDB
testdb 17425 1 0 Aug29 ? 00:01:12 ora_psp0_TESTDB
testdb 20847 26200 0 20:54 pts/1 00:00:00 /bin/bash -c ps -ef|grep ora_p|grep TESTDB
testdb 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
testdb 32543 1 2 10:09 ? 00:17:41 ora_p001_TESTDB
testdb 32545 1 2 10:09 ? 00:18:51 ora_p002_TESTDB
testdb 32547 1 2 10:09 ? 00:15:55 ora_p003_TESTDB
testdb 32549 1 3 10:09 ? 00:19:22 ora_p004_TESTDB
testdb 32551 1 3 10:09 ? 00:24:52 ora_p005_TESTDB
testdb 32553 1 3 10:09 ? 00:21:43 ora_p006_TESTDB
testdb 32561 1 3 10:09 ? 00:24:52 ora_p007_TESTDB
testdb 32563 1 1 10:09 ? 00:08:30 ora_p008_TESTDB
testdb 32565 1 1 10:09 ? 00:07:20 ora_p009_TESTDB
我们现在来做一个映射,看看在数据库中的进程和系统进程的映射关系,可以看到分配的进程还是比较富裕的,有2个进程还是available的状态,剩下的都在使用,都是in use.
SQL> select *from v$px_process;
SERV STATUS PID SPID SID SERIAL#
---- --------- ---------- ------------------------ ---------- ----------
P000 IN USE 224 32541 4539 7523
P001 IN USE 226 32543 4921 3235
P002 IN USE 228 32545 5295 31345
P003 IN USE 229 32547 5487 29377
P004 IN USE 230 32549 5671 48289
P005 IN USE 231 32551 5863 10459
P006 IN USE 232 32553 6051 9605
P007 IN USE 233 32561 6240 32193
P009 AVAILABLE 238 32565
P008 AVAILABLE 237 32563
10 rows selected.
比如说进程32541这个进程
testdb 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
在数据库中的信息如下,可见映射是完整的。
SERV STATUS PID SPID SID SERIAL#
---- --------- ---------- ------------------------ ---------- ----------
P000 IN USE 224 32541 4539 7523
然后如果想知道更多协调进程的信息,可以使用v$session,v$process来关联。我们看到协调进程的sid是6620
select paddr, sid,serial#,username,osuser ,machine,process,terminal,type,to_char(LOGON_TIME,'yyyy-mm-dd hh24:mi:ss')login_time from v$session
where sid=6620
PADDR SID SERIAL# USERNAME OSUSER MACHINE PROCESS TERMINAL TYPE LOGIN_TIME
---------------- ---------- ---------- ------------------------------ ------------------------------ ---------- ------------------------ ------------------------------ ---------- -------------------
00000002597CEB88 6620 49463 TESTDB testdb testdb 21568 pts/3 USER 2014-10-06 20:52:55
有了这些信息,来和v$proess关联就能够看到对应的进程了。可以看到系统进程是21569.
ADDR SPID PID
---------------- ------------------------ ----------
00000002597CEB88 21569 115
SQL> !ps -ef|grep 21569
testdbuser 21569 21568 16 20:52 ? 00:06:33 oracleTESTDB (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
testdbuser 26835 26200 0 21:32 pts/1 00:00:00 /bin/bash -c ps -ef|grep 21569
testdbuser 26837 26835 0 21:32 pts/1 00:00:00 grep 21569
所以这些视图还是很实用的,至少在看到很多的并行进程的时候,能够有思路去查找倒底是哪儿在运行这些,可能有问题的部分。
从系统进程中可以看到一些并行session在运行。
SQL> !ps -ef|grep ora_p|grep TESTDB
testdbuser 17422 1 0 Aug29 ? 00:04:56 ora_pmon_TESTDB
testdbuser 17425 1 0 Aug29 ? 00:01:12 ora_psp0_TESTDB
testdbuser 20847 26200 0 20:54 pts/1 00:00:00 /bin/bash -c ps -ef|grep ora_p|grep TESTDB
testdbuser 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
testdbuser 32543 1 2 10:09 ? 00:17:41 ora_p001_TESTDB
testdbuser 32545 1 2 10:09 ? 00:18:51 ora_p002_TESTDB
testdbuser 32547 1 2 10:09 ? 00:15:55 ora_p003_TESTDB
testdbuser 32549 1 3 10:09 ? 00:19:22 ora_p004_TESTDB
testdbuser 32551 1 3 10:09 ? 00:24:52 ora_p005_TESTDB
testdbuser 32553 1 3 10:09 ? 00:21:43 ora_p006_TESTDB
testdbuser 32561 1 3 10:09 ? 00:24:52 ora_p007_TESTDB
testdbuser 32563 1 1 10:09 ? 00:08:30 ora_p008_TESTDB
testdbuser 32565 1 1 10:09 ? 00:07:20 ora_p009_TESTDB
如果查看v$session,会发现program中有一些session是和并行相关的session。
SQL> select sid,username,program from v$session where sid in (select sid from v$px_session ) and username='TESTDB';
SID USERNAME PROGRAM
---------- ------------------------------ ------------------------------------------------
2738 testdb oracle@dbserver (P000)
666 testdb oracle@dbserver (P001)
1371 testdb oracle@dbserver (P002)
1590 testdb oracle@dbserver (P003)
2183 testdb oracle@dbserver (P004)
2671 testdb oracle@dbserver (P005)
3125 testdb oracle@dbserver (P006)
4084 testdb oracle@dbserver (P007)
3053 testdb sqlplus@dbserver (TNS V1-V3)
9 rows selected.
在并行中 3053 是相当于这个并行处理的代言人,协调者,其他的session都是在后台默默的工作着。各个并行进程对处理完的数据进行最后的合并都是由3053这个进程来最后完成,展现给用户。
有时候定义了并行度,想对并行的情况进行一个简单的监控,至少可以知道目前系统是否还有足够的资源。并行资源的使用情况等。
可以参考v$px_session, v$px_process,v$session,v$process,v$px_sesstat,v$pq_sesstat来完成。
简单举个例子来分析一下。
如果目前我运行一个脚本,设定的并行度为8,查看一下运行的并行度情况
select pxsess.sid,sess.username,pxsess.serial#,pxsess.qcsid,pxsess.qcserial#,pxsess.degree,pxsess.server#,pxsess.req_degree from v$px_session pxsess,v$session sess where pxsess.sid=sess.sid and sess.username='TESTDB';
这个例子显示了并行相关的session,列acsid就是对应的协调session,可以看到显示的都是6620.,可以通过字段degree,req_degree看到申请了8个进程,然后也得到了8个进程。server_set中可以看到
SID USERNAME SERIAL# QCSID QCSERIAL# DEGREE SERVER_SET REQ_DEGREE
---------- ------------------------------ ---------- ---------- ---------- ---------- ---------- ----------
4539 testdb 7255 6620 49463 8 1 8
4921 testdb 2967 6620 49463 8 2 8
5295 testdb 31077 6620 49463 8 3 8
5487 testdb 29109 6620 49463 8 4 8
5671 testdb 48021 6620 49463 8 5 8
5863 testdb 10191 6620 49463 8 6 8
6051 testdb 9337 6620 49463 8 7 8
6238 testdb 2979 6620 49463 8 8 8
6620 testdb 49463 6620
得到了基本的信息来看看对应的进程信息。
SQL> !ps -ef|grep ora_p|grep TESTDB
testdb 17422 1 0 Aug29 ? 00:04:56 ora_pmon_TESTDB
testdb 17425 1 0 Aug29 ? 00:01:12 ora_psp0_TESTDB
testdb 20847 26200 0 20:54 pts/1 00:00:00 /bin/bash -c ps -ef|grep ora_p|grep TESTDB
testdb 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
testdb 32543 1 2 10:09 ? 00:17:41 ora_p001_TESTDB
testdb 32545 1 2 10:09 ? 00:18:51 ora_p002_TESTDB
testdb 32547 1 2 10:09 ? 00:15:55 ora_p003_TESTDB
testdb 32549 1 3 10:09 ? 00:19:22 ora_p004_TESTDB
testdb 32551 1 3 10:09 ? 00:24:52 ora_p005_TESTDB
testdb 32553 1 3 10:09 ? 00:21:43 ora_p006_TESTDB
testdb 32561 1 3 10:09 ? 00:24:52 ora_p007_TESTDB
testdb 32563 1 1 10:09 ? 00:08:30 ora_p008_TESTDB
testdb 32565 1 1 10:09 ? 00:07:20 ora_p009_TESTDB
我们现在来做一个映射,看看在数据库中的进程和系统进程的映射关系,可以看到分配的进程还是比较富裕的,有2个进程还是available的状态,剩下的都在使用,都是in use.
SQL> select *from v$px_process;
SERV STATUS PID SPID SID SERIAL#
---- --------- ---------- ------------------------ ---------- ----------
P000 IN USE 224 32541 4539 7523
P001 IN USE 226 32543 4921 3235
P002 IN USE 228 32545 5295 31345
P003 IN USE 229 32547 5487 29377
P004 IN USE 230 32549 5671 48289
P005 IN USE 231 32551 5863 10459
P006 IN USE 232 32553 6051 9605
P007 IN USE 233 32561 6240 32193
P009 AVAILABLE 238 32565
P008 AVAILABLE 237 32563
10 rows selected.
比如说进程32541这个进程
testdb 32541 1 2 10:09 ? 00:18:23 ora_p000_TESTDB
在数据库中的信息如下,可见映射是完整的。
SERV STATUS PID SPID SID SERIAL#
---- --------- ---------- ------------------------ ---------- ----------
P000 IN USE 224 32541 4539 7523
然后如果想知道更多协调进程的信息,可以使用v$session,v$process来关联。我们看到协调进程的sid是6620
select paddr, sid,serial#,username,osuser ,machine,process,terminal,type,to_char(LOGON_TIME,'yyyy-mm-dd hh24:mi:ss')login_time from v$session
where sid=6620
PADDR SID SERIAL# USERNAME OSUSER MACHINE PROCESS TERMINAL TYPE LOGIN_TIME
---------------- ---------- ---------- ------------------------------ ------------------------------ ---------- ------------------------ ------------------------------ ---------- -------------------
00000002597CEB88 6620 49463 TESTDB testdb testdb 21568 pts/3 USER 2014-10-06 20:52:55
ADDR SPID PID
---------------- ------------------------ ----------
00000002597CEB88 21569 115
testdbuser 21569 21568 16 20:52 ? 00:06:33 oracleTESTDB (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
testdbuser 26835 26200 0 21:32 pts/1 00:00:00 /bin/bash -c ps -ef|grep 21569
testdbuser 26837 26835 0 21:32 pts/1 00:00:00 grep 21569
所以这些视图还是很实用的,至少在看到很多的并行进程的时候,能够有思路去查找倒底是哪儿在运行这些,可能有问题的部分。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-1290414/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-1290414/