Mailing List
Home
Forum Home
Oracle List - by freelists.org
Oracle on SUSE Linux - Runing Oracle on SUSE Linux
Oracle database error code ...
www.freelists.org
Subjects
ORA 12540: TNS:internal limit restriction exceeded
ORA 12838 please : Is possible to append two times to the same table befo
ORA 12838 please : Is possible to append two times to the same table before
ora 04031
ora 12500 on windows
ORA 32004: obsolete and/or deprecated parameter(s) specified
ORA 01925: maximum of 30 enabled roles exceeded
ORA 01925: maximum of 30 enabled roles exceeded
ora 12500 on windows
ORA 01650, one idea
ORA 01650
ORA 4030
ORA 12838 please : Is possible to append two times to thesametable before do
ORA 12838 please : Is possible to append two times to thesame table before d
ORA 01536
ORA 03113 end of file on communication channel
ORA 32004: obsolete and/or deprecated parameter(s) specified
ORA 00600:
ORA 00020: maximum number of processes (%s) exceeded
ORA 01925: maximum of 30 enabled roles exceeded
ORA 3113 while creating a cluster database 9201 RAC on Linux with OCFS
ora 12500 on windows
ora 12500 on windows
ora 12500 on windows
ORA 01650, one idea
ora 12500 on windows
ora 12500 on windows
ora 12500 on windows
ORA 2000 Error Using DBMS STATS GATHER SCHEMA STATS
ORA 01650, one idea
ORA 01650, one idea
ORA 01650, one idea
ORA 01650
ORA 01650
ORA 01031
ORA 4030
ORA 4030
ORA 06502: PL/SQL: numeric or value error: Bulk Bind: Truncated Bind
ORA 01722 invalid number
 
-none-

-none-

2007-10-02       - By qihua wu

 Back
The database is running on hpux. And the sql is the exactly the same on test
and production.

Thanks,
Qihua

