SEO

Hello,

I'm encountering problem that I have never seen before. According to
Statspack report, control file sequential read wait is one of the top
one waits (on Monday first, Tuesday second, today third) and roughly
has the same total wait time as db file sequential read. Average wait
is 4ms, but there is many of them.
There are three control files, created as raw devices on three
different disks. The control files are not stripped, but as a storage
we're using EMC's DMX, so this should be sufficient for something not
really read demanding as are (usually) control files. Our statistics
from nmon64 showed that disk drives, where these control files are
stored, are not overloaded (at most 40%).
There is almost nothing on Metalink related to this (only place on
other device).

Have anyone encountered something like this?

Environment: IBM p670, AIX 5.2 64bit, 12GB RAM, EMC DMX2000, RAID1 or
RAID10 (no fives), everything connected by fibre.
Database:
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning and Real Application Clusters options
JServer Release 9.2.0.5.0 - Production

P.S. There is Data Guard as a DR solution and the second RAC node is
now down (only one is running).

Thank you for any ideas

--
Dusan Bolek
http://www.db-support.com

Email: spambin@seznam.cz
Pls add "Not Guilty" to the subject, otherwise your email will face an
unpleasant end as SPAM.

"Dusan Bolek" <pagesflames@usa.net> wrote in message news:1e8276d6.0407210149.4e329eeb@posting.google.c om...
> Hello,
>
> I'm encountering problem that I have never seen before. According to
> Statspack report, control file sequential read wait is one of the top
> one waits (on Monday first, Tuesday second, today third) and roughly
> has the same total wait time as db file sequential read. Average wait
> is 4ms, but there is many of them.
> There are three control files, created as raw devices on three
> different disks. The control files are not stripped, but as a storage
> we're using EMC's DMX, so this should be sufficient for something not
> really read demanding as are (usually) control files. Our statistics
> from nmon64 showed that disk drives, where these control files are
> stored, are not overloaded (at most 40%).
> There is almost nothing on Metalink related to this (only place on
> other device).
>
> Have anyone encountered something like this?
>
> Environment: IBM p670, AIX 5.2 64bit, 12GB RAM, EMC DMX2000, RAID1 or
> RAID10 (no fives), everything connected by fibre.
> Database:
> Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
> With the Partitioning and Real Application Clusters options
> JServer Release 9.2.0.5.0 - Production
>
> P.S. There is Data Guard as a DR solution and the second RAC node is
> now down (only one is running).
>
> Thank you for any ideas
>
> --
> Dusan Bolek
> http://www.db-support.com
>
> Email: spambin@seznam.cz
> Pls add "Not Guilty" to the subject, otherwise your email will face an
> unpleasant end as SPAM.

Just a wild guess: http://www.ixora.com.au/tips/event_10359.htm

Anurag

If you ask David Fitz***, he would tell you that this is normal. Then when
your waits hit 90 seconds and your instnace crash; and you get the boots;

If the stock market crashes again due to some funds investing in you
company; then pls record my warning and tell David to beam herself to
hell!

If you want to check similar situation; go to metalink and search on the
words of your title.

"omlet" <notrolls@notrolls.omlet.org.notrolls> wrote in message news:<debe02c8476f944b24307befeeff57fc@localhost.t alkaboutdatabases.com>...
> If you ask David Fitz***, he would tell you that this is normal. Then when
> your waits hit 90 seconds and your instnace crash; and you get the boots;
>

From the information presented I cannot tell if it's 'normal' or not,
however I would suspect it isn't, unless there are nologging LOB
transactions occurring. This is well covered in the link Anurag
posted, so why repeat information?

> If the stock market crashes again due to some funds investing in you
> company; then pls record my warning and tell David to beam herself to
> hell!
>

Prove any of that 'stock market crash' nonsense if you can, and, since
you cannot I shall be investigating the possibility of a libel suit
against you. You should be easy to find and sue.

> If you want to check similar situation; go to metalink and search on the
> words of your title.

