| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Drawbacks to Serializable Mode?
A copy of this was sent to <terrysutton_at_usa.net>
(if that email address didn't require changing)
On Fri, 26 Feb 1999 11:45:14 -0800, you wrote:
>
>I had not heard this. I've been getting my information about isolation
>levels from the O8 manuals. Is there a document sowewhere stating this is
>the case? (not that I'm doubting you, I just have to support this to a team)
>>- 8 obsoletes this setting in the init.ora, no long supported
>
In 7.x, there was a setting:
serializable = true
that you could put in your init.ora file. In the Oracle8.0 documentation set, this setting is no longer documented (i couldn't find it in the server reference manual anymore). In the 8.1 documentation set (which you haven't seen yet) it is specifically documented that this setting is not documented and not supported (it just sort of 'disappeared' in Oracle8.0). I cut and pasted from the 8.1 doc set in the previous posting.
this "serializable = true" feature was implemented PRIOR to the 7.3.3 feature of:
SQL> alter session set isolation_level=serializable; Session altered.
setting the isolation_level to serializable is *very* different from serializable=true.
>
>This would certainly be bad, but seems to differ from from the Oracle
>manuals say. They say that a read never locks a table so others can't use
>it. The mechanism seems to be if Transaction A begins, then transaction B,
>and A updates a row read by B, then B will get an error if it tries to
>update the row. At least that's my understanding of it.
thats the behaviour using the isolation level of serializable -- you'll get a "cannot serialize access" error. It is *not* true of the 7.x serializable=true init.ora setting. In 7.x with init.ora setting of serializable=true, if - A begins and reads a row from T
that is because both A and B will have a share lock preventing updates to T.
Here are some samples:
time session1 session2
---------- ---------------- -------------
1 select * from emp;
2 update emp set ename=lower(ename)
*BLOCKED*
3 commit
4 update runs
5 select * from emp;
*BLOCKED*
6 commit;
7 select runs
with an alter session set isolation..., this would not be the case -- they would NOT block.
Perhaps you never really meant to say
>We are considering setting a database to Serializable = True to eliminate
but meant to say "we are considering setting the isolation_level for each transaction to serializable"??
In the oracle8 documentation, there is no serializable = true anymore. In 7.x there was.
>>- serializable = true causes a share table lock to be placed whenever you
>READ a
>>table (not so with serializable transactions using set transaction). This
>>means, if you read a table with serializable=true -- no one can
>>insert/update/delete it until you commit. slightly bad for concurrency.
>
>
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Service Industries
Reston, VA USA
--
http://govt.us.oracle.com/ -- downloadable utilities
 |
 |