Alter system kill session always gives ORA-00030

Hello
Im writing a tool for oracle and one of its features requires killing user session (Im connecting with JDBC). The database Im testing on is 11.2.0.2.
I find the sid and the serial# without problems, than I issue the "alter system kill session 'x,y' immediate" command.
So far so good, but I always get an ORA-00030 error saying this session cannot be found.
I double check and the session does exist in the database.
Because I want the tool to make the kill, killing via the OS is not an option.
Its doesn't look like a permission problem because it gives the same error even when connected as system.
Whats wrong ? does this kill command work at all ? Whats its limitations ?
Thanks
Guy Shilo
Edited by: user13266377 on Jun 9, 2011 1:15 AM

user13266377 wrote:
Hello
Im writing a tool for oracle and one of its features requires killing user session (Im connecting with JDBC). The database Im testing on is 11.2.0.2.
I find the sid and the serial# without problems, than I issue the "alter system kill session 'x,y' immediate" command.
So far so good, but I always get an ORA-00030 error saying this session cannot be found.
I double check and the session does exist in the database.
Because I want the tool to make the kill, killing via the OS is not an option.
Its doesn't look like a permission problem because it gives the same error even when connected as system.
Whats wrong ? does this kill command work at all ? Whats its limitations ?
Thanks
Guy Shilo
Edited by: user13266377 on Jun 9, 2011 1:15 AMyou cannot kill the session already killed or disconnected from the session.
refer the link:- this may help you to write scripts to kill session using dbms_scheduler
Grant restricted and kill sessions.

Similar Messages

ALTER SYSTEM KILL SESSION 에 대하여(ORA-30)

제품 : ORACLE SERVER
작성날짜 : 1997-07-30
ALTER SYSTEM KILL SESSION 에 대하여
--- Problem
사용자는 다음과 같은 상황에서 session 을 kill 하려는 시도를 하게 된다.
1. os 에는 process 가 존재하지 않지만, v$session 에는 active 로 존재하고
있을 경우
2. shadow process 는 살아 있는데, client machine 을 rebooting 한 경우
3. session 이 걸고 있던 lock 을 release 해야 할 경우
4. OS 나 Oracle 의 자원을 지나치게 많이 사용하여 성능을 저하시키는
process
그런데, alter system kill session ('sid, serial#'); 후에 다음과 같은
에러가 발생할 경우가 있다.
ora-00030, 00000, "user session ID does not exist"
// *Cause: The user session id no longer exists, probably because the
// session was logged out.
// *Action: Use a valid session ID.
--- 원인과 대책
kill session을 할 수 없는 이유는 PMON이 이미 이 session을 delete하고 있는
중이기 때문이다. 즉, PMON 이 dead session 을 clean-up 하고 있는 중에는
serial number의 값이 증가한다.
문제는 PMON이 process를 kill하는 시간인데, transaction의 크기에 따라,
PMON의 rollback 시간이 결정된다. 먼저 PMON은 dead process를 찾아내어,
이 process가 사용한 resource 를 release하는 시도를 한다.
PMON은 계속 이 작업을 시도하다가 마침내, free buffer의 부족으로 더 이상
resource를 free-up 하지 못하게 된다.
이 때, 이 process를 delete하고 있다는 message를 trace file에 출력하는데,
이것은 process를 delete하는 데 필요한 resource(data cache 내의 free buffer)
의 부족으로 위의 작업이 지연되고 있다는 의미이다.
PMON이 process 를 clean-up 할 때 걸리는 시간은, 5분에서 24 시간까지 소요
될 수 있다. 문제는 이 process가 hold 하고 있는 lock으로 인해 특정 작업이
수행되지 못하는 데 있다. MTS 를 사용할 때는 configuration MTS setting,
sqlnet.expire_time 사용)에 따라 다르지만, clean-up 작업을 하는데 72 시간이
소요된 경우도 있다.
아직까지는 PMON이 작업을 마칠 때까지 기다리는 방법 또는 db를 restartup하는
방법 밖에는 없다.
--- PMON 의 작업
PMON은 network failure 나 기타의 원인으로 생긴 old process connection을
clean-up 하는 역할을 한다. 그런데, PMON 은 clean-up 해야 하는 connection
중에 정해진 개수 만큼의 transaction 을 rollback 할 수 있는데, 이 값은
initSID.ora 의 cleanup_rollback_entries(default = 20) 에 의해 결정된다.
예를 들어, 1000 개의 uncommitted update가 있다면, 일정한 시간마다
cleanup_rollback_entries 의 개수 만큼의 record 만 rollback 할 수 있으므로
이 작업 동안에 lock 은 그대로 유지된다.
PMON 은 위의 작업 이외에 DB maintenance 역할이 있으므로, 위의 rollback 이
비교적 빠르게 처리되지 못할 수도 있다. 이러한 rollback을 빠르게 처리하기
위하여 cleanup_rollback_entries 를 늘릴 수도 있다. 그러나, 그 만큼 일정
시간 동안 PMON 의 작업이 많아지게 되므로, 다른 사용자들의 작업 요청이
느려지게 되는 trade-off 가 있으므로, 신중히 고려한 후에 수정하는 것이
바람직하다.
alter system kill session 에 의해서도 위와 같이 rollback 이 이루어지는데,
이 session 이 완전히 clean-up 되기 전까지 v$session, v$process에 남아 있게
된다.
--- ALTER SYSTEM KILL SESSION 을 하기 전에 ...
kill session 을 원할 경우는 다음의 순서대로 작업하는 것이 좋다.
1. kill the user process first
2. wait for 3 - 4 minutes
3. query v$session
4. if any information find in v$session, query v$lock
like
select count(*) from v$lock where SID ='sid';
위의 count(*) 가 0 이 아니라면, 아직 PMON 이 rollback을 끝내지 못한 경우
이므로 다시 얼마 후에 v$lock 을 조회하여 lock 의 개수가 감소하였는지
반복적으로 확인한다.
만약, 이 값이 전혀 변하지 않았다면, ALTER SYSTEM KILL SESSION 을 수행하고
v$session, v$lock을 query 하여 변화가 있는지 확인하여 변화가 있다면,
좀 더 기다린다.
그래도, v$lock 의 count(*) 가 0 이 되지 않을 경우, 마지막으로 수행할 수
있는 유일한 방법은 instance 를 restartup 하는 것이다.

user13266377 wrote:
Hello
Im writing a tool for oracle and one of its features requires killing user session (Im connecting with JDBC). The database Im testing on is 11.2.0.2.
I find the sid and the serial# without problems, than I issue the "alter system kill session 'x,y' immediate" command.
So far so good, but I always get an ORA-00030 error saying this session cannot be found.
I double check and the session does exist in the database.
Because I want the tool to make the kill, killing via the OS is not an option.
Its doesn't look like a permission problem because it gives the same error even when connected as system.
Whats wrong ? does this kill command work at all ? Whats its limitations ?
Thanks
Guy Shilo
Edited by: user13266377 on Jun 9, 2011 1:15 AMyou cannot kill the session already killed or disconnected from the session.
refer the link:- this may help you to write scripts to kill session using dbms_scheduler
Grant restricted and kill sessions.

Alter System Kill Session Not Working

I'm not certain as to what the problem may be, but the following code does not work in that the session is not being disconnected.
The attempt is to have this trigger kill a user's logon session if the user is attempting to run a program named 'ex_oc.exe'
I've tested the code (getting the values back to the table as expected) and it appears to be working but it doesn't execute.
I've also tried ''ALTER SYSTEM DISCONNECT SESSION'.
Database is 11g.
Any ideas?
Thanks
CREATE OR REPLACE TRIGGER SYS.DENY_MSB_TRIGGER_UPDATEDD
AFTER LOGON ON Database
DECLARE
v_programname varchar2(64);
v_logontime date;
v_process varchar2(24);
v_machine varchar2(64);
v_sid number;
v_serialnum number;
v_username varchar2(30);
v_stmt2run VARCHAR2(327);
cur INTEGER;
ret INTEGER;
v_string VARCHAR2(500);
BEGIN
SELECT PROGRAM, PROCESS, MACHINE, SID, SERIAL#, USERNAME
INTO v_programname, v_process, v_machine, v_sid, v_serialnum, v_username
FROM V$SESSION
WHERE PROGRAM = LOWER('ex_oc.exe');
INSERT INTO SAUDIT.DENYMSB (PROGRAM, PROCESS, MACHINE, SID, SERIALNUM, USERNAME)
VALUES (v_programname, v_process, v_machine, v_sid, v_serialnum, v_username );
v_string := 'ALTER SYSTEM KILL SESSION' || CHR(39)||v_sid||','||v_serialnum|| CHR(39)||' IMMEDIATE';
EXECUTE IMMEDIATE v_string;
END;
Edited by: user12451703 on Jan 14, 2010 8:57 AM
Edited by: user12451703 on Jan 14, 2010 8:58 AM

user12451703 wrote:
I'm not trying to kill my own session.
Trigger written by Sys and running it as a generic user.You completely misunderstand triggers. Same as SP/SF trigger is always executed in invoking session on behalf of trigger owner. Below is a slighly modified version of your trigger that does not allow user U1 to connect by killing user U1 session:
SQL> connect scott as sysdba
Enter password: *****
Connected.
SQL> CREATE OR REPLACE TRIGGER SYS.DENY_MSB_TRIGGER_UPDATEDD
2 AFTER LOGON ON Database
3 DECLARE
4 v_programname varchar2(64);
5 v_logontime date;
6 v_process varchar2(24);
7 v_machine varchar2(64);
8 v_sid number;
9 v_serialnum number;
10 v_username varchar2(30);
11 v_stmt2run VARCHAR2(327);
12 cur INTEGER;
13 ret INTEGER;
14 v_string VARCHAR2(500);
15 BEGIN
16 SELECT PROGRAM, PROCESS, MACHINE, SID, SERIAL#, USERNAME
17 INTO v_programname, v_process, v_machine, v_sid, v_serialnum, v_username
18 FROM V$SESSION where username = 'U1';
19 EXECUTE IMMEDIATE ('ALTER SYSTEM KILL SESSION ''' || v_sid || ',' || v_serialnum || '''');
20 EXCEPTION
21 WHEN OTHERS THEN
22 RAISE_APPLICATION_ERROR(-20001, 'Execution of this program not allowed', TRUE);
23 END;
24 /
Trigger created.
SQL> create user u1 identified by u1
2 /
User created.
SQL> grant create session to u1
2 /
Grant succeeded.
SQL> connect u1/u1
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: Execution of this program not allowed
ORA-06512: at line 20
<font color=red size =2>ORA-00027: cannot kill current session</font>
Warning: You are no longer connected to ORACLE.
SQL>
Also, user not that keen to change the name of the exe.Is cex_soc.exe client side executable? If so what prevents user from renaming it?
SY.

ALTER SYSTEM KILL SESSION

Hello Everybody,
1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
thanks in advance

Welcome to the forum!
Whenever you post provide your 4 digit Oracle version (result of SELECT * FROM V$VERSION)
>
Hello Everybody,
1) Is there any difference between “ALTER SYSTEM KILL SESSION & “kill -9”? Which one is the preferred method?
2) When we do alter system kill 'sid, serial#'. Are we killing the user process or the server process?
>
You should only use the 'kill' from the OS as a last resort.
There are TWO Oracle options: KILL session and DISCONNECT session. Only rarely, in my experience will DISCONNECT SESSION not get the job done.
See ALTER SYSTEM in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
>
end_session_clauses
The end_session_clauses give you several ways to end the current session.
DISCONNECT SESSION Clause
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever). To use this clause, your instance must have the database open. You must identify the session with both of the following values from the V$SESSION view:
•For integer1, specify the value of the SID column.
•For integer2, specify the value of the SERIAL# column.
If system parameters are appropriately configured, then application failover will take effect.
•The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
•The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
◦If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
◦If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
See Also:
"Disconnecting a Session: Example"
KILL SESSION Clause
The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources. To use this clause, your instance must have the database open. Your session and the session to be terminated must be on the same instance unless you specify integer3.You must identify the session with the following values from the V$SESSION view:
•For integer1, specify the value of the SID column.
•For integer2, specify the value of the SERIAL# column.
•For the optional integer3, specify the ID of the instance where the target session to be killed exists. You can find the instance ID by querying the GV$ tables.
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. The PMON background process then marks the session as terminated when the activity is complete.
Whether or not the session has an ongoing transaction, Oracle Database does not recover the entire session state until the session user issues a request to the session and receives a message that the session has been terminated.
See Also:
"Terminating a Session: Example"
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.

Urgent-how to run 'alter system kill session 'sid, serial#' in form 6i ?

I want to write a procedure in Form 6i so that user can kill the session by herself.
I know kill session sql is 'alter system kill session 'sid, serial#'', however, I fould that I can only run it it sql plus screen, how can I run it in Form or in Stored procedure?
Urgent....Please!

try using Forms_ddl('alter system......'); in the forms. it will execute the dml statements in the form.
zaibi.

ALTER SYSTEM KILL SESSION privilege

Hi All,
Is there any possibility to use this command from a without having DBA priviileges, what is the privilege to be grantd to the ordinary users to execute ALTER SYSTEM KILL SESSION... statement..
Thanks in advance

The procedure proposed by Rusell would be more or less so:
SQL> create or replace procedure kill_session
2 ( v_sid number, v_serial number )
3 as
4 v_varchar2 varchar2(100);
5 begin
6 execute immediate 'ALTER SYSTEM KILL SESSION '''
7 || v_sid || ',' || v_serial || '''';
8 end;
9 /
Procedure created.
SQL> select username, sid, serial# from v$session;
USERNAME                              SID    SERIAL#
                                      147       5078
SYS                                   148       6161
                                      151       6769
                                      156          1
                                      158          1
                                      159          1
REPOS_OWNER                           161      14502
                                      163          1
                                      164          1
                                      165          1
                                      166          1
USERNAME                              SID    SERIAL#
                                      167          1
                                      168          1
                                      169          1
                                      170          1
15 rows selected.
SQL>
SQL> exec kill_session(161,14502);
PL/SQL procedure successfully completed.
SQL>Joel Pérez
http://otn.oracle.com/experts

Abend while executing alter system kill session command

I have a ML350 G3 Hp server(Xeon 2.4 Ghz) running oracle 8.1.5 on Novell 5.1. Frequently i have locking problems in my software. So when i tried to kill the active session using alter system kill session 'sid, serial#' my server produce following error:
Fatal Exception (Number 14, cause abend: Page fault running process: orcl_000000fe code executing in module core81.nlm v8.1d at offset +6c490h). Any suggestions.

This forum is for posting feedback about the OTN site.
The best place for your question is probably a Database forum.
There is a list of Database forums here:
http://forums.oracle.com/forums/index.jsp?cat=18

Regarding Alter System Kill Session

Hi Guys,
I have to do db refresh from the build .For this I have to kill the sessions and drop the users and recreate the users with the latest build.As the application is running and there are some idle sessions, I have to kill the sessions and drop the users for that I am using a code as below
DECLARE
v_alt_stmt VARCHAR2(1000) := 'ALTER SYSTEM KILL SESSION ''';
v_kill_stmt VARCHAR2(1000);
CURSOR cur_session IS
SELECT s.type type,
s.sid sid,
s.serial# srl_no,
s.username user_name,
s.PROGRAM prog_name
FROM v$session s JOIN gv$process p ON p.addr = s.paddr and s.type='USER';
BEGIN
EXECUTE IMMEDIATE 'ALTER SYSTEM ENABLE RESTRICTED SESSION';
DBMS_OUTPUT.PUT_LINE('The Session has been put in the restricted mode');
FOR v_cur_ssn IN cur_session
LOOP
BEGIN
v_kill_stmt := v_alt_stmt || v_cur_ssn.sid || ',' || v_cur_ssn.srl_no || '''';
DBMS_OUTPUT.PUT_LINE(v_kill_stmt);
EXECUTE IMMEDIATE v_kill_stmt;
EXCEPTION
WHEN others THEN
-- DBMS_OUTPUT.PUT_LINE('The current sessions sid is ' || v_cur_ssn.sid || ' and the srl no is ' || v_cur_ssn.srl_no || ' can not be killed');
END;
END LOOP;
EXECUTE IMMEDIATE 'ALTER SYSTEM DISABLE RESTRICTED SESSION';
DBMS_OUTPUT.PUT_LINE('The restricted mode of the system has been removed');
END;
But sometimes after killing the sessions there are some os processes are going on,to avoid that I have to use 'ALTER SYSTEM DISCONNECT SESSION ''' and 'MMEDIATE' it is workig fine .
Can Any one tell me the logical difference between kill sessions and disconnect
Any information will be highly appreciated.
Thanks in advance
Prafulla

>
Can Any one tell me the logical difference between kill sessions and disconnect
>
Disconnect can be used to disconnect immediately without waiting for any ongoing transactions to complete and recovers all session resousrces.
Kill rolls back ongoing transactions and partially recovers session resources.
Kill is simiilar to SHUTDOWN IMMEDIATE while disconnect is more like SHUTDOWN ABORT.
See DISCONNECT SESSION Clause in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm
>
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever).
•The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.
>
And KILL SESSION in the same doc next section
>
The KILL SESSION clause lets you mark a session as terminated, roll back ongoing transactions, release all session locks, and partially recover session resources.
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.

Alter system kill session in RAC

Hi,
After identifying all inactive jdbc sessions or blocking sessions from gv$session or gv$lock respectively, should alter system kill session executed in both instances of RAC?, Can't we execute like alter system kill session ' inst_id,sid,serial#' from a single instance to kill all the session of RAC instances?
So, above problem answered in 11g as:
Alter system kill session ‘SID, serial#, @instance_id’;
Eg: ALTER SYSTEM KILL SESSION ‘115,9779,@1';
So, In our environment, most of the databases are in 10gR1 or 10g R2. Is there any patch for 10g Where instance_id can be recognized by alter system kill session?
Thanks,
Sunil.

Hi Dan,
Not sure what you mean by "instance specific kill session capability".
To be clear, I'm speaking of a new feature, introduced in 11gR1, that provides for an optional third parameter to 'alter system kill session', which allows you to kill a session on a remote instance, in a RAC environment.
Documentation is here:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_2013.htm#i2065117
-Mark

Trace File Created Upon Execution of "alter system kill session sid, serial# immediate;"

A problem within a third-party application is causing it to create and abandon Oracle sessions. At times three hundred or more abandoned sessions accumulated in the instance. The software company is working on the problem. Oracle's background processes will get rid of those sessions after several hours, but at times there were so many they caused the server to start using paging space. We wrote a SQL*Plus script to identify the abandoned sessions and kill them with command "alter system kill session <sid, serial#> immediate;". We automated the execution of the script a week ago. Today I noticed that in my udump directory an Oracle trace file has been created each time our script kills a session. A single trace file is created regardless of how many sessions are killed. No errors appear in the trace file.
Is the creation of these trace files an indication that problems have occurred or are they there for information only?
Since I know how and why the sessions are being killed, is it safe to ignore the trace files?
Thank you,
Bill

