Maximum number of transaction. (Newby question).

"VC" wrote in message
news:31e0625e.0310300645.4c908003@posting.google.com...
> Hello Ben,
>
> The behaviour you're observing is explained by Oracle 9i's creating
> _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> It can be easily verified by dumping the data block.
>
> If you perform an update #3 on row #3 in addition to the two you've
> already initiated, you'll get the desired effect.
>
> Rgds.
>

Thanks I immediatly tried it and this explains the behavior of
the Oracle database. Not the dumping but using a third session.

I think that the Oracle documentation fails here, because most
docs (that I have read) do not explain this correctly. Learning from
books which explain something false and then trying these things
is not easy.

This effect probably explains a deadlock I have experienced in the
past. (When I asked about this on an Oracle course they couldn't
give any explanation about deadlocks concerning totaly 'disconnected'
sessions not sharing any data. This does explain that. Although I still
do not know if this really was the cause).

Thanks for taken the time to answer,

ben brugman




>
> "ben brugman" wrote in message
news:<3fa0f04d$0$245$4d4ebb8e@read.news.nl.uu.net>...
> > At the moment I am playing around with an Oracle database.
> >
> > I have set The number of transactions for a test table
> > initial to 1 and maximum to 1.
> > I enter 3 small rows into a table.
> > (All rows end up in the same block, when selecting with rowid
> > all is the same except that the last digit becomes A or B or C).
> >
> > Now I open a session and do an update on the first row.
> > I open a second session and do an update on the second row.
> >
> > Both updates succeede and I can commit both.
> > Because of the only one transaction in a block I would expect that
> > one transaction would be blocked by the first.
> >
> > What am I missing or understanding wrongly.
> >
> > ben brugman

"VC" wrote in message
news:31e0625e.0310300645.4c908003@posting.google.com...
> Hello Ben,
>
> The behaviour you're observing is explained by Oracle 9i's creating
> _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> It can be easily verified by dumping the data block.
>
> If you perform an update #3 on row #3 in addition to the two you've
> already initiated, you'll get the desired effect.
>
> Rgds.
>

Thanks I immediatly tried it and this explains the behavior of
the Oracle database. Not the dumping but using a third session.

I think that the Oracle documentation fails here, because most
docs (that I have read) do not explain this correctly. Learning from
books which explain something false and then trying these things
is not easy.

This effect probably explains a deadlock I have experienced in the
past. (When I asked about this on an Oracle course they couldn't
give any explanation about deadlocks concerning totaly 'disconnected'
sessions not sharing any data. This does explain that. Although I still
do not know if this really was the cause).

Thanks for taken the time to answer,

ben brugman




>
> "ben brugman" wrote in message
news:<3fa0f04d$0$245$4d4ebb8e@read.news.nl.uu.net>...
> > At the moment I am playing around with an Oracle database.
> >
> > I have set The number of transactions for a test table
> > initial to 1 and maximum to 1.
> > I enter 3 small rows into a table.
> > (All rows end up in the same block, when selecting with rowid
> > all is the same except that the last digit becomes A or B or C).
> >
> > Now I open a session and do an update on the first row.
> > I open a second session and do an update on the second row.
> >
> > Both updates succeede and I can commit both.
> > Because of the only one transaction in a block I would expect that
> > one transaction would be blocked by the first.
> >
> > What am I missing or understanding wrongly.
> >
> > ben brugman

>
> >
> You are assuming that your interpretation of MINTRANS and MAXTRANS is as
> you
> think it is. I'd suggest going to http://tahiti.oracle.com and
> researching the subject more.

Thanks for pointing this out to me,
from the other mails I learned indeed that a 1 should be interpreted as a 2,
my interpretation was indeed wrong.
Although I tried to go to the place you pointed, before I even got close
to an answer I needed an account, so I did not persue that route.
I do not know if I would be able to find such an anwser from the web
pages you pointed me to.

thanks,
ben brugman


>
> --
> 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)
>

>
> >
> You are assuming that your interpretation of MINTRANS and MAXTRANS is as
> you
> think it is. I'd suggest going to http://tahiti.oracle.com and
> researching the subject more.

Thanks for pointing this out to me,
from the other mails I learned indeed that a 1 should be interpreted as a 2,
my interpretation was indeed wrong.
Although I tried to go to the place you pointed, before I even got close
to an answer I needed an account, so I did not persue that route.
I do not know if I would be able to find such an anwser from the web
pages you pointed me to.

thanks,
ben brugman


>
> --
> 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)
>

Hello Niall,

1. The original poster 'desired' to see the situation wherein the
locking phenomenon caused by paucity of ITL slots occurs, hence the
'desired' effect. The poster wanted eagerly(syn. desired) to educate
himself through experimenting with Oracle. Of course, in a production
environment, one usually does not 'desire' the above effect.

2. If it was an attempt to be funny, I apologize for my not getting
the joke.

Rgds.

"Niall Litchfield" wrote in message news:<3fa131a6$0$9473$ed9e5944@reading.news.pipex.net>...
> "VC" wrote in message
> news:31e0625e.0310300645.4c908003@posting.google.com...
> > Hello Ben,
> >
> > The behaviour you're observing is explained by Oracle 9i's creating
> > _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> > It can be easily verified by dumping the data block.
> >
> > If you perform an update #3 on row #3 in addition to the two you've
> > already initiated, you'll get the desired effect.
>
> This must be some new definition of the word 'desired' with which I am
> unfamiliar.

Hello Niall,

1. The original poster 'desired' to see the situation wherein the
locking phenomenon caused by paucity of ITL slots occurs, hence the
'desired' effect. The poster wanted eagerly(syn. desired) to educate
himself through experimenting with Oracle. Of course, in a production
environment, one usually does not 'desire' the above effect.

2. If it was an attempt to be funny, I apologize for my not getting
the joke.

Rgds.

"Niall Litchfield" wrote in message news:<3fa131a6$0$9473$ed9e5944@reading.news.pipex.net>...
> "VC" wrote in message
> news:31e0625e.0310300645.4c908003@posting.google.com...
> > Hello Ben,
> >
> > The behaviour you're observing is explained by Oracle 9i's creating
> > _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> > It can be easily verified by dumping the data block.
> >
> > If you perform an update #3 on row #3 in addition to the two you've
> > already initiated, you'll get the desired effect.
>
> This must be some new definition of the word 'desired' with which I am
> unfamiliar.

>
> 1. The original poster 'desired' to see the situation wherein the
> locking phenomenon caused by paucity of ITL slots occurs, hence the
> 'desired' effect. The poster wanted eagerly(syn. desired) to educate
> himself through experimenting with Oracle. Of course, in a production
> environment, one usually does not 'desire' the above effect.

Added to that if it would happen in a production environment, one would
like to reproduce the effect. Sometimes even on the same production
environment, because in a testsetting you often can not reproduce the
same setting.
Even when using the same data, it is difficult to get the data organised
in exactly the same way in the blocks.

>
> 2. If it was an attempt to be funny, I apologize for my not getting
> the joke.

I am trying if I can see the humor in the 'request', and although I am
known to make jokes about even the most morbide situations I do
not succeede to get any humor out of it.
It was a genuane serious request.
(I have allready spend several hours on researching this effect, your
answer has given me were I have been looking for.).

thanks,
ben brugman


>
> Rgds.
>
> "Niall Litchfield" wrote in message
news:<3fa131a6$0$9473$ed9e5944@reading.news.pipex.net>...
> > "VC" wrote in message
> > news:31e0625e.0310300645.4c908003@posting.google.com...
> > > Hello Ben,
> > >
> > > The behaviour you're observing is explained by Oracle 9i's creating
> > > _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> > > It can be easily verified by dumping the data block.
> > >
> > > If you perform an update #3 on row #3 in addition to the two you've
> > > already initiated, you'll get the desired effect.
> >
> > This must be some new definition of the word 'desired' with which I am
> > unfamiliar.

>
> 1. The original poster 'desired' to see the situation wherein the
> locking phenomenon caused by paucity of ITL slots occurs, hence the
> 'desired' effect. The poster wanted eagerly(syn. desired) to educate
> himself through experimenting with Oracle. Of course, in a production
> environment, one usually does not 'desire' the above effect.

Added to that if it would happen in a production environment, one would
like to reproduce the effect. Sometimes even on the same production
environment, because in a testsetting you often can not reproduce the
same setting.
Even when using the same data, it is difficult to get the data organised
in exactly the same way in the blocks.

>
> 2. If it was an attempt to be funny, I apologize for my not getting
> the joke.

I am trying if I can see the humor in the 'request', and although I am
known to make jokes about even the most morbide situations I do
not succeede to get any humor out of it.
It was a genuane serious request.
(I have allready spend several hours on researching this effect, your
answer has given me were I have been looking for.).

thanks,
ben brugman


>
> Rgds.
>
> "Niall Litchfield" wrote in message
news:<3fa131a6$0$9473$ed9e5944@reading.news.pipex.net>...
> > "VC" wrote in message
> > news:31e0625e.0310300645.4c908003@posting.google.com...
> > > Hello Ben,
> > >
> > > The behaviour you're observing is explained by Oracle 9i's creating
> > > _two_ ITL slots instead of one despite your specifying 'initrans 1'.
> > > It can be easily verified by dumping the data block.
> > >
> > > If you perform an update #3 on row #3 in addition to the two you've
> > > already initiated, you'll get the desired effect.
> >
> > This must be some new definition of the word 'desired' with which I am
> > unfamiliar.

ben brugman wrote:

>>You are assuming that your interpretation of MINTRANS and MAXTRANS is as
>>you
>>think it is. I'd suggest going to http://tahiti.oracle.com and
>>researching the subject more.
>>
>>
>
>Thanks for pointing this out to me,
>from the other mails I learned indeed that a 1 should be interpreted as a 2,
>my interpretation was indeed wrong.
>Although I tried to go to the place you pointed, before I even got close
>to an answer I needed an account, so I did not persue that route.
>I do not know if I would be able to find such an anwser from the web
>pages you pointed me to.
>
>thanks,
>ben brugman
>
>
>
>
>>--
>>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)
>>
>>
>>
Create the account. It will be a most valuable use of two minutes of
your time. All you need
to do is provide a userid and password (of your choosing). There is no
cost. There is no
license requirement. And you will receive no spam or advertising.

--
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)