|
IDS Forum
Re: RSS/HDT Sec - Different Query Plans???
Posted By: Fernando Nunes Date: Wednesday, 8 July 2015, at 5:19 p.m.
In Response To: Re: RSS/HDT Sec - Different Query Plans??? (Art Kagel)
For reference, now that I got a couple of minutes:
http://www-01.ibm.com/support/docview.wss?uid=swg1IC73133
I think there was also one for the procedure cache.
It would be interesting to see if the nrows column of systables is the same
on both servers.
Another scenario I saw once was that one create index was no properly
replicated (the index was not usable on an RSS or HDR server).
But from what I recall, in that case the query plan, or the query withing
the query plan was shown twice... Because basically the engine attempted to
use the index, and when it found it couldn't then it recalculated
(silently) another query plan and executed it.
Again, a PMR was opened and a bug created... but this was a bit more weird
and I'd need to dive deeper to find it.
In most situations, differences on parameters or session settings was the
most common cause for the differences.
Regards
On Wed, Jul 8, 2015 at 4:33 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Run it on either. I assume that the row counts are the same on both
> servers.
>
> Art
>
> Art S. Kagel, President and Principal Consultant
> ASK Database Management
> www.askdbmgt.com
>
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on the IIUG, nor any other organization with which I am
> associated either explicitly, implicitly, or by inference. Neither do
> those opinions reflect those of other individuals affiliated with any
> entity with which I am affiliated nor those of the entities themselves.
>
> On Wed, Jul 8, 2015 at 11:05 AM, Mueller, Daniel D. <
> ddmueller@intercall.com
> > wrote:
>
> > Art,
> >
> > Cannot answer the actual number of rows at this time. This was discovered
> > during some month end processing a few days ago and I was not involved.
> The
> > DBA on call switched them to run on the RSS vs the HDR and the query ran
> in
> > the expected time. I have not fully run the query, only with
> avoid_execute.
> > That is how I got the plans.
> >
> > The reservation.site_call_date IS indexed. It is a btree non-unique
> index.
> > We
> > run your dostats for the distribution weekly. I actually unloaded the
> rows
> > from sysdistrib for the tabid/colon and ran the results through diff.
> They
> > are
> > all identical.
> >
> > Would it be helpful to executw the entire query on both secondaries for
> the
> > row count?
> >
> > Thanx,
> > Dan
> >
> > -----Original Message-----
> > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art
> > Kagel
> > Sent: Wednesday, July 08, 2015 10:22 AM
> > To: ids@iiug.org
> > Subject: Re: RSS/HDT Sec - Different Query Plans??? [35404]
> >
> > Dan:
> >
> > Both queries estimate 12,383,288 rows returned what is the actual count?
> >
> > I agree that the main issue is that the query plans are different and
> > perform
> > differently, but I suspect that neither is optimal. Are there
> > distributions on
> > the reservation.site_call_date column? Is it indexed?
> >
> > Art
> >
> > Art S. Kagel, President and Principal Consultant ASK Database Management
> > www.askdbmgt.com
> >
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own opinions
> > and
> > do not reflect on the IIUG, nor any other organization with which I am
> > associated either explicitly, implicitly, or by inference. Neither do
> those
> > opinions reflect those of other individuals affiliated with any entity
> with
> > which I am affiliated nor those of the entities themselves.
> >
> > On Wed, Jul 8, 2015 at 9:53 AM, DAN MUELLER <ddmueller@intercall.com>
> > wrote:
> >
> > > Forgive the long post but I have been asked for the 2 sqexplain
> outputs.
> > > Also,
> > > just because nothiung is easy, the 2 secondaries were switched from
> > > their origunal status. IE... What is now the NDR SEC was originally an
> > > RSS Sec and vice versa. Not sure if that plays into this or not. Also,
> > > it seems to be to be time to open a PMR.
> > >
> > > HDR QUERY PLAN
> > >
> > > QUERY: (OPTIMIZATION TIMESTAMP: 07-06-2015 13:51:05)
> > > ------
> > > SELECT reservation.res_id , reservation.conference_id ,
> > > reservation.owner_number , reservation.site_id , reservation.series_id
> > > , reservation.call_date , reservation.timezone_code ,
> > > reservation.reservation_status , reservation.placed_via ,
> > > reservation.employee_id , reservation.call_setup_mins ,
> > > reservation.site_call_date , reservation.bu_call_date ,
> > > reservation.duration , reservation.legs , reservation.call_type ,
> > > reservation.special_indicator , reservation.bridge_id ,
> > > reservation.team_id , reservation.pac_code_value ,
> > > reservation.per_fname , reservation.per_lname ,
> > > reservation.per_position , reservation.per_country_code ,
> > > reservation.per_phone_num , reservation.per_ext ,
> > > reservation.per_fax_num , reservation.per_email ,
> > > reservation.ldr_fname , reservation.ldr_lname ,
> > > reservation.ldr_position , reservation.ldr_country_code ,
> > > reservation.ldr_phone_num , reservation.ldr_ext ,
> > > reservation.ldr_fax_num , reservation.ldr_email ,
> > > reservation.confirm_fax_num , reservation.confirm_country_code ,
> > > reservation.confirm_email , reservation.confirm_format ,
> > > reservation.confirm_fmt , reservation.password ,
> > > reservation.setup_status , reservation.upper_ldr_lname ,
> > > reservation.date_added , reservation.progress_res , reservation.topic
> > > , reservation.acct_specialist , reservation.schedule_ind ,
> > > reservation.bridge_conf_num , reservation.premium ,
> > > reservation.walk_thru_flag , reservation.cancel_date ,
> > > reservation.do_conf_only , reservation.template_id FROM informix.owner
> > > owner, informix.account account, informix.company company,
> > > informix.reservation reservation where ( company.bu_id = 1 OR
> > > company.bu_id = 4) and ( account.company_number =
> > > company.company_number ) and ( reservation.owner_number =
> > > owner.owner_number ) and ( owner.account_number =
> > > account.account_number ) and ( reservation.site_call_date >
> > > '2015-06-01 00:00:00' )
> > >
> > > Estimated Cost: 42464232
> > > Estimated # of Rows Returned: 12383288
> > >
> > > 1) informix.company: INDEX PATH
> > >
> > > (1) Index Name: informix.idx_co_bu_co
> > >
> > > Index Keys: bu_id company_number (Key-Only) (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.company.bu_id = 1
> > >
> > > (2) Index Name: informix.idx_co_bu_co
> > >
> > > Index Keys: bu_id company_number (Key-Only) (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.company.bu_id = 4
> > >
> > > 2) informix.account: SEQUENTIAL SCAN
> > >
> > > DYNAMIC HASH JOIN (Build Outer)
> > >
> > > Dynamic Hash Filters: informix.account.company_number =
> > > informix.company.company_number
> > >
> > > 3) informix.owner: INDEX PATH
> > >
> > > (1) Index Name: informix.idx_own_acct_own
> > >
> > > Index Keys: account_number owner_number (Key-Only) (Serial, fragments:
> > > ALL)
> > >
> > > Lower Index Filter: informix.owner.account_number =
> > > informix.account.account_number NESTED LOOP JOIN
> > >
> > > 4) informix.reservation: SEQUENTIAL SCAN
> > >
> > > Filters:
> > >
> > > Table Scan Filters: informix.reservation.site_call_date >
> > > datetime(2015-06-01
> > > 00:00:00) year to second
> > >
> > > DYNAMIC HASH JOIN (Build Outer)
> > >
> > > Dynamic Hash Filters: informix.reservation.owner_number =
> > > informix.owner.owner_number
> > >
> > > RSS QUERY PLAN
> > >
> > > QUERY: (OPTIMIZATION TIMESTAMP: 07-06-2015 13:44:06)
> > > ------
> > > SELECT reservation.res_id , reservation.conference_id ,
> > > reservation.owner_number , reservation.site_id , reservation.series_id
> > > , reservation.call_date , reservation.timezone_code ,
> > > reservation.reservation_status , reservation.placed_via ,
> > > reservation.employee_id , reservation.call_setup_mins ,
> > > reservation.site_call_date , reservation.bu_call_date ,
> > > reservation.duration , reservation.legs , reservation.call_type ,
> > > reservation.special_indicator , reservation.bridge_id ,
> > > reservation.team_id , reservation.pac_code_value ,
> > > reservation.per_fname , reservation.per_lname ,
> > > reservation.per_position , reservation.per_country_code ,
> > > reservation.per_phone_num , reservation.per_ext ,
> > > reservation.per_fax_num , reservation.per_email ,
> > > reservation.ldr_fname , reservation.ldr_lname ,
> > > reservation.ldr_position , reservation.ldr_country_code ,
> > > reservation.ldr_phone_num , reservation.ldr_ext ,
> > > reservation.ldr_fax_num , reservation.ldr_email ,
> > > reservation.confirm_fax_num , reservation.confirm_country_code ,
> > > reservation.confirm_email , reservation.confirm_format ,
> > > reservation.confirm_fmt , reservation.password ,
> > > reservation.setup_status , reservation.upper_ldr_lname ,
> > > reservation.date_added , reservation.progress_res , reservation.topic
> > > , reservation.acct_specialist , reservation.schedule_ind ,
> > > reservation.bridge_conf_num , reservation.premium ,
> > > reservation.walk_thru_flag , reservation.cancel_date ,
> > > reservation.do_conf_only , reservation.template_id FROM informix.owner
> > > owner, informix.account account, informix.company company,
> > > informix.reservation reservation where ( company.bu_id = 1 OR
> > > company.bu_id = 4) and ( account.company_number =
> > > company.company_number ) and ( reservation.owner_number =
> > > owner.owner_number ) and ( owner.account_number =
> > > account.account_number ) and ( reservation.site_call_date >
> > > '2015-06-01 00:00:00' )
> > >
> > > Estimated Cost: 87333752
> > > Estimated # of Rows Returned: 12383288
> > >
> > > 1) informix.reservation: SEQUENTIAL SCAN
> > >
> > > Filters: informix.reservation.site_call_date > datetime(2015-06-01
> > > 00:00:00)
> > > year to second
> > >
> > > 2) informix.owner: INDEX PATH
> > >
> > > (1) Index Name: informix.idx_owner_pk
> > >
> > > Index Keys: owner_number (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.reservation.owner_number =
> > > informix.owner.owner_number NESTED LOOP JOIN
> > >
> > > 3) informix.account: INDEX PATH
> > >
> > > (1) Index Name: informix.idx_account_pk
> > >
> > > Index Keys: account_number (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.owner.account_number =
> > > informix.account.account_number NESTED LOOP JOIN
> > >
> > > 4) informix.company: INDEX PATH
> > >
> > > (1) Index Name: informix.idx_co_bu_co
> > >
> > > Index Keys: bu_id company_number (Key-Only) (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.company.bu_id = 1
> > >
> > > (2) Index Name: informix.idx_co_bu_co
> > >
> > > Index Keys: bu_id company_number (Key-Only) (Serial, fragments: ALL)
> > >
> > > Lower Index Filter: informix.company.bu_id = 4
> > >
> > > DYNAMIC HASH JOIN
> > >
> > > Dynamic Hash Filters: informix.account.company_number =
> > > informix.company.company_number
> > >
> > >
> > >
> > >
> >
> >
> >
>
> *******************************************************************************
> > > Forum Note: Use "Reply" to post a response in the discussion forum.
> > >
> > >
> >
> > --047d7bdc11bc5f0b09051a5ddcfa
> >
> >
> >
> >
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
> >
> >
>
> *******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --089e0116197aa4c8d4051a5edaf8
>
>
>
> *******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--001a113e12b8e6cb21051a63b161
Messages In This Thread
IDS Forum is maintained by Administrator with WebBBS 5.12.
|
|