I have a problem to set a JDBC connection as READ UNCOMMITED.
setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
This is causing lots of blocking on tables
and update or insert doesn't work properly.
Does anyone have any idea what I'm missing here?
I asked i-net support and they suggested to call
setAutoCommit(false) after the above function
and it didn't work.
also suggested impltrans = true, and I changed that option on SQL
and it caused more blocking.
Thanks in advance for any info.neo wrote:
> Hi,
> I have a problem to set a JDBC connection as READ UNCOMMITED.
> setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> This is causing lots of blocking on tables
> and update or insert doesn't work properly.
> Does anyone have any idea what I'm missing here?
> I asked i-net support and they suggested to call
> setAutoCommit(false) after the above function
> and it didn't work.
> also suggested impltrans = true, and I changed that option on SQL
> and it caused more blocking.
> Thanks in advance for any info.
Why are you letting anyone, or any thing, read an uncommited
transaction? If it is not committed ... it doesn't exist.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||Daniel Morgan <damorgan@.x.washington.edu> wrote in message news:<1069122434.507152@.yasure>...
> neo wrote:
> > Hi,
> > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > This is causing lots of blocking on tables
> > and update or insert doesn't work properly.
> > Does anyone have any idea what I'm missing here?
> > I asked i-net support and they suggested to call
> > setAutoCommit(false) after the above function
> > and it didn't work.
> > also suggested impltrans = true, and I changed that option on SQL
> > and it caused more blocking.
> > Thanks in advance for any info.
> Why are you letting anyone, or any thing, read an uncommited
> transaction? If it is not committed ... it doesn't exist.
This function sets dirty-read enable.
So even though there is blocking,
with this connection, data can still be read. That's what I want.|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote in message news:1069122434.507152@.yasure...
> neo wrote:
> > Hi,
> > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > This is causing lots of blocking on tables
> > and update or insert doesn't work properly.
> > Does anyone have any idea what I'm missing here?
> > I asked i-net support and they suggested to call
> > setAutoCommit(false) after the above function
> > and it didn't work.
> > also suggested impltrans = true, and I changed that option on SQL
> > and it caused more blocking.
> > Thanks in advance for any info.
> Why are you letting anyone, or any thing, read an uncommited
> transaction? If it is not committed ... it doesn't exist.
ah.. this is a typical oracleisque response. Well there are
some circumstances when READ_UNCOMMITTED makes perfect sense.
For e.g. if u r running report on past data (like last week's report)
which is guaranteed to be read-only at the time of running
the report. why bother about COMMITTED data? a simple dirty
read will do the job as effectively, but more efficiently.
Oracle's MVRC sounds great, but unless it gives an option
to bypass when it is unnecessary, it is an overkill.
rk-|||rkusenet wrote:
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote in message news:1069122434.507152@.yasure...
>>neo wrote:
>>
>>
>>>Hi,
>>>I have a problem to set a JDBC connection as READ UNCOMMITED.
>>>
>>>setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
>>>
>>>This is causing lots of blocking on tables
>>>and update or insert doesn't work properly.
>>>
>>>Does anyone have any idea what I'm missing here?
>>>
>>>I asked i-net support and they suggested to call
>>>setAutoCommit(false) after the above function
>>>and it didn't work.
>>>also suggested impltrans = true, and I changed that option on SQL
>>>and it caused more blocking.
>>>
>>>Thanks in advance for any info.
>>
>>Why are you letting anyone, or any thing, read an uncommited
>>transaction? If it is not committed ... it doesn't exist.
>
> ah.. this is a typical oracleisque response. Well there are
> some circumstances when READ_UNCOMMITTED makes perfect sense.
> For e.g. if u r running report on past data (like last week's report)
> which is guaranteed to be read-only at the time of running
> the report. why bother about COMMITTED data? a simple dirty
> read will do the job as effectively, but more efficiently.
> Oracle's MVRC sounds great, but unless it gives an option
> to bypass when it is unnecessary, it is an overkill.
> rk-
Makes sense but if you only do READ_UNCOMMITTED on old data why not just
partition it?
My concern is that while some might use this as you describe ... others
could just as easily produce invalid reports. There is no protection in
the system to protect the end-user. How do they know?
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote
> Makes sense but if you only do READ_UNCOMMITTED on old data why not just
> partition it?
why an oracle like approach for everything :-) U asked a question whether
READ_UNCOMMITTED has any value, I gave one and I can give many more
examples like this where a particular ISOLATION mode may be appropriate.
Oracle's assumption that its MVRC is best for all situations is plain
horse manure. They should give the flexibility to the developers to
use appropriate ISOLATION mode. I use it in Informix and SQLSERVER and
I am very happy with these products (atleast on this count) which gives
me the flexibility.
> My concern is that while some might use this as you describe ... others
> could just as easily produce invalid reports. There is no protection in
> the system to protect the end-user. How do they know?
well, I am using ur own words of wisdon. Learn to work in SQLSERVER as
it is suppose to work, not like Oracle :-). I expect SQLSERVER developrs
to have an understanding of ISOLATION level.
rk-|||"rkusenet" <rkusenet@.sympatico.ca> wrote in message
news:bpdm0b$1nhu6v$1@.ID-75254.news.uni-berlin.de...
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote in message
news:1069122434.507152@.yasure...
> > neo wrote:
> > > Hi,
> > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > > > This is causing lots of blocking on tables
> > > and update or insert doesn't work properly.
> > > > Does anyone have any idea what I'm missing here?
> > > > I asked i-net support and they suggested to call
> > > setAutoCommit(false) after the above function
> > > and it didn't work.
> > > also suggested impltrans = true, and I changed that option on SQL
> > > and it caused more blocking.
> > > > Thanks in advance for any info.
> > Why are you letting anyone, or any thing, read an uncommited
> > transaction? If it is not committed ... it doesn't exist.
> ah.. this is a typical oracleisque response. Well there are
> some circumstances when READ_UNCOMMITTED makes perfect sense.
> For e.g. if u r running report on past data (like last week's report)
> which is guaranteed to be read-only at the time of running
> the report. why bother about COMMITTED data? a simple dirty
> read will do the job as effectively, but more efficiently.
Unless you're running low on memory and getting lock escalation from row to
page lock, I don't see why your past data (assuming you don't update past
data) will have a lock on them. If there's no lock, then why would there be
a difference between doing READ_UNCOMMITTED and READ_COMMITTED on those
rows. If there's no difference, then why did you say READ_UNCOMMITTED will
do the job "more efficiently"?
Cheers,
Dave
> Oracle's MVRC sounds great, but unless it gives an option
> to bypass when it is unnecessary, it is an overkill.
> rk-|||One concern I have with uncommitted/dirty read is that documentation says
that "this is the lowest level where transactions are isolated only enough
to ensure that physically corrupt data is not read". This is not enough to
guarantee row-level read consistency, meaning you might not get data of the
same version for all columns, particularly for columns which have BLOB or
CLOB types for which the data is typically stored in another page.
- Dave
"Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam> wrote
in message news:SMvub.33830$sk4.10816@.newssvr27.news.prodigy. com...
> "rkusenet" <rkusenet@.sympatico.ca> wrote in message
> news:bpdm0b$1nhu6v$1@.ID-75254.news.uni-berlin.de...
> > "Daniel Morgan" <damorgan@.x.washington.edu> wrote in message
> news:1069122434.507152@.yasure...
> > > neo wrote:
> > > > > Hi,
> > > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > > > > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > > > > > This is causing lots of blocking on tables
> > > > and update or insert doesn't work properly.
> > > > > > Does anyone have any idea what I'm missing here?
> > > > > > I asked i-net support and they suggested to call
> > > > setAutoCommit(false) after the above function
> > > > and it didn't work.
> > > > also suggested impltrans = true, and I changed that option on SQL
> > > > and it caused more blocking.
> > > > > > Thanks in advance for any info.
> > > > Why are you letting anyone, or any thing, read an uncommited
> > > transaction? If it is not committed ... it doesn't exist.
> > ah.. this is a typical oracleisque response. Well there are
> > some circumstances when READ_UNCOMMITTED makes perfect sense.
> > For e.g. if u r running report on past data (like last week's report)
> > which is guaranteed to be read-only at the time of running
> > the report. why bother about COMMITTED data? a simple dirty
> > read will do the job as effectively, but more efficiently.
> Unless you're running low on memory and getting lock escalation from row
to
> page lock, I don't see why your past data (assuming you don't update past
> data) will have a lock on them. If there's no lock, then why would there
be
> a difference between doing READ_UNCOMMITTED and READ_COMMITTED on those
> rows. If there's no difference, then why did you say READ_UNCOMMITTED
will
> do the job "more efficiently"?
> Cheers,
> Dave
> > Oracle's MVRC sounds great, but unless it gives an option
> > to bypass when it is unnecessary, it is an overkill.
> > rk-|||"neo" <second714@.hotmail.com> wrote in message
news:155f8e7d.0311171747.939d534@.posting.google.co m...
> Hi,
> I have a problem to set a JDBC connection as READ UNCOMMITED.
> setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> This is causing lots of blocking on tables
> and update or insert doesn't work properly.
When compared with READ COMMITTED, did you get more or same or less blocking
using READ UNCOMMITTED? Maybe your updates and inserts by themselves
already generate a lot of blocking, irrespective of your reads. This can
happen say for example if you run low on memory and SQL Server starts
locking pages instead of rows.
Another suggestion I can think of is update your JDBC driver to the latest
version.
HTH,
Dave
> Does anyone have any idea what I'm missing here?
> I asked i-net support and they suggested to call
> setAutoCommit(false) after the above function
> and it didn't work.
> also suggested impltrans = true, and I changed that option on SQL
> and it caused more blocking.
> Thanks in advance for any info.|||"Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam> wrote
in message news:SMvub.33830$sk4.10816@.newssvr27.news.prodigy. com...
> "rkusenet" <rkusenet@.sympatico.ca> wrote in message
> news:bpdm0b$1nhu6v$1@.ID-75254.news.uni-berlin.de...
> > "Daniel Morgan" <damorgan@.x.washington.edu> wrote in message
> news:1069122434.507152@.yasure...
> > > neo wrote:
> > > > > Hi,
> > > > I have a problem to set a JDBC connection as READ UNCOMMITED.
> > > > > > setTransactionIsolation(Connection.TRANSACTION_REA D_UNCOMMITTED)
> > > > > > This is causing lots of blocking on tables
> > > > and update or insert doesn't work properly.
> > > > > > Does anyone have any idea what I'm missing here?
> > > > > > I asked i-net support and they suggested to call
> > > > setAutoCommit(false) after the above function
> > > > and it didn't work.
> > > > also suggested impltrans = true, and I changed that option on SQL
> > > > and it caused more blocking.
> > > > > > Thanks in advance for any info.
> > > > Why are you letting anyone, or any thing, read an uncommited
> > > transaction? If it is not committed ... it doesn't exist.
> > ah.. this is a typical oracleisque response. Well there are
> > some circumstances when READ_UNCOMMITTED makes perfect sense.
> > For e.g. if u r running report on past data (like last week's report)
> > which is guaranteed to be read-only at the time of running
> > the report. why bother about COMMITTED data? a simple dirty
> > read will do the job as effectively, but more efficiently.
> Unless you're running low on memory and getting lock escalation from row
to
> page lock, I don't see why your past data (assuming you don't update past
> data) will have a lock on them. If there's no lock, then why would there
be
> a difference between doing READ_UNCOMMITTED and READ_COMMITTED on those
> rows. If there's no difference, then why did you say READ_UNCOMMITTED
will
> do the job "more efficiently"?
Never mind. I see - because of the overhead of the single read lock when
you use READ_COMMITTED. My bad.
- Dave
> Cheers,
> Dave
> > Oracle's MVRC sounds great, but unless it gives an option
> > to bypass when it is unnecessary, it is an overkill.
> > rk-|||"Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam> wrote
> > ah.. this is a typical oracleisque response. Well there are
> > some circumstances when READ_UNCOMMITTED makes perfect sense.
> > For e.g. if u r running report on past data (like last week's report)
> > which is guaranteed to be read-only at the time of running
> > the report. why bother about COMMITTED data? a simple dirty
> > read will do the job as effectively, but more efficiently.
> Unless you're running low on memory and getting lock escalation from row to
> page lock, I don't see why your past data (assuming you don't update past
> data) will have a lock on them. If there's no lock, then why would there be
> a difference between doing READ_UNCOMMITTED and READ_COMMITTED on those
> rows. If there's no difference, then why did you say READ_UNCOMMITTED will
> do the job "more efficiently"?
actually I should have been clearer.
the more efficiently part was in comparison to oracle's MVRC approach,
not a one to one comparison between SQLSERVER RC and RUC approach.
Even within SQLSERVER RC and RUC, RUC is slightly more efficient since
it does not have to put a read lock on a row.
RUC vs MVRC is all together different. In MVRC it has to check for
every page whether the SCN is less than the SCN when the query started,
a totally unnecessary step for the case in question.|||rkusenet wrote:
<snipped>
> RUC vs MVRC is all together different. In MVRC it has to check for
> every page whether the SCN is less than the SCN when the query started,
> a totally unnecessary step for the case in question.
True. But on the other hand it doesn't have to check to see if the
row is locked. Because in the Oracle world it would be irrelevant.
Writes don't block reads and reads don't brock writes.
All RDBMS's have over-head issues. They are always there ... they are
just different.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote in message news:1069192733.974181@.yasure...
> rkusenet wrote:
> <snipped>
> > RUC vs MVRC is all together different. In MVRC it has to check for
> > every page whether the SCN is less than the SCN when the query started,
> > a totally unnecessary step for the case in question.
> True. But on the other hand it doesn't have to check to see if the
> row is locked.
That is in RC and SER only.
RUC does not check whether the row is locked and for the case in
question, RUC is best.
> Because in the Oracle world it would be irrelevant.
> Writes don't block reads and reads don't brock writes.
oracle does not give any flexiblity in writing the application as
required. It forces MVRC always. In Informix I use RC, RUC and
SER as they are required on a case to case basis. Now I follow
the same priciple in SQLServer also.
I am not denying that MVRC is good. All I am disputing is that
it is DA best for every situation, as Oracle arrogantly assumes.
Clearly it isn't.
I believe SQLServer is implementing MVRC in Yukon. That's great,
since they will still be offering RC,RUC and SER. Oracle should also
do that.
rk-|||rkusenet wrote:
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote in message news:1069192733.974181@.yasure...
>>rkusenet wrote:
>>
>><snipped>
>>
>>>RUC vs MVRC is all together different. In MVRC it has to check for
>>>every page whether the SCN is less than the SCN when the query started,
>>>a totally unnecessary step for the case in question.
>>>
>>
>>True. But on the other hand it doesn't have to check to see if the
>>row is locked.
>
> That is in RC and SER only.
> RUC does not check whether the row is locked and for the case in
> question, RUC is best.
>
>>Because in the Oracle world it would be irrelevant.
>>Writes don't block reads and reads don't brock writes.
>
> oracle does not give any flexiblity in writing the application as
> required. It forces MVRC always. In Informix I use RC, RUC and
> SER as they are required on a case to case basis. Now I follow
> the same priciple in SQLServer also.
> I am not denying that MVRC is good. All I am disputing is that
> it is DA best for every situation, as Oracle arrogantly assumes.
> Clearly it isn't.
> I believe SQLServer is implementing MVRC in Yukon. That's great,
> since they will still be offering RC,RUC and SER. Oracle should also
> do that.
> rk-
Arrogantly is no more a constructive phrase when referring to MVCC than
would be the same statement with respect to SQL Server's inability to
run on a UNIX platform. Lets leave the hyperbole to the marketing
departments where it belongs.
Then visit this link:
http://download-west.oracle.com/doc...06a.htm#2067250
and notice the graphic a few inches from the bottom of the first page.
The one that contains SET TRANSACTION. See anything that might make you
reconsider the depth of your knowledge of Oracle?
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote
> Then visit this link:
> http://download-west.oracle.com/doc...06a.htm#2067250
> and notice the graphic a few inches from the bottom of the first page.
> The one that contains SET TRANSACTION. See anything that might make you
> reconsider the depth of your knowledge of Oracle?
I never claimed that I am an expert in Oracle. Indeed I would have worked
less than six months of my career in Oracle. My information about MVRC
is based on what oracle marketing literature.
However it gives me a good idea on the depth of ur knowledge
as a database teacher in Washingto Univ if u make a stupid
and false claim that reading uncommitted data is useless under
all circumstances. I proved it isn't.
Now that we both have insulted each other, can u come to the
point. Does oracle allow applications to bypass MVRC. I could
have gone to the above link, but it requires a registered login.
thanks.
rk-|||"rkusenet" <rkusenet@.sympatico.ca> wrote in message
news:bpeddq$1m702g$1@.ID-75254.news.uni-berlin.de...
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote
> > Then visit this link:
http://download-west.oracle.com/doc...06a.htm#2067250
> > and notice the graphic a few inches from the bottom of the first page.
> > The one that contains SET TRANSACTION. See anything that might make you
> > reconsider the depth of your knowledge of Oracle?
> I never claimed that I am an expert in Oracle. Indeed I would have worked
> less than six months of my career in Oracle. My information about MVRC
> is based on what oracle marketing literature.
> However it gives me a good idea on the depth of ur knowledge
> as a database teacher in Washingto Univ if u make a stupid
> and false claim that reading uncommitted data is useless under
> all circumstances. I proved it isn't.
> Now that we both have insulted each other, can u come to the
> point. Does oracle allow applications to bypass MVRC. I could
> have gone to the above link, but it requires a registered login.
I think what rk is talking about is whether Oracle ever allows you to read a
block without checking its SCN.
SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
consistency. The bottom line is these all require checking the SCN of every
block that you read, comparing its SCN to the SCN of either the beginning of
statement execution, or the beginning of the transaction, and rolling back
the data if necessary. AFAIK, there's no mechanism in Oracle to read a
block without checking its SCN, although SCN checking is basically only an
integer comparison, and even though you're doing it for every block read, I
don't think it represents any significant overhead compared to the time it
takes to actually read the block.
- Dave
> thanks.
>
> rk-|||"Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam> wrote
> I think what rk is talking about is whether Oracle ever allows you to read a
> block without checking its SCN.
correct. just like Read Uncommitted allows reading a row without checking
for anything.
> SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
> use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
> and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
> consistency. The bottom line is these all require checking the SCN of every
> block that you read, comparing its SCN to the SCN of either the beginning of
> statement execution, or the beginning of the transaction, and rolling back
> the data if necessary. AFAIK, there's no mechanism in Oracle to read a
> block without checking its SCN, although SCN checking is basically only an
> integer comparison, and even though you're doing it for every block read
So I was right.
> I don't think it represents any significant overhead compared to the time it
> takes to actually read the block.
In real world applications, YMMV.
rk-|||Comments in-line
rkusenet wrote:
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote
>>Then visit this link:
>>http://download-west.oracle.com/doc...06a.htm#2067250
>>
>>and notice the graphic a few inches from the bottom of the first page.
>>The one that contains SET TRANSACTION. See anything that might make you
>>reconsider the depth of your knowledge of Oracle?
>
> I never claimed that I am an expert in Oracle. Indeed I would have worked
> less than six months of my career in Oracle. My information about MVRC
> is based on what oracle marketing literature.
Good lord man. I hope you don't buy or use any product, not even a
dish washer basedon marketing literature.
> However it gives me a good idea on the depth of ur knowledge
> as a database teacher in Washingto Univ if u make a stupid
> and false claim that reading uncommitted data is useless under
> all circumstances. I proved it isn't.
Don't mean to be insulting here but perhaps you should re-read my posts,
I never said reading uncommitted data was useless. Dangerous perhaps but
not useless: Never used the word.
> Now that we both have insulted each other, can u come to the
> point. Does oracle allow applications to bypass MVRC. I could
> have gone to the above link, but it requires a registered login.
If by bypass you mean transactions that don't use it? Yes! But if you
think that means dirty reads ... no.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||Comments inline.
rkusenet wrote:
> "Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam> wrote
>
>>I think what rk is talking about is whether Oracle ever allows you to read a
>>block without checking its SCN.
> correct. just like Read Uncommitted allows reading a row without checking
> for anything.
This is an impossible question to answer. Because you can not ever read
a block (in SQL Server verbiage page) without reading the SCN as it is
stored in the block. You can't read something and not read part of it.
Even if you wanted to the operating system would ignore you. Sort of
like asking MS Word to open a document but not read the document's font
information.
But if you mean not use multiversion concurrency with the SCN to
determine whether the row has been changed yes you can.
>>SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>>use transaction-level read consistency, whereas SET TRANSACTION READ WRITE
>>and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level read
>>consistency. The bottom line is these all require checking the SCN of every
>>block that you read, comparing its SCN to the SCN of either the beginning of
>>statement execution, or the beginning of the transaction, and rolling back
>>the data if necessary. AFAIK, there's no mechanism in Oracle to read a
>>block without checking its SCN, although SCN checking is basically only an
>>integer comparison, and even though you're doing it for every block read
>
> So I was right.
No you weren't. I'd suggest you stop spending so much energy trying to
be correct and use this as an opportunity to learn something. You may
well end up on a project some day that requires knowledge of more than a
single RDBMS. I, for example, am currently working in Oracle, Informix,
SQL Server, MS Access, and FoxPro between a variety of projects.
>>I don't think it represents any significant overhead compared to the time it
>>takes to actually read the block.
It takes zero extra time because it is part of the block. If a block is
8K then part of that 8K is the SCN information.
> In real world applications, YMMV.
> rk-
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote in message
news:1069217819.771457@.yasure...
> Comments inline.
> rkusenet wrote:
> > "Dave Hau" <nospam_dave_nospam_123@.nospam_netscape_nospam.net_ nospam>
wrote
> >>I think what rk is talking about is whether Oracle ever allows you to
read a
> >>block without checking its SCN.
> > correct. just like Read Uncommitted allows reading a row without
checking
> > for anything.
> This is an impossible question to answer. Because you can not ever read
> a block (in SQL Server verbiage page) without reading the SCN as it is
> stored in the block. You can't read something and not read part of it.
> Even if you wanted to the operating system would ignore you. Sort of
> like asking MS Word to open a document but not read the document's font
> information.
> But if you mean not use multiversion concurrency with the SCN to
> determine whether the row has been changed yes you can.
> >>SET TRANSACTION READ ONLY and SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE
> >>use transaction-level read consistency, whereas SET TRANSACTION READ
WRITE
> >>and SET TRANSACTION ISOLATION LEVEL READ COMMITTED use statement-level
read
> >>consistency. The bottom line is these all require checking the SCN of
every
> >>block that you read, comparing its SCN to the SCN of either the
beginning of
> >>statement execution, or the beginning of the transaction, and rolling
back
> >>the data if necessary. AFAIK, there's no mechanism in Oracle to read a
> >>block without checking its SCN, although SCN checking is basically only
an
> >>integer comparison, and even though you're doing it for every block read
> > So I was right.
> No you weren't. I'd suggest you stop spending so much energy trying to
> be correct and use this as an opportunity to learn something. You may
> well end up on a project some day that requires knowledge of more than a
> single RDBMS. I, for example, am currently working in Oracle, Informix,
> SQL Server, MS Access, and FoxPro between a variety of projects.
> >>I don't think it represents any significant overhead compared to the
time it
> >>takes to actually read the block.
> It takes zero extra time because it is part of the block. If a block is
> 8K then part of that 8K is the SCN information.
Daniel, I think what rk is talking about is whether Oracle ever allows you
to read a block without *checking* its SCN, not just reading the SCN. Of
course, you're right - when you read a block, you read the SCN as well. But
he's talking about the extra step of checking the SCN against the SCN at the
beginning of the statement execution (for statement level read consistency)
or the SCN at the beginning of the transaction (for transaction level read
consistency) to determine if you need to roll back the block.
Regards,
Dave
> > In real world applications, YMMV.
> > rk-
> --
> Daniel Morgan
> http://www.outreach.washington.edu/...oad/oad_crs.asp
> http://www.outreach.washington.edu/...aoa/aoa_crs.asp
> damorgan@.x.washington.edu
> (replace 'x' with a 'u' to reply)|||Dave Hau wrote:
> Daniel, I think what rk is talking about is whether Oracle ever allows you
> to read a block without *checking* its SCN, not just reading the SCN. Of
> course, you're right - when you read a block, you read the SCN as well. But
> he's talking about the extra step of checking the SCN against the SCN at the
> beginning of the statement execution (for statement level read consistency)
> or the SCN at the beginning of the transaction (for transaction level read
> consistency) to determine if you need to roll back the block.
> Regards,
> Dave
The SCN is only checked in transactions where the data could have been
modified between the initiation of the transaction and when the cursor
gets to the rows. One example of the SCN being ignored is in read-only
tablespaces. Another would be when rows are intentionally locked with
SELECT FOR UPDATE.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote
> The SCN is only checked in transactions where the data could have been
> modified between the initiation of the transaction and when the cursor
> gets to the rows. One example of the SCN being ignored is in read-only
> tablespaces.
Do datas get moved to read-only tablespaces magically. If I have a workflow
table where rows only get inserted/updated for a short period of time,
and then remain static, it makes sense to use READ UNCOMMITTED when running
reports for anything other than the current activities.
I don't know how easy it is in oracle to move yesterday's data in a read-only
tablespace.
>This is an impossible question to answer. Because you can not ever read
>a block (in SQL Server verbiage page) without reading the SCN as it is
>stored in the block.
What about comparing the SCN in data block with the SCN when the query
was initiated. As I see, unless it is a read only tablespace or SELECT
FOR UPDATE, it always does this SCN comparison. It is this SCN comparison
which I think is totally unnecessary when dealing with static data
as in the above example I gave.
rk-|||rkusenet wrote:
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote
>>The SCN is only checked in transactions where the data could have been
>>modified between the initiation of the transaction and when the cursor
>>gets to the rows. One example of the SCN being ignored is in read-only
>>tablespaces.
>
> Do datas get moved to read-only tablespaces magically.
Can you ask a question without being belitteling, demeaning and/or
insulting? I'm serious: Because the answer to this questions is
blazingly obvious.
My contributions are an attempt to educate not some testosterone laden
internet contest. I invite you to reask your question with more
appropriate verbiage if you actually want an answer.
If not ... you win, I lose, you're the man.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)|||"Daniel Morgan" <damorgan@.x.washington.edu> wrote
> Can you ask a question without being belitteling, demeaning and/or
> insulting? I'm serious: Because the answer to this questions is
> blazingly obvious.
> My contributions are an attempt to educate not some testosterone laden
> internet contest. I invite you to reask your question with more
> appropriate verbiage if you actually want an answer.
I admit that the tone of my post was derisive and it was intentional.
Bcos I find you highly opinionated and the way u insult non oracle
products is offending. Be prepared to get offended if u offend others.
You find faults with all products and jump in to defend Oracle the moment
it is attacked, making ur bias too obvious. For e.g. you mentioned recently
that SQL Server is so bad that even a non tuned Oracle/Informix/DB2 can give
performance upto 9x times. Bah. I agree that SQLServer is not yet in the
class of Informix, but to say that it is way behind them is plain stupid.
Do u think some of the heavily used sites like BarnesAndNoble, Dell,Expedia
are stupid to use SQLServer. or Verizon Communications, Lucent etc.
check this: http://www.wintercorp.com/vldb/2003...pTenWinners.asp
You can disregard my question re: oracle read-only tablespace. At this time I
have no desire to learn about Oracle.
I sincerely offer my apology if I offended you and I hope that you will
also change your attitude towards non oracle products.
cheers.
rk-
|||rkusenet wrote:
> "Daniel Morgan" <damorgan@.x.washington.edu> wrote
>
>>Can you ask a question without being belitteling, demeaning and/or
>>insulting? I'm serious: Because the answer to this questions is
>>blazingly obvious.
>>My contributions are an attempt to educate not some testosterone laden
>>internet contest. I invite you to reask your question with more
>>appropriate verbiage if you actually want an answer.
>
> I admit that the tone of my post was derisive and it was intentional.
> Bcos I find you highly opinionated and the way u insult non oracle
> products is offending. Be prepared to get offended if u offend others.
> You find faults with all products and jump in to defend Oracle the moment
> it is attacked, making ur bias too obvious. For e.g. you mentioned recently
> that SQL Server is so bad that even a non tuned Oracle/Informix/DB2 can give
> performance upto 9x times. Bah. I agree that SQLServer is not yet in the
> class of Informix, but to say that it is way behind them is plain stupid.
> Do u think some of the heavily used sites like BarnesAndNoble, Dell,Expedia
> are stupid to use SQLServer. or Verizon Communications, Lucent etc.
> check this: http://www.wintercorp.com/vldb/2003...pTenWinners.asp
> You can disregard my question re: oracle read-only tablespace. At this time I
> have no desire to learn about Oracle.
> I sincerely offer my apology if I offended you and I hope that you will
> also change your attitude towards non oracle products.
> cheers.
> rk-
I'm not in marketing and make no more money from Oracle than I do
from other RDBMS products. That I teach one at the U says more about
what the students want than anything else. And I have repeatedly pointed
out that different RDBMS products are different. I don't rush to defend
or attack any of them because I have no vested interest in any one of them.
If you insist on putting a value judgement on differences ... good
vs evil, white hat vs black hat, cowboys vs indians, that is your value
judgement ... not mine. And I'm not at all offended. I just don't choose
to play games that consist primarily of seeing who can have the most
testosterone shooting from their eyeballs.
As an educator I am surprised you have no interest in learning Oracle. I
make it a point to keep up my skills in SQL Server, DB2, and Informix.
Used to also keep current in Sybase and Teradata. Much of my consulting
work comes from helping people that don't know multiple products perform
migrations or make a product work in heterogenous environments. Guess I
should thank you for keeping my vacation plans on-track.
--
Daniel Morgan
http://www.outreach.washington.edu/...oad/oad_crs.asp
http://www.outreach.washington.edu/...aoa/aoa_crs.asp
damorgan@.x.washington.edu
(replace 'x' with a 'u' to reply)sql
No comments:
Post a Comment