Just like you do, and purport that the responses are yours. Sop lying
to people about what you know and for whom you've worked. It only
goes as evidence against you.

David Fitzjarrell

On Wed, 21 Jul 2004 22:47:46 +0000, Anurag Varma wrote:


>>
>> Email: spambin@seznam.cz
>> Pls add "Not Guilty" to the subject, otherwise your email will face an
>> unpleasant end as SPAM.
>
> Just a wild guess: http://www.ixora.com.au/tips/event_10359.htm
>
> Anurag


The behavior that Steve Adams is talking about is a result of an ancient
bug (BUG# 733426). The link to the 9.0.1 manual is non-functional. I
would contact Oracle support, rather then just setting the event 10359.

--
A city is a large community where people are lonesome together.

"Anurag Varma" <avdbi@hotmail.com> wrote in message news:<moCLc.77219$bp1.39462@twister.nyroc.rr.com>. ..
> "Dusan Bolek" <pagesflames@usa.net> wrote in message news:1e8276d6.0407210149.4e329eeb@posting.google.c om...
> > Hello,
> >
> > I'm encountering problem that I have never seen before. According to
> > Statspack report, control file sequential read wait is one of the top
> > one waits (on Monday first, Tuesday second, today third) and roughly
> > has the same total wait time as db file sequential read. Average wait
> > is 4ms, but there is many of them.
> Just a wild guess: http://www.ixora.com.au/tips/event_10359.htm
>
> Anurag

Thanks, Anurag. This is an interesting point, but I do not think that
this is the case. I have checked in the database and there are no
NOLOGGING LOBs with expection of two system ones and one in an empty
table. However, it is good to know for the future.

Dusan

"omlet" <notrolls@notrolls.omlet.org.notrolls> wrote in message news:<debe02c8476f944b24307befeeff57fc@localhost.t alkaboutdatabases.com>...
> If you ask David Fitz***, he would tell you that this is normal. Then when
> your waits hit 90 seconds and your instnace crash; and you get the boots;
>
> If the stock market crashes again due to some funds investing in you
> company; then pls record my warning and tell David to beam herself to
> hell!
>
> If you want to check similar situation; go to metalink and search on the
> words of your title.

The last sentence of your post was the only one with some relevant
information. However, I'm always checking Metalink before looking here
for help and I if you would really read my post, you can se at the
end:

"There is almost nothing on Metalink related to this (only place on
other device)."

But you have been probably to busy fighting David Fitzjarrell. To be
honest I must admit I do not understand what's your problem with David
and in fact I do not really care.

--
Dusan

pagesflames@usa.net (Dusan Bolek) wrote:
> Hello,
>
> I'm encountering problem that I have never seen before. According to
> Statspack report, control file sequential read wait is one of the top
> one waits (on Monday first, Tuesday second, today third)

Something has to be the top wait.

> and roughly
> has the same total wait time as db file sequential read.

And what is that total?

> Average wait
> is 4ms, but there is many of them.

How many of them are there?


> There are three control files, created as raw devices on three
> different disks. The control files are not stripped, but as a storage
> we're using EMC's DMX, so this should be sufficient for something not
> really read demanding as are (usually) control files. Our statistics
> from nmon64 showed that disk drives, where these control files are
> stored, are not overloaded (at most 40%).
> There is almost nothing on Metalink related to this (only place on
> other device).
>
> Have anyone encountered something like this?

Yes. During periods when my database is bored out its gourd,
control file I/O waits are often the top waits. What kind of load
was your system under during the collection?

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

Ok; control files are not the first; you have attacked OMLET use of shared
cursors set to FORCE. My answer was and still eat sh** and shut up;
because there may be may be someone who knows slightly more than you.

Well let me make another bet: Do you know what you have in common with
opiosq, opicca, opiexe, opifch or kernel calls kkspsc, kksumc, kkspfx,
kkspin?

the first four are the dicks that banged you shared azz; the last four are
the ones that banged your mother cusorit.

Actually sharing such a shared objects
- requires shared lock;
- creation of a kgl object;
- pinning the name's object heap zero in shared mode
-- might require checking if there is some context area that could be
used by this dick, by pinning the child objects, one by one, and seeing if
are also fuckable or usable.
-- release the pin locks
- pin the parent heap zero in exclusive mode, create new child marked as
not bind-qualified; lock the child kglob in breakable shared mode, release
the parent pin lock, parse; release the pin lock and object lock on the
child
- bind all bind variables
- pin parent heap zero in shared mode; check all matching children by
pinning their heap zero to see if any is fuckable or reusable byu this
dick.

do the above till your mother cursorit is willing and dripping; lock it in
breakable-share mode.

on every dip, pin in S mode; do cleanups; if the dick slips signal an
error if mid-fetch;

keep doing this till you and your mama scream.


Woho; what an overhead with this crappy PLSQL (untyped)

Or of course you can set cursor sharing to force and gang bang the
hookers!

Disclaimer: This is not related to any product whatsoever;
all names are fictional and do not relate to any real life objects

"omlet" <notrolls@notrolls.omlet.org.notrolls> wrote in message news:<f9f706273c861a5ebc66d9dfe3ff90b1@localhost.t alkaboutdatabases.com>...
> Ok; control files are not the first; you have attacked OMLET use of shared
> cursors set to FORCE. My answer was and still eat sh** and shut up;
> because there may be may be someone who knows slightly more than you.
>

Most certainly there are people who know more than I do, and, not
surprisingly, they all concur with my evaluation of the
cursor_sharing=force fiasco. To make one or two queries 'better' you
risk generating ORA-00600 errors and creating far more of a mess by
changing current query plans that may be quite efficient. And, such
responses still do not prove any of the libelous statements you've
made concerning me and my career, statements archived on this
newsgroup and accessed by my attorneys.

> Well let me make another bet: Do you know what you have in common with
> opiosq, opicca, opiexe, opifch or kernel calls kkspsc, kksumc, kkspfx,
> kkspin?
>
> the first four are the dicks that banged you shared azz; the last four are
> the ones that banged your mother cusorit.
>

Interesting use of vulgarity. Of course, I choose to write so that
anyone may read and understand. And the vulgar mind is a weak mind,
and you are certainly showing your weakness with this wondrous post.

> Actually sharing such a shared objects
> - requires shared lock;
> - creation of a kgl object;
> - pinning the name's object heap zero in shared mode
> -- might require checking if there is some context area that could be
> used by this dick, by pinning the child objects, one by one, and seeing if
> are also fuckable or usable.
> -- release the pin locks
> - pin the parent heap zero in exclusive mode, create new child marked as
> not bind-qualified; lock the child kglob in breakable shared mode, release
> the parent pin lock, parse; release the pin lock and object lock on the
> child
> - bind all bind variables
> - pin parent heap zero in shared mode; check all matching children by
> pinning their heap zero to see if any is fuckable or reusable byu this
> dick.
>
> do the above till your mother cursorit is willing and dripping; lock it in
> breakable-share mode.
>
> on every dip, pin in S mode; do cleanups; if the dick slips signal an
> error if mid-fetch;
>
> keep doing this till you and your mama scream.
>
>

With explanations like this it is no wonder why OMLET needs
cursor_sharing=force.

> Woho; what an overhead with this crappy PLSQL (untyped)
>
> Or of course you can set cursor sharing to force and gang bang the
> hookers!
>

Which apparently you do with frequency. Of course such behaviour has
no place in a relational database.

> Disclaimer: This is not related to any product whatsoever;
> all names are fictional and do not relate to any real life objects

Your 'disclaimer' in no way absolves you of responsibility for the
prior libelous statements you've made against me. You've made your
bed, now you'll need to lie in it. Of course, lying is what you do
best, so this shouldn't be a difficult task.

David Fitzjarrell