RE: sql trace - forward attribution

2004-01-06 Thread Boris Dali
Thanks, Raj, but I don't think so. The whole reason
behind enabling a db-wide trace was to capture
everything sql trace is instrumented to capture. As
you know sql_trace is a static parameter, so I got
everything "from the begining", including:

PARSING IN CURSOR #1 
ALTER DATABASE   MOUNT
..
PARSING IN CURSOR #1 
ALTER DATABASE OPEN

PARSING IN CURSOR #2
create table bootstrap$ ( line#

PARSING IN CURSOR #2 
CREATE ROLLBACK SEGMENT SYSTEM

.. but not the cursor #0 

(Interestingly "alter database mount" went to one
trace file, while "alter database open" and the rest
to another - so to mount a DB Oracle spawns a
different process on your behalf and than passes
control back to your foreground to open it?)


 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > you may not be
seeing parse etc entries for cursor
> #0 merely because maybe by design, cursor#0 gets
> invoked before trace gets activated. This way, you
> will never get cursor #0 info.
> 
> You can tell, I am guessing but to get similar
> experience, start trace in an already active session
> and you'll see.
> Raj
>

> Rajendra dot Jamadagni at nospamespn dot com
> All Views expressed in this email are strictly
> personal.
> QOTD: Any clod can have facts, having an opinion is
> an art !
> 
> 
> -Original Message-
> Sent: Tuesday, January 06, 2004 12:00 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Thanks to Anjo, Cary, Tanel, and everybody who
> provided feedback back channel.
> 
> Just to rule out the possibility of a collection
> error
> (somebody suggested that cursor #0 is simply not
> captured) I bounced the DB today, enabled a DB-wide
> trace ... and as expected 
> 
> grep -i "cursor #0" *
> 
> returned nothing, while "wait #0" gives plenty. So
> it
> is not a trace activation/termination error.
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Jamadagni, Rajendra
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: sql trace - forward attribution

2004-01-06 Thread Boris Dali
Thanks, Tanel.

I did checked v$session_connect info, but it doesn't
tell me much, except authentication_type='PROXY' which
is less than useful as it doesn't tell to whom.

v$session.client_identifier is empty.

Thanks,
Boris Dali.

> Check V$SESSION_CONNECT_INFO view.
> CLIENT_IDENTIFIER in V$SESSION might show something
> as well, if mid-tier is
> configured to pass client id to server.
> 
> Tanel.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: sql trace - forward attribution

2004-01-06 Thread Boris Dali
Thanks to Anjo, Cary, Tanel, and everybody who
provided feedback back channel.

Just to rule out the possibility of a collection error
(somebody suggested that cursor #0 is simply not
captured) I bounced the DB today, enabled a DB-wide
trace ... and as expected 

grep -i "cursor #0" *

returned nothing, while "wait #0" gives plenty. So it
is not a trace activation/termination error.

---

I think what we deal with here is a "variant" of what
Anjo described, but not exactly that as I don't see 

*** SESSION ID:(sid.serial#) lines in the middle of
any trace file, only in the header, but I think it
still might be "session switching" of a kind.

What we use here is an n-tier proxy authentication and
I suspect these waits is the price we pay for it. Not
sure, but maybe if proxy attributes are "switched" sql
trace doesn't capture this properly, "forgeting" to
emit new session info? I would be interested to know
how to

1) confirm or refute this
2) since waits #0 appear only before the calls to a
stored code - I don't know if they deliberatly "switch
sessions" in the code that runs on the app server and
run the stored code as the schema owner (similar to
switching current schema as an alternative to using
synonyms) or it is a feature of Oracle's proxy
authentication implementation
3) how to check "proxy identity" of the user - i.e.
how to run something like sys_context('userenv',
'proxy_user') for sessions other than my own.

Thanks,
Boris Dali.

 --- Anjo Kolk <[EMAIL PROTECTED]> wrote: > They write
all to the same trace file. So there
> should be different
> sid.serial# combinations.


______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: sql trace - forward attribution

2004-01-05 Thread Boris Dali
Tanel,

What I see in the trace file header is something like
the following:

...
*** SESSION ID:(22.9304) 2003-12-29 15:04:45.743
...

Which is sid.serial# isn't it?

If "session switching" occurs, handled by the same
shadow process and the new session with a different
sid.serial# continues to write to the **same** trace
file... wouldn't you expect to see line similar to the
above, but with a new sid.serial# in it?

 --- Tanel Poder <[EMAIL PROTECTED]> wrote: >
Trace file has server process number in it's name,
> not session number, thus
> as long as the sessions are served by the same
> server process, the contents
> will be written into one single file.
> 
> Tanel.
> 
> - Original Message - 
> To: "Multiple recipients of list ORACLE-L"
> <[EMAIL PROTECTED]>
> Sent: Monday, January 05, 2004 10:49 PM
> 
> 
> > Right, but the new session (that inherits the sql
> > trace attribute) - wouldn't it produce a
> **separate**
> > trace file? In my case there's only one trace file
> > with sid.serial# clearly stated at the begining of
> the
> > trace file and WAIT #0 scattered all over the t
> race
=== message truncated === 

______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: sql trace - forward attribution

2004-01-05 Thread Boris Dali
Right, but the new session (that inherits the sql
trace attribute) - wouldn't it produce a **separate**
trace file? In my case there's only one trace file
with sid.serial# clearly stated at the begining of the
trace file and WAIT #0 scattered all over the trace. 
..Or am I missing something?

 --- Anjo Kolk <[EMAIL PROTECTED]> wrote: > No,
