FOR UPDATE...SKIP LOCKED - Is it supported to use in 10.2?

Hi.
Is the "SKIP LOCKED" feature in SELECT..FOR UPDATE..SKIP LOCKED supported to use in 10.2.0.3?
It does exactly what we want to do. The patchsets for 10g also contains bug fixes for this feature.
I know that it's supported (and documented) for 11g, but we have not upgraded yet.
Also I'm fully aware of the locking mechanism using this feature (it does not lock when opening a cursor,
it locks when the rows are fetched).
Regards
Krister Lundmark

Also I'm fully aware of the locking mechanism using this feature (it does not lock when opening a cursor,
it locks when the rows are fetched).Usual FOR UPDATE statement locks data at the moment of cursor opening - according to the concepts it has to get
locked consistent snapshot before fetching. SKIP LOCKED differs from usual FOR UPDATE in that it
tries to lock at the moment of fetch and skips rows already locked by other transactions:
The first transaction:
SQL> select ename from emp where ename = 'KING' for update;
ENAME
KINGThe second: I wait at the moment of cursor opening, not fetching
SQL> declare
2 cursor x is select * from emp for update;
3 begin
4 open x;
5 end;
6 /Now I lock 'KING' and open FOR UPDATE SKIP LOCKED cursor
SQL> var rc refcursor
SQL> exec open :rc for select ename from emp where ename in ('KING','ALLEN') for update skip locked;
PL/SQL procedure successfully completed.I can lock 'ALLEN' in another transaction - cursor opening didn't lock it:
SQL> select ename from emp where ename = 'ALLEN' for update;
ENAME
ALLENAnd then I fetch cursor I find it's empty - I can't find unlocked rows at the fetch stage:
SQL> print rc
no rows selectedRgds.

Similar Messages

11g FOR UPDATE SKIP LOCKED behavior

Hello pl/sql experts,
I am trying to test the new SELECT clause in 11g called FOR UPDATE SKIP LOCKED.
I don't understand why I am getting the following error.
Here is a test case:
DROP TABLE T1 PURGE;
CREATE TABLE t1 (id NUMBER, name VARCHAR2 (10));
INSERT INTO t1 VALUES (1, 'a');
INSERT INTO t1 VALUES (1, 'b');
INSERT INTO t1 VALUES (2, 'a');
INSERT INTO t1 VALUES (2, 'b');
INSERT INTO t1 VALUES (3, 'a');
INSERT INTO t1 VALUES (3, 'b');
INSERT INTO t1 VALUES (4, 'a');
INSERT INTO t1 VALUES (4, 'b');
INSERT INTO t1 VALUES (5, 'a');
INSERT INTO t1 VALUES (5, 'b');
INSERT INTO t1 VALUES (6, 'a');
INSERT INTO t1 VALUES (6, 'b');
INSERT INTO t1 VALUES (7, 'a');
INSERT INTO t1 VALUES (7, 'b');
INSERT INTO t1 VALUES (8, 'a');
INSERT INTO t1 VALUES (8, 'b');
INSERT INTO t1 VALUES (9, 'a');
INSERT INTO t1 VALUES (9, 'b');
INSERT INTO t1 VALUES (10, 'a');
INSERT INTO t1 VALUES (10, 'b');
COMMIT;
Now run following anonymous pl/sql block in 2 sessions simultaneously.
SET SERVEROUTPUT ON
DECLARE
CURSOR c (c_id t1.id%TYPE)
IS
SELECT ROWID rid, id, name
FROM t1
WHERE id = c_id
FOR UPDATE SKIP LOCKED;
TYPE t_rowid IS TABLE OF ROWID
INDEX BY BINARY_INTEGER;
TYPE t_id IS TABLE OF t1.id%TYPE
INDEX BY BINARY_INTEGER;
TYPE t_name IS TABLE OF t1.name%TYPE
INDEX BY BINARY_INTEGER;
l_rowid t_rowid;
l_id t_id;
l_name t_name;
BEGIN
FOR i IN ( SELECT DISTINCT id
FROM t1
ORDER BY 1)
LOOP
OPEN c (i.id);
LOOP
FETCH c
BULK COLLECT INTO l_rowid, l_id, l_name;
FOR j IN l_id.FIRST .. l_id.LAST
LOOP
DBMS_OUTPUT.put_line (l_id (j) || ' : ' || l_name (j));
END LOOP;
DBMS_LOCK.sleep (1);
EXIT WHEN c%NOTFOUND;
END LOOP;
CLOSE c;
END LOOP;
ROLLBACK;
END;
The first session runs fine and produces following output.
SQL> /
1 : a
1 : b
2 : a
2 : b
3 : a
3 : b
4 : a
4 : b
5 : a
5 : b
6 : a
6 : b
7 : a
7 : b
8 : a
8 : b
9 : a
9 : b
10 : a
10 : b
PL/SQL procedure successfully completed.
The second session fails:
SQL> /
DECLARE
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at line 32
Line 32 is: FOR j IN l_id.FIRST .. l_id.LAST
I keep getting the error in session 2 while the block is still running in session 1. As soon as the block finishes in session 1, session 2 runs without any error and produces the same output as session 1 did.
I have 2 questions:
1. Why am I getting this error?
2. The documentation on FOR UPDATE SKIP LOCKED says the row locks are acquired when a fetch occurs. Does that also apply to BULK FETCH? So should I expect to have 2 rows locked per iteration of the loop in the example above?
Thank you.

