你的那个oracle中process一直满是怎么解决的？求教

Posted 2023-04-24

修改process数不是最总解决办法。
你是用的连接池技术吗，如果是考虑和开发人员一起讨论一下，是不是连接池配置有问题，导致连接一直不释放，一直增加。
我曾经遇到过这样的问题 参考技术A job queue process 不用改这么大吧追问

是process，不是job_queue_process

参考技术B 修改process的量追问

修改到多大？我已经加到900了，还是爆，纠结啊，难不成搞几千？

orcal数据库表被锁了怎么解锁??

1、在做Oracle监听程序测试时，发现帐户已经被锁定。

2、在数据库安装电脑上，点击开始打开运行窗口。

3、在运行窗口输入CMD，调出命令提示符界面。

3、在命令提示符下面，用管理员身份登入到数据库sqlplus / as sysdba。

4、输入解锁命令alter user Scott account unlock后回车。

5、看见用户已更改的字样，表示命令已成功执行。

6、再切换到监听程序验证，原来的ora-28000帐户被锁定的提示已经不存在了。用户解锁成功。

参考技术A

1、在做Oracle监听程序测试时，发现帐户已经被锁定。

2、在数据库安装电脑上，点击开始打开运行窗口。

3、在运行窗口输入CMD，调出命令提示符界面。

3、在命令提示符下面，用管理员身份登入到数据库sqlplus / as sysdba。

4、输入解锁命令alter user Scott account unlock后回车。

5、看见用户已更改的字样，表示命令已成功执行。

6、再切换到监听程序验证，原来的ora-28000帐户被锁定的提示已经不存在了。用户解锁成功。

参考技术B 锁有以下几种模式: 0：none 1：null 空 2：Row-S 行共享(RS)：共享表锁 3：Row-X 行专用(RX)：用于行的修改 4：Share 共享锁(S)：阻止其他DML操作 5：S/Row-X 共享行专用(SRX)：阻止其他事务操作 6：exclusive 专用(X)：独立访问使用 数字越大锁级别越高, 影响的操作越多。一般的查询语句如select ... from ... ;是小于2的锁, 有时会在v$locked_object出现。select ... from ... for update; 是2的锁。当对话使用for update子串打开一个游标时， 所有返回集中的数据行都将处于行级(Row-X)独占式锁定， 其他对象只能查询这些数据行，不能进行update、delete或select...for update操作。insert / update / delete ... ; 是3的锁。没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。创建索引的时候也会产生3,4级别的锁。locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。有主外键约束时 update / delete ... ; 可能会产生4,5的锁。DDL语句时是6的锁。以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句：select object_id,session_id,locked_mode from v$locked_object;select t2.username,t2.sid,t2.serial#,t2.logon_time from v$locked_object t1,v$session t2 where t1.session_id=t2.sid order by t2.logon_time;如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁：alter system kill session 'sid,serial#';如果出现了锁的问题, 某个DML操作可能等待很久没有反应。当你采用的是直接连接数据库的方式， 也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接， 因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。 参考技术C 在操作数据库的时候，有时候会由于操作不当引起数据库表被锁定，这么我们经常不知所措，不知怎么给这些表解锁，在pl/sql Developer工具的的菜单“tools”里面的“sessions”可以查询现在存在的会话，但是我们很难找到那个会话被锁定了，想找到所以被锁的会话就更难了，下面这叫查询语句可以查询出所以被锁的会话。如下：
SELECT sn.username, m.SID,sn.SERIAL#, m.TYPE,
DECODE (m.lmode,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
lmode, LTRIM (TO_CHAR (lmode, '990'))
) lmode,
DECODE (m.request,
0, 'None',
1, 'Null',
2, 'Row Share',
3, 'Row Excl.',
4, 'Share',
5, 'S/Row Excl.',
6, 'Exclusive',
request, LTRIM (TO_CHAR (m.request, '990'))
) request,
m.id1, m.id2
FROM v$session sn, v$lock m
WHERE (sn.SID = m.SID AND m.request != 0) --存在锁请求，即被阻塞
OR ( sn.SID = m.SID --不存在锁请求，但是锁定的对象被其他会话请求锁定
AND m.request = 0
AND lmode != 4
AND (id1, id2) IN (
SELECT s.id1, s.id2
FROM v$lock s
WHERE request != 0 AND s.id1 = m.id1
AND s.id2 = m.id2)
)
ORDER BY id1, id2, m.request;

通过以上查询知道了sid和 SERIAL#就可以开杀了
alter system kill session 'sid,SERIAL#';