The OS is AIX 5.2. The database server is 10.2.0.2. We are in the processing of upgrading to AIX 7.1 and database server 11.2.0.3.6.
The script does not enable tracing for the SQL*Plus session.
Below is the alert log message from a session killed at 11:22, and the corresponding trace file created at that same time:
From alert_<sid>.log:
Wed Jul 31 11:22:01 2013
Immediate Kill Session#: 1119, Serial#: 59885
Immediate Kill Session: sess: 70000014dc4a7e0 OS pid: 267254
/u02/admin/EXPRESS/udump $ ls -l express_ora_113358.trc
-rw-r----- 1 oracle dba 2276 Jul 31 11:22 express_ora_113358.trc
/u02/admin/EXPRESS/udump $ pg express_ora_113358.trc
Dump file /u02/admin/EXPRESS/udump/express_ora_113358.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0
System name: AIX
Node name: navis
Release: 2
Version: 5
Machine: 0005CD8C4C00
Instance name: EXPRESS
Redo thread mounted by this instance: 1
Oracle process number: 225
Unix process pid: 113358, image: oracleEXPRESS@navis
*** ACTION NAME:() 2013-07-31 11:22:01.181
*** MODULE NAME:(SQL*Plus) 2013-07-31 11:22:01.181
*** SERVICE NAME:(EXPRESS.WORLD) 2013-07-31 11:22:01.181
*** SESSION ID:(1723.61000) 2013-07-31 11:22:01.181
SO: 70000014d44d278, type: 2, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=463, calls cur/top: 0/700000139166298, flag: (0) -
int error: 0, call error: 0, sess error: 0, txn error 0
(post info) last post received: 108 0 4
last post received-location: kslpsr
last process to post me: 70000014d36c398 1 6
last post sent: 0 0 24
last post sent-location: ksasnd
last process posted by me: 70000014d36c398 1 6
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 70000014d6aec00
O/S info: user: oracle, term: UNKNOWN, ospid: 267254
OSD pid info: Unix process pid: 267254, image: oracleEXPRESS@navis
Short stack dump:
ksdxfstk+002c<-ksdxcb+04e4<-sspuser+0074<-00004CB0<-nttrd+0120<-nsprecv+0750<-ns
rdr+0114<-nsdo+1714<-nsbrecv+0040<-nioqrc+04a8<-opikndf2+0688<-opitsk+088c<-opii
no+0990<-opiodr+0adc<-opidrv+0474<-sou2o+0090<-opimai_real+01bc<-main+0098<-__st
art+0090
Dump of memory from 0x070000014D2CC3B0 to 0x070000014D2CC5B8
70000014D2CC3B0 00000004 00000000 07000001 39DA8D48 [............9..H]
70000014D2CC3C0 00000010 0003139D 07000001 39166298 [............9.b.]
70000014D2CC3D0 00000003 0003139D 07000001 4C73D508 [............Ls..]
70000014D2CC3E0 0000000B 0003139D 07000001 4DC4A7E0 [............M...]
70000014D2CC3F0 00000004 00031291 00000000 00000000 [................]
70000014D2CC400 00000000 00000000 00000000 00000000 [................]
Repeat 26 times
70000014D2CC5B0 00000000 00000000 [........]
Thanks,
Bill

Can't kill session with "Alter system kill session"?

I'm using 9iR2.
After I check the v$session table:
SQL> select sid, serial# from v$session where username='XMLDEMO';
SID SERIAL#
18 19155
I issue the command:
SQL> alter system kill session '18,19155' immediate;
System altered.
But after this, I still can find this session:
SQL> select sid, serial# from v$session where username='XMLDEMO';
SID SERIAL#
18 19155
Can anyone tell me why? Did I miss something?
Any help will be appreciated.
Jinyu

keep issuing that query and notice if the serial number starts to change..if it does it is reflecting pmon cleaning up the sessions, when pmon finishes his work
the sesison will disappear from v$session.
steve
I'm using 9iR2.
After I check the v$session table:
SQL> select sid, serial# from v$session where username='XMLDEMO';
SID SERIAL#
18 19155
I issue the command:
SQL> alter system kill session '18,19155' immediate;
System altered.
But after this, I still can find this session:
SQL> select sid, serial# from v$session where username='XMLDEMO';
SID SERIAL#
18 19155
Can anyone tell me why? Did I miss something?
Any help will be appreciated.
Jinyu

Alter system kill session 'sid, serial#'

Hi,
how can I do
alter system kill session 'sid, serial#'
while sid and serial# should come from :
select sid, serial# from v$session where
Explanation :
I want :something like :
alter system kill session 'select sid, serial# from v$session where '
Do you know a solution?
Many thanks before.

In SQL*Plus you could issue:
SQL> select
2     'alter system kill session '''||TO_CHAR(sid)||','||to_char(serial#)||''';'
3 from
4     v$session
5 where
6     username=user
7 /
'ALTERSYSTEMKILLSESSION'''||TO_CHAR(SID)||','||TO_CHAR(SERIAL#)||''';'
alter system kill session '421,4259';
alter system kill session '424,103';Then copy + run the output.
HTH
David

Can I execute "Alter System Disconnect Session" in a OLE VB Script?

Will this work? If not - How to do it?
The speadsheet contains a list of sid's and serial#. I want to highlight a cell containing a username, then run the kill session macro on it.
Sub Kill_Session()
Dim KillStatement As Object
DBPassword = "uuuu/pppppppp"
DatabaseName = "dddd"
Set objSession = CreateObject("OracleInProcServer.XOraSession")
Set objdatabase = objSession.opendatabase(DatabaseName, DBPassword, 0&)
objdatabase.Parameters.Add "SERIAL", 0, 2
objdatabase.Parameters("SERIAL").ServerType = 1
objdatabase.Parameters.Add "SID", 0, 2
objdatabase.Parameters("SID").ServerType = 1
Inputdata = ActiveCell.Value
RowNo = ActiveCell.Row
objdatabase.Parameters("SERIAL").Value = Worksheets("Sheet1").Cells(RowNo, 13)
objdatabase.Parameters("SID").Value = Worksheets("Sheet1").Cells(RowNo, 12)
Set OraSqlStmt = objdatabase.CreateSQL("ALTER SYSTEM DISCONNECT SESSION ':SID, :SERIAL' IMMEDIATE;", 0&)
MsgBox objdatabase.Parameters("SID").Value
MsgBox objdatabase.Parameters("SERIAL").Value
objdatabase.Parameters.Remove ("SERIAL")
objdatabase.Parameters.Remove ("SID")
End Sub

on 10gR1/10gR2, you can not use
ALTER SYSTEM KILL SESSION ‘115,9779,@1';that start from 11gR1
Only
* For integer1, specify the value of the SID column.
* For integer2, specify the value of the SERIAL# column.
ALTER SYSTEM KILL SESSION ‘115,9779';http://download.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_2013.htm#SQLRF00902
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_2013.htm#SQLRF00902
You may use crontab to help ....
Example about blocking (SID):
select 'ALTER SYSTEM KILL SESSION ''' ||sid||','||serial#|| ''' IMMEDIATE;' from gv$session s where sid in (
select distinct(l1.sid) from
gv$lock l1, gv$lock l2
where l1.block = 1 and l2.request > 0
and l1.id1=l2.id1
and l1.id2=l2.id2
) AND INST_ID = (select INSTANCE_NUMBER from v$instance )and ....
Good Luck

ALTER SYSTEM SET processes=1000 generates ORA-00064: object is too large to

Hi All
I'm using Oracle Release 10.2.0.1.0.
When performing:
=============
ALTER SYSTEM SET processes=10000 SCOPE=SPFILE;
We can't start the 10g DB: ORA-00064: object is too large to allocate on this O/S (1,5282400)
When reducing the size to 150 there is no problem starting the db. I can not start it. ORA-00064: object is too large to allocate on this O/S (1,5282400)
I refered to ORA-00064: object is too large to allocate on this O/S :::Plz Help Me
But I can not resolve this problem.
Please help me.
thiensu

Not sure, because i haven't got ORA-00064 yet.
ORA-00064: object is too large to allocate on this O/S num, num
Cause: The initialization parameter DB_BLOCK_SIZE is set to a value that calls for more contiguous space than can be allocated on the operating system being used.
Action: Reduce the value of DB_BLOCK_SIZE so that the requested contiguous space is within the capacity of the operating system.
http://www.pitt.edu/~hoffman/oradoc/server.804/a58312/newch2a1.htm
Regards
Girish Sharma

64-bit OCILogon() is fine, but 32-bit version always gives ORA-12154

Hello,
I am porting an application from Oracle 9.2 on Solaris 8 on Sparc to
Oracle 10.2 on Solaris 10 on x64, using Sun C++ 5.8 on both.
The Oracle installation was quite straightforward, and everything works fine, except that if I compile my app for 32-bit all I ever get from
OCI is 'ORA-12154: TNS:could not resolve the connect identifier specified'
sqlplus and tnsping, which are both 64-bit executables are also fine.
Here is a little example program which writes a few BLOBs into
an existing table:
sun03%
sun03% printenv
HOME=/d0/sj
SHELL=/bin/csh
PATH=/usr/bin:/usr/ucb:/usr/bin:/etc:/usr/local/bin:/opt/csw/bin:/opt/sfw/bin:/u
sr/dt/bin:/usr/ccs/bin:/usr/xpg4/bin:/opt/v11/SUNWspro/bin:/usr/openwin/bin:/usr
/sbin:/usr/local/samba/bin:/opt/sfw/sbin:/usr/platform/sun4u/sbin:/usr/ccs/bin:/
usr/sfw/bin:/d0/adam/Rational/releases/PurifyPlus.7.0/sun4_solaris2/bin:/usr/ORA
/bin:/usr/sbin
USER=sj
PWD=/d0/sj/handover
ORACLE_SID=oradev1
ORACLE_HOME=/opt/oracle/product/10.2.0/db_1
LD_LIBRARY_PATH=/usr/ORA/lib
THREADS_FLAG=native
LOGNAME=sj
LIBPATH=/usr/ORA/lib:/usr/local/lib
LANG=en_GB
sun03%
sun03%
sun03% cat ora_prog1.h
#define USERNAME "sj"
#define PASSWORD "sj"
#define ORASID "oradev1"
#define NUM_OF_BLOBS 3
#define BLOB_SIZE 32766
sun03%
sun03% cat ora_prog1.cpp
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <oci.h>
#include <oratypes.h>
#include <string>
#include "ora_prog1.h"
using namespace std;
#define OCI_CHECK(errhp, htype, status, OCIfunc) \
do { if (OCI_SUCCESS != ((status) = (OCIfunc)))                                             \
string msg = checkerr((dvoid *)(errhp), (ub4)(htype), (sword)(status), (text *)0, \
(sb4)0, (text *)__FILE__, (sb4)__LINE__); \
cleanup(msg); \
} } while(0)
// get the error from the DB
void errprint(dvoid errhp, ub4 htype, sb4 errcodep,
string& msg)
text errbuf[512];
if (errhp)
sb4 errcode;
if (errcodep == (sb4 *)0)
errcodep = &errcode;
(void) OCIErrorGet((dvoid *)errhp, (ub4) 1, (text *) NULL, errcodep,
errbuf, (ub4) sizeof(errbuf), htype);
char outBuffer[1024];
(void) sprintf(outBuffer, "Error - %.*s\n", 512, errbuf);
msg += outBuffer;
// generate and return the appropriate error message
string checkerr(dvoid errhp, ub4 htype, sword status, text note,
sb4 code, text *file, sb4 line)
string msg = "";
// make sure that each print fits into this buffer
char outBuffer[1024];
sb4 errcode = 0;
if (status != OCI_SUCCESS)
(void) sprintf(outBuffer, "OCI Error %ld occurred at File %s:%ld\n",
(long)status, (char *)file, (long)line);
msg += outBuffer;
if (note)
(void) sprintf(outBuffer, "File %s:%ld (code=%ld) %s\n",
(char *)file, (long)line, (long)code, (char *)note);
msg += outBuffer;
switch (status)
case OCI_SUCCESS:
break;
case OCI_SUCCESS_WITH_INFO:
(void) sprintf(outBuffer, "Error - OCI_SUCCESS_WITH_INFO\n");
msg += outBuffer;
errprint(errhp, htype, &errcode, msg);
msg += outBuffer;
break;
case OCI_NEED_DATA:
(void) sprintf(outBuffer, "Error - OCI_NEED_DATA\n");
msg += outBuffer;
break;
case OCI_NO_DATA:
(void) sprintf(outBuffer, "Error - OCI_NO_DATA\n");
msg += outBuffer;
break;
case OCI_ERROR:
errprint(errhp, htype, &errcode, msg);
break;
case OCI_INVALID_HANDLE:
(void) sprintf(outBuffer, "Error - OCI_INVALID_HANDLE\n");
msg += outBuffer;
break;
case OCI_STILL_EXECUTING:
(void) sprintf(outBuffer, "Error - OCI_STILL_EXECUTE\n");
msg += outBuffer;
break;
case OCI_CONTINUE:
(void) sprintf(outBuffer, "Error - OCI_CONTINUE\n");
msg += outBuffer;
break;
default:
break;
return msg;
// Display info or fail
void cleanup(string& msg)
fprintf(stderr, "Oracle failed message:\n%s",
msg.c_str());
exit(1);
int main()
sword ociret;
OCIEnv *envhp;                  // environment handle
OCIError *errhp;                // error handle
OCISvcCtx *svchp;               // service context
OCIStmt *stmthp;                // statement handle
OCILobLocator *lobLoc;
OCIBind *bindp = 0;
OCIDefine *defnp = 0;
char stmt[1024];
char data = (char )malloc(BLOB_SIZE);
OCI_CHECK((dvoid *)0, (ub4)0, ociret,
OCIEnvCreate(&envhp, OCI_DEFAULT, (dvoid *)0,
0, 0, 0, (size_t)0, (dvoid **)0));
OCI_CHECK(envhp, OCI_HTYPE_ENV, ociret,
OCIHandleAlloc((dvoid *)envhp, (dvoid **)&errhp,
OCI_HTYPE_ERROR, 0, (dvoid **) 0));
// Create a handle for writing SQL statements - this is reused with various stmts
OCI_CHECK(envhp, OCI_HTYPE_ENV, ociret,
OCIHandleAlloc((dvoid *)envhp, (dvoid **)&stmthp,
OCI_HTYPE_STMT, (size_t)0, (dvoid **)0));
// Simplified logon for a single user session for one DB connection
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCILogon(envhp, errhp, &svchp,
(CONST OraText *)USERNAME, strlen(USERNAME),
(CONST OraText *)PASSWORD, strlen(PASSWORD),
(CONST OraText *)ORASID, strlen(ORASID)));
// Allocate the LOB descriptors
OCI_CHECK(envhp, OCI_HTYPE_ENV, ociret,
OCIDescriptorAlloc((CONST dvoid *)envhp,
(dvoid **)&lobLoc, OCI_DTYPE_LOB, 0, 0));
for(int i = 0; i < NUM_OF_BLOBS; i++)
memset(data, 'A'+i, BLOB_SIZE);
sprintf(stmt, "INSERT INTO TEST_TABLE VALUES (%d, :1)", i);
// Set the LOB to empty in order that it may be involved in an insert
ub4 lobEmpty = 0;
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIAttrSet(lobLoc, OCI_DTYPE_LOB, &lobEmpty, 0,
OCI_ATTR_LOBEMPTY, errhp));
// Prepare to insert the empty LOBs
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIStmtPrepare(stmthp, errhp,
(text *)stmt, (ub4)strlen(stmt),
OCI_NTV_SYNTAX, OCI_DEFAULT));
// Bind the BLOB to the parameter
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIBindByPos(stmthp, &bindp, errhp,
(ub4)1, (dvoid *)&lobLoc, (sb4)-1,
SQLT_BLOB, 0, 0, 0, 0, 0, OCI_DEFAULT));
// Execute the statement
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIStmtExecute(svchp, stmthp, errhp,
(ub4)1, (ub4)0,
(CONST OCISnapshot *)NULL, (OCISnapshot *)NULL,
OCI_DEFAULT));
// Lock the row for update
sprintf(stmt, "SELECT DATA FROM TEST_TABLE WHERE ID=%d FOR UPDATE", i);
// Prepare a statement that will read the LOB
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIStmtPrepare(stmthp, errhp,
(text *)stmt, (ub4)strlen(stmt),
OCI_NTV_SYNTAX, OCI_DEFAULT));
// Define space to hold the result of the query
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIDefineByPos(stmthp, &defnp, errhp,
(ub4)1, &lobLoc, -1,
SQLT_BLOB, 0, 0, 0, OCI_DEFAULT));
// Execute the statement
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCIStmtExecute(svchp, stmthp, errhp,
(ub4)1, (ub4)0,
(CONST OCISnapshot *)NULL, (OCISnapshot *)NULL,
OCI_DEFAULT));
ub4 expected_len = BLOB_SIZE;
// Write data in one go
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCILobWrite(svchp, errhp, lobLoc,
&expected_len, (ub4)1,
data, BLOB_SIZE, OCI_ONE_PIECE, 0, 0, 0, SQLCS_IMPLICIT));
assert(expected_len == BLOB_SIZE);
OCI_CHECK(errhp, OCI_HTYPE_ERROR, ociret,
OCITransCommit(svchp, errhp, OCI_DEFAULT));
// Cleanup by freeing the descriptor
(void)OCIDescriptorFree(lobLoc, OCI_DTYPE_LOB);
sun03%
sun03%
sun03% CC -xtarget=native64 -I/usr/ORA/rdbms/public -L/usr/ORA/lib -lclntsh -o ora_prog1 ora_prog1.cpp
sun03% ora_prog1
Compiled for 64-bit the program runs silently.
But if I redirect my paths to the 32-bit libraries and
recompile for 32-bit, OCILogon always fails:
sun03%
sun03%
sun03% setenv LIBPATH /usr/ORA/lib32:/usr/local/lib
sun03% setenv LD_LIBRARY_PATH /usr/ORA/lib32
sun03% CC -I/usr/ORA/rdbms/public -L/usr/ORA/lib32 -lclntsh -o ora_prog1 ora_prog1.cpp
sun03% ora_prog1
Oracle failed message:
OCI Error -1 occurred at File ora_prog1.cpp:143
Error - ORA-12154: TNS:could not resolve the connect identifier specified
sun03%
Recompiling for 32-bit like this works fine on Oracle 9.2 on Solaris 8,
so I have obviously missed something simple in my installation.
Any help would be appreciated.
Thanks
-- Steve

Hi prajithparan,
I am facing the same problem on my Dual Core AMD running Solaris 11.06 x96-64. As long as I compile and link using the flag '-m64' everything work fine. But I use '-m32' or none getting 32 bit binaries I got the same error:
'ORA-12154: TNS:could not resolve the connect identifier specified'
even my LD_LIBRARY_PATH is set as below:
echo $LD_LIBRARY_PATH
/oracle/app/product/10.2.0/lib32
Also I have to mention that SQLPLUS and TNSPING works fine on my side too. So I suppose that there is something wrong with trying to use 32 bit ORACLE libraries. Any idea?
Please find attached my output (my APP is OCI / C based but not OCCI / C++):
./cdemouni user comext password noftnc dblink test stmt "select table_name from all_tables"
option --user (-u) with value comext
option --password (-p) with value noftnc
option --dblink (-d) with value test
option --stmt (-s) with value select table_name from all_tables
OCIServerAttach( test -- 4 )
FAILED: OCIServerAttach(), RC = -1
Error [ OCI error 12154 ]- ORA-12154: TNS:could not resolve the connect identifier specified
Regards,
Ioan

Alter system kill session always gives ORA-00030

Similar Messages

Maybe you are looking for