Re: 8.1.7.4 migration from 32 bit to 64 bit problem

  • From: "Terry Sutton" <terrysutton@xxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 19 Nov 2004 14:33:55 -0800

Check your underscore init params.  Jonathan Lewis has counted 22
optimizer-related init params which have changed whose defaults have changed
from FALSE to TRUE in 9i.  It's possible that your 32-bit DB had one of
these changed to FALSE, and the 64-bit is TRUE.  Or something like that.

You say your init.ora is the same, but it wouldn't hurt to look at the
parameters in the DB themselves.

As sys:
col parameter   format a50 heading "Instance Parameter and Value"
word_wrapped
col description format a20 heading "Description" word_wrapped
col dflt        format a5  heading "Dflt?" word_wrapped

select  rpad(i.ksppinm, 35) || ' = ' || v.ksppstvl parameter,
        i.ksppdesc description,
        v.ksppstdf dflt
from    x$ksppi         i,
        x$ksppcv        v
where   v.indx = i.indx
and     v.inst_id = i.inst_id
and     i.ksppinm like '&name%'
order by i.ksppinm
/

--Terry
full disclosure-- I believe the query above originated with Tim Gorman.

----- Original Message ----- 
From: "Duret, Kathy" <kduret@xxxxxxxxxxxxxxxxxxxx>
To: <Ron.Reidy@xxxxxxxxxxxxxxxxxx>; <mark.powell@xxxxxxx>;
<oracle-l@xxxxxxxxxxxxx>
Sent: Friday, November 19, 2004 1:32 PM
Subject: RE: 8.1.7.4 migration from 32 bit to 64 bit problem


The explan plans are very long but it boils down to now the bad explain plan
is doing a merge cartesian join.

I have tried various things, including re:

alter session set optimizer_mode='RULE';

 alter session set optimizer_index_cost_adj=50;
 alter session set optimizer_index_caching=90;

 alter session set optimizer_index_cost_adj=1;
 alter session set optimizer_index_caching=100;

putting ordered and use_nl in all the views,
 setting the _complex_view parameter and bouncing the database.

INcreasing the SGA.

I am willing to trying anything at this point...

Kathy

-----Original Message-----
From: Reidy, Ron [mailto:Ron.Reidy@xxxxxxxxxxxxxxxxxx]
Sent: Friday, November 19, 2004 3:05 PM
To: kduret@xxxxxxxxxxxxxxxxxxxx; mark.powell@xxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: RE: 8.1.7.4 migration from 32 bit to 64 bit problem


Can you post both plans?

Maybe someone here can give you an idea.

-----------------
Ron Reidy
Lead DBA
Array BioPharma, Inc.


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Duret, Kathy
Sent: Friday, November 19, 2004 1:48 PM
To: 'mark.powell@xxxxxxx'; 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: 8.1.7.4 migration from 32 bit to 64 bit problem



Nothing was changed..... I tried to increase the shared pool on the new =
dev
version and bounced it.... no good.

I am trying various hints in all the views and sub views to no avail.  I
finally got a descent tech now for my tar....=20

Yes I just updated the stats again for the new tech.  I am going to give =
him
a 10053 trace as well.  The explain plan for the new database is very
strange for this query.

Kathy
-----Original Message-----
From: Powell, Mark D [mailto:mark.powell@xxxxxxx]
Sent: Friday, November 19, 2004 2:06 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: RE: 8.1.7.4 migration from 32 bit to 64 bit problem


Sometimes even a small change in plans can result in a large change in
performance for the query depending on what the change is.

Were the statistics updated on the new version?

Was the shared pool increased in size to compensate for the additional 4
bytes in every address pointer used.  The 64 bit version of 8.1.7 needs
about a 20% increase in the shared pool just to run the same load in our
experience, but then we have a lot of stored code (pl/sql in the =
database).

Were any database parameters changed?

HTH -- Mark D Powell --


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Jeremiah Wilton
Sent: Friday, November 19, 2004 2:09 PM
To: Oracle L (E-mail)
Subject: RE: 8.1.7.4 migration from 32 bit to 64 bit problem


Sorry if this has been explored, but it sounds like the difference in
the plans is the problem.  Can you elaborate on WHAT is different
about the plans?

Is something else hogging temp?

--
Jeremiah Wilton
Independent Oracle Professional
Oracle Certified Master
Disaster Recovery - Seminars - Technical Interviews
http://www.speakeasy.net/~jwilton

On Fri, 19 Nov 2004, Duret, Kathy wrote:

> two database set up is EXACTLY the same (init.ora, files size etc)
>
> Query using two views in OLD 32 bit runs in 2 seonds and with the =
WHOLE
> company running on the database uses less than 1/2 G of temp =
tablespaces.
>
> Query ONLY running on new production database get ora-1652 (out of =
temp
> space) on 1G of temp space after 81 seconds.
>
> Once again same set up, same data,  BUT the explain plans are =
different
but
> are fairly similiar.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l



This transmission contains information solely for intended recipient and =
may
be privileged, confidential and/or otherwise protect from disclosure.  =
If
you are not the intended recipient, please contact the sender and delete =
all
copies of this transmission.  This message and/or the materials =
contained
herein are not an offer to sell, or a solicitation of an offer to buy, =
any
securities or other instruments.  The information has been obtained or
derived from sources believed by us to be reliable, but we do not =
represent
that it is accurate or complete.  Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject =
to
change without notice.  Any information you share with us will be used =
in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written =
agreement,
we are not agreeing to treat any information confidentially and will use =
any
and all information and reserve the right to publish or disclose any
information you share with us.
--
//www.freelists.org/webpage/oracle-l

This electronic message transmission is a PRIVATE communication which =
contains
information which may be confidential or privileged. The information is =
intended=20
to be for the use of the individual or entity named above. If you are =
not the=20
intended recipient, please be aware that any disclosure, copying, =
distribution=20
or use of the contents of this information is prohibited. Please notify =
the
sender  of the delivery error by replying to this message, or notify us =
by
telephone (877-633-2436, ext. 0), and then delete it from your system.

--
//www.freelists.org/webpage/oracle-l



This transmission contains information solely for intended recipient and may
be privileged, confidential and/or otherwise protect from disclosure.  If
you are not the intended recipient, please contact the sender and delete all
copies of this transmission.  This message and/or the materials contained
herein are not an offer to sell, or a solicitation of an offer to buy, any
securities or other instruments.  The information has been obtained or
derived from sources believed by us to be reliable, but we do not represent
that it is accurate or complete.  Any opinions or estimates contained in
this information constitute our judgment as of this date and are subject to
change without notice.  Any information you share with us will be used in
the operation of our business, and we do not request and do not want any
material, nonpublic information. Absent an express prior written agreement,
we are not agreeing to treat any information confidentially and will use any
and all information and reserve the right to publish or disclose any
information you share with us.
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l

Other related posts: