"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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/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/docs...6a.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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/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/docs...6a.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/docs...6a.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/docs...6a.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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/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/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/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/e...ad/oad_crs.asp
> http://www.outreach.washington.edu/e...oa/aoa_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>