Hi all
Been trying to get www.oraperf.com (oraperf.veritas.com ) to
resend my forgotten password as well as new registration on the site
but am not getting any email from them.
I need to try something out in the next day and would appreciate
it if someone could provide me with an account and
Thanks for reading. A kind soul (babu) was kind enough to pass
me an account . Will wait for my own now.
ta
tony
At 10:24 AM 18/09/2003 -0800, you wrote:
Hi all
Been trying to get www.oraperf.com (oraperf.veritas.com ) to
resend my forgotten password as well as new registration on the
The main problem as I see it is that you might be
lucky in getting IO balance with a
tables-here-indexes-there approach in rule based
databases, where pretty much the only thing Oracle can
do is table scan and single block index read.
But since 7.3, and even more so with the more recent
releases,
: Re: oraperf comment
Yechiel,
You had mentioned only one possible scenario
(i.e. "user A accesses table while user B simultaneously accesses index")
where there are several other possible, equally-likely scenarios (i.e. "user A
accesses table while user B simultan
: oraperf comment
Ray,
I don't know exactly what was intended with the
comment, but I agree with your interpretation.
---
As far as any other reasons for the
comment...
RANT
In terms ofmyths that have persisted with
Oracle over the years, the ideathat some performance
me as i'm looking for guidance.
=)
-Original Message-From: Yechiel Adar
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 22, 2002 5:44
AMTo: Multiple recipients of list ORACLE-LSubject: Re:
oraperf comment
Hello Tim
I beg to differ. Without raid it is better to put
i
...resending, as the original send encountered some
kind of "locking problem" at fatcity...
- Original Message -
From: Tim Gorman
To: [EMAIL PROTECTED]
Sent: Tuesday, October 22, 2002 6:35 AM
Subject: Re: oraperf comment
Why?What are the chances of
preciselythat scenari
Tim,
point well said. Thank you.
-Original Message-From: Tim Gorman
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, October 22, 2002 11:15
AMTo: Multiple recipients of list ORACLE-LSubject: Fw:
oraperf comment
...resending, as the original send encountered
some kind
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 5:14
PM
Subject: Fw: oraperf comment
...resending, as the original send encountered
some kind of "locking problem" at fatcity...
- Original Message -
From: Tim Gorman
To: [EMAIL PROTECTE
:
Markham, Richard
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 5:03
PM
Subject: RE: oraperf comment
I'm a little confused when one is talking about putting indexes and
tables into seperate TABLESPACES and the other is talking about seperate
DISKS
:
Sent by: Subject: RE: oraperf comment
[EMAIL PROTECTED
Thanks for your comments Tim. The reason I brought this up is that the
conventional wisdom is, well, conventional. I like your logic, but
have always lived on the other side of the tracks on this. I'll say
one thing for oraperf, they got my attention. The oraperf writer used
the exclusive
whether they are tables or indexes, one can make better determinations on how to
distribute I/O across non-RAID devices.
Hope this helps...
-Tim
- Original Message -
From:
Yechiel
Adar
To: Multiple recipients of list ORACLE-L
Sent: Tuesday, October 22, 2002 10
Yechiel,
You had mentioned only one possible scenario (i.e. user A accesses table while user
B simultaneously
accesses index) where there are several other possible, equally-likely scenarios
(i.e. user A accesses
table while user B simultaneously accesses table, user A accesses index
An recent oraperf report included the comment: Never split index
and data files to different sets of disks. It goes on to state that
striping is better. If the system in question does not have
raid support, wouldn't it be better to split the index and data across
spindles? That would make
e different blocksizes are possible for different
tablespaces
These last points are related to performance, but
not in the sense that the mythical"conventional wisdom"
dictates...
Hope this helps...
-Tim
- Original Message -
From: "Ray Stell" [EMAIL PROTECTED]
To: &q
PROTECTED]
cc:
Subject:oraperf comment
An recent oraperf report included the comment: Never split index
and data files to different sets of disks. It goes on to state that
striping is better. If the system in question does not have
raid support, wouldn't it be better
I have just tried using www.oraperf.com again after about a year since the
last time.
The output both in terms of formatting, readability and comment are much
improved on what was already a valuable resource
Well done Anjo
2 questions that the list (or even Anjo) may be able to answer for me
Hi Anjo,
Tried uploading a statspack report to ORAPERF and the reply I get only goes
down to BREAK DOWN OF CPU TIME and than finishes.
Should I not be uploading level 10 statspack reportt?
Sorry for sending this through this list but figured this was the quickest
way
TIA
Jack
Jack,
It should work, please send me the file to [EMAIL PROTECTED] and I will have a
look why it fails.
Anjo.
Jack van Zanen wrote:
Hi Anjo,
Tried uploading a statspack report to ORAPERF and the reply I get only goes
down to BREAK DOWN OF CPU TIME and than finishes.
Should I
. This change
made no difference in the number of Failures reported. I am hoping the
log_buffer change recommended by the oraperf analyzer will help, but can
anyone comment on that redo log size recommendation? I ran a variety of
statspack reports through and all said the same thing!
Thanks
am hoping the
log_buffer change recommended by the oraperf analyzer will help, but can
anyone comment on that redo log size recommendation? I ran a variety of
statspack reports through and all said the same thing!
Thanks,
Debi
--
Please see the official ORACLE-L FAQ: http
in the number of Failures reported. I am hoping
the
log_buffer change recommended by the oraperf analyzer will help, but
can
anyone comment on that redo log size recommendation? I ran a variety
of
statspack reports through and all said the same thing!
Thanks,
Debi
--
Please
... but them a minute or so later it is archived.
This change
made no difference in the number of Failures reported. I am
hoping the
log_buffer change recommended by the oraperf analyzer will help,
but can
anyone comment on that redo log size recommendation? I ran a
variety
errors in the alert log that indicate slow archiving of redo logs, Failed
to archive... but them a minute or so later it is archived. This change
made no difference in the number of Failures reported. I am hoping the
log_buffer change recommended by the oraperf analyzer will help, but can
anyone
made no difference in the number of Failures reported. I am hoping the
log_buffer change recommended by the oraperf analyzer will help, but can
anyone comment on that redo log size recommendation? I ran a variety of
statspack reports through and all said the same thing!
Thanks,
Debi
Cherie,
I have been trying to figure out your upload problems. And I noticed that your
report of statspack looks like it is from 8.1.6, but there are some small
differences.
Can you tell me the source of this statspack, where did you get it ? Did you
modify any of it. I am contemplating a fix,
When I try to use YAPP to analyze my STATSPACK report, I get an error
message which states that my SQL is wrapping or too long. It says that I
should set my pagesize and linesize correctly.
The report looks o.k. to the naked eye.
I looked all over their website but I don't see anywhere that
Cherie,
Send the report to me, so I can have a look what is causing the problem. On
the secondary upload site, this shouldn't be a problem anymore. It may fail on
the primary.
Anjo.
[EMAIL PROTECTED] wrote:
When I try to use YAPP to analyze my STATSPACK report, I get an error
message
29 matches
Mail list logo
