Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

640: QPlan sanity failure (1403.0)

70 views
Skip to first unread message

Zunino, Kathy

unread,
Feb 26, 2002, 11:09:33 AM2/26/02
to

I ran into this problem on 7.31.UC2... The only solution I found was to run
"update statistics for procedure xxx;" where xxx was the offending SPL.


-----Original Message-----
From: vivek.c...@st.com [mailto:vivek.c...@st.com]
Sent: Friday, February 22, 2002 1:23 PM
To: inform...@iiug.org
Subject: 640: QPlan sanity failure (1403.0)


We are planning to migrate from I7.31FC7 to I7.31FD3. But we are
running into this problem. This bug occurs while using "DISTINCT" in a
stored procedure. Tech. Support says that work around is to run "update
statistics low drop distribution" and then run update statistics. As
many of you are in the same situation, I don't have the luxury of
couple of hours to run "update statistics". Informix is running on
HP-UX 11.

Somebody suggested to disable PDQ which worked for some of the stored
procedures but then problem still exists.

Any input or suggestions would be greatly appreciated. I will post the
solution once I find one.

Vivek Chaudhary


**********************************************************************
Privileged/Confidential information may be contained in this message.
If you are not an addressee indicated in this message (or responsible
for delivery of the message to such person[s]), you may not copy or
deliver this message to anyone. If you have received this message in
error, you should destroy and delete it from your computer and notify
the sender by reply email. Opinions, conclusions and other information
in this message that do not relate to the official business of
Diversified Collection Services shall be understood as neither given
nor endorsed by the company. Accordingly, Diversified Collection
Services disclaims all responsibility and accepts no responsibility for
the consequences of any person(s) acting, or refraining from acting,
on such information prior to the receipt by that person(s) of
subsequent written confirmation.
**********************************************************************

vivek.c...@st.com

unread,
Feb 26, 2002, 11:12:16 AM2/26/02
to

Did you have to run "update statistics low drop distribution" also. Or
just running update statistics for
procedures was sufficient.

thanks

Vivek

Zunino, Kathy

unread,
Feb 26, 2002, 11:15:21 AM2/26/02
to

In my case; just the update statistics on procedure. A note though: in my
case, the 2 SPLs affected were pretty isolated, meaning they did not call
other SPLs, and they were not called by other SPLs, they simply
updated/inserted into a couple of tables. In my engine, I have many SPLs
which call other SPLs, and running 'update statisti

Zunino, Kathy

unread,
Feb 26, 2002, 11:16:36 AM2/26/02
to

In my case; just the update statistics on procedure. A note though: in my
case, the 2 SPLs affected were pretty isolated, meaning they did not call
other SPLs, and they were not called by other SPLs, they simply
updated/inserted into a couple of tables. In my engine, I have many SPLs
which call other SPLs, and running 'update statistics' on an SPL can cause
710s on any parent SPLs (unless you run 'update statistics' on the parent(s)
too).

Zunino, Kathy

unread,
Feb 26, 2002, 12:20:30 PM2/26/02
to

In retrospect, this occured about 2 1/2 or 3 years ago... I don't remember
for sure whether or not I did update stats on the tables as well; but I am
sure that I didn't 'drop distributions'. In my specific case, the SPL was
on engine A updating/inserting into tables which were synonyms over to
engine B.
0 new messages