On 10/2/07, Vlad Sadilovskiy <vlovsky@(protected)> wrote:
>
> Sun iostat -cnmxPz 1 would show you the most of the information on IO
> subsystem throughput and lattency as well as the current load. What is OS
> you are operating on?
>
> Vlad Sadilovskiy
> Oracle Database Tools
> http://www.fourthelephant.com
>
>
> On 9/30/07, qihua wu <staywithpin@(protected)> wrote:
> >
> > Hi,
> >
> > I can see both databases spend the majortiy of the time on 'db file
> > sequential read' from the AWR.  Another possiblity is that there are more
> > disk contention on production than on the test database.
> >
> > Thanks,
> > Qihua
> >
> > On 9/30/07, Tony Adolph <tony.adolph.dba@(protected) > wrote:
> > >
> > > Without too much thought, I'd say you're doing index lookups (db file
> > > sequential read') on one db and table scans (db file scattered read)
> > > on the other... are the stats up-to-date on both?
> > >
> > > Is there a particular update that's causing you a problem,...have you
> > > checked and compared the plans?
> > >
> > > I think I'd start there before going to the I/O system.
> > >
> > > HTH
> > > Tony
> > >
> > >
> > > On 9/30/07, qihua wu <staywithpin@(protected) > wrote:
> > > > We have one test database another production database, the data
> > > volumn
> > > > nearly the small. But a single update statement takes about 2,000
> > > seconds on
> > > > test  database, but 7,000 seconds on the productoin database. For
> > > the report
> > > > of OEM, both test database and production database take about 1,500
> > > seconds
> > > > on CPU. But the test database only takes 500 seconds on "sequential
> > > read"
> > > > and production database take 4,500 seconds on "sequential read".
> > > >
> > > > So I ran the following sql on the both database, and found that
> > > single
> > > > sequential read wait time on production is much longer than test
> > > database.
> > > > And I am wondering whether the IO subsystem in production is not as
> > > good as
> > > > test.  What's your opinion on the big difference on "sequential
> > > read'?
> > > >
> > > > BTW,The unix team and SAN team are not easy to appoach, so I must
> > > gather
> > > > evidence to please them look into the IO subsystem. The sql result
> > > is only
> > > > from database level and they won't look at any evidence from
> > > database level.
> > > > Is there any standard unix tool that can test the "sequential read'
> > > speed?
> > > >
> > > > select
> > > >    sum(a.time_waited_micro )/sum(a.total_waits)/1000000 c1,
> > > >    sum(b.time_waited_micro)/sum(b.total_waits)/1000000 c2,
> > > > from
> > > >    dba_hist_system_event a,
> > > >    dba_hist_system_event b
> > > > where
> > > >    a.snap_id = b.snap_id
> > > > and
> > > >    a.event_name = 'db file scattered read'
> > > > and
> > > >    b.event_name = 'db file sequential read';
> > > >
> > >
> >
> >
>

The database is running on hpux. And the sql is the exactly the same on test
and production.<br><br>Thanks,<br>Qihua<br><br><div><span class="gmail_quote"
>On 10/2/07, <b class="gmail_sendername">Vlad Sadilovskiy</b> &lt;<a href=
"mailto:vlovsky@(protected)">
vlovsky@(protected)</a>&gt; wrote:</span><blockquote class="gmail_quote" style=
"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding
-left: 1ex;"><div>Sun iostat -cnmxPz 1 would show you the most of the
information on IO subsystem throughput and lattency as well as the current load
. What is OS you are operating on?
</div><span class="sg">
<div>&nbsp;</div>
<div>Vlad Sadilovskiy<br>Oracle Database Tools<br><a href="http://www
.fourthelephant.com/" target="_blank" onclick="return top.js.OpenExtLink(window
,event,this)">http://www.fourthelephant.com</a><br><br>&nbsp;</div></span><div>
<span class="e" id="q_11562fdb3f27e19d_2">
<div><span class="gmail_quote">On 9/30/07, <b class="gmail_sendername">qihua wu
</b> &lt;<a href="mailto:staywithpin@(protected)" target="_blank" onclick="return
top.js.OpenExtLink(window,event,this)">staywithpin@(protected)</a>
&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204
); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Hi, <br><br>I can see both
databases spend the majortiy of the time on &#39;db file sequential read&#39;
from the AWR.&nbsp; Another possiblity is that there are more disk contention
on production than on the test database.
<br><br>Thanks,<br>Qihua<br><br>
<div><span class="gmail_quote">On 9/30/07, <b class="gmail_sendername">Tony
Adolph</b> &lt;<a href="mailto:tony.adolph.dba@(protected)" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">tony.adolph.dba@(protected)
.com
</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204
); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Without too much thought, I&
#39;d say you&#39;re doing index lookups (db file<br>sequential read&#39;) on
one db and table scans (db file scattered read)
<br>on the other... are the stats up-to-date on both?<br><br>Is there a
particular update that&#39;s causing you a problem,...have you <br>checked and
compared the plans?<br><br>I think I&#39;d start there before going to the I/O
system.
<br><br>HTH<br>Tony
<div><span><br><br><br>On 9/30/07, qihua wu &lt;<a href="mailto:staywithpin
@(protected)" target="_blank" onclick="return top.js.OpenExtLink(window,event,this
)">staywithpin@(protected)</a> &gt; wrote:
<br>&gt; We have one test database another production database, the data volumn
<br>&gt; nearly the small. But a single update statement takes about 2,000
seconds on<br>&gt; test&nbsp;&nbsp;database, but 7,000 seconds on the
productoin database. For the report
<br>&gt; of OEM, both test database and production database take about 1,500
seconds<br>&gt; on CPU. But the test database only takes 500 seconds on &quot
;sequential read&quot;<br>&gt; and production database take 4,500 seconds on
&quot;sequential read&quot;.
<br>&gt;<br>&gt; So I ran the following sql on the both database, and found
that single<br>&gt; sequential read wait time on production is much longer than
test database.<br>&gt; And I am wondering whether the IO subsystem in
production is not as good as
<br>&gt; test.&nbsp;&nbsp;What&#39;s your opinion on the big difference on
&quot;sequential read&#39;?<br>&gt;<br>&gt; BTW,The unix team and SAN team are
not easy to appoach, so I must gather<br>&gt; evidence to please them look into
the IO subsystem. The sql result is only
<br>&gt; from database level and they won&#39;t look at any evidence from
database level.<br>&gt; Is there any standard unix tool that can test the &quot
;sequential read&#39; speed?<br>&gt;<br>&gt; select<br>&gt;&nbsp;&nbsp;&nbsp;
&nbsp;sum(
a.time_waited_micro
)/sum(a.total_waits)/1000000 c1,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;sum(b.time
_waited_micro)/sum(b.total_waits)/1000000 c2,<br>&gt; from<br>&gt;&nbsp;&nbsp;
&nbsp;&nbsp;dba_hist_system_event a,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;dba_hist
_system_event b<br>&gt; where<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;a.snap_id =
b.snap_id<br>&gt; and<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;a.event_name = &#39;db
file scattered read&#39;<br>&gt; and<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;b.event
_name = &#39;db file sequential read&#39;;<br>&gt;<br></span></div></blockquote>
</div><br></blockquote></div>
<br>
</span></div></blockquote></div><br>