With 2 CPUs, a Run-Queue of 1.27 isn't high. As SharePlex seems to be
the only process taking CPU, it is taking 100% of 1 CPU. If it is one
process only,
then the CPU speed __could__ [and I'm not saying IS] the constraint.
Adding CPUs wouldn't help. However, upgrading to a faster CPU would
How big is the box that is the source for this machine? Have you tried
running sp_ctrl and doing a shutdown and startup?
Allan
-Original Message-
Sent: Thursday, October 23, 2003 10:30 AM
To: Multiple recipients of list ORACLE-L
Hi gurus,
Oracle 8.1.7.3 on Sun Solaris
One of our
Allan,
I don't know about the source machine.
I receive around 350Megs of data every day.
I'm using sp_ctrl to stop and restart my Post process and monitor the queue.
I'm pretty sure that the bottleneck come from Shareplex. Oracle is waiting
for Shareplex, we have server's resources available
Dan,
The process taking 50% is an Oracle process and it is connected on Shareplex
Oracle user.
I have two different error messages:
1- System call error: sp_cop(dsm) Temporary error (h_errno = 2)
gethostbyname (can't add entry for ora4)
I got this error every 10 minutes, but I didn't find
Shareplex is fast here. We replicate a 6 CPU db to a 4 CPU machine
without excessive loads or problems. We run an average of 29 messages
with about 1 GB in the queues. Our data is 0 minutes old.
Outside of contacting Quest support I'm sure of how much help I can be.
When I have seen SP claim
Who's using other 50%? Is SP active or is waiting?
On 10/23/2003 02:19:32 PM, [EMAIL PROTECTED] wrote:
Allan,
I don't know about the source machine.
I receive around 350Megs of data every day.
I'm using sp_ctrl to stop and restart my Post process and monitor the
queue.
I'm pretty sure that the
Now we don't use Shareplex, but I do know of others who do this is not the first
time I hear of performance problems, but I may be able to shed some light on the
problem. Since Shareplex reads the redo logs, if one statement on the source database
affects more than one row (lets say 10 for
Your DNS is toasty. Gethostbyname is a UNIX system call that takes your
ip address and turns it into a name. This could be a big part of your
delay. Networked apps do not take kindly to being unable to both
forward and reverse lookups. H_errno = 2 is not found.
Allan
-Original
Since the results of triggers firing in the source will appear in the
log files, then in general you do not want the same triggers firing in
the target. Similarly since data integrity is usually enforced in the
source db you can typically disable it in the target. I suppose
something on this
I probably found my problem. My replicated tables have a lot of indexs.
I removed all of them, and step by step I will add indexs who will help my
replication.
Tx
Luc
-Original Message-
Sent: October 23, 2003 3:04 PM
To: Multiple recipients of list ORACLE-L
Since the results of
Do you have primary keys etc and hint file? Also do you have constraints disabled. Some "Nelson, Allan" [EMAIL PROTECTED] wrote:
Since the results of triggers firing in the source will appear in thelog files, then in general you do not want the same triggers firing inthe target. Similarly since
One of my clients has been talking to me about similar issues.
What kind of system are you replicating?
How much redo logging are you generating per day?
Does shareplex start to fall behind during the processing peaks?
_
David Kurtz
Go-Faster Consultancy Ltd.
tel: +44
Title: RE: Performance Problem
'her' ??
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
Did you analyze the sys schema by mistake. This can stop the fastest
database. We had a contractor do that to an 8.0.5 database once, and only
once.
Ruth
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Burton, Laura
Sent: Monday, August 25, 2003 4:49
No, I had read not to analyze the sys tables in the 'TIP' section of the
book I am using as a reference (Oracle Performance Tuning/Tips
Techniques). As I stated earlier, I also made sure that I analyzed all
the tables and indexes that were involved, because I had read that
leaving a table
Laura,
You might find the problem by checking the things you plan to check, and
by following the advice of the book you're using. But the odds are very
good that you will not. At least not for a long time...
Any application program on your system can tell you where it is spending
its time. Let
Title: RE: Performance Problem
Funny ...
I have tkprof give up analyzing a 4.2G tracefile on a 64bit platform. anyone else experienced this??
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views
Laura, I really believe that you should take the 10046 and then contact
Hotsos.
It may and probably will save you some time and aggravation. They're not
very expensive,
around $50 per file analyzed.
--
Mladen Gogala
Oracle DBA
-Original Message-
Burton, Laura
Sent: Tuesday, August
Of
Jamadagni, RajendraSent: Tuesday, August 26, 2003 4:54
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
Performance Problem
Funny ...
I have tkprof give up analyzing a 4.2G tracefile on a 64bit
platform. anyone else experienced this??
Raj
Was it always slow ?
Are you monitoring specifics jobs ? If so, have you run tkprof your main SQL
statements ?
When running, what are the main ressources Oracle is waiting on ?
Have you monitor from the OS ? Are you IO bound or CPU bound ?
Cost base optimiser in 805 is not as good as on 8i or
Burton, Laura wrote:
We currently have an application we are trying to speed up. In
researching rule/cost based optimizers, I read that the cost based
optimizer was the way to go (although rule had its moments) because that
is where Oracle would be focusing any upgrades, enhancements, etc.
To speed up the application, you have to know where the time is spent.
Initial estimates can be made based on V$SESSION_WAIT and V$SESSION_EVENT
for
the application sessions, but to go really deep, you need a detailed
performance
analysis, based on timings and waits produced by the event 10046,
Laura,
Keep in mind that analyzing tables/indexes will invalidate related SQL in
the shared pool. If you have Statspack snapshots at that time, you will see
that both latching (for shared pool/library cache) as well as waits for
'library cache pin/locks/loads' was high at that time. You may have
'Laura' On Monday, August 25, 2003 1:49 PM said;
We currently have an application we are trying to speed up. In
researching rule/cost based optimizers, I read that the cost based
optimizer was the way to go (although rule had its moments) because that
is where Oracle would be focusing any
Mladen's advice actually covers that. No matter what's causing the slow
performance, if something's taking time, then it will show up in the
10046 trace data. That's why we love her so.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Hotsos Clinic 101 in Sydney
-
Scott,
I don't understand I have tried to capture a
session, but I need to get a repository up to look at the trace that was
generated.
No mention of Oracle versions or even O/S levels but I am sure you have
Statspack available which should give you a good start.
So have an overall view of
Scott - I would approach this as a standard tuning problem, and try to avoid
making assumptions about what the answer is. Find out what the system waits
are. STATSPACK is pretty good at listing your waits. Otherwise, there are
scripts available that you can run. Make sure the database is waiting
Hi Scott,
I wouldn't worry about the hit ratios. Have you tried to find badly
performing SQL. The chances are the execution plan may have changed for some of
the frequently used SQL. When you doubled the block size, did you halve the
db_file_multiblock_read_count ? The optimizer may be
I have done this before and I always do it
on a test machine first as everything that
has been tuned up to this point is now at step
1 all over again.
Did you import everything properly ? Indexes ?
Make sure your schema objects are analyzed again.
Find out the time of the day where
in addition you could also have
I/O and or CPU problems so check those things
out too.
-Original Message-
Sent: Thursday, August 01, 2002 3:31 PM
To: '[EMAIL PROTECTED]'
I have done this before and I always do it
on a test machine first as everything that
has been tuned up to
Strange, I'd expect, that dropping 12 partitions should speed up the query.
Still partitioning helps only if column, used for partitioning, is specified
as one your search criteria, or if you do full table scan in parallel, or in
maintenance when you can quickly drop a partition instead of
Jessica,
It looks like your query has to deal with all 14 partitions, because the
column 'poid_id0', which your table partitioned on, is not in 'where'
clause.
That's why Oracle can not eliminate other (not populated) 13 partitions.
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
- Original
Thank you Igor. But only 1 of the 14 partitions contains data during all the tests.
Why should the extra 13 empty partitions slows down the query? I also tried to drop 12
of the empty partitions. Results didn't change. -Jessica
-Original Message-
Sent: Thursday, January 24, 2002 5:37
Biddell, Ian wrote:
Hi all,
Hoping someone can shed some light on a problem I have.
We a particular cursor in a batch program running in production at a
client site which has suddenly decided to work really badly.
The program hasn't been changed but I think the customer has done some
Hi Stephane,
Thanks for writing back, I would normally look at some hints or
something like that but as far as I can tell it's going through the
tables in the correct way. My problem is when we run it on a Production
copy on my server we don't get that big number against that table. The
tkprof
Did they rebuild their indexes after this reorg? It could be that they
simply exported/imported the table without rebuilding the appropriate
indexes?
Just a thought..
Mark
-Original Message-
Ian
Sent: 19 December 2001 12:55
To: Multiple recipients of list ORACLE-L
Hi Stephane,
Title: Performance problem HELP :-(
Hi Ian,
take a careful look at fragmentation of their
indexes and possible chained rows in the tables. Probably RATE_SCHEDULE_LINK_PK
is a good start point
Also the cardinality(estimated numbers
of output rows for each step) may confuse you if their
Ian,
What kind of a reorg was done? So the RATE_SCHEDULE_LINK_B table has about
the same number of rows in both instances? The explain plans are the same.
It looks like one just has more records to access. Both could be improved by
changing the sql to be more selective.
Mike
From: Biddell,
unable to open the zip files.
-Original Message-
From: Dharani Ravi [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, September 26, 2001 10:05 AM
To: Multiple recipients of list ORACLE-L
Subject: Performance problem with connect string (2nd attempt)
Hi,
Last week I had
Dear Nirmal Kumar,
I give below the content of the files :
# LISTENER.ORA Configuration
File:/oracle/app/oracle/product/8.1.6/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
40 matches
Mail list logo