Toon,
Thank you. You are absolutely correct.
The bulk fetch results in zero rows found when they are locked.
So I need to change my code as follows:
FETCH c
BULK COLLECT INTO l_rowid, l_id, l_name;
IF (l_id.COUNT > 0)
THEN
FOR j IN l_id.FIRST .. l_id.LAST
LOOP
DBMS_OUTPUT.put_line (l_id (j) || ' : ' || l_name (j));
END LOOP;
DBMS_LOCK.sleep (1);
END IF;
I need to check to see if the count is greater than zero, then process, else skip the processing.
Thank you for figuring that out!

FOR UPDATE SKIP LOCKED

I've been working with the SELECT ...FOR UPDATE SKIP LOCKED feature and it appears to work great for skipping and locking records that are already locked.
But, I've read that it is "undocumented" and I'm wondering if it should not be used since it is undocumented?
Thanks in advance.

It appears in 11g documentation (http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_10002.htm#SQLRF01702 and search for "SKIP LOCKED").
But in 10g R2 it is indeed missing from docs. I'd check with "documentation" forum or with metalink whether it is undocumented on purpose or by mistake.

When does select for update release locks

Hello all,
Does anyone know when Oracle realeases the row locks when a
select for update is issued?
Does Oracle realase the row lock at the time when an actual update statement is
issued for the locked row, or does it wait until a commit statment is executed?
So for example, can I lock several rows with a select for update clause, and then
issue update statements as many times as I want on each locked row without
having to worry about the lock being released until I issue a commit statement.
Thanks,
David

yes.
The lock is released only when your transaction ends. A transaction can end because of:
1). Commit.
2). Rollback.
3). client disconnects.
etc. etc...

Solution to skip an update of locked record

9.2
Suppose there is a program which has to updates a record in the table. Record is currently locked
Need a solution to skip this update (possibly something like in 5 sec).
Thaks.
Solution like update ...where lock_status = 0 - is not good in this case
Edited by: Bolev on Feb 2, 2009 10:41 PM

Bolev wrote:
So go back to the original question
If there is an update in a program and I want to skip record if it is locked , the only solution is opening a cursor for upodate ?
Is this only way?Bolev,
yes, I think so, there is no equivalent option in the normal UPDATE DML command as far as I know. If you intend to change the code, I suggest you consider this recent post from Rob van Wijk where he shows a fundamental difference in the behaviour between the "SELECT FOR UPDATE" and the "SELECT FOR UPDATE SKIP LOCKED":
http://rwijk.blogspot.com/2009/02/for-update-skip-locked.html
Note in addition that the SKIP LOCKED option has only been officially documented in 11g, so if you're attempting to use it in pre-11g in production like environment (it's available in previous releases, but not officially documented) you might be out of support in case you encounter issues that you want to take up with Oracle support.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Inconsistent Locking with Select for Update

Hi,
I seem to be having some issues in using SELECT FOR UPDATE and was hoping to get some insight from the Oralce Guru's out there.
I have a J2EE application, running in WebLogic 8.1.4 using Oralce 9.2.0.1.0.
The application contains code that requires locking to be done on a specific table with multiple transactions (tx) requesting the same lock. Eg:
Tx 1: Select * from Zone where Zoneid = 'Zone1' for update (Obtains lock)
Tx 2: Select * from Zone where Zoneid = 'Zone1' for update (waits)
Tx 100: Select * from Zone where Zoneid = 'Zone1' for update
Tx1 commits.
It appears that the following transactions, i.e. Tx2 - Tx100 do not seem to execute in the order the lock was requested. That is Tx 100 always appears to be the second last transaction to execute, after which some arbitrary transaction between Tx2 - Tx99 will execute after Tx100 has committed.
This seems to tell me that the lock is not being handed in a FIFO manner and is causing us great pain as our data is not longer consistent.
Does anyone know how i might be able to trace which transaction is being awarded the lock? Also if anyone has any suggestion on how to troubleshoot/solve this issue, greatly appreciated.
TIA
Prem

Oracle does not have a lock queue/manager at all. The locked status of a record is essentially an attribute of the record itself. It is stored on the datablock header. When a transaction requests a lock and can't get it, and is willing to wait (SELECT FOR UPDATE without NOWAIT), it first spins while waiting for the lock (four times as I recall), then sleeps waiting for the lock. The the more times it sleeps before getting the lock, the longer it will sleep before trying again.
What is likely happening here is that transaction 100 is still spinning when transaction 1 commits, so checks back more frequently and gets the lock first. The rest get the lock whenever they wake up and noone else has taken the lock.
If you need the transaction to occur in order, then I do not think you can use Oracle's native locking mechanism. Depending on what exactly you are trying to do, you may want to look at Advanced Queueing, or possibly the built-in package DBMS_LOCK.
HTH
John

RE: for update clause

Hi,
If you are using Forte as 2-tier tools, there shouldn't be any problem in
using select ... for update. The sql is actually passed through to your
back-end database. So everything should work the same, provided that every
user has his own database session ( like by using DBResourceMgr to create
DBSession at run-time for each user. )
However, if you are building multi-tier application, there is no simple
answer to your question. The problem is common to all 3-tier application
since the application / database layer is shared among many users. If you
start a transaction from client side, use select ... for update to lock a
record, allow user to change data, then update and end the transaction, you
are not just locking up a record, but also a database session. In such
model, you will run out of DBSession very soon.
What we did here is to use a "lock count", which exists is every table.
When client retrieves a record, it won't start a transaction there. A
transaction is started only on the server and after client commits its
changes to the server. Data consistency is checked by checking the lock
count in the update where clause.
It looks dumb, but it's the only solution that we can reach after consulting
a lot of white paper and Forte consultants. Moreover, Forte consultant also
said its bad to start a transaction on client side.
I do hope that there is a better solution out there in handling 3-tier
applications too. Afterall, this lock count thing is clumsy.
Peter Sham.
-----Original Message-----
From: Phong Tran [SMTP:[email protected]]
Sent: Thursday, March 18, 1999 6:50 AM
To: [email protected]
Subject: for update clause
dear forte-users,
I notice the "for update" clause can only used with cursor.
Just wonder why you can not use it with "sql select ...." statement.
Also as I understand it, one way to protect the data consistency is
through
the mutex lock but then you turn the object to a single-threaded to
serialize access even though you access different rows in a
database
table. The fact is you only want access on a particular row.
Does anyone know the best way to lock a row (or rows) in the
database ?
If you have to rely on the "for update" clause in the cursor
definition for
the locking, then you almost end up with a lot of cursors.
Example: the method ReadnWriteDB(ordeId) accesses a specific row
but since the orderOBj serializes access, other tasks have to wait.
OrderObj: OrderMgr = new(IsShared = TRUE, IsTransactional = TRUE);
method GetOrderInfo() of the TransactionSO.
begin transaction
OrderObj.ReadnWriteDB(orderId);
end transaction;
From Client:
Begin
start task TransactionSO.GetOrderInfo(orderId);
end;
Phong
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive
<URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Which application front end are you using.
Also, you'll get the same error if your Query runs too long, and/or your rollbacks are too small.

Unecessary use of SELECT...FOR UPDATE causing Deadlock

DB version:10gR2
We are getting a deadlock issue frequently. When i looked at the trace file i found that the Rolled back SQL and the Successfull SQL are both SELECT FOR UPDATE statements. They both are declared before UPDATE statments.
Both of these PL/SQL codes are developed by a C++ guy. When is it appropriate to use SELECT ..FOR UPDATE. I've seen SELECT ...FOR UPDATE very rarely in the codes developed by PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE to lock rows before UPDATE/DELETE/INSERT in their codes?

For update is a rowlevel locking. like
Session 1
SQL> conn scott/tiger
Connected.
SQL> select * from emp;
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7369 SMITH CLERK 7902 17-DEC-80 800 20
 7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30
 7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30
 7566 JONES MANAGER 7839 02-APR-81 2975 20
 7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30
 7698 BLAKE MANAGER 7839 01-MAY-81 2850 30
 7782 CLARK MANAGER 7839 09-JUN-81 2450 10
 7788 SCOTT ANALYST 7566 19-APR-87 3000 20
 7839 KING PRESIDENT 17-NOV-81 5000 10
 7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30
 7876 ADAMS CLERK 7788 23-MAY-87 1100 20
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7900 JAMES CLERK 7698 03-DEC-81 950 30
 7902 FORD ANALYST 7566 03-DEC-81 3000 20
 7934 MILLER CLERK 7782 23-JAN-82 1300 10
14 rows selected.
SQL> select * from emp where empno = 7369 for update;
 EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
 7369 SMITH CLERK 7902 17-DEC-80 800 20
SQL>
Session 2
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> update emp set sal = 1000 where empno = 7900
2 /
1 row updated.
SQL> commit;
Commit complete.
SQL> update emp set sal = 1000 where empno = 7369
2
SQL> /In session 1 we have lock row where empno = 7369 & in session 2 we are updating salary where empno = 7900 it is updating successfully, but we are updating a empno = 7369 then session 2nd hangs for waiting for the next session.
Also read the Link (http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html)

Select for update that doesn't return any rows

Are there any odd side-effects that may occur if a select for update that returns no results is never committed? I wouldn't think there are, but I'm not sure if there would be some kind of overhead or unforeseen consequences. This isn't a terribly important question, but it's come up in some coding I've done and I've not been able to find any documentation addressing it.

A select for update only locks rows that meet the predicate specified in the where clause. So, if the query returns no rows, no rows are locked.
session1> SELECT * FROM t;
        ID DESCR
         1 Un
         5 One
         2 THIS IS WA
session1> SELECT * FROM t
2 WHERE id = 11 FOR UPDATE;
no rows selectedA second session can update rows in the table
session2> UPDATE t
2 SET descr = 'One'
3 WHERE id = 1;
1 row updated.John
Edited by: John Spencer on Jan 7, 2009 1:36 PM
I just realized that, although you can do updates on the table after the select fo update that returns no rows, you cannot do DDL operations liike a truncate. Unless the session that does the select for update either ends the transaction (i.e. commit or rollback) or ends the session DDL operations will fail.

FOR UPDATE OF how does it work?

Hi,
I was wondering what was happening in the databse when a SELECT...FOR UPDATE... is executed. How does Oracle handle this Row Share Table Locks? How does the DB know which rows are locked?
Thanks for any feedback
Maurice

When you do a SELECT ... FOR UPDATE, Oracle locks each row that is returned by the SELECT. The mechanics of locking in Oracle is that the lock bit is actually stored in the row, rather than being centralized in the v$lock table. This allows Oracle to be very scalable and prevents you from worrying about things like lock escalation, but it makes it hard for individual DBA's and developer's to know what rows are locked.
Justin

Cursor have for update clause

Hi all,
Can any one please tell me,what is main use of for update cursor.in which case we are using this clause.with simple example can any one please explain.
Thanks,
K.venkata Sanjeeva Rao.

user13483989 wrote:
Can any one please tell me,what is main use of for update cursor.in which case we are using this clause.with simple example can any one please explain.Where you are looping through data for some reason and want to update the current row.
Simple example...
SQL> select * from emp;
     EMPNO ENAME      JOB              MGR HIREDATE                    SAL       COMM     DEPTNO
      7369 SMITH      CLERK           7902 17-DEC-1980 00:00:00        800                    20
      7499 ALLEN      SALESMAN        7698 20-FEB-1981 00:00:00       1600        300         30
      7521 WARD       SALESMAN        7698 22-FEB-1981 00:00:00       1250        500         30
      7566 JONES      MANAGER         7839 02-APR-1981 00:00:00       2975                    20
      7654 MARTIN     SALESMAN        7698 28-SEP-1981 00:00:00       1250       1400         30
      7698 BLAKE      MANAGER         7839 01-MAY-1981 00:00:00       2850                    30
      7782 CLARK      MANAGER         7839 09-JUN-1981 00:00:00       2450                    10
      7788 SCOTT      ANALYST         7566 19-APR-1987 00:00:00       3000                    20
      7839 KING       PRESIDENT            17-NOV-1981 00:00:00       5000                    10
      7844 TURNER     SALESMAN        7698 08-SEP-1981 00:00:00       1500          0         30
      7876 ADAMS      CLERK           7788 23-MAY-1987 00:00:00       1100                    20
      7900 JAMES      CLERK           7698 03-DEC-1981 00:00:00        950                    30
      7902 FORD       ANALYST         7566 03-DEC-1981 00:00:00       3000                    20
      7934 MILLER     CLERK           7782 23-JAN-1982 00:00:00       1300                    10
14 rows selected.
SQL> ed
Wrote file afiedt.buf
1 declare
2    cursor cur_emp is
3      select empno, ename, comm
4      from emp
5      for update;
6 begin
7    for e in cur_emp
8    loop
9      dbms_output.put_line('('||e.empno||') '||e.ename);
10      if e.comm is null then
11        update emp
12        set comm = 0
13        where current of cur_emp;
14        dbms_output.put_line('-- Commission reset to 0');
15      else
16        dbms_output.put_line('-- Commission: '||e.comm);
17      end if;
18    end loop;
19* end;
SQL> /
(7369) SMITH
-- Commission reset to 0
(7499) ALLEN
-- Commission: 300
(7521) WARD
-- Commission: 500
(7566) JONES
-- Commission reset to 0
(7654) MARTIN
-- Commission: 1400
(7698) BLAKE
-- Commission reset to 0
(7782) CLARK
-- Commission reset to 0
(7788) SCOTT
-- Commission reset to 0
(7839) KING
-- Commission reset to 0
(7844) TURNER
-- Commission: 0
(7876) ADAMS
-- Commission reset to 0
(7900) JAMES
-- Commission reset to 0
(7902) FORD
-- Commission reset to 0
(7934) MILLER
-- Commission reset to 0
PL/SQL procedure successfully completed.
SQL> select * from emp;
     EMPNO ENAME      JOB              MGR HIREDATE                    SAL       COMM     DEPTNO
      7369 SMITH      CLERK           7902 17-DEC-1980 00:00:00        800          0         20
      7499 ALLEN      SALESMAN        7698 20-FEB-1981 00:00:00       1600        300         30
      7521 WARD       SALESMAN        7698 22-FEB-1981 00:00:00       1250        500         30
      7566 JONES      MANAGER         7839 02-APR-1981 00:00:00       2975          0         20
      7654 MARTIN     SALESMAN        7698 28-SEP-1981 00:00:00       1250       1400         30
      7698 BLAKE      MANAGER         7839 01-MAY-1981 00:00:00       2850          0         30
      7782 CLARK      MANAGER         7839 09-JUN-1981 00:00:00       2450          0         10
      7788 SCOTT      ANALYST         7566 19-APR-1987 00:00:00       3000          0         20
      7839 KING       PRESIDENT            17-NOV-1981 00:00:00       5000          0         10
      7844 TURNER     SALESMAN        7698 08-SEP-1981 00:00:00       1500          0         30
      7876 ADAMS      CLERK           7788 23-MAY-1987 00:00:00       1100          0         20
      7900 JAMES      CLERK           7698 03-DEC-1981 00:00:00        950          0         30
      7902 FORD       ANALYST         7566 03-DEC-1981 00:00:00       3000          0         20
      7934 MILLER     CLERK           7782 23-JAN-1982 00:00:00       1300          0         10