> 
> Each session will have its own sid and serail#, but
> they all run in the
> same process. Basically the client side tells
> oracle, that it wants to
> switch from session to session and oracle will keep
> the state of the
> switched out session. So you don't have to commit or
> rollback on every
> switch that you perform. SQL trace is inherited by
> the process it you
> set in a session, so other sessions that run in the
> same process will
> produce also trace output.
> 
> Anjo.
> 
> -Original Message-
> Boris Dali
> Sent: Monday, January 05, 2004 7:34 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Thanks, Anjo.
> 
> When session switching occurs does the new session
> get
> the same sid and serial#? And what happens with the
> session being "switched/replaced" - does the
> transaction it was performing get
> commited/rollbacked?
> I don't see XCTEND markers before those pesky WAIT
> #0
> in the trace file.
> Also if session gets switched, wouldn't this
> terminate
> sql trace for the session (in my case it doesn't)?
> 
> Thanks,
> Boris Dali.
> 
>  --- Anjo Kolk <[EMAIL PROTECTED]> wrote: > 
> > 
> > Cursor 0 also happens in oracle due to session
> > switching (multiple
> > sessions in the same process), oracle apps uses
> that
> > but it also could
> > happen with certain other application servers
> > (haven't investigated it).
> > 
> > Anjo.
> > 
> > 
> > -Original Message-
> > Boris Dali
> > Sent: Monday, January 05, 2004 3:59 PM
> > To: Multiple recipients of list ORACLE-L
> > 
> > 
> > Thanks, Cary.
> > 
> > Could you elaborate what do you mean by "wait
> events associated with 
> > COMMIT processing"? Why does Oracle need this
> "exchange of messages" 
> > with the client (well, with the app server really
> in my case of a
> > 3-tier deployment) to perform a commit?
> > 
> > 
> > In any event, as I described earlier in my case I
> > think Cursor #0 doesn't fall in neither of the two
> > uses you mentioned.
> > 
> > Bug 2425312 is RPC related as I understand. I
> don't
> > work distributed (single DB) and app server (and
> > clients - thin) don't have their own SQL engine,
> so
> > all SQL processing is happening strictly on the DB
> > server. So this doesn't seem to apply to me.
> > 
> > And I see Cursor #0 used with no commits/rollbacks
> > as
> > part of one Oracle transaction.
> > 
> > 
> > I see these WAIT #0 flying back and forth between
> DB
> > and the app server sometimes 20 times just before
> > stored procs are called and I can't figure out
> why.
> > Another bug?
> > 
> > Thank you,
> > Boris Dali.
> > 
> >  --- Cary Millsap <[EMAIL PROTECTED]> wrote:
> >
> > Boris,
> > > 
> > > Cursor #0 seems reserved for two special uses:
> (1)
> > > wait events
> > > associated with COMMIT processing (also, of
> > course,
> > > ROLLBACK and
> > > SAVEPOINT), and (2) wait events associated with
> > > dbcalls not instrumented
> > > because of bug 2425312.
> > > 
> > > 
> > > Cary Millsap
> > > Hotsos Enterprises, Ltd.
> > > http://www.hotsos.com
> > > 
> > > Upcoming events:
> > > - Performance Diagnosis 101: 1/27 Atlanta
> > > - SQL Optimization 101: 2/16 Dallas
> > > - Hotsos Symposium 2004: March 7-10 Dallas
> > > - Visit www.hotsos.com for schedule details...
> > > 
> > > 
> > > -Original Message-
> > > Boris Dali
> > > Sent: Thursday, January 01, 2004 10:29 AM
> > > To: Multiple recipients of list ORACLE-L
> > > 
> > > Thanks a lot for your reply, Cary.
> > > 
> > > One follow-up question. What would motivate "a
> > chat"
> > > of sometimes 5, sometimes 10-20 'SQL*Net message
> > > to/from client' consecutive wait lines emitted
> to
> > > the
> > > trace file in the following manner:
> > > 
> > > WAIT #0: nam=

RE: sql trace - forward attribution

2004-01-05 Thread Boris Dali
Anjo,

I suppose your test-case involved more than just use
of sqlplus. Probably some middle tier with
connection/session pooling of some sort?

 --- Anjo Kolk <[EMAIL PROTECTED]> wrote: > I actually
build a testcase for this and it still
> failed on 9.2 without
> any patches. It is supposed to be fixed in some
> later patch. I don't
> have the patches
> 
> -Original Message-
> Anjo Kolk
> Sent: Monday, January 05, 2004 6:49 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> 
> 
> Cursor 0 also happens in oracle due to session
> switching (multiple
> sessions in the same process), oracle apps uses that
> but it also could
> happen with certain other application servers
> (haven't investigated it).
> 
> Anjo.
> 
> 
> -Original Message-
> Boris Dali
> Sent: Monday, January 05, 2004 3:59 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Thanks, Cary.
> 
> Could you elaborate what do you mean by "wait events
> associated with COMMIT processing"? Why does Oracle
> need this "exchange of messages" with the client
> (well, with the app server really in my case of a
> 3-tier deployment) to perform a commit?
> 
> 
> In any event, as I described earlier in my case I
> think Cursor #0 doesn't fall in neither of the two
> uses you mentioned.
> 
> Bug 2425312 is RPC related as I understand. I don't
> work distributed (single DB) and app server (and
> clients - thin) don't have their own SQL engine, so
> all SQL processing is happening strictly on the DB
> server. So this doesn't seem to apply to me.
> 
> And I see Cursor #0 used with no commits/rollbacks
> as
> part of one Oracle transaction.
> 
> 
> I see these WAIT #0 flying back and forth between DB
> and the app server sometimes 20 times just before
> stored procs are called and I can't figure out why.
> Another bug?
> 
> Thank you,
> Boris Dali.
> 
>  --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
> Boris,
> > 
> > Cursor #0 seems reserved for two special uses: (1)
> > wait events
> > associated with COMMIT processing (also, of
> course,
> > ROLLBACK and
> > SAVEPOINT), and (2) wait events associated with
> > dbcalls not instrumented
> > because of bug 2425312.
> > 
> > 
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > 
> > Upcoming events:
> > - Performance Diagnosis 101: 1/27 Atlanta
> > - SQL Optimization 101: 2/16 Dallas
> > - Hotsos Symposium 2004: March 7-10 Dallas
> > - Visit www.hotsos.com for schedule details...
> > 
> > 
> > -Original Message-
> > Boris Dali
> > Sent: Thursday, January 01, 2004 10:29 AM
> > To: Multiple recipients of list ORACLE-L
> > 
> > Thanks a lot for your reply, Cary.
> > 
> > One follow-up question. What would motivate "a
> chat"
> > of sometimes 5, sometimes 10-20 'SQL*Net message
> > to/from client' consecutive wait lines emitted to
> > the
> > trace file in the following manner:
> > 
> > WAIT #0: nam='SQL*Net message to client' ela= 2
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message from client' ela=
> 678 p1=1413697536 p2=1
> 
> > p3=0 WAIT #0: nam='SQL*Net message to client' ela=
> 1 p1=1413697536 
> > p2=1 p3=0 WAIT #0: nam='SQL*Net message from
> client' ela= 3463
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message to client' ela= 1
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message from client' ela=
> 3322
> > p1=1413697536 p2=1 p3=0
> > 
> > 
> > I see this pattern of "message exchanges" before
> > calling a stored code from the app server (OCI),
> so
> > using forward attribution it is a call to a stored
> > code that it to blame correct?
> > I can't of course eliminate a call to a stored
> code
> > but is there something that can be done to
> minimize
> > amount of these 'SQL*Net message...' lines? While
> > the
> > latency of these waits is low, these 3-5
> > milliseconds
> > get accumulated slowly, but surely.
> > 
> > Also does cursor #0 has some special meaning in
> > traces? I can't seem to create a test-case where I
> > get
> > cursor #0 emitted for me and yet tracing real
> > applications I see it all over (like in the
> excerpt
> > above)
> > 
> > 
> > I guess I have more than one follow-up question
> :-(
> > 
> &

RE: sql trace - forward attribution

2004-01-05 Thread Boris Dali
Thanks, Anjo.

When session switching occurs does the new session get
the same sid and serial#? And what happens with the
session being "switched/replaced" - does the
transaction it was performing get commited/rollbacked?
I don't see XCTEND markers before those pesky WAIT #0
in the trace file.
Also if session gets switched, wouldn't this terminate
sql trace for the session (in my case it doesn't)?

Thanks,
Boris Dali.

 --- Anjo Kolk <[EMAIL PROTECTED]> wrote: > 
> 
> Cursor 0 also happens in oracle due to session
> switching (multiple
> sessions in the same process), oracle apps uses that
> but it also could
> happen with certain other application servers
> (haven't investigated it).
> 
> Anjo.
> 
> 
> -Original Message-
> Boris Dali
> Sent: Monday, January 05, 2004 3:59 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Thanks, Cary.
> 
> Could you elaborate what do you mean by "wait events
> associated with COMMIT processing"? Why does Oracle
> need this "exchange of messages" with the client
> (well, with the app server really in my case of a
> 3-tier deployment) to perform a commit?
> 
> 
> In any event, as I described earlier in my case I
> think Cursor #0 doesn't fall in neither of the two
> uses you mentioned.
> 
> Bug 2425312 is RPC related as I understand. I don't
> work distributed (single DB) and app server (and
> clients - thin) don't have their own SQL engine, so
> all SQL processing is happening strictly on the DB
> server. So this doesn't seem to apply to me.
> 
> And I see Cursor #0 used with no commits/rollbacks
> as
> part of one Oracle transaction.
> 
> 
> I see these WAIT #0 flying back and forth between DB
> and the app server sometimes 20 times just before
> stored procs are called and I can't figure out why.
> Another bug?
> 
> Thank you,
> Boris Dali.
> 
>  --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
> Boris,
> > 
> > Cursor #0 seems reserved for two special uses: (1)
> > wait events
> > associated with COMMIT processing (also, of
> course,
> > ROLLBACK and
> > SAVEPOINT), and (2) wait events associated with
> > dbcalls not instrumented
> > because of bug 2425312.
> > 
> > 
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > 
> > Upcoming events:
> > - Performance Diagnosis 101: 1/27 Atlanta
> > - SQL Optimization 101: 2/16 Dallas
> > - Hotsos Symposium 2004: March 7-10 Dallas
> > - Visit www.hotsos.com for schedule details...
> > 
> > 
> > -Original Message-
> > Boris Dali
> > Sent: Thursday, January 01, 2004 10:29 AM
> > To: Multiple recipients of list ORACLE-L
> > 
> > Thanks a lot for your reply, Cary.
> > 
> > One follow-up question. What would motivate "a
> chat"
> > of sometimes 5, sometimes 10-20 'SQL*Net message
> > to/from client' consecutive wait lines emitted to
> > the
> > trace file in the following manner:
> > 
> > WAIT #0: nam='SQL*Net message to client' ela= 2
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message from client' ela=
> 678 p1=1413697536 p2=1
> 
> > p3=0 WAIT #0: nam='SQL*Net message to client' ela=
> 1
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message from client' ela=
> 3463
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message to client' ela= 1
> > p1=1413697536 p2=1 p3=0
> > WAIT #0: nam='SQL*Net message from client' ela=
> 3322
> > p1=1413697536 p2=1 p3=0
> > 
> > 
> > I see this pattern of "message exchanges" before
> > calling a stored code from the app server (OCI),
> so
> > using forward attribution it is a call to a stored
> > code that it to blame correct?
> > I can't of course eliminate a call to a stored
> code
> > but is there something that can be done to
> minimize
> > amount of these 'SQL*Net message...' lines? While
> > the
> > latency of these waits is low, these 3-5
> > milliseconds
> > get accumulated slowly, but surely.
> > 
> > Also does cursor #0 has some special meaning in
> > traces? I can't seem to create a test-case where I
> > get
> > cursor #0 emitted for me and yet tracing real
> > applications I see it all over (like in the
> excerpt
> > above)
> > 
> > 
> > I guess I have more than one follow-up question
> :-(
> > 
> > Thanks,
> > Boris Dali

Re: rewrite group by query

2004-01-05 Thread Boris Dali
How about

select * from (select tab1.*, count(a) over(partition
by a) a_count from tab1) where a_count =1;

... would probably save you one pass over tab1.

Thanks,
Boris Dali.

 --- elain he <[EMAIL PROTECTED]> wrote: > Hi,
> Does anyone have a better way of rewriting the
> following query? I'm trying 
> to avoid querying the table, tab1 twice.
> 
> select a, b from tab1
> where a in (select a from tab1 group by a having
> count(*)=1);
> 
> 
> Thanks.
> 
> elain
> 
>
_
> Make your home warm and cozy this winter with tips
> from MSN House & Home.  
> http://special.msn.com/home/warmhome.armx
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: elain he
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: sql trace - forward attribution

2004-01-05 Thread Boris Dali
Thanks, Cary.

Could you elaborate what do you mean by "wait events
associated with COMMIT processing"? Why does Oracle
need this "exchange of messages" with the client
(well, with the app server really in my case of a
3-tier deployment) to perform a commit?


In any event, as I described earlier in my case I
think Cursor #0 doesn't fall in neither of the two
uses you mentioned.

Bug 2425312 is RPC related as I understand. I don't
work distributed (single DB) and app server (and
clients - thin) don't have their own SQL engine, so
all SQL processing is happening strictly on the DB
server. So this doesn't seem to apply to me.

And I see Cursor #0 used with no commits/rollbacks as
part of one Oracle transaction.


I see these WAIT #0 flying back and forth between DB
and the app server sometimes 20 times just before
stored procs are called and I can't figure out why.
Another bug?

Thank you,
Boris Dali.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> Cursor #0 seems reserved for two special uses: (1)
> wait events
> associated with COMMIT processing (also, of course,
> ROLLBACK and
> SAVEPOINT), and (2) wait events associated with
> dbcalls not instrumented
> because of bug 2425312.
> 
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Performance Diagnosis 101: 1/27 Atlanta
> - SQL Optimization 101: 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
> 
> 
> -Original Message-
> Boris Dali
> Sent: Thursday, January 01, 2004 10:29 AM
> To: Multiple recipients of list ORACLE-L
> 
> Thanks a lot for your reply, Cary.
> 
> One follow-up question. What would motivate "a chat"
> of sometimes 5, sometimes 10-20 'SQL*Net message
> to/from client' consecutive wait lines emitted to
> the
> trace file in the following manner:
> 
> WAIT #0: nam='SQL*Net message to client' ela= 2
> p1=1413697536 p2=1 p3=0
> WAIT #0: nam='SQL*Net message from client' ela= 678
> p1=1413697536 p2=1 p3=0
> WAIT #0: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1 p3=0
> WAIT #0: nam='SQL*Net message from client' ela= 3463
> p1=1413697536 p2=1 p3=0
> WAIT #0: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1 p3=0
> WAIT #0: nam='SQL*Net message from client' ela= 3322
> p1=1413697536 p2=1 p3=0
> 
> 
> I see this pattern of "message exchanges" before
> calling a stored code from the app server (OCI), so
> using forward attribution it is a call to a stored
> code that it to blame correct?
> I can't of course eliminate a call to a stored code
> but is there something that can be done to minimize
> amount of these 'SQL*Net message...' lines? While
> the
> latency of these waits is low, these 3-5
> milliseconds
> get accumulated slowly, but surely.
> 
> Also does cursor #0 has some special meaning in
> traces? I can't seem to create a test-case where I
> get
> cursor #0 emitted for me and yet tracing real
> applications I see it all over (like in the excerpt
> above)
> 
> 
> I guess I have more than one follow-up question :-(
> 
> Thanks,
> Boris Dali.
> 
>  --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
> > 
> > >WAIT #31: nam='SQL*Net message to client' ela= 1
> > p1=1413697536 p2=1 p3=0
> > >WAIT #31: nam='SQL*Net message from client' ela=
> > 692 p1=1413697536 p2=1
> > p3=0
> > >WAIT #31: nam='SQL*Net message to client' ela= 1
> > p1=1413697536 p2=1
> > p3=0 >FETCH
> >
>
#31:c=0,e=261,p=0,cr=7,cu=0,mis=0,r=4,dep=0,og=4,tim=2001475650589
> > >WAIT #31: nam='SQL*Net message from client' ela=
> > 2295 p1=1413697536
> > p2=1 p3=0
> > >
> > 
> > Boris, "SQL*Net message..." events are
> > "between-call" events. Their
> > times are not included in the following dbcall's
> > elapsed time. But it
> > *is* appropriate to "blame" the dbcall that
> follows
> > for the time
> > consumed by the event. That is, if you can
> eliminate
> > the dbcall that
> > follows, then you can eliminate the between-call
> > event (and its elapsed
> > time). The "assignment of blame" is what "forward
> > attribution" is about.
> > 
> > 
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > 
> > Upcoming events:
> > - Performance Diagnosis 101: 1/27 Atlanta
> > - SQL Optimization

RE: sql trace - forward attribution

2004-01-01 Thread Boris Dali
Thanks a lot for your reply, Cary.

One follow-up question. What would motivate "a chat"
of sometimes 5, sometimes 10-20 'SQL*Net message
to/from client' consecutive wait lines emitted to the
trace file in the following manner:

WAIT #0: nam='SQL*Net message to client' ela= 2
p1=1413697536 p2=1 p3=0
WAIT #0: nam='SQL*Net message from client' ela= 678
p1=1413697536 p2=1 p3=0
WAIT #0: nam='SQL*Net message to client' ela= 1
p1=1413697536 p2=1 p3=0
WAIT #0: nam='SQL*Net message from client' ela= 3463
p1=1413697536 p2=1 p3=0
WAIT #0: nam='SQL*Net message to client' ela= 1
p1=1413697536 p2=1 p3=0
WAIT #0: nam='SQL*Net message from client' ela= 3322
p1=1413697536 p2=1 p3=0


I see this pattern of "message exchanges" before
calling a stored code from the app server (OCI), so
using forward attribution it is a call to a stored
code that it to blame correct?
I can't of course eliminate a call to a stored code
but is there something that can be done to minimize
amount of these 'SQL*Net message...' lines? While the
latency of these waits is low, these 3-5 milliseconds
get accumulated slowly, but surely.

Also does cursor #0 has some special meaning in
traces? I can't seem to create a test-case where I get
cursor #0 emitted for me and yet tracing real
applications I see it all over (like in the excerpt
above)


I guess I have more than one follow-up question :-(

Thanks,
Boris Dali.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
> 
> >WAIT #31: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1 p3=0
> >WAIT #31: nam='SQL*Net message from client' ela=
> 692 p1=1413697536 p2=1
> p3=0
> >WAIT #31: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1
> p3=0 >FETCH
>
#31:c=0,e=261,p=0,cr=7,cu=0,mis=0,r=4,dep=0,og=4,tim=2001475650589
> >WAIT #31: nam='SQL*Net message from client' ela=
> 2295 p1=1413697536
> p2=1 p3=0
> >
> 
> Boris, "SQL*Net message..." events are
> "between-call" events. Their
> times are not included in the following dbcall's
> elapsed time. But it
> *is* appropriate to "blame" the dbcall that follows
> for the time
> consumed by the event. That is, if you can eliminate
> the dbcall that
> follows, then you can eliminate the between-call
> event (and its elapsed
> time). The "assignment of blame" is what "forward
> attribution" is about.
> 
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Performance Diagnosis 101: 1/27 Atlanta
> - SQL Optimization 101: 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
> 
> 
> -Original Message-
> Boris Dali
> Sent: Monday, December 29, 2003 9:39 AM
> To: Multiple recipients of list ORACLE-L
> 
> I don't have the book with me right now, but I am
> obviously missing something in the "forward
> attribution" concept as it doesn't seem to help me
> in
> explanation of the following lines:
> 
>  
> WAIT #31: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1 p3=0
> WAIT #31: nam='SQL*Net message from client' ela= 692
> p1=1413697536 p2=1 p3=0
> WAIT #31: nam='SQL*Net message to client' ela= 1
> p1=1413697536 p2=1 p3=0
> FETCH
>
#31:c=0,e=261,p=0,cr=7,cu=0,mis=0,r=4,dep=0,og=4,tim=2001475650589
> WAIT #31: nam='SQL*Net message from client' ela=
> 2295
> p1=1413697536 p2=1 p3=0
> 
> 
> Shouldn't 1 + 692 + 1 (and possibly + 2295 ???) be
> less than 261?
>  
> Oracle 9.2.0.4.0 on HP-UX 11.11
> 
> Thanks,
> Boris Dali.
> 
>
__
> 
> Post your free ad now! http://personals.yahoo.ca
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Boris Dali
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
&

phys reads vs blocks read - statspack's segment stats

2003-12-31 Thread Boris Dali
I am reviewing segment statistics taken in a 15 min
snapshot (from stats$seg_stat) for a specific table,
which resides in 2 datafiles. The stats for datafiles
(stats$filestatxs) are as follows:

file# blocks read physical_reads
- --- --
11  8,171960
12  6,149387

while the table stats are:

liodb block changes phyrds
--  ---
42,0640  10,821

One would expect stats$seg_stat.physical_reads for
specific segment/snapshot to be <=
stats$filestat.physrds for the datafiles, segment
resides in, which doesn't seem to be the case.

Number of reads from the table somewhat makes sense if
compared against number of blocks read from the
datafiles, but not against number of reads from these
datafiles.

I know v$filestat timing info is notoriously
unreliable, but I thought i/o (number and blocks)
stuff can be trusted to.

Am I missing something obvious?

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: SQL CASE Statement

2003-12-29 Thread Boris Dali
Version?

select case when substr(banner, instr(banner,
'Release')+length('Release')+1, 1) < 9 then
   'tough luck. sql and pl/sql parsers are different'
   else 'check the syntax' end
from v$version where banner like 'Oracle%';

Thanks,
Boris Dali.

 --- "Pillai, Rajesh" <[EMAIL PROTECTED]>
wrote: > Hi All,
>   Any clues on why does a CASE block does not work in
> an INSERT-APPEND-SELECT statement called in a sql
> block in an UNIX script? If I replace the case block
> with a decode function then it works Whereas in
> a sql command prompt, both DECODE and CASE yields
> results.
> 
> TIA for all ur hints.
> 
> Thanks,
> Rajesh
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Pillai, Rajesh
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


sql trace - forward attribution

2003-12-29 Thread Boris Dali
I don't have the book with me right now, but I am
obviously missing something in the "forward
attribution" concept as it doesn't seem to help me in
explanation of the following lines:

 
WAIT #31: nam='SQL*Net message to client' ela= 1
p1=1413697536 p2=1 p3=0
WAIT #31: nam='SQL*Net message from client' ela= 692
p1=1413697536 p2=1 p3=0
WAIT #31: nam='SQL*Net message to client' ela= 1
p1=1413697536 p2=1 p3=0
FETCH
#31:c=0,e=261,p=0,cr=7,cu=0,mis=0,r=4,dep=0,og=4,tim=2001475650589
WAIT #31: nam='SQL*Net message from client' ela= 2295
p1=1413697536 p2=1 p3=0


Shouldn't 1 + 692 + 1 (and possibly + 2295 ???) be
less than 261?
 
Oracle 9.2.0.4.0 on HP-UX 11.11

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: STATSPACK interpretation

2003-12-23 Thread Boris Dali
Thanks, Jonathan.
Of course you are right :-)

Playing with this a little longer, I can get up to 4
versions (child_number from 0 to 3) of the same pl/sql
cursor by changing bind variable sizes. It ceases
being sharable when bv size changes from 32 to 33,
from 128 to 129 and from 2000 to 2001:

1-32
33-128
129-2000
2001-4000

I wonder if this behavior can be changed by some init
settings?

Thanks,
Boris Dali.

 --- Jonathan Lewis <[EMAIL PROTECTED]>
wrote: > 
> Notes in-line.
> 
> Regards
> 
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
> 
>   The educated person is not the person
>   who can answer the questions, but the
>   person who can question the answers -- T. Schick
> Jr
> 
> 
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
> 
> 
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> UK___November
> 
> 
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> 
> 
> - Original Message - 
> To: "Multiple recipients of list ORACLE-L"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, December 23, 2003 8:44 PM
> 
> 
> > Jonathan,
> >
> > Wouldn't bind variable issue that prevents cursor
> from
> > sharing be visible in bind_mismatch?
> 
> I would certainly hope so - but I remember playing
> around with v$sql_shared_cursor when it first came
> out and find cases where un-shared cursors came up
> with a full set of N's in the view.
> 
> > How can one simulate this?
> >
> > var v varchar2(1)
> > begin select count(5) into :v from dual; end;
> > /
> > select address, sql_text from v$sql where sql_text
> > like '%count(5)%';
> >
> > ADDRESS  SQL_TEXT
> > 
> >
>
--
> -
> > 6DE92A74 SELECT count(5) from dual
> > 6DE960D0 begin select count(5) into :v from dual;
> end;
> >
> > -- Change a bind variable size:
> > var v varchar2(30)
> > begin select count(5) into :v from dual; end;
> > /
> > -- same output, no change, both sql and pl/sql
> wrapper
> > cursors are still shared
> >
> 
> Nicely done. I think I'd run event 10046
> at level 4 as well to get the bind variable dumps
> and check if the the SQL (or pl/sql) environment
> was ignoring the MAXLEN value for your
> variables.  There are a few places where 'special
> optimisations' exist in Oracle's internal coding.
> 
> You might also try it with the most extreme
> case - it may be (for example) that Oracle
> rounds up varchar2() variables to 32 bytes -
> I'd go for 1 and 4000 - just in case.
> 
> 
> 
> > -- Change a bind variable type:
> > var v number
> > begin select count(5) into :v from dual; end;
> > /
> > ADDRESS  SQL_TEXT
> > 
> >
>
--
> --
> > 6DE92A74 SELECT count(5) from dual
> > 6DE960D0 begin select count(5) into :v from dual;
> end;
> > 6DE960D0 begin select count(5) into :v from dual;
> end;
> >
> > -- ok, here pl/sql parent (dep=0) cursor is no
> longer
> > shared
> >
> > [EMAIL PROTECTED]> select * from v$sql_shared_cursor where
> > kglhdpar = '6DE960D0';
> >
> > ADDRESS  KGLHDPAR U S O O S L S E B P I S T A B D
> L T
> > R I I R L I O S M U T N F
> >   - - - - - - - - - - - - - - - -
> - -
> > - - - - - - - - - - - - -
> > 6DE95B54 6DE960D0 N N N N N N N N N N N N N N N N
> N N
> > N N N N N N N N N N N N N
> > 6DE86F94 6DE960D0 N N N N N N N N N N N N N N Y N
> N N
> > N N N N N N N N N N N N N
> >
> > 2 rows selected.
> >
> > -- yep, bind variables mismatch
> >
> > Thanks,
> > Boris Dali.
> >
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Jonathan Lewis
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California    -- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 


Re: STATSPACK interpretation

2003-12-23 Thread Boris Dali
Jonathan,

Wouldn't bind variable issue that prevents cursor from
sharing be visible in bind_mismatch?
How can one simulate this?

var v varchar2(1)
begin select count(5) into :v from dual; end;
/
select address, sql_text from v$sql where sql_text
like '%count(5)%';

ADDRESS  SQL_TEXT

---
6DE92A74 SELECT count(5) from dual
6DE960D0 begin select count(5) into :v from dual; end;

-- Change a bind variable size:
var v varchar2(30)
begin select count(5) into :v from dual; end;
/
-- same output, no change, both sql and pl/sql wrapper
cursors are still shared

-- Change a bind variable type:
var v number
begin select count(5) into :v from dual; end;
/
ADDRESS  SQL_TEXT


6DE92A74 SELECT count(5) from dual
6DE960D0 begin select count(5) into :v from dual; end;
6DE960D0 begin select count(5) into :v from dual; end;

-- ok, here pl/sql parent (dep=0) cursor is no longer
shared

[EMAIL PROTECTED]> select * from v$sql_shared_cursor where
kglhdpar = '6DE960D0';

ADDRESS  KGLHDPAR U S O O S L S E B P I S T A B D L T
R I I R L I O S M U T N F
  - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - -
6DE95B54 6DE960D0 N N N N N N N N N N N N N N N N N N
N N N N N N N N N N N N N
6DE86F94 6DE960D0 N N N N N N N N N N N N N N Y N N N
N N N N N N N N N N N N N

2 rows selected.

-- yep, bind variables mismatch

Thanks,
Boris Dali.

 --- Jonathan Lewis <[EMAIL PROTECTED]>
wrote: > 
> I recall James Morle saying something about
> code not being sharable if the declared sizes 
> of the bind variables don't match.  If Informatica
> is using a 3GL to call anonymous pl/sql blocks
> with different bind variables every time, perhaps
> it is causing a bind variable mismatch.
> 
> As for the 400MB - I've often noticed oddities where
> a new entry is created, but "carries forward" a
> report 
> of the memory requirements of earlier variants, so
> if you
> have 10 cursors, they don't report 10 units of
> memory, but
> 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 units. It is 
> possible that you are seeing some effect like this. 
> 
> 
> 
> 
> Regards
> 
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
> 
>   The educated person is not the person 
>   who can answer the questions, but the 
>   person who can question the answers -- T. Schick
> Jr
> 
> 
> One-day tutorials:
> http://www.jlcomp.demon.co.uk/tutorial.html
> 
> 
> Three-day seminar:
> see http://www.jlcomp.demon.co.uk/seminar.html
> UK___November
> 
> 
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> 
> 
> - Original Message - 
> To: "Multiple recipients of list ORACLE-L"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, December 23, 2003 5:09 PM
> 
> 
> > Thomas,
> > 
> > The version count is the number of child cursors
> > present in the cache for this SQL.  The cursor is
> > not being shared for some reason with 456
> versions.
> > 
> > The 400m of memory seems a bit excessive.
> > 
> > There is a script at Jonathan's site with some
> info
> > about v$sqlarea and a script you can run that
> looks
> > at the current memory requirements for a SQL
> statement.
> > 
> > http://www.jlcomp.demon.co.uk/sqlarea.html
> > 
> > Does the output match what you see in statspack?
> > 
> > Also, the number of executions is much lower than
> > the version count, which is rather odd.  There's a
> bug
> > in early 9i versions that would cause this, but
> was
> > supposed to be corrected by 9.2.0.2.
> > 
> > In experimenting with this, I managed to get 4
> different 
> > sessions to create 2 versions of a cursor.  I'm
> not sure 
> > why as it was pl/sql and variables were used for
> the calling
> > parameters.
> > 
> > A 'select * from v$sql_shared_cursor' did not
> reveal any
> > reason for it.  
> > 
> > After bouncing the database and trying this again,
> I couldn't
> > duplicate it. 
> > 
> > Maybe a couple of things to pursue here, but
> perhaps not
> > an abundance of help. :(
> > 
> > Jared
> > 
> > 
> > 
> > On Tue, 2003-12-23 at 04:44, Thomas Jeff wrote:
> > > Jared,
> > > 
> > > Digging into it more, I found out that it's
> called from an 
> > > Informatica client.   Apparently, the gist of
> the client-side 
> > > algorithim is as follows:
> > > 
> > > For eac

Re: RE: connection pooling from an application server to oracle

2003-12-15 Thread Boris Dali
I might be totatly off here, but I think it depends on
the type of the pool. For example in OCI land there
are two - connection pool and session pool. The former
is stateful, while the latter is stateless. Again
unless I am totally off base, with a session pool I
think your session gets returned to a pool manager
(for potential re-use) after _about_ every statement,
effectively making tx:stmt relationship to become
about 1:1. 

This is exactly what I am dealing with here and as a
result when user navigates on the screen the app
server instead of issuing say 30 selects, adds
additional 30 implicit rollbacks, one after each
select.

This is also the reason I think I see pattern like
this for example all over on DMLs:

XCTEND rlbk=0, rd_only=0-- explicit commit
here
WAIT #0: nam='SQL*Net message to client'...
WAIT #0: nam='SQL*Net message from client'...
XCTEND rlbk=1, rd_only=1-- implicit rollback
right after commit due to OCITransRollback() call

Thanks,
Boris Dali.

 --- [EMAIL PROTECTED] wrote: > doesnt this force
you to commit after every single
> DML statement? 
> > 
> > From: "Mercadante, Thomas F"
> <[EMAIL PROTECTED]>
> > Date: 2003/12/15 Mon AM 08:36:09 EST
> > To: "'[EMAIL PROTECTED]'"
> <[EMAIL PROTECTED]>
> > CC: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > Subject: RE: connection pooling from an
> application server to oracle
> > 
> > Ryan,
> > 
> > This is becoming for normal.  There are a lot of
> software pieces that do
> > connection pooling - basically, everybody is
> plaing in everbody else's
> > space.
> > 
> > I have a couple of projects where the app-server
> does the connection
> > pooling.  One using Dcom and the other IBM
> WebSphere.
> > 
> > From your point of view, it's just one less thing
> to worry about.  The
> > number of db connections will be relatively small.
>  The app server keeps
> > track of transactions.  As long as they say it
> works, it's not your problem.
> > 
> > Tom Mercadante
> > Oracle Certified Professional
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> > Sent: Monday, December 15, 2003 7:59 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: connection pooling from an application
> server to oracle
> > 
> > 
> > The software engineers here are using an
> application server with connection
> > pooling to connect to our oracle instances. 
> > They are doing it with a dedicated connection to
> Oracle. No MTS.
> > 
> > they compartmentalize stuff here, so Im having
> trouble figuring out exactly
> > how this affects the database and how to monitor
> performance. All I know is
> > that I see a handful of constantly open dedicated
> connections. I have been
> > told that this is actually alot of users
> connecting to the database. 
> > 
> > This concerns me. how do you handle transaction
> control in this type of
> > environment? in this type of environment do you
> have to commit after every
> > DML statement? since multiple users will access
> the database with the same
> > conneciton? 
> > 
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> > -- 
> > Author: <[EMAIL PROTECTED]
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> > San Diego, California-- Mailing list and
> web hosting services
> >
>
-
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB
> ORACLE-L
> > (or the name of mailing list you want to be
> removed from).  You may
> > also send the HELP command for other information
> (like subscribing).
> > 
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: <[EMAIL PROTECTED]
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-----
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
>

RE: CPU Capacity Planning

2003-12-08 Thread Boris Dali
Thanks a lot, Cary.

Yes, this sentence on p.248: 

"As long the execution of each business function can
be expressed in terms of an LIO count, you can
translate the queueing model's output in terms of
business function response time and throughput" 

was the one I marked as something to go back to, as I
didn't really understand it.

Thanks,
Boris Dali.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> I think I covered this in my response to Ryan. It
> was the "two stages"
> part.
> 
> Note that you can avoid even using queueing theory
> at all if you just
> make sure that utilization stays to the left of the
> knee in the
> performance curve for each resource on the system.
> You can learn the
> location of the knee for a given number of parallel
> service channels
> (for example, CPUs in your case) on Table 9-3 on
> p260 of "Optimizing
> Oracle Performance."
> 
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Performance Diagnosis 101: 12/16 Detroit, 1/27
> Atlanta
> - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
> 
> 
> -Original Message-
> Boris Dali
> Sent: Sunday, December 07, 2003 12:39 PM
> To: Multiple recipients of list ORACLE-L
> 
> Thanks for the clarifications, Cary.
> 
> With regards to a hardware sizing - how do LIOs fit
> into queueing theory? Let's say I can come up with
> something like:
> 
> #CPUs required = Sum( LIOs(Bus.Tx i)) / 
> (10,000*clock rate/100)
> 
> where i={Bus.Tx 1..n}
> 
> [on a projected box that haven't been bought yet, it
> might be a little difficult to estimate the
> denominator, ... and on the existing one I guess I
> have to get hold of Jonathan's paper to learn how
> this
> can be done]
> 
> ..but in any event for forecasting purposes, how
> queueing effect might be taken into account here?
> Let's say I measured Sum( LIOs(...)) for a 50 users
> in
> a unit testing environment and I am told that
> production would be 10 times more than that, what do
> I
> do?
> 
> Thanks,
> Boris Dali.
> 
>  --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
> My answers are in-line, preceded with "[Cary
> > Millsap]"...
> > 
> > 
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> > 
> > Upcoming events:
> > - Performance Diagnosis 101: 12/16 Detroit, 1/27
> > Atlanta
> > - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
> > - Hotsos Symposium 2004: March 7-10 Dallas
> > - Visit www.hotsos.com for schedule details...
> > 
> > 
> > -Original Message-
> > Boris Dali
> > Sent: Sunday, December 07, 2003 9:54 AM
> > To: Multiple recipients of list ORACLE-L
> > 
> > Thanks a lot for the reply, Cary. Yes, your
> > explanation makes all the sense in the world even
> > though it is precisely the weighted average
> approach
> > that I've seen on some capacity planning
> > spreadsheets.
> > 
> > Two additional questions if I may, Cary.
> > Would it be correct to say that when I throw
> > additional users on a system it is only queueing
> > component of a response time that climbs up, while
> > service time stays the same?
> > 
> > [Cary Millsap] "Sort of," but not exactly. There
> are
> > lots of scalability
> > threats that begin to manifest in reality when you
> > crank up the load.
> > For example, you'll see "latch free" waiting on
> > applications that parse
> > too much, but only at higher user volumes (never
> in
> > unit test). You can
> > consider the new appearance of "latch free" events
> > to be a type of
> > queueing if you want, but it's really not queueing
> > in the sense of a
> > simple CPU queueing model. 
> > 
> > If that's true, than does
> > it matter how I measure service time of my Bus.Tx1
> -
> > on a loaded system where hundreds of users run
> this
> > operation or when nobody executes it all? Also is
> it
> > important to have the other two operations -
> Bus.Tx2
> > and Bus.Tx3 - running concurrently (as they would
> in
> > a
> > real life) for the c measurements?
> > 
> > [Cary Millsap] You'll put yourself at risk if you
> > simply try to use a
> > queueing model to extrapolate big-system
> performance
> > from data collected
> > in a unit testing

RE: CPU Capacity Planning

2003-12-07 Thread Boris Dali
Thanks for the clarifications, Cary.

With regards to a hardware sizing - how do LIOs fit
into queueing theory? Let's say I can come up with
something like:

#CPUs required = Sum( LIOs(Bus.Tx i)) / 
(10,000*clock rate/100)

where i={Bus.Tx 1..n}

[on a projected box that haven't been bought yet, it
might be a little difficult to estimate the
denominator, ... and on the existing one I guess I
have to get hold of Jonathan's paper to learn how this
can be done]

..but in any event for forecasting purposes, how
queueing effect might be taken into account here?
Let's say I measured Sum( LIOs(...)) for a 50 users in
a unit testing environment and I am told that
production would be 10 times more than that, what do I
do?

Thanks,
Boris Dali.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
My answers are in-line, preceded with “[Cary
> Millsap]”...
> 
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Performance Diagnosis 101: 12/16 Detroit, 1/27
> Atlanta
> - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
> 
> 
> -Original Message-
> Boris Dali
> Sent: Sunday, December 07, 2003 9:54 AM
> To: Multiple recipients of list ORACLE-L
> 
> Thanks a lot for the reply, Cary. Yes, your
> explanation makes all the sense in the world even
> though it is precisely the weighted average approach
> that I've seen on some capacity planning
> spreadsheets.
> 
> Two additional questions if I may, Cary.
> Would it be correct to say that when I throw
> additional users on a system it is only queueing
> component of a response time that climbs up, while
> service time stays the same?
> 
> [Cary Millsap] “Sort of,” but not exactly. There are
> lots of scalability
> threats that begin to manifest in reality when you
> crank up the load.
> For example, you’ll see “latch free” waiting on
> applications that parse
> too much, but only at higher user volumes (never in
> unit test). You can
> consider the new appearance of “latch free” events
> to be a type of
> queueing if you want, but itÂ’s really not queueing
> in the sense of a
> simple CPU queueing model. 
> 
> If that's true, than does
> it matter how I measure service time of my Bus.Tx1 -
> on a loaded system where hundreds of users run this
> operation or when nobody executes it all? Also is it
> important to have the other two operations - Bus.Tx2
> and Bus.Tx3 - running concurrently (as they would in
> a
> real life) for the c measurements?
> 
> [Cary Millsap] YouÂ’ll put yourself at risk if you
> simply try to use a
> queueing model to extrapolate big-system performance
> from data collected
> in a unit testing environment. ItÂ’s because of the
> potentially
> out-of-model scalability threats.
> 
> In other words assuming I have an identical replica
> of
> a production environment where I am the only user -
> would service time/rate measured there be applicable
> for a loaded system with heterogeneous workload?
> 
> [Cary Millsap] ...Only if you your production
> environment doesnÂ’t
> trigger any new serialization issues that werenÂ’t
> visible on your unit
> test env.
> 
> And another stupid question.
> Knowing individual business tx. characteristics
> (response time, number of CPUs required to comply
> with
> SLA requirements, average utilization per CPU, etc),
> how does one go about sizing the box in terms of the
> overall "system" required CPU capacity? Or put it
> another way - what do I tell a hardware vendor?
> 
> That is, if what comes out of a queueuing exercise
> is:
>m   pho
>    ---
> Bus.Tx1   2-way70%
> Bus.Tx2   3-way50%
> Bus.Tx3   4-way80%
> 
> What should be the optimistic (let's assume perfect
> liner CPU scalability for now) recommendation to
> decision makers in terms of the horsepower required
> to
> run this "system" on? 
> After all, yes individual business transactions have
> their own SLA requirements (e.g. worst tolerated
> response time), but they all use the same resources,
> don't they? So even though a service time of Bus.Tx1
> might remain constant the queueing delay (and hence
> the response time) would likely to increase due to
> other concurrent activities on the system. Is there
> a
> way to account for this if capacity planning is done
> at the individual bus.tx level?
> 
> [Cary Millsap] The hardest part about capacity
> planning is that thereÂ’s
> no useful industry-wide standard unit of CPU work to
> use. You canÂ’t use
> MHz, you canÂ’t

RE: CPU Capacity Planning

2003-12-07 Thread Boris Dali
Thanks a lot for the reply, Cary. Yes, your
explanation makes all the sense in the world even
though it is precisely the weighted average approach
that I've seen on some capacity planning spreadsheets.

Two additional questions if I may, Cary.
Would it be correct to say that when I throw
additional users on a system it is only queueing
component of a response time that climbs up, while
service time stays the same? If that's true, than does
it matter how I measure service time of my Bus.Tx1 -
on a loaded system where hundreds of users run this
operation or when nobody executes it all? Also is it
important to have the other two operations - Bus.Tx2
and Bus.Tx3 - running concurrently (as they would in a
real life) for the c measurements?

In other words assuming I have an identical replica of
a production environment where I am the only user -
would service time/rate measured there be applicable
for a loaded system with heterogeneous workload?



And another stupid question.
Knowing individual business tx. characteristics
(response time, number of CPUs required to comply with
SLA requirements, average utilization per CPU, etc),
how does one go about sizing the box in terms of the
overall "system" required CPU capacity? Or put it
another way - what do I tell a hardware vendor?

That is, if what comes out of a queueuing exercise is:
   m   pho
   ---
Bus.Tx1   2-way70%
Bus.Tx2   3-way50%
Bus.Tx3   4-way80%

What should be the optimistic (let's assume perfect
liner CPU scalability for now) recommendation to
decision makers in terms of the horsepower required to
run this "system" on? 
After all, yes individual business transactions have
their own SLA requirements (e.g. worst tolerated
response time), but they all use the same resources,
don't they? So even though a service time of Bus.Tx1
might remain constant the queueing delay (and hence
the response time) would likely to increase due to
other concurrent activities on the system. Is there a
way to account for this if capacity planning is done
at the individual bus.tx level?

Thanks,
Boris Dali.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> If you mean that some people on your system execute
> Bus.Tx1, some others
> execute Bus.Tx2, and some others (maybe with some
> overlap) execute
> Bus.Tx3, then my answer to your question is:
> 
>   No, I would strongly encourage you *not* to do
> this!
> 
> It was exercises like this that first led me to
> discover the fact that
> there's no such thing as a "system" in the sense
> that most people use
> the term (that is, as a big mishmash of different
> transactions, in which
> averages have any real meaning).
> 
> Combining your three CDFs will hurt you in the way
> described in "Why
> understanding distribution is important" on
> pp238-239 of the Optimizing
> Oracle Performance book. Here's another example:
> Imagine the following
> "system"...
> 
>avg.   avg.
>  runs/day   sec/run   who uses it
> Tx1   10,0001   Group A
> Tx21,000   10   Group B
> Tx3  100  100   Group C
> 
> So, what's this "system's" average response time? A
> naïve
> "mathematician" might think it's the weighted
> average of all the
> response times: (1*1 + 1000*10 + 100*100) /
> (1+1000+100) = 2.7
> sec. But what use is this figure? Nobody's response
> time is "ever"
> really 2.7 sec. I say "ever" here because
> it's of course
> possible that a program whose "avg. sec/run" is 1
> (or even 10) will
> occasionally have a true response time of
> 2.7.
> 
> If you're *anybody* actually using the system, the
> number "2.7 sec/run"
> is just stupid! The 2.7s figure is especially
> ludicrous if you're a
> member of Group B or C, because your average
> response time is either
> really 3.7x that number (B) or 37x that number (C)!
> The mathematical
> explanation for the stupid-looking-ness is that, no
> matter what you're
> doing, this 2.7 number is an average influenced by
> stuff that you're
> *not* doing.
> 
> There is no such thing as an "average user" (any
> more than there's an
> American family with 2.3 children); in this example,
> there are only
> members of Groups A, B, and C. What if you're a
> member of two groups
> simultaneously (e.g., you run different transaction
> types in the same
> day)? It's the same problem, because your
> expectation of, for example,
> Tx1 response time is completely different from your
> expectation of Tx3
> response time. Clumping response times from Tx1 and
> Tx2 in

CPU Capacity Planning

2003-12-06 Thread Boris Dali
Let's say I have 3 business transactions (consisting
of numerous Oracle transactions each) and I know total
service time for each (from c readings off sql traces
for the length of the bus.tx). Doing queuing theory
exercise I can also get CDF(r max) for each. Let's say

Bus.Tx1 - CPU time=5s   CDF(r)=97%
Bus.Tx2 - CPU time=8s   CDF(r)=95%
Bus.Tx3 - CPU time=10s  CDF(r)=90%

How can I combine these three together and make any
conclusions as to what the overall CDF(r) would be for
the whole system consisting of the above 3 business
transactions? Is this doable?

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: raw traces - EXEC: c=10,000 e=40

2003-12-04 Thread Boris Dali
Cary, thanks a lot for the explanation (and the other
one [and especially the other one :-) ]). Much
appreciated.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
You're on the right trail by experimenting with it.
> I'm surprised that
> the number of gettimeofday() calls is so small. The
> times() call is the
> SVR4 analog of the BSD getrusage() call. I guess I
> shouldn't be
> surprised to see both times() and getrusage() being
> used.
>  
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Performance Diagnosis 101: 12/16 Detroit, 1/27
> Atlanta
> - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...

=== message truncated === 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Fwd: RE: raw traces - EXEC: c=10,000 e=40

2003-12-03 Thread Boris Dali
Yes, turning time_statistics off (at the session
level) gets rid of all the times() calls. Further
turning off timed_os_statistics (from 5 to 0) gets rid
of getrusage() as well, leaving only gettimeofday()
calls

Thanks,
Boris Dali.

 --- Boris Dali <[EMAIL PROTECTED]> wrote: > Date:
Wed, 03 Dec 2003 10:29:24 -0800
> To: Multiple recipients of list ORACLE-L
> <[EMAIL PROTECTED]>
> From: Boris Dali <[EMAIL PROTECTED]>
> Subject: RE: raw traces - EXEC: c=10,000 e=40
> 
> Is this true? strace-ing on linux shows gettimeofday
> calls (for e) and getrusage (for c) - just like Cary
> describes. On HP however tusc-ing a simple "select *
> from dual" issued from sqlplus I see:
> 
> calls sys call
> - 
> 1 gettimeofday()
> 1 getrusage()
> 15times()
> 
> Which sys call is used for what? 
> Guess I can turn timed_statistics off and see how it
> affects the (amount of) sys calls issued
> 
> Thanks,
> Boris Dali.
> 
>  --- Niall Litchfield
> <[EMAIL PROTECTED]> wrote: > 
> reads
> Jonathan's description and blushes 
> > 
> > So it'll be a *feature* and not a bug then. IIRC e
> > comes from POSIX
> > gettimeofday calls on all platforms except Windows
> > -- where it looks
> > like GetTickCount. If this is true then the
> accuracy
> > of e will be
> > limited by the accuracy of gettimeofday. 
> > 
> > Niall
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On 
> > > Behalf Of Niall Litchfield
> > > Sent: 02 December 2003 22:24
> > > To: Multiple recipients of list ORACLE-L
> > > Subject: RE: raw traces - EXEC: c=10,000 e=40
> > > 
> > > 
> > > I'd be highly, highly suspicious of the cpu time
> > c. 
> > > 
> > > 1. You should be able to verify (roughly the
> > elapsed time) of 
> > > the statement, if by no other means than running
> > in sqlplus 
> > > with timing on. 
> > > 2. 3 statements with *exactly* the same cpu time
> -
> > all in 
> > > very very round numbers. Seems unlikely to me. 
> > > 
> > > Might be an hp-ux bug but as I don't have HP-UX
> to
> > play with 
> > > that is speculation of the first order. 
> > > 
> > > Niall
> > > 
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > > > Behalf Of Boris Dali
> > > > Sent: 02 December 2003 20:49
> > > > To: Multiple recipients of list ORACLE-L
> > > > Subject: raw traces - EXEC: c=10,000 e=40
> > > > 
> > > > 
> > > > Reading Cary's book I understand that c and e
> > are
> > > > measured via different system calls (haven't
> > truss'ed
> > > > [well tusc'ed] them yet - I am on HP-UX
> 11.11),
> > but
> > > > would anybody know what the reasonable upper
> > limit of
> > > > c-e might be?
> > > > 
> > > > I am looking at the trace file where c is more
> > than
> > > > two orders of magnitude greater than e, which
> > make me
> > > > wonder if I a have some anomaly on my system
> > > > 
> > > > Some examples:
> > > > 
> > > > EXEC
> > > > 
> > >
> >
>
#98:c=1,e=433,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=1777312113968
> > > > 
> > > > EXEC
> > > >
> >
>
#110:c=1,e=390,p=0,cr=1,cu=3,mis=0,r=1,dep=1,og=4,tim=1777
> > > > 312181650
> > > > 
> > > > PARSE
> > > > 
> > >
> >
>
#103:c=1,e=40,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1777314524922
> > > > 
> > > > Oracle 9.2.0.4.0 on HP-UX 11.11
> > > > 
> > > > Thanks,
> > > > Boris Dali.
> > > > 
> > > >
> >
>
__
> > > > 
> > > > Post your free ad now!
> http://personals.yahoo.ca
> > > > -- 
> > > > Please see the official ORACLE-L FAQ:
> > http://www.orafaq.net
> > > > -- 
> > > > Author: Boris Dali
> > > >   INET: [EMAIL PROTECTED]
> > > > 
> > > > Fat City Network Services-- 858-538-5051
> > http://www.fatcity.com
> > > > San Diego, California-- Mailing list
> and
> > web 
> > > hostin

RE: raw traces - EXEC: c=10,000 e=40

2003-12-03 Thread Boris Dali
Is this true? strace-ing on linux shows gettimeofday
calls (for e) and getrusage (for c) - just like Cary
describes. On HP however tusc-ing a simple "select *
from dual" issued from sqlplus I see:

calls sys call
- 
1 gettimeofday()
1 getrusage()
15times()

Which sys call is used for what? 
Guess I can turn timed_statistics off and see how it
affects the (amount of) sys calls issued

Thanks,
Boris Dali.

 --- Niall Litchfield
<[EMAIL PROTECTED]> wrote: >  reads
Jonathan's description and blushes 
> 
> So it'll be a *feature* and not a bug then. IIRC e
> comes from POSIX
> gettimeofday calls on all platforms except Windows
> -- where it looks
> like GetTickCount. If this is true then the accuracy
> of e will be
> limited by the accuracy of gettimeofday. 
> 
> Niall
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Niall Litchfield
> > Sent: 02 December 2003 22:24
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: raw traces - EXEC: c=10,000 e=40
> > 
> > 
> > I'd be highly, highly suspicious of the cpu time
> c. 
> > 
> > 1. You should be able to verify (roughly the
> elapsed time) of 
> > the statement, if by no other means than running
> in sqlplus 
> > with timing on. 
> > 2. 3 statements with *exactly* the same cpu time -
> all in 
> > very very round numbers. Seems unlikely to me. 
> > 
> > Might be an hp-ux bug but as I don't have HP-UX to
> play with 
> > that is speculation of the first order. 
> > 
> > Niall
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> > > Behalf Of Boris Dali
> > > Sent: 02 December 2003 20:49
> > > To: Multiple recipients of list ORACLE-L
> > > Subject: raw traces - EXEC: c=10,000 e=40
> > > 
> > > 
> > > Reading Cary's book I understand that c and e
> are
> > > measured via different system calls (haven't
> truss'ed
> > > [well tusc'ed] them yet - I am on HP-UX 11.11),
> but
> > > would anybody know what the reasonable upper
> limit of
> > > c-e might be?
> > > 
> > > I am looking at the trace file where c is more
> than
> > > two orders of magnitude greater than e, which
> make me
> > > wonder if I a have some anomaly on my system
> > > 
> > > Some examples:
> > > 
> > > EXEC
> > > 
> >
>
#98:c=1,e=433,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=1777312113968
> > > 
> > > EXEC
> > >
>
#110:c=1,e=390,p=0,cr=1,cu=3,mis=0,r=1,dep=1,og=4,tim=1777
> > > 312181650
> > > 
> > > PARSE
> > > 
> >
>
#103:c=1,e=40,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1777314524922
> > > 
> > > Oracle 9.2.0.4.0 on HP-UX 11.11
> > > 
> > > Thanks,
> > > Boris Dali.
> > > 
> > >
>
__
> > > 
> > > Post your free ad now! http://personals.yahoo.ca
> > > -- 
> > > Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> > > -- 
> > > Author: Boris Dali
> > >   INET: [EMAIL PROTECTED]
> > > 
> > > Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> > > San Diego, California-- Mailing list and
> web 
> > hosting services
> > > 
> >
>
-
> > > To REMOVE yourself from this mailing list, send
> an E-Mail message
> > > to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru')
> > > and in the message BODY, include a line
> containing: UNSUB 
> > > ORACLE-L (or the name of mailing list you want
> to be removed 
> > > from).  You may also send the HELP command for
> other 
> > > information (like subscribing).
> > > 
> > 
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> > -- 
> > Author: Niall Litchfield
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> > San Diego, California-- Mailing list and
> web hosting services
> >
>
-
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of

raw traces - EXEC: c=10,000 e=40

2003-12-02 Thread Boris Dali
Reading Cary's book I understand that c and e are
measured via different system calls (haven't truss'ed
[well tusc'ed] them yet - I am on HP-UX 11.11), but
would anybody know what the reasonable upper limit of
c-e might be? 

I am looking at the trace file where c is more than
two orders of magnitude greater than e, which make me
wonder if I a have some anomaly on my system

Some examples:

EXEC
#98:c=1,e=433,p=0,cr=2,cu=2,mis=0,r=1,dep=1,og=4,tim=1777312113968

EXEC
#110:c=1,e=390,p=0,cr=1,cu=3,mis=0,r=1,dep=1,og=4,tim=1777312181650

PARSE
#103:c=1,e=40,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1777314524922

Oracle 9.2.0.4.0 on HP-UX 11.11

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: migration sequence oci problem

2003-11-27 Thread Boris Dali
Jeron,

I don't know if it would help any, but if it is a DB
issue, event 10217 might be useful:

$ oerr ORA 10217
10217, 0, "debug sequence numbers"
// *Cause:
// *Action:

I have never used it myself before, but if you push
support a bit maybe they might provide details on how
this can be used. I've just experimented with it a bit
now, but to no avail - just setting it alone and/or
combined with 10046 doesn't seem to make much
difference.

Thanks,
Boris Dali.

 --- Jeroen van Sluisdam
<[EMAIL PROTECTED]> wrote: > We could
narrow it down to the value of the sequence
> exceeding
> 16777216 (2 to the power of 24)
> This looks familiar as described in bug 2573172
> This bug describes to change the type in the odefin
> call to type 3 but this
> doesn't help. 
> I know this is not really a dba issue now anymore
> but I'm desperate for any
> advice because I don't have any developers
> left with oci-knowledge
> Tnx, 
> Jeroen
>  
>  
> -Oorspronkelijk bericht-
> Van: Jeroen van Sluisdam 
> Verzonden: Wednesday, November 26, 2003 16:40
> Aan: '[EMAIL PROTECTED]'
> Onderwerp: migration sequence oci problem
>  
>  
> Hi,
>  
> We're testing an oracle 9.2.0.4 database with an
> oracle 7 client.
> This is a C++ client, using OCI to go to oracle.
> We see strange behaviour when using a sequence which
> worked 
> nicely before. The sequence is not incremented when
> issueing
> "select res_id.nextval from dual
>  
> When I test this with an oracle 7 sqlplus client
> this works also
> as expected.
>  
> Is there any known bug or issue known with migrating
> oci-applications.
> According to manuals it shouldn't be a problem and I
> cannot find any
> problems
> on metalink about this.
>  
> Thanks in advance,
>  
> Jeroen
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: sql trace - recursive relationships

2003-11-27 Thread Boris Dali
Thanks a lot, Cary.
Indeed the indented notation seems rather convenient.

I would be delighted to take your PD101 course, just
not sure if people here dealing with the training
budget would share the delight with me :-( 
Doesn't hurt to ask though...

Thanks again,
Boris Dali.


__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: sql trace - XCTEND rlbk=1, rd_only=1

2003-11-26 Thread Boris Dali
Thanks, Jared.

Yes, running select vs select+rollback in a loop of
1000 iterations I got similar results (average over 3
runs):

STAT...user rollbacks  0  1,000  1,000
LATCH...enqueues 570  1,574  1,004
LATCH...shared pool7,434  9,063  1,629
STAT...recursive   7,754 10,264  2,510
LATCH...library cache 13,401 17,429  4,028

So, every select w/ a rollback is at least 1 enqueue
and 4 latches (1 shared pool + 3 library cache) more
expensive than select wo/ a rollback.

Since latches are scalability inhibitors - would it be
far away from the truth to say that an application
that uses OCI session pooling (as opposed to
connection pooling I suppose? - just reading chapter 9
of the OCI manual) doesn't scale well with respect to
the number of concurrent users?

Thanks,
Boris Dali.

 --- Jared Still <[EMAIL PROTECTED]> wrote: > Using a
slightly modified version of run_stats to
> return
> timings in 1/1 of a second, the timing of 1000
> iterations
> of a loop executing noop vs. 1000 doing rollback:
> 
> .0005 secs
> .0354 secs
> 
> Here are the stats that were different between the
> two,
> kind of what you would expect:
> 
> LATCH.cache buffers chains  113 
>   13320
> STAT...redo size  27160 
> 27648   488
> STAT...user rollbacks 0 
>  1000  1000
> LATCH.enqueues0 
>  1001  1001
> LATCH.shared pool 3 
>  1004  1001
> LATCH.session idle bit0 
>  1001  1001
> STAT...execute count  3 
>  1004  1001
> LATCH.library cache pin  13 
>  2014  2001
> LATCH.session allocation  0 
>  2002  2002
> STAT...recursive calls4 
>  2008  2004
> LATCH.library cache  14 
>  3018  3004

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: sql trace - recursive relationships

2003-11-26 Thread Boris Dali
Thanks, Raj.

So yes, as I said in my other email - the rule stated
in the book seem to apply to EXEC db calls only (in
case of SQL fired from PL/SQL). I guess I
misinterpreted it the way that it applies to ALL db
calls for recursive cursors.

Thanks,
Boris Dali.

 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > Sorry about the
last empty email ...
> 
> Cary is right, the EXEC at dep=0 is the database
> call you should be looking for, why? because until
> #1 is parsed, db has no way of finding what needs to
> do. And once it finds that "Oh I must run a SQL",
> the dep increases.  So, I'd look for a subsequent
> EXEC instead of PARSE line.
> 
> I'll take a stab at this ...  lines with --> are
> mine
> 
> =
> PARSING IN CURSOR #1 len=94 dep=0 uid=83 oct=47
> lid=83 tim=1617285502494 hv=1138148843 ad='605d0998'
> --> Anonymous block
> BEGIN nav_tree_pkg.get_nav_parent_node_id( 
>:p_nodeid, :p_parentnodeid ); 
>  END; 
> END OF STMT
> --> anon block gets parsed, it probably contains a
> sql.
> PARSE
>
#1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1617285502483
> --> Found the sql, so oracle opened another cursor
> #1 which is dependent on cursor #1 so dep = 1
> PARSING IN CURSOR #2 len=68 dep=1 uid=98 oct=3
> lid=98 tim=1617285503241 hv=1778717541 ad='606795e8'
> --> sql test
> SELECT PARENT_NAV_NODE_ID FROM NAV_NODE WHERE
> NAV_NODE_ID = :b1 
> END OF STMT
> --> Successful parsing of cursor #2
> PARSE
>
#2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503230
> --> Executing cursor #2
> EXEC
>
#2:c=0,e=151,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503563
> --> Fetch cursor #2
> FETCH
>
#2:c=0,e=40,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=1617285503648
> --> Data returned to anon block
> WAIT #1: nam='SQL*Net message to client' ela= 2
> p1=1413697536 p2=1 p3=0
> --> Now the anon block executes. the e time includes
> the time for all actions of cursor #2
> EXEC
>
#1:c=0,e=1037,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=1617285503786
> WAIT #1: nam='SQL*Net message from client' ela= 2470
> p1=1413697536 p2=1 p3=0
> 
> 
> Now, I'll just wait for Cary to come along and tell
> me that I got it all wrong ...
> 
> Happy Thanksgiving (or Turky Day)
> Raj

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: sql trace - recursive relationships

2003-11-25 Thread Boris Dali
Thanks for your reply, Daniel.

Yes, it makes sense for the EXEC calls, but it doesn't
explain the PARSEs, does it?

PARSING IN CURSOR #1 len=94 dep=0...
PARSE #1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0...
PARSING IN CURSOR #2 len=68 dep=1...
PARSE #2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1...

Here I presume elapsed time of the PL/SQL call is
141-60=81 microsec, but it doesn't follow the same
rule of parent db call following the recursive/child
one - it is out of sequence.

It is even more interesting with FETCHes. I can't seem
to find FETCH call for the parent anywhere in the
trace file. Maybe it makes sense to omit this call
altogether as time tallied against PL/SQL proc call
goes to EXEC anyway, but than again it breaks the
rule.

And no, I don't think it is a trace activation/data
collection error as these parent-child cursors appear
in the middle of the trace.

Thanks again,
Boris Dali.

 --- Daniel Fink <[EMAIL PROTECTED]> wrote: > Boris,
> 
> Cary is correct. It gets a little confusing,
> especially with pl/sql
> involved. It also helps to remember to differentiate
> between database
> calls (parse/execute/fetch) and other events
> (wait/stat).
> 
> Using your example below, I'll attempt an
> explanation inline.
> 
> Daniel Fink
> 
> Boris Dali wrote:
> 
> > Reading Cary's "Optimizing Oracle Performance",
> page
> > 91 it says:
> > "A database call with dep=n+1 is the recursive
> child
> > of the first SUBSEQUENT (empasis mine) dep=n
> database
> > call listed in the SQL trace data stream"
> >
> > Does this apply to the SQL issued from PL/SQL?
> >
> > I am looking at the simple packaged stored proc:
> >
> > PACKAGE BODY nav_tree_pkg is
> >   PROCEDURE GET_NAV_PARENT_NODE_ID
> >  ( p_NodeId IN NUMBER,
> >p_ParentNodeId OUT NUMBER)
> >  IS
> >   BEGIN
> >  SELECT PARENT_NAV_NODE_ID INTO p_ParentNodeId
> >  FROM NAV_NODE
> >  WHERE NAV_NODE_ID = p_NodeId;
> >   EXCEPTION
> >   WHEN NO_DATA_FOUND THEN
> >   p_ParentNodeId := -1 ;
> >   END; -- Procedure
> > END;
> >
> > ... and here's what I see in the trace (sorry the
> > lines are probably wrapped):
> >
> > =
> > PARSING IN CURSOR #1 len=94 dep=0 uid=83 oct=47
> lid=83
> > tim=1617285502494 hv=1138148843 ad='605d0998'
> > BEGIN nav_tree_pkg.get_nav_parent_node_id(
> >:p_nodeid,
> >:p_parentnodeid
> >  );
> >  END;
> >
> > END OF STMT
> > PARSE
>
#1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1617285502483
> >
> > BINDS #1:  bind 0: dty=2 mxl=22(22) mal=00 scl=00
> pre=00
> > oacflg=01 oacfl2=0 size=48 offset=0
> >bfp=83fbc005ff80 bln=22 avl=01 flg=05
> >value=0
> >  bind 1: dty=2 mxl=22(22) mal=00 scl=00 pre=00
> > oacflg=01 oacfl2=0 size=0 offset=24
> >bfp=83fbc005ff98 bln=22 avl=00 flg=01
> > =
> 
> Here, the pl/sql block is parsed. The next step in
> the statement process
> is to execute the statement (parse/execute/fetch).
> However, notice that
> EXEC #1 is not the next database call.
> 
> >
> > PARSING IN CURSOR #2 len=68 dep=1 uid=98 oct=3
> lid=98
> > tim=1617285503241 hv=1778717541 ad='606795e8'
> > SELECT PARENT_NAV_NODE_ID FROM NAV_NODE
> >  WHERE NAV_NODE_ID = :b1
> > END OF STMT
> > PARSE
>
#2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503230
> > BINDS #2:
> >  bind 0: dty=2 mxl=22(21) mal=00 scl=00 pre=00
> > oacflg=03 oacfl2=4001 size=24 offset=0
> >bfp=83fbc005f660 bln=22 avl=01 flg=05
> >value=0
> 
> Okay, here we parse the sql statement inside the
> block. In the next
> couple of db calls, we do the execute/fetch of
> Cursor #2.
> 
> >
> > EXEC
>
#2:c=0,e=151,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503563
> > FETCH
> >
>
#2:c=0,e=40,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=1617285503648
> > WAIT #1: nam='SQL*Net message to client' ela= 2
> > p1=1413697536 p2=1 p3=0
> > EXEC
>
#1:c=0,e=1037,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=1617285503786
> 
> Here is the execute database call for the block. It
> is the execution of
> the block that motivates the parse/execute/fetch of
> the inner statement.
> 
> >
> > WAIT #1: nam='SQL*Net message from client' ela=
> 2470
> > p1=1413697536 p2=1 p3=0
> > =
> > ... Totaly different calls
> > =
> >
> > So here it looks like th

Re: sql trace - XCTEND rlbk=1, rd_only=1

2003-11-25 Thread Boris Dali
Thanks, Jared, Tanel.

I was a little supprised to see a combination
rlbk=1,rd_only=1. Why read-only bit is set here if it
rolls back anyway? 
So I thought may be they mark their tx explicitly as
read-only (aka "set transaction read-only"). Reveiwing
OCI fine manual there seemed to be an option of doing
just that with the OCITransStart() call and setting
some flags...

But than simple test-case of tracing commit and
rollback in SQL*Plus disproved the theory about
read-only tx, as "normal" commit/rollback produce this
combination regardless of the tx type:

commit   -   XCTEND rlbk=0, rd_only=1
rollback -   XCTEND rlbk=1, rd_only=1

set transaction read only

commit   -   XCTEND rlbk=0, rd_only=1
rollback -   XCTEND rlbk=1, rd_only=1

So much for my theory :-(


Another question I had here is whether or not having
so many (implicit?) rollbacks on about every SELECT
statement all over my trace file bears any overhead
and proves deficiency of a stateless architecture used
by this application - but again reviewing v$sesstat
before and after I see user rollbacks count
incremented, but no additional redo vectors generated.
I guess I can try Tom Kyte's test harness, but it just
doesn't sit well with me that 30 selects are as cheap
as 30 selects with 30 rollbacks.

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


sql trace - recursive relationships

2003-11-24 Thread Boris Dali
Reading Cary's "Optimizing Oracle Performance", page
91 it says:
"A database call with dep=n+1 is the recursive child
of the first SUBSEQUENT (empasis mine) dep=n database
call listed in the SQL trace data stream"

Does this apply to the SQL issued from PL/SQL?

I am looking at the simple packaged stored proc:

PACKAGE BODY nav_tree_pkg is
  PROCEDURE GET_NAV_PARENT_NODE_ID
 ( p_NodeId IN NUMBER,
   p_ParentNodeId OUT NUMBER)
 IS
  BEGIN
 SELECT PARENT_NAV_NODE_ID INTO p_ParentNodeId
 FROM NAV_NODE
 WHERE NAV_NODE_ID = p_NodeId;
  EXCEPTION
  WHEN NO_DATA_FOUND THEN
  p_ParentNodeId := -1 ;
  END; -- Procedure
END;

... and here's what I see in the trace (sorry the
lines are probably wrapped):

=
PARSING IN CURSOR #1 len=94 dep=0 uid=83 oct=47 lid=83
tim=1617285502494 hv=1138148843 ad='605d0998'
BEGIN nav_tree_pkg.get_nav_parent_node_id( 
   :p_nodeid,  
   :p_parentnodeid 
 ); 
 END; 

END OF STMT
PARSE
#1:c=0,e=141,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=1617285502483
BINDS #1:
 bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00
oacflg=01 oacfl2=0 size=48 offset=0
   bfp=83fbc005ff80 bln=22 avl=01 flg=05
   value=0
 bind 1: dty=2 mxl=22(22) mal=00 scl=00 pre=00
oacflg=01 oacfl2=0 size=0 offset=24
   bfp=83fbc005ff98 bln=22 avl=00 flg=01
=
PARSING IN CURSOR #2 len=68 dep=1 uid=98 oct=3 lid=98
tim=1617285503241 hv=1778717541 ad='606795e8'
SELECT PARENT_NAV_NODE_ID FROM NAV_NODE
 WHERE NAV_NODE_ID = :b1
END OF STMT
PARSE
#2:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503230
BINDS #2:
 bind 0: dty=2 mxl=22(21) mal=00 scl=00 pre=00
oacflg=03 oacfl2=4001 size=24 offset=0
   bfp=83fbc005f660 bln=22 avl=01 flg=05
   value=0
EXEC
#2:c=0,e=151,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=1617285503563
FETCH
#2:c=0,e=40,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=1617285503648
WAIT #1: nam='SQL*Net message to client' ela= 2
p1=1413697536 p2=1 p3=0
EXEC
#1:c=0,e=1037,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=1617285503786
WAIT #1: nam='SQL*Net message from client' ela= 2470
p1=1413697536 p2=1 p3=0
=
... Totaly different calls
=

So here it looks like the child CURSOR #2 with dep=1
is emitted AFTER the parent (CURSOR #1, dep=0)

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


sql trace - XCTEND rlbk=1, rd_only=1

2003-11-24 Thread Boris Dali
I've got a third party package that connects to Oracle
via OCI and works in HTTP-like (stateless) fashion.
Reviewing raw SQL trace output I don't see a single
commit or rollback there, but there are plenty of
XCTEND tx markers with rlbk=1 (after about every
SELECT statement). Is this normal? Does this mean that
this app rollbacks (implicitly?) after each  of those
selects?

Thanks,
Boris Dali.

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: Redos gone crazy--a job for audit?

2003-10-10 Thread Boris Dali
Igor,

Try running the following test:

create table t6 (i int) ;

create global temporary table t7 (i int) on commit
delete rows;

select value from v$mystat m, v$statname s 
where m.statistic#=s.statistic# and s.name = 'redo
size';

--> Note the value here

insert into t6 select obj# from sys.obj$ where rownum
<= 1;

commit;

select value from v$mystat m, v$statname s 
where m.statistic#=s.statistic# and s.name = 'redo
size';

--> Compare the two. In my case it's almost 10-fold
increase in the amount of redo generated.

We ran into this not too long ago. Bug# 2874489. Fixed
in 10.1.0.1 with some backports available for
9.2.0.3/4 on **some** platforms

Note: Bug above doesn't affect direct path load

Thanks,
Boris.

 --- Igor Neyman <[EMAIL PROTECTED]> wrote: >
Why?
> Did you have bad experiences with temp tables?
> I thought, using temp tables should reduce amount of
> redo.
> 
> Igor Neyman, OCP DBA
> [EMAIL PROTECTED]
> 
> 
> 
> -Original Message-
> Boris Dali
> Sent: Friday, October 10, 2003 12:54 PM
> To: Multiple recipients of list ORACLE-L
> 
> Barbara,
> 
> Shoot in the dark. Any chance last vendor upgrade
> introduced global temporary tables?
> 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: Redos gone crazy--a job for audit?

2003-10-10 Thread Boris Dali
Barbara,

Shoot in the dark. Any chance last vendor upgrade
introduced global temporary tables?

 --- Daniel Fink <[EMAIL PROTECTED]> wrote: > Barb,
> 
> Even if you can't find the user, you can still find
> the session info and
> run a trace on the session. If it is consistent, you
> should be able to
> trace for a short amount of time and retrieve the
> statements that are
> generating redo. Then you can go back to the vendor
> and say "This
> statement (update emp set empno = empno) is
> generating 3g of redo per
> day and it is not performing any work. Please
> consider this a P1 bug and
> we need a fix in 10 days." It is especially valuable
> if you can trace
> the 'old-good' app and compare it with the 'new-bad'
> app.
> 
> Dan
> 
> Barbara Baker wrote:
> 
> > Dan:
> > Thanks for this -- I'll definitely tuck this away
> for
> > future reference.
> >
> > Sadly, it's not going to help this time.  I don't
> have
> > a user generating redo, I have an application
> running
> > amuck.
> >
> > The users (reporters) never log into the database.
> > Some service (Solaris high availability service, I
> > believe) logs a database user on 20 times, then
> > buffers requests from the HA service to the
> database.
> >  A minute or two later, it logs the 20 sessions
> out
> > and logs in 20 more.
> >
> > Between around 5:30 am and 3:00 am the following
> day,
> > the database is rolling a new redo log about every
> 16
> > minutes.  Pretty much new log file every 16
> minutes
> > like clockwork.   Between 3:00 and 5:30, the HA
> > service is disabled and some kind of maintenance
> is
> > running.  The entire database is about 4100 megs.
> > We're generating more than 3 gigs of redo per day.
> >
> > I sure would like to know what's in those redo
> logs.
> >
> > Thanks for the help!
> > Looks like another beautiful weekend to hang out
> on
> > top of a mountain.  Did you get to see the leaves
> > turning this year??
> >
> > Barb
> > begin:vcard 
> n:Fink;Daniel
> x-mozilla-html:FALSE
> org:Sun Microsystems, Inc.
> adr:;;
> version:2.1
> title:Lead, Database Services
> x-mozilla-cpt:;9168
> fn:Daniel  W. Fink
> end:vcard
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: Copying statistics : used a lot ????

2003-09-21 Thread Boris Dali
What a timely thread! We've been discussing this very
issue back and forth for some time now in our
organization.

We are getting a new application, which presumably
will run on something like lower-end Superdome 16-way,
~30GB RAM type of box. The question is whether 4-way,
4GB RAM Rp5470 (entry-level) will do as a test server
or it should be a "close mirror" of the production
one?

The argument of those against a "similar to a Prod
box" is simple: "Can't afford another one for this
project. Don't you know how to use dbms_stats to
convince CBO it's on Superdome with 16 CPUs and
millions of rows of data and not on a 4-way, couple of
thousands in row sources?" 

So if we "can't afford" what Raj describes - is a
smaller server a viable solution for a test box? Or we
have to convince damanagement that their "can't
afford" is going to cost them more in the long run?
(easlier said than done)

---

As Cris mentioned I've read Tom's take on this, but it
only confused me futher. Tom states:
"Some people adopt the strategy of importing the prod
statistics ... and think they can get optimizer to
generate the plans that will be used in prod and test
using that data ... That approach will work only if
you can read a query plan and be 100% confident that
the plan is good and will give subsecond response
times ... I don't think I can make such a judgment
call..."

I don't follow. Does this imply that with importing
stats we can't get 100% identical CBO
decisions/executions plans in a DB on a smaller
machine? Or is it that we have to be 100% confident
that we "replicated" all the stats from Prod and it is
not a simple task? Or something else?

"... Most people are striving to get query plans that
use indexes all of the time, without realizing that as
you scale up, indexes may not be the best solution
..."

This part I understood even less. After reading Cary's
excellent paper on scalability I thought that O(n)
type of scalability of FTS is worse than say O(log2,
n) of IRS? 
Wouldn't it be correct to say than, that if today on a
thousand row tables I get index access path delivering
better response time that table scan, I can expect
this to stay the same (or better) when my data gets to
a million rows range?
Is it the scalability of NL vs HJ Tom is taking about?
Bitmap/Domain indexes? Or is it a "general" statement?

"... This is not to say that ... import statistics is
not very useful. Quite the contrary - I've seen people
use (with great success) the ability to import/export
statistics, but ***not to tune in test***. Instead
they take the results of statistics gathering done in
test and import into production! Quite the reverse of
what most people initially consider using dbms_stats
for..."

The last remark certainly applies to me. With all due
respect to Tom, I got only more confused ater reading
the above. Can somebody enlighten me?

TIA,
Boris Dali.

 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > Our production
and test systems are same ... test
> lags 24 hours behind
> production that's all. But I have successfully used
> dbms_stats to copy over
> stats from production to test on a table by table
> basis to verify explain
> plans.
> 
> My opinion WAD - Works as designed ... remember to
> take a backup of existing
> stats on test in a separate table so you can reload
> them when needed
> quickly.
> 
> My experience is on 9ir2 only for this feature.
> Raj
>

> 
> Rajendra dot Jamadagni at nospamespn dot com
> All Views expressed in this email are strictly
> personal.
> QOTD: Any clod can have facts, having an opinion is
> an art !
> 
> 
> -Original Message-
> Sent: Friday, September 12, 2003 10:29 AM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Well no, I have bought the Expert one on one book.
> I check on his web site and I found one reference
> where he addresses the use
> of changing the stats.
> 
> Usually you can find what is its opinion just by the
> tone, but this time I
> was not able to see if he's against or not on this.
> 
> Can you share more of what's in the book ?
> 
> 
> Stephane Paquette
> Administrateur de bases de donnees
> Database Administrator
> Standard Life
> www.standardlife.ca
> Tel. (514) 499-7999 7470 and (514) 925-7187
> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> -Original Message-
> Grabowy, Chris
> Sent: Thursday, September 11, 2003 5:44 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> By chance, do you have Tom Kyte's latest book? 
> Effective Oracle by Desig

RE: Copying statistics : used a lot ????

2003-09-21 Thread Boris Dali
What a timely thread! We've been discussing this very
issue back and forth for some time now in our
organization.

We are getting a new application, which presumably
will run on something like lower-end Superdome 16-way,
~30GB RAM type of box. The question is whether 4-way,
4GB RAM Rp5470 (entry-level) will do as a test server
or it should be a "close mirror" of the production
one?

The argument of those against a "similar to a Prod
box" is simple: "Can't afford another one for this
project. Don't you know how to use dbms_stats to
convince CBO it's on Superdome with 16 CPUs and
millions of rows of data and not on a 4-way, couple of
thousands in row sources?" 

So if we "can't afford" what Raj describes - is a
smaller server a viable solution for a test box? Or we
have to convince damanagement that their "can't
afford" is going to cost them more in the long run?
(easlier said than done)

---

As Cris mentioned I've read Tom's take on this, but it
only confused me futher. Tom states:
"Some people adopt the strategy of importing the prod
statistics ... and think they can get optimizer to
generate the plans that will be used in prod and test
using that data ... That approach will work only if
you can read a query plan and be 100% confident that
the plan is good and will give subsecond response
times ... I don't think I can make such a judgment
call..."

I don't follow. Does this imply that with importing
stats we can't get 100% identical CBO
decisions/executions plans in a DB on a smaller
machine? Or is it that we have to be 100% confident
that we "replicated" all the stats from Prod and it is
not a simple task? Or something else?

"... Most people are striving to get query plans that
use indexes all of the time, without realizing that as
you scale up, indexes may not be the best solution
.."

This part I understood even less. After reading Cary's
excellent paper on scalability I thought that O(n)
type of scalability of FTS is worse than say O(log2,
n) of IRS? 
Wouldn't it be correct to say than, that if today on a
thousand row tables I get index access path delivering
better response time that table scan, I can expect
this to stay the same (or better) when my data gets to
a million rows range?
Is it the scalability of NL vs HJ Tom is taking about?
Bitmap/Domain indexes? Or is it a "general" statement?

"... This is not to say that ... import statistics is
not very useful. Quite the contrary - I've seen people
use (with great success) the ability to import/export
statistics, but ***not to tune in test***. Instead
they take the results of statistics gathering done in
test and import into production! Quite the reverse of
what most people initially consider using dbms_stats
for..."

The last remark certainly applies to me. With all due
respect to Tom, I got only more confused ater reading
the above. Can somebody enlighten me?

TIA,
Boris Dali.

 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > Our production
and test systems are same ... test
> lags 24 hours behind
> production that's all. But I have successfully used
> dbms_stats to copy over
> stats from production to test on a table by table
> basis to verify explain
> plans.
> 
> My opinion WAD - Works as designed ... remember to
> take a backup of existing
> stats on test in a separate table so you can reload
> them when needed
> quickly.
> 
> My experience is on 9ir2 only for this feature.
> Raj
>

> 
> Rajendra dot Jamadagni at nospamespn dot com
> All Views expressed in this email are strictly
> personal.
> QOTD: Any clod can have facts, having an opinion is
> an art !
> 
> 
> -Original Message-
> Sent: Friday, September 12, 2003 10:29 AM
> To: Multiple recipients of list ORACLE-L
> 
> 
> Well no, I have bought the Expert one on one book.
> I check on his web site and I found one reference
> where he addresses the use
> of changing the stats.
> 
> Usually you can find what is its opinion just by the
> tone, but this time I
> was not able to see if he's against or not on this.
> 
> Can you share more of what's in the book ?
> 
> 
> Stephane Paquette
> Administrateur de bases de donnees
> Database Administrator
> Standard Life
> www.standardlife.ca
> Tel. (514) 499-7999 7470 and (514) 925-7187
> [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> -Original Message-
> Grabowy, Chris
> Sent: Thursday, September 11, 2003 5:44 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> By chance, do you have Tom Kyte's latest book? 
> Effective Oracle by Design??
&

RE: selectivity of predicates with LIKE - diff between 8i and 9i

2003-06-11 Thread Boris Dali
Aha, just come accross note 94051.1 explaining
_LIKE_WITH_BIND_AS_EQUALITY... but it's probably not
relevant in my case as my query doesn't make use of
bind variables. And yes I tried it (at the session
level) just for kicks with no effect on the execution
plan

Thanks anyway,
Boris Dali.



__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: selectivity of predicates with LIKE - diff between 8i and 9i

2003-06-11 Thread Boris Dali
Thanks, KG

No, CURSOR_SHARING is not set (meaning it defaults to
EXACT on both 8i and 9i)

No bind variables. The query given with ... LIKE
'LOVE%' is the real one

Yes, I can try setting _LIKE_WITH_BIND_AS_EQUALITY.

One additional piece of info - we don't have
OPTIMIZER_INDEX_* parameter set on eigher one (I
should re-read Tim's excellent paper). It would
probably be a safer bet to change "supported"
parameters first (after understanding what is
different in 9i that is), but I am not sure what
effect it might have on the rest of the app.

Cheers,
Boris.

 --- K Gopalakrishnan <[EMAIL PROTECTED]> wrote: > By
any chance are you using CURSOR_SHARING parameter
> in your 8i version?
> I think the default selectivity of 5% is used while
> costing the like
> operator and with the binds (and with an underscore
> parameter which
> I think defaults TRUE) it is treated as equality .
> 
> If not you can set the underscore parameter
> _like_with_bind_as_equality to get the index
> costing.
> 
> KG

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


selectivity of predicates with LIKE - diff between 8i and 9i

2003-06-11 Thread Boris Dali
Dear List,

Is there any difference between 8i and 9i in how
selectivity of the predicates with LIKE are estimated
by CBO?
We are migrating some apps running on 8.1.7.4 on HP-UX
11.0 into 9.2.0.3 on the same box and some queries
choose completely different execution plans - HJ with
FTS vs original NL with IRS.
After simplifying the real query to a primitive
one-liner it looks like predicates with LIKE are
estimated differently in 9i:

[EMAIL PROTECTED]> @target

  COUNT(1)
--
   291

[EMAIL PROTECTED]> l
  1*  select  count(1) from DIS_TAB_ALBUM_TITRE ALT
where ALT.ait_ds_titre LIKE 'LOVE%'

-- 8i:
[EMAIL PROTECTED]> @explain8

  Id  ParCSTCDN Plan
  -- --
-
   0   3  1   SELECT STATEMENT
(choose) Cost (3,1,20)
   10 1 SORT   
(aggregate)
   21  3  2   INDEX (analyzed)
NON-UNIQUE OPS$DEVDIS0 DIS_IND_ALBUM_TITRE_1 (range
scan)  Cost (3,2,40)

-- 9i:
[EMAIL PROTECTED]> @explain8

  Id  ParCSTCDN Plan
  -- --
---
   0  39  1   SELECT STATEMENT
(choose) Cost (39,1,19)
   10 1 SORT   
(aggregate)
   21 39   8415   INDEX (analyzed)
NON-UNIQUE OPS$DEVDIS0 DIS_IND_ALBUM_TITRE_1 (range
scan) (Columns 1  Cost (39,8415,159885)


-- 8i:
  Access path: index (index-only)
  INDEX#: 307169  TABLE: DIS_TAB_ALBUM_TITRE
(obj_id=307169 -> DIS_IND_ALBUM_TITRE_1)
  CST: 3  IXSEL:  6.2017e-06  TBSEL:  6.2017e-06
...
  BEST_CST: 3.00  PATH: 4  Degree:  1


-- 9i:
  Access path: index (index-only)
  Index: DIS_IND_ALBUM_TITRE_1
  TABLE: DIS_TAB_ALBUM_TITRE
  RSC_CPU: 0   RSC_IO: 39
  IX_SEL:  3.4877e-02  TB_SEL:  3.4877e-02
...
  BEST_CST: 39.00  PATH: 4  Degree:  1




In 8i assuming a filter factor to be simply 1/NDV, CST
is understandably equals to 3 (given the data below):

  INDEX#: 307169  COL#: 3 
TOTAL ::  LVLS: 2   #LB: 1035  #DK: 161254  LB/K:
1  DB/K: 1  CLUF: 204303

Column: AIT_DS_TIT  Col#: 3  Table:
DIS_TAB_ALBUM_TITRE   Alias: ALT
NDV: 161254NULLS: 0 DENS: 6.2014e-06
  TABLE: DIS_TAB_ALBUM_TITRE ORIG CDN: 241286 
CMPTD CDN: 2


IRS CST= blevel+ff*lb+ff*cf=2 + 6.2*10^-6 * (1035 +
204303) ~ 3.3 -> 3


But in 9i CBO probably uses something else as a FF for
this predicate with LIKE, since CST becomes 39:

  INDEX NAME: DIS_IND_ALBUM_TITRE_1  COL#: 3 
TOTAL ::  LVLS: 2   #LB: 1035  #DK: 161254  LB/K:
1  DB/K: 1  CLUF: 204338

Column: AIT_DS_TIT  Col#: 3  Table:
DIS_TAB_ALBUM_TITRE   Alias: ALT
NDV: 157906NULLS: 0 DENS: 6.3329e-06
NO HISTOGRAM: #BKT: 1 #VAL: 2
  TABLE: DIS_TAB_ALBUM_TITRE ORIG CDN: 241286 
ROUNDED CDN: 8415  CMPTD CDN: 8415

IRS CST= ??? = 39

Questions:
1) Does anybody know what CBO uses for a FF
calcualation for predicates with LIKE in 9i? How does
it get 39?
2) Is there a simple way to get it "back on track" to
CST=2 without hints or stored outlines - some spfile
parameter would be ideal?
3) Both computed cardinalities seem to be way off (2
in 8i, 8415 in 9i - while the real number of rows
returned is 291).
   Would histograms be the right way to get CMPTD CDN
closer to the reality in this case?


Not sure if it's important, but we are using automatic
PGA management here (worksize_policy_area is TRUE,
pga_aggreagate_target is a 100M)

Thanks for any help,
Boris Dali.


__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-09 Thread Boris Dali
Mogens, Dennis,

I know I am going to catch flames for this, but here
goes:

It seems to be quite fashionable to bash statspack,
but help me out in understanding the alternatives to
the StatsPack in the following cases:

Case1:
-
At the client I am currently with, they have some 50+
applications. Performance is generally not an issue.
Can things be optimized? Oh yeah. No doubt about it.
Users don't complain though and 3-person DBA team
focuses on operational/prod. support stuff.

3 weeks ago applcation support person took one of the
applications "offline" and submitted a job to rebuild
the indexes (this functionality is built into the
app). DBA team wasn't obviously consulted as to
whether or not it's of any benefit. In fact DBA team
wasn't even aware that there's a maintenance activity
going on :-(

Job dutifully dropped the indexes (as it doesn't seem
to be aware of rebuilding, not to mention rebuilding
online etc), but got stuck somewhere on re-creating
them... so next morning app support person realized
that there's a problem and recalled that there is a
DBA team "that probably messed up his DB" (from his
response to the ticket).

For DBA it didn't take long to see that what used to
be a quick index lookup returning a single row, turned
out to be a FTS on a 3mln row table as index wasn't
re-created there. But...
If OS and StatsPack monitoring was in place DBA would
know that long before app support person showed up as
iostat -nmxzP on Solaris (or even iostat -d -x on
Linux) with StatsPack data (or something as simple as
query comparing current v$filestat with baseline one)
would be self evident that things changed.

Utility to check execution plans against the baseline
ones would be probably useful in this case, but I
haven't heard about it before this thread :-)

Case2:
--
Application benchmarking.
Last summer while with another client, DBA team was
asked to monitor the newly purchased system in stress
testing/sizing exercise. While not explicitely stated
two additional objectves were to verify the
scalability of the app with respect to the number of
concurrent users as well as the data volumes.
Mercury tools were used in colloboration with the
StatsPack on the back-end. We couldn't get more than
some 120 concurrent users and StatsPack clearly
indicated the load profile w/ ~500,000 LIOs/sec, only
~50 KB/sec redo generation, 300:1 read:write ratio,
with latch free being by far the most prominent wait
event.
This case is probably an extreme, but when the support
engineers of the product received our
Mercury/StatsPack report there was no doubt that "SQL
needs to be revisited"


The point I am trying to make is that I think there's
monitoring for the sake of tuning (and than I agree -
system wide data shouldn't probably drive the tuning
effort). But there's also other types of monitoring
where StatsPack seems to be quite useful to me. It all
depends on the objectives.

Cheers,
Boris Dali.

 --- Mogens_Nørgaard <[EMAIL PROTECTED]> wrote: >
Couldn't agree more. We need to stop using StatsPack
> for gathering lots 
> and lots of stats we can't use for anything anyway.
> When two experts can 
> look at the same summary data and get to different
> conclusions you're 
> not gathering data at the correct level. It's sort
> of like the 
> economists that will study the reams of data about
> GDP, GDI, money 
> supply 1 thru 6, and what have you - and arrive at
> complete opposite 
> conclusions. Same with bstat/estat, StatsPack, our
> own MirMon, etc.
> 
> Mogens
> 
> DENNIS WILLIAMS wrote:
> >Boris - I'm not surprised in your results


______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-09 Thread Boris Dali
Nice one, John!
And quite portable. Runs on Solaris and Linux alike.
On HP-UX 11.0 I had to modify it slightly, but it
looks good too:

if [ $# -eq 1 ] ;then
  UNIX95= ps -eo pid,pcpu,ruser,time,etime,args | grep
$1 | sort -nr +1 | awk '{if (NR <= 20) print
substr($0,1,80)}'
else
  same as above wo/ grep
fi


I usually used BSD stile of ps on Linux. Something
like:
 ps aufx | egrep '(USER|oracle)'
with exporting COLUMNS=200 prior to running this and
stiking the puppy into an alias. But sorting by %CPU
looks cool. (Solaris doesn't seem to understand the f
flag and it should be /usr/ucb/ps, not default
/usr/bin/ps)


Ok, back to the original issue :-)
Since snapshot causes 100% CPU util only for some 3
sec it was quite a challenge to catch it. The best I
got so far is 72% for the shadow process taking the
snapshot (after some 20 tries). I should probably put
it in an infinite loop and "spool" (or tee) it to a
file. Might as well try to catch /proc/pid/status (as
I don't have the luxury of pmap here on Linux) for
some memory stuff.

One thing, John. Since it doesn't split CPU
utilization into user and kernel buckets - how does
this help me? Wouldn't it be nice to get output
similar to ptime [or at least time(x)] in "ps" output?

I am thinking of taking Dennis's advice and see what
happens with level=0 or simply start commenting out
code in the package and see when high CPU utilization
drops (and I was hopping to go with level=7 to get
some segement stats - he-he)

Thanks, John.

Cheers,
Boris Dali.


 --- John Kanagaraj <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> Nice to discuss this with someone who understands
> the numerous (and various)
> options of 'sar' :)  I use 'sar -r' to cross verify
> the 'rate of need for
> swap' - a sudden increase may mean either bursts of
> I/O (eating up File
> buffer space), memory leaks or a sudden rush of
> programs Could you take
> a quick snapshot of the top 20 CPU consumers using
> the script below when the
> snapshot runs? It takes the SID as a parameter to
> grep out only Oracle
> processes for that SID. The interesting part is that
> the CPUTIME *and*
> ELAPSED time is shown - you should run the snapshot
> as a script (as in
> sqlplus perfstat/ @snapshot.sql) where
> snapshot.sql has an execute,
> followed by an exit. This way, one has a crude set
> of CPU and Elapsed time
> for that process as it runs...
> 
> I use this to quickly point out processes that are
> heavy and consistent CPU
> consumers, allowing me to rap some knuckles ;-)
> 
> #!/bin/ksh
> #
> #  Name:  top20.ksh
> #  Purpose:   Display the top 20 CPU consumers.
> Specify a SID to collect
> # only those top procs related to that
> SID in a multi-db system
> #  Author:John Kanagaraj, DBSoft Inc/ Aug 2001
> #  Notes: Tested and works on Solaris - may need
> adjustment for other OS
> #
> uptime
> echo "PID   %CPURUSER CPUTIME ELAPSED
> COMMAND"
> if [ $# == 1 ]; then
> ps -eo pid,pcpu,ruser,time,etime,args | grep
> $1 | sort -nr +1  |
> head -20 | awk '{print substr($0,1,80)}'
> else
> ps -eo pid,pcpu,ruser,time,etime,args | sort
> -nr +1  | head -20 |
> awk '{print substr($0,1,80)}'
> fi
> 
> John Kanagaraj
> Oracle Applications DBA
> DBSoft Inc
> (W): 408-970-7002
> 
> Great, uplifting music - http://www.klove.com
> 
> ** The opinions and statements above are entirely my
> own and not those of my
> employer or clients **

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-06 Thread Boris Dali
Thanks, John.

No there's no paging/swapping going on (1GB real
memory for a single 200MB SGA and just a couple of
users). 

Out of curiousity, John. I usually measure paging via
vmstat (si/so columns on Linux and pi/po everywhere
else - "everywhere else" being HP-UX, Solaris and
AIX), as well as via sar -w (swpin/s, swpot/s) on
HP-UX/Solaris and sar -W on Linux (pswpin/s,
pswpot/s).

Is sar -r a better way? 

Quick check shows that on Linux it seems to report
memory and swap utilization (but not in terms of
rates, rather absolute numbers). On HP-UX it doesn't
seem to be covered by man pages, but effectively the
output is the same as -w. On Solaris it shows "unused
memory pages and disk blocks". And I don't currently
have any IBM boxes around


As for the wrong bucket... well, I'll be able to
verify it in the next couple of weeks on Solaris and
for sure on HP-UX. One thing I know is that both
vmstat and sar -u agree here on Mandrake that it is
the kernel-mode that chews up most of the CPU for this
3-4 sec snapshot time.

Thanks,
Boris Dali.


 --- John Kanagaraj <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> I missed the second part of your question...
> apologies. If your SGA/Shared
> pool was partly swapped out, I would assume that you
> might see an increased
> 'system' utilization. Did you check 'sar -q' and
> 'sar -r' at the same time
> to check? I haven't used mandrake - just wondering
> if the CPU cycles used
> for memory access are being counted against the
> wrong pigeonhole..
> 
> John Kanagaraj
> Oracle Applications DBA
> DBSoft Inc
> (W): 408-970-7002
> 
> Grace - Getting something we don't deserve; Mercy -
> NOT getting something we
> deserve
> Click on 'http://www.needhim.org' for Grace and
> Mercy that is freely
> available!
> 
> ** The opinions and statements above are entirely my
> own and not those of my
> employer or clients **

______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-06 Thread Boris Dali
Thanks, Dennis. I am with you on your point about GUI
tools...

 --- DENNIS WILLIAMS <[EMAIL PROTECTED]> wrote:
> Boris - I think John has an excellent point (as
> always). I just remembered
> that one vendor (can't recall which) has some sort
> of "stealth" method to
> directly sample the SQL buffer. They make a big deal
> about how it doesn't
> impact your system, so I would infer as John says
> that with a large shared
> pool this might be significant.
>My point is to just collect the information that
> is of value to you. If a
> level 0 gets you everything you need, go with that.
> When I suggest writing
> your own routines, I'm not proposing that you could
> collect all the
> information STATSPACK collects more efficiently, but
> if you only use one or
> two pieces of information and you need a level 5
> snapshot to get it, then
> you might consider a quick script to collect just
> what you need. Also if you
> need frequent snapshots to capture certain critical
> data, you can avoid some
> snapshots.
>CPU cycles are meant to be used, so if snapshots
> aren't affecting your
> overall system, then what is the problem? Well,
> unfortunately you would like
> to collect statistics when the system is the
> busiest.
>I find STATSPACK to be the most useful when the
> system appears "hung".
> With the GUI tools you are still clicking screens
> when the problem clears
> itself up. You can take a couple of STATSPACK
> snapshots and do damage
> control on the people side in between. But man are
> those snapshots SLW
> when the system is about belly up.
> 
> Dennis Williams
> DBA, 80%OCP, 100% DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED] 

______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-06 Thread Boris Dali
Thanks, John.

Any insight as to why is it primarily the system mode
CPU? I've seen high system mode CPU utilization in
non-Oracle stuff (like NFS), but for Oracle I thought
it should be primarily user mode?

Does Oracle's "CPU used by this session" represents
user-, kernel-mode or both? And what about "c" in the
raw traces?

Thanks John,
Boris Dali.

 --- John Kanagaraj <[EMAIL PROTECTED]> wrote: >
Boris,
> 
> The default statspack snapshot is at level 5, which
> collects Top SQL (by
> buffer and Phys reads, etc.) from the Shared pool,
> and that would cause
> significant latching for a large shared pool which
> in turn results in a high
> CPU usage. You could try a level 0 snapshot and look
> at the CPU utilization
> at that time...
> 
> John Kanagaraj
> Oracle Applications DBA
> DBSoft Inc
> (W): 408-970-7002
> 
> Disappointment is inevitable, but Discouragement is
> optional! 
> 
> ** The opinions and statements above are entirely my
> own and not those of my
> employer or clients **
> 
> 
> > -Original Message-
> > From: Boris Dali [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, June 05, 2003 2:05 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: statspack snapshots cause 3-4 sec of 100%
> CPU utilization
> > 
> > 
> > As subject line indicates standard (level 5)
> snapshots
> > make "vmstat 1" or "sar  -u 1 100"  show 100% CPU
> > utilization (75% system mode) for about 3 seconds.
> > 
> > Is this normal? Is statspack that brutal on CPU?
> And
> > why would that be a system mode primarily?
> > 
> > Environment:
> > 
> > Oracle 9.2.0.2 on Mandrake 9.0
> > (2.4.19-16mdkenterprise)
> > 2.4GHz uniprocessor P4 box, 1GB SDRAM
> > 
> > TIA,
> > Boris Dali.
> > 
> > 
> >
>
__
> >  
> > Post your free ad now! http://personals.yahoo.ca
> > -- 
> > Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> > -- 
> > Author: Boris Dali
> >   INET: [EMAIL PROTECTED]
> > 
> > Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> > San Diego, California-- Mailing list and
> web hosting services
> >
>
-
> > To REMOVE yourself from this mailing list, send an
> E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB
> ORACLE-L
> > (or the name of mailing list you want to be
> removed from).  You may
> > also send the HELP command for other information
> (like subscribing).
> > 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: John Kanagaraj
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-06 Thread Boris Dali
As subject line indicates standard (level 5) snapshots
make "vmstat 1" or "sar  -u 1 100"  show 100% CPU
utilization (75% system mode) for about 3 seconds.

Is this normal? Is statspack that brutal on CPU? And
why would that be a system mode primarily?

Environment:

Oracle 9.2.0.2 on Mandrake 9.0
(2.4.19-16mdkenterprise)
2.4GHz uniprocessor P4 box, 1GB SDRAM

TIA,
Boris Dali.


__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


RE: statspack snapshots cause 3-4 sec of 100% CPU utilization

2003-06-06 Thread Boris Dali
Thanks, Dennis.

I've been using statspack for quite some time now, but
I've never bothered to ask myself an obvious question,
namely what overhead does statspack impose on the
system (taking about Heisenberg's principle of
uncertainty, he-he)
I guess part of the reason is the fact that
statspack.snap returns prompt almost immediately so I
sort of subconsciously assumed that it's ... "light"
in terms of resource consumption.

Thanks for the suggestion to write my own routines,
but I don't think I'll go down this route. It's true
that it's probably not too difficult as the statspack
schema is pretty much self explanatory with RI
constarints in place and besides (supprisingly)
statspack package is not wrapped, but ... With every
new release/feature you'll need to keep pace, which
doesn't sound like fun to me. With standard
out-of-the-box statspack you get it for free (stuff
like segment stats in 9i statspack)

Thanks again,
Boris Dali.


 --- DENNIS WILLIAMS <[EMAIL PROTECTED]> wrote:
> Boris - I'm not surprised in your results. I
> wouldn't describe STATSPACK as
> "brutal", but it is a significant hit, so you
> wouldn't want to start doing
> snaps at 1 second intervals. STATSPACK does collect
> a LOT of data, and you
> can adjust the amount of data collected with the
> level if you feel the need
> to reduce the brutality. If you find you only need a
> few pieces of
> information, you could write your own routines to
> collect just what you
> need.
>I have no idea why your system mode sees an
> impact. Perhaps someone who
> has more systems experience can venture a guess. You
> might try several
> measurements just in case you caught the system at a
> bad moment. 
> 
> Dennis Williams
> DBA, 80%OCP, 100% DBA
> Lifetouch, Inc.
> [EMAIL PROTECTED] 
> 
> 
> -Original Message-
> Sent: Thursday, June 05, 2003 4:05 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> As subject line indicates standard (level 5)
> snapshots
> make "vmstat 1" or "sar  -u 1 100"  show 100% CPU
> utilization (75% system mode) for about 3 seconds.
> 
> Is this normal? Is statspack that brutal on CPU? And
> why would that be a system mode primarily?
> 
> Environment:
> 
> Oracle 9.2.0.2 on Mandrake 9.0
> (2.4.19-16mdkenterprise)
> 2.4GHz uniprocessor P4 box, 1GB SDRAM
> 
> TIA,
> Boris Dali.
> 
> 
>
__
> 
> Post your free ad now! http://personals.yahoo.ca
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Boris Dali
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: DENNIS WILLIAMS
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


Re: DB character set

2003-02-18 Thread Boris Dali
In case anybody is interested in the character set
business:

I asked this question (best char set for mixed
environment of Unix and MS DBs with primarily MS
clients and C/S applications) Gilles Briard, the
author of article in OraMag on accomodating Euro
symbol in a DB
(http://www.oracle.com/oramag/webcolumns/2001/index.html?euro.html).

After couple of emails I realized that the basic
question I should've asked in the first place is much
simpler:

Q: 
If DB charater set is WE8ISO8859P1
1-st user on MS Win with client side char set (part of
NLS_LANG) WE8MSWIN1252
2-nd user on Unix with client side char set
WE8ISO8859P1

Would there be any difference in performance (elapsed
time) if both clients (one on Unix, one on MS Win) are
located on the same segment with the same network
bandwith and latency and run the same simple query
(say select * from sys.source$; in SQL* Plus) ?


I always thought that the one on MS Win might be
slower (in the example above) because Oracle has to go
through a char set conversion. 
The following URL from Oracle Globalization Guide
seemed to confirm that:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2.htm#100796

Gilles response was that if all other factors are the
same and the only difference is the NLS_LANG value on
the client, than user on Unix and MS should expirience
the same performance (if I understood it correctly).
The reason for this is the following steps that Oracle
goes through in any case:

1 - DB server: translate char set P15 data to binary
2 - network transmission of binary data
3 - Client: translate binary to P15 back (in case of
Unix) OR to WIN1252 (in case of MS Win)
4 - Client: graphical transformation

So translation in step 3 or translation with
conversion (or is it conversion with translation?)
cost the same?

I'll be setting up a test maybe next week (not only
for performance impications, but also to check if
symbols like 1/2 and 1/4 we use here can be stored and
retrieved back), but I would appreciate if anybody can
comment on the above.


Resources used
-
1. Globalization Guide
2. 144192.1 Whether or not to change the DB char set
to support the Euro sign
3. 225938.1 Do I have incorrect  char in the DB and
how to recover
4. 140014.1 RDBMS support for the Euro Currency symbol
5. 15095.1  Exp/Imp and NLS considerations
6. 119119.1 UTF8 DB char set implications
7. 181508.1 Choosing the DB char set
8. 137127.1 Char set, Code Pages, Fonts and the
NLS_LANG value
9. 158577.1 NLS_LANG explained (how does client-server
char converison works?)
10.
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2.htm#100796


Thanks,
Boris Dali.



 --- Boris Dali <[EMAIL PROTECTED]> wrote: > Dear
List,
> 
> Life was pretty easy here before they came up with
> this euro symbol :-( We had WE8ISO8859P1 (the
> default
> I bevieve) as a char set on all Unix and MS (sorry
> we
> have those as well) DBs accross the board.
> That was also the client side char set (part of
> NLS_LANG) - most clients here are on MS (code page
> 1252), some browser based.
> 
> Well, with euro it looks like they went different
> directions:
> - On MS: it's recommended to have WE8MSWIN1252
> (super
> set of good old WE8ISO8859P1)
> - On Unix: it's WE8ISO8859P15
> 
> My question is:
>   1. if I want to stick with one char set accross the
> board (as we have now) for all DBs on Unix and MS 
> AND
>   2. avoid (automatic, but not free) conversion on
> DB-Client Net communication AND
>   3. we need euro symbol
> 
> is there a painless solution out there? 
> 
> Thanks,
> Boris Dali
> 
>
__
> 
> Post your free ad now! http://personals.yahoo.ca
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> -- 
> Author: Boris Dali
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing l

DB character set

2003-02-05 Thread Boris Dali
Dear List,

Life was pretty easy here before they came up with
this euro symbol :-( We had WE8ISO8859P1 (the default
I bevieve) as a char set on all Unix and MS (sorry we
have those as well) DBs accross the board.
That was also the client side char set (part of
NLS_LANG) - most clients here are on MS (code page
1252), some browser based.

Well, with euro it looks like they went different
directions:
- On MS: it's recommended to have WE8MSWIN1252 (super
set of good old WE8ISO8859P1)
- On Unix: it's WE8ISO8859P15

My question is:
1. if I want to stick with one char set accross the
board (as we have now) for all DBs on Unix and MS  AND
2. avoid (automatic, but not free) conversion on
DB-Client Net communication AND
3. we need euro symbol

is there a painless solution out there? 

Thanks,
Boris Dali

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




RE: Recipe for application design to run on RAC

2002-12-06 Thread Boris Dali
Thanks, Raj.

 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > Boris,
> 
> the example I gave you is 9012 RAC and I have 5
> other production systems
> that are 9202 RAC.  BTW remember if you have
> cluster_database is true, then
> no matter how many instances, you will see GC
> traffic and boy those numbers
> are crooked .. it is a generic problem hopefully
> there will be patch for it
> to fix the GC timing..
> 
> I think that advise should have been prefixed with
> something like ...
> "Following statement is issued so that in case your
> application fails to
> scale contrary to our well publicized claim that RAC
> is extensible and
> scalable, we can always blame on your
> not-so-well-thought-rac-incompatible
> design. This way we will be safe and no one in media
> can blame us."
> 
> I am pretty sure it is hidden somewhere ...
> 
> BTW 9202 ... make sure you get all the patches ...
> this upgrade is a painful
> story (at-least for us).
> Raj
>
__
> Rajendra JamadagniMIS, ESPN Inc.
> Rajendra dot Jamadagni at ESPN dot com
> Any opinion expressed here is personal and doesn't
> reflect that of ESPN Inc.
> 
> QOTD: Any clod can have facts, but having an opinion
> is an art!
> 
> 
> -Original Message-
> Sent: Wednesday, December 04, 2002 9:19 PM
> To: Multiple recipients of list ORACLE-L
> 
> 
> On a more serious note the following guidelines look
> interesting:
>
http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96600/migrate.htm
> #1013313
> 
> "Migrate to RAC ... unless your application was
> specifically designed to not use cluster database
> processing". 
> I wonder why would somebody do that?
> >
This
> e-mail message is confidential, intended only for
> the named recipient(s) above and may contain
> information that is privileged, attorney work
> product or exempt from disclosure under applicable
> law. If you have received this message in error, or
> are not the named recipient(s), please immediately
> notify corporate MIS at (860) 766-2000 and delete
> this e-mail message from your computer, Thank
>
you.*****2
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




Re: Recipe for application design to run on RAC

2002-12-06 Thread Boris Dali

Thanks a lot, Tim. Enjoyable reading. Much
appreciated.

Just to clarify what data modeling vendor might mean
by "RAC-aware" model:
In one of the draft suggestions they had "activity"
class tables that would record all major steps in the
system like registration, signing a contract,
inventory replenishment etc.
This class of tables would be inevitably DMLed from
different nodes in active/active deployment and it
would probably present "bottleneck" much like AOL or
FND schemas in your example with Oracle Apps

Another thing that I saw on the draft ERD was "event"
entity with exclusive arc to 7 (seven!) others. Same
thing. On the final one it's broken down into two
event_sales and event_inventory.

While it's easily can be abstracted to a single entity
(similar attributes) they separated them into two
presumably to minimize data shuffles over
interconnect.
Isn't it kind of "segregation" (if I am not mistaken
the term Oracle doco seems to use is "application
segmentation"
http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96598/ebizapps.htm#22163)?


Tim, I appreciate your "mutual failover" suggestion,
but I am afraid it wouldn't work here as these 30+
apps would be totally merged and at these
point cease to exist as separate schemas.


Now to the cool stuff :)
Your idea of the middle tier "data-routing" seems very
interesting. Is it like app server having two data
sources defined (one for each node) and issuing DMLs
based on some sort of criteria?
Would it be too much to ask you elaborate on this? Is
it "one table gets rows inserted from one node with
even ids (assuming sequence based artificial PK) and
rows with odd ids from another node" type of scenario
(or something similar like based on
type/group/code/whatever but the same table DMLed from
different nodes based on data ranges)?
Or am I totally off base here?

Tim, thanks again for your help!


 --- Tim Gorman <[EMAIL PROTECTED]> wrote: > comments
inline...
> 


__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




RE: Recipe for application design to run on RAC

2002-12-04 Thread Boris Dali
Thanks, Raj.

>> H... it is probably not an good example ...
Why not? On the contrary. I am sure damanagement here
would love to here this. Besides it fully supports
Oracle's statement that application can be migrated to
RAC "as is" (as I think Hemant mentioned).

Wait... did you say 9i? release 2? recently? - may be
it's a Christmas magic that made it happen for you?
(although those sceptical might say that it had to do
with your careful app "partitioning"/segmentation
rather than a festive season)


On a more serious note the following guidelines look
interesting:
http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96600/migrate.htm#1013313

"Migrate to RAC ... unless your application was
specifically designed to not use cluster database
processing". 
I wonder why would somebody do that?


 --- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote: > H... it is
probably not an good example but we
> too have a (couple of)
> mission critical app (affects on air production)
> running on 9i RAC. One of
> which has two major schema. We logically partitioned
> the application such
> that, for two groups of people 9accessing one schema
> each) we gave them a
> preference. 
> 
> Schema1 users have tns entry for db1 and fail over
> to db2
> Schema2 users have a preference for db2 with a fail
> over to db1
> 
> This effectively allows us to do load balance, they
> don't share too much
> data, so traffic through interconnect is manageable.
> If need be, we just
> shutoff listener on one side, and everyone fails
> over to the other side
> while we can perform maintenance. All their
> applications are written in VB,
> JAVA so they handle fail over from within
> application.
> 
> None of the people involved in the design worried
> about which side of RAC
> they will be on and how the DML activity affects etc
> etc. They designed a
> plain application with a good design and it is
> working fine.
> 
> Like I mentioned this is not a good example ... but
> this is how we did it in
> one of our major application.
> Raj
>
__
> Rajendra JamadagniMIS, ESPN Inc.
> Rajendra dot Jamadagni at ESPN dot com
> Any opinion expressed here is personal and doesn't
> reflect that of ESPN Inc.
> 
> QOTD: Any clod can have facts, but having an opinion
> is an art!
> >
*This
> e-mail message is confidential, intended only for
> the named recipient(s) above and may contain
> information that is privileged, attorney work
> product or exempt from disclosure under applicable
> law. If you have received this message in error, or
> are not the named recipient(s), please immediately
> notify corporate MIS at (860) 766-2000 and delete
> this e-mail message from your computer, Thank
>
you.*****1
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




Re: Are Oracle courses required for Oracle Certification now?

2002-12-04 Thread Boris Dali
 mailing list you want to be
> removed from).  You 
> >may
> >> also send the HELP command for other information
> (like subscribing).
> >> 
> >> 
> >
> >
> >-- 
> >Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> >-- 
> >Author: Lyndon Tiu
> >  INET: [EMAIL PROTECTED]
> >
> >Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> >San Diego, California-- Mailing list and
> web hosting services
>
>-
> >To REMOVE yourself from this mailing list, send an
> E-Mail message
> >to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and 
> >in
> >the message BODY, include a line containing: UNSUB
> ORACLE-L
> >(or the name of mailing list you want to be removed
> from).  You may
> >also send the HELP command for other information
> (like subscribing).
> >
> >
> >
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Alan Davey
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> 
=== message truncated === 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




Re: Recipe for application design to run on RAC

2002-12-04 Thread Boris Dali
gt; application somehow.  Whether it is by major
> application module (i.e. "sales
> and marketing" versus "order entry and inventory"
> versus "general ledger",
> etc) as Boris had illustrated, or by some other
> mechanism (i.e. all
> customers whose names start with A-M on one node,
> all whose names start with
> N-Z on the other node, etc), the application must be
> able to partition.
> 
> ---
> 
> In Oracle7 OPS and Oracle8 OPS and Oracle8i OPS, the
> mechanism (i.e.
> "pinging" performed through the I/O subsystem) was
> quite slow on most
> platforms, resulting in huge latencies.  The major
> exception to this rule
> was DEC/Compaq/HP OpenVMS, where the performance of
> the "pinging" mechanism
> is so fast as to be quite unnoticeable.  Not
> surprising if one considers the
> history of VMS and OpenVMS...
> 
> Beginning with pieces of the cache-coherency
> mechanisms in Oracle8i OPS and
> fully implemented in Oracle9i RAC, the
> "cache-fusion" mechanism still
> performs the same locking and data-transfer of
> database block buffers
> between instances, only faster.  How much faster is
> dependent on the OS and
> configuration.  But the additional latency is still
> there.  Obviously, if
> the inter-connect mechanism between nodes is not
> fast or misconfigured, then
> "cache-fusion" cannot be fast either...
> 
> ---
> 
> When Oracle states that "applications can be
> migrated to RAC without
> modification", they are saying so in the faith that
> the reduced latencies in
> the cache-fusion mechanism and other improvements in
> the
> sharing/modification of global enqueues will result
> in almost-zero latency,
> or at least latency that is within the tolerance of
> the end-users.  As the
> old saying goes, "your mileage may vary" or YMMV. 
> As OpenVMS and its near
> zero-latency "pinging" mechanism shows, the choice
> and configuration of
> platform really matters also!
> 
> ---
> 
> In order to assess if an application is likely to
> scale effectively when
> migrating from non-RAC to RAC, I would pay close
> attention the nature,
> frequency, and volume of UPDATE, SELECT ... FOR
> UPDATE, and DELETE
> statements generated by the application.  While
> still in its non-RAC
> implementation, I would recommend collecting and
> examining such SQL
> statements generated by application and
> understanding what program modules
> are generating each statement and why.  I would then
> prioritize these
> statements by their volume and the business
> criticality of the generating
> program module.  Last, according to this
> prioritization, I would examine how
> the WHERE clauses and the data values used in them
> can be controlled by
> application logic.  For example, if a
> business-critical online form is
> generating lots of UPDATE and SELECT ... FOR UPDATE
> statements, is it
> possible to determine whether those statements are
> generated against rows
> previously INSERTed by the same session?  Or, does
> that online form perform
> UPDATE and SELECT ... FOR UPDATE operations against
> any data in the database
> at all?
> 
> Some applications are really quite "partitionable"
> under the covers, and
> only a small amount of such analysis can assure you
> that RAC is feasible.
> Other applications are so dreadfully complex that
> only by load-testing with
> real-world data values can the scalability be
> determined...
> 
> Oracle has correctly identified all of the major
> bottlenecks in
> inter-instance contention and has improved each of
> these areas in RAC since
> OPS.  The question is whether the improvements are
> sufficient for your
> requirements...
> 
> ---
> 
> Relevant wisdom from "The Meaning of Life" by Monty
> Python (1983):
> 
> Mother (going through labor pains, alert and
> panicky):  What's that for?
> 
> Obstetrician #1:  That's the machine that goes
> "ping". << PING! >>  You
>   see?  That means your
> baby is still alive!
> 
> Obstetrician #2:  And it's the most expensive
> machine in the whole
>   hospital!
> 
> Obstetrician #1:  Yes, it cost over three
> quarters of a million pounds!
> 
> Obstetrician #2 (slowly and condescendingly): 
> AREN'T YOU LUCKY?
> 
> 
> - Original Message -
> To: "Multiple recipients of list ORACLE-L"
> <[EMAIL PROTECTED]>
> Sent: Wednesday, November 

RE: Recipe for application design to run on RAC

2002-11-27 Thread Boris Dali
Thanks for taking time to reply, Cary. Much
appreciated.

Did I understand it correctly that in active/active
setup it would be beneficial to give each node "it's
own virtual empire" so to speak. 
Like one node to service say marketing and sales,
while the other to deal with say inventory and
automation and minimize interdependencies between the
two?
I was thinking more along the lines of equally
distributing/balancing the utilization across the
nodes (which presumably makes it easier to re-route db
calls to surviving node in case of instance/node
failure after remastering, since all nodes are
"peers")
I obviously need to do some serious RTFMing here.


So if the key is to have application partitioned (by
probably functional/business areas?), is it at the
logical design stage that this needs to be accounted
for?
Assuming enterprise framework in place, like Zachman's
(http://www.zifa.com/framework.html) would it be at
the system model/logical level (or using Oracle
Designer terminology I guess at the system analysis
stage) that "design for RAC" comes to the picture for
a first time?

Thanks again.

 --- Cary Millsap <[EMAIL PROTECTED]> wrote: >
If two or more RAC instances will be trying to cache
> the same data
> blocks, then this causes the performance problems
> that you'll see show
> up as lots of time spent on the event called "global
> cache cr request".
> If you can partition your application so that RAC
> nodes don't have to
> share blocks very often through the cache fusion
> mechanism, then your
> system will scale a lot better.
> 
> 
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> 
> Upcoming events:
> - Hotsos Clinic, Dec 9-11 Honolulu
> - Hotsos Clinic 101, Jan 7-9 Knoxville
> - Steve Adams's Miracle Master Class, Jan 13-15
> Copenhagen
> - 2003 Hotsos Symposium, Feb 9-12 Dallas
> 
> 
> -Original Message-
> Sent: Tuesday, November 26, 2002 3:34 PM
> To: Multiple recipients of list ORACLE-L
> 
> Dear List,
> 
> Number of times I've seen that one of prerequsites
> for
> switching from single node DB to OPS/RAC is to have
> an
> application specifically designed / architectured to
> run on RAC.
> Can somebody elaborate? Is it something "visible" on
> 
> ERD? That is by looking at the model can RAC guru
> tell
> that it wouldn't work well on RAC?
> Or put it another way can one conclude based on the
> ERD that app was modeled to run on RAC?
> 
> What's the recepie for app design for RAC?
> 
> TIA
> 
>
__
> 
> Post your free ad now! http://personals.yahoo.ca
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Boris Dali
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
> 
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Cary Millsap
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
>  

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




Recipe for application design to run on RAC

2002-11-26 Thread Boris Dali
Dear List,

Number of times I've seen that one of prerequsites for
switching from single node DB to OPS/RAC is to have an
application specifically designed / architectured to
run on RAC.
Can somebody elaborate? Is it something "visible" on 
ERD? That is by looking at the model can RAC guru tell
that it wouldn't work well on RAC?
Or put it another way can one conclude based on the
ERD that app was modeled to run on RAC?

What's the recepie for app design for RAC?

TIA

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).




Re: Oracle 9.2.0.1/2 on Mandrake 9 - solved

2002-11-14 Thread Boris Dali
 --- Markus Reger <[EMAIL PROTECTED]> wrote: > out of
curiosity : did you ever check the filesizes
> in bytes of yr first corrupt downloads with the
> bytes of the files on the download site? 

I did. They bear some resemblace, but figures are not
exactly the same. 
I also compared sizes of files I got on disk
(unpacked) after my first and second downloads and
they are different for all 3 files, even though only
Disk2 was... well, not good. Math doesn't seem to rule
here. Go figure

> i'm running O9i too, now wondering if this test
might suffice to
> tell whether the download was successful or not. i
> didn't experience any probs so far until recently
> when i changed/patched to 9.2.0.2.0 - the
> oem/console dosn't display the XML database. the
> flaw is, that it doesn't have some index ...
> 
> created a totally new -userdefined,NOT preconfigured
> - database and could successfully display the
> XML-stuff.
> 
> installation is on a rh 7.2 - was a rh 8.0 - but on
> rh8.0 the console didn't work - unproperly
> terminated connect string when attempting to connect
> even to a local database. dumped the whole rh 8.0,
> reinstalled the 7.2.
> 
> lfw to a reply 
> mr  
> >>> [EMAIL PROTECTED] 11/14/02 17:32 PM >>>
> Ray, right on target!
> 
> After looking for disk errors in dmesg output,
> /var/log/messages to no avail, I finally uninstalled
> the whole 9.2 OH last night,
> re-downloaded/re-burned/re-... and this time
> installation of both 9.2.0.1 and a patch went with
> no
> glitches. 
> 
> Apparently Disk2 was corrupted/missing files/??? on
> downloading/burning/unpacking, but what surprised me
> the most is that I didn't get any errors at
> gunzip/cpio stage, which I always thought of as a
> good
> indication that software on CDs is valid. This
> assumption cost me week and a half of hopeless tries
> to make it work...
> 
> On the bright side, some .o, .so etc. files I see in
> OUI during installation look painfully familiar...
> 
> Thanks a lot for you help.
> 
>  --- Ray Stell <[EMAIL PROTECTED]> wrote: > On Tue,
> Nov 12, 2002 at 01:50:52PM -0800
> 
>
__
> 
> Post your free ad now! http://personals.yahoo.ca
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Boris Dali
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing).
> 
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author: Markus Reger
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



Re: Oracle 9.2.0.1/2 on Mandrake 9 - solved

2002-11-14 Thread Boris Dali
Ray, right on target!

After looking for disk errors in dmesg output,
/var/log/messages to no avail, I finally uninstalled
the whole 9.2 OH last night,
re-downloaded/re-burned/re-... and this time
installation of both 9.2.0.1 and a patch went with no
glitches. 

Apparently Disk2 was corrupted/missing files/??? on
downloading/burning/unpacking, but what surprised me
the most is that I didn't get any errors at
gunzip/cpio stage, which I always thought of as a good
indication that software on CDs is valid. This
assumption cost me week and a half of hopeless tries
to make it work...

On the bright side, some .o, .so etc. files I see in
OUI during installation look painfully familiar...

Thanks a lot for you help.

 --- Ray Stell <[EMAIL PROTECTED]> wrote: > On Tue,
Nov 12, 2002 at 01:50:52PM -0800

__ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



Re: Oracle 9.2.0.1/2 on Mandrake 9

2002-11-12 Thread Boris Dali
Thanks for reply, Ray.

I guess disk explanation is the most logical one to
assume, but I've no idea how to confirm and overcome
it. As I mentioned I re-installed it in different
combinations multiple times. Would this file always go
the same place on disk (say same bad sector)?

One interesting thing I've noticed after comparing
your ls -l output with mine is that all other 4 image
files in this directory are dated way back to 2000
timeframe, whereas credits.gif has a time stamp of
yestarday (day I tried the installation last time). I
can view the file with the browser, however. What does
it tell me?

 --- Ray Stell <[EMAIL PROTECTED]> wrote: > On Tue,
Nov 12, 2002 at 10:53:37AM -0800, Boris Dali
> wrote:
> > 
> > Hope not everybody is off to OOW :(
> > 
> > Did anybody get the above combo working? I know
> that
> 
> 
> 
> I have installed Oracle 9.2.0.1 on Mandrake 9 twice
> on marginal machines without any such behavior. 
> Could
> you have gotten an i/o error on the disk?
> 
> # pwd
> /db03/app/oracle/product/9.2.0/wwg/admin/images
> [root@haglid images]# ls -l credits.gif
> -rw-r--r--1 oracle   oinstall   181222 Jul 12 
> 2000 credits.gif
>  
> I was just about to patch them, so I am nervous
> about
> getting to 9.2.0.2, hope to do that today.
> 
>
===
> Ray Stell   [EMAIL PROTECTED] (540) 231-4109
> KE4TJC28^D
> -- 
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> -- 
> Author: Ray Stell
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- 858-538-5051
> http://www.fatcity.com
> San Diego, California-- Mailing list and web
> hosting services
>
-
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from).  You may
> also send the HELP command for other information
> (like subscribing). 

______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



Oracle 9.2.0.1/2 on Mandrake 9

2002-11-12 Thread Boris Dali

Hope not everybody is off to OOW :(

Did anybody get the above combo working? I know that
Oracle is not certified on Mandrake and I don't
care... as long as I can make it work that is

Here are the facts:
1) HW: One way 2.4 GH box with 1GB DDR RAM, plenty of
disk space
2) SW/OS: Mandrake 9 / 2.4.19-16mdk enterprise w/ the
latest security patches applied
3) Plenty of swap (as per free, swapon -s, cat
/proc/swaps) and /temp

Here's `rpm -q gcc cpp glibc-devel kernel-headers
binutils` output:

gcc-3.2-1mdk
package cpp is not installed
glibc-devel-2.2.5-16mdk
kernel-headres-2.4.18-41mdk
binutils-2.12.90.0.15-1mdk

OUI came up smoothly (had some troubles to convince it
to come up with 8.1.7 on the same box - previous
install, first OH). I went with Enterprise
DB/SoftwareOnly option

Problem: 
1) at 61% on  error
pops up:
"Error in writting to
$OH/wwg/admin/images/credits.gif"

- fuser on credits.gif doesn't show that somebody is
using it
- deleteting it (and/or the whole $OH/wwg directory)
doesn't help as OUI simply re-creates them and gets
stuck on the same error message
- oraInventory log doesn't add any additional info
- tried to re-install it I think a dosen times by now
in diff. variations (Custom/w seed DB/ etc.) with the
same result
- applying 9.2.0.2 patch and re-install of the same
component didn't help eigther (not sure why I expected
it to help, but I seemed to exaust all the other
options)...

Is it a bad disk sector (no idea how to check disk for
bad sectors on Linux)? Is it Oracle's corrupted jar
file (no idea how to find name of the jar and test it
for corruptions)?

2) The above error wouldn't bother me too much (no
other errors at the install phase), but I also got
stuck at the relinking phase which seem to be related
to the error above. 

The reason is that my $OH/rdbms/lib is missing
config.c, opimai.o, ssoraed.o, ttcsoi.o and may be
others. So cancelling/ignoring PL/SQL Embedded Gateway
component (what is it anyway? Sounds like Transparent
gateways to Bill/Informix/DB2 etc. to me) seem to
cancel installation of some critical files needed for
relinking...

Coping config.c from 8.1.7.4 (different binary
tree/OH, even diff OS acount) doesn't seem to help:

make -f ins_rdbms.mk config

fails with infamous "Error 1" error. Coping config.o
and the rest 3 o files missing and relinking via
 or  gets
a little futher, but fails latter with the same "Error
1"

Reasons? Others seem to indicate 2 prime reasons: "-z
defs" issue and binutils version:

a- "-z defs" in LD_SELF_CONTAINED inside $OH/genclntsh
doesn't seem to be an issue in my case. Oracle
automatically comments it out, but even if I uncomment
it and re-run genclntsh I get the same result:

basename: too few arguments
Try 'basename --help'
cp: missing file arguments
Try 'cp --help'
...
Created $OH/lib/libclntst9.a

So not everything is 100%, but at least I got
libclntst9.a generated eigther way

b- binutils? Not sure if it's still an issue in 9.2.
Mine seems to be way higher than the one Oracle was
ready to swallow in 9.1. I know for sure I didn't have
a problem with 9.0.1 on Mandrake 8.0...


Net result so far: I can confirm that Oracle Client
9.2 works like a charm on Mandrake9 :(. As far as the
rest, so far I fail to get oracle, orapwd and others
in my $OH/bin...

Any help would be appreciated.

TIA,
Boris


______ 
Post your free ad now! http://personals.yahoo.ca
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Boris Dali
  INET: [EMAIL PROTECTED]

Fat City Network Services-- 858-538-5051 http://www.fatcity.com
San Diego, California-- Mailing list and web hosting services
-
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).