14 rows selected.Though, of course this is a pointless example as a simple single update would achieve the same. It's more useful if there are 'other things' you need to do with the data that would exceed the capabilities of just using SQL. Personally I've had little need to use this sort of construct.

Cursor with for update clause problem

Hi all,
We are having this problem with Oracle 8.1.7 where in we have a cursor with for update clause. The PL/SQL script used to work fine with Oracle 8.0.5 but is causing problems with Oracle 8.1.7. What the script is ending up doing in 8.1.7 is that it updates only one record instead of updating close to 60000 which it used to do in Oracle 8.0.5
The script just hangs after updating one record. We have replicated the same problem.
Has anyone seen this error before and attained resolution?
Thanks

Hello ,
I have found the same / very close to the same problem. I tried the code below in Oracle 10.2.0.1 and got the following error after the first loop.
ORA-01002: fetch out of sequence
ORA-06512: at "DEMO_TEST_RESEARCH_PKG", line 18
ORA-06512: at line 7
After trying to debug it , i thought i would try it in Oracle 9.0.2.0.7.0 , and to my suprise it worked fine.
Am i missing something ? Thanks in advance , ...
I have included the code i was running ...
PROCEDURE WhereCurrentOf(Param1 IN NUMBER) IS
v_title_eng ISSUES.TITLE_ENG%TYPE;
v_issue_id ISSUES.ISSUE_ID%TYPE;
CURSOR issues_cur
IS
SELECT issue_id,title_eng
FROM issues
WHERE title_eng IS NULL
FOR UPDATE OF title_eng;
BEGIN
FOR i IN issues_cur
LOOP
FETCH issues_cur INTO v_issue_id,v_title_eng;
EXIT WHEN issues_cur%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(v_issue_id||' This was the english title before : '||v_title_eng);
v_title_eng := 'This is my title';
UPDATE issues
SET title_eng = v_title_eng
WHERE CURRENT OF issues_cur;
DBMS_OUTPUT.PUT_LINE(v_issue_id||' This is the english title after : '||v_title_eng);
END LOOP;
END WhereCurrentOf;

Why does it take so long to check for updates?

I have my setting to not auto download because of my limited satellite IP. But when I go to check the App store for updates it just sits there spinning apparently using up my download allowance. I am beginning to think Apples don't belong on Satellites.
MacPro with upgraded Mountain Lion

I have machines on both platforms and am well aware of amount of updates. What I was wondering about is an issue I have when trying to check for updates, the length of time it takes to connect with the update server. I realize though it may be a "satellite" problem not experienced by DSL users.
But I am surprised that Apple doesn't provide an "inhouse" download scheduler given the size of many of their downloads (considerably larger than the average MS download)

I updated to ios 7 and now the battery does not stop charging any ideas, or have to wait for update? thanks

i updated to ios 7 and now the battery does not stop charging any ideas, or have to wait for update? thanks

To show the battery percentage used go to settings
from there click general scroll to usage and select
scroll to bottom of page for battery usage select on.
This will show the icon battery and the percent numbers on the top right.
When phone is connected to an outlet sometimes it does not always show complete charge. I do not understand why but it is what it is.
FYI I sent reply to you not to deggie. You can have your own satisfaction to reply direct.

SELECT FOR UPDATE with the SKIP LOCK clause

Hi,
I have a query regarding the SELECT FOR UPDATE with the SKIP LOCK clause.
Whether this will be really good for parallel processing.
Also if we are selecting a set of records in a cursor whether the lock will be done at the records level once we fetch the records?
Also do we have any known issues with this one?
We are trying to figure out whether this will fit for business requirement, we are trying to do a implement a threading kind of thing for our stored procedure invocation in background using shell script.
Any suggestion or feedback on this will be helpful for us.
Thanks a lot for the support given....
Regards,
Basil Abraham.

http://www.oracle.com/technology/oramag/oracle/08-mar/o28plsql.html
Please read the above thread for few information...Thanks!

FOR UPDATE...SKIP LOCKED - Is it supported to use in 10.2?

Similar Messages

Maybe you are looking for