query stesse, server diversi, diversi piani exec, statistiche sono aggiornate

Question

Ho la stessa query in esecuzione su due server diversi, e ottenere prestazioni molto diverse. Ho aggiornato tutte le statistiche su oggetti dipendenti e non ha risolto il problema. Mi sono perso su dove rivolgersi successiva.

Ecco quello che i piani assomigliano, la parte superiore beign l'esecuzione Dex (quello che funziona), e la parte inferiore è l'esecuzione del test (il lento).

modifica: ecco cosa gli sguardi SQL come:

ALTER procedure [ardb].[NewProjects] 
    -- Add the parameters for the stored procedure here
as 
begin
    -- SET NOCOUNT ON added to prevent extra result sets from
    -- interfering with SELECT statements.
    set NOCOUNT on ;

    -- Insert statements for procedure here



;with b as
(
    select distinct
        coalesce(a.STUDY_NUMBER,b.STUDY_NUMBER, c.study_number) as StudyNumber
    from
    (
        SELECT     SUBSTRING(PAPROJNUMBER, 1, 5) AS STUDY_NUMBER
        FROM         appdb.PROD.dbo.PA01201 AS PA01201_1
        where PAPROJNUMBER>'0'
            and PAPROJNUMBER not like '%[a-z]%'
    ) a
        full outer join
        (
            SELECT     SUBSTRING(PAPROJNUMBER, 1, 5) AS STUDY_NUMBER
            FROM        appdb.MO1.dbo.PA01201 AS PA01201_1
            where PAPROJNUMBER>'0'
                and PAPROJNUMBER not like '%[a-z]%'
        ) b
            on a.STUDY_NUMBER=b.STUDY_NUMBER
        full outer join 
        (
            SELECT     STUDY_NUMBER
            FROM         appdb.ptwdb.dbo.tblARCompletedStudies
            where STUDY_NUMBER>'0'
        ) c
            on a.STUDY_NUMBER=c.study_number
                and b.STUDY_NUMBER=c.study_number
)

select
    snStudyNumber as ProjectNumber,
    c.clName as CompanyName,
    q.quQuoteNumber as QuoteNumber,
    q.quQuoteID as QuoteID,
    q.quDateWon as DateWon,
    s.snPTWCompletionDate as PTWCompletionDate
from CDB.cdb.Quotes q
    inner join CDB.cdb.LineItems l
        on q.PK_quID=l.FK_quID
    inner join CDB.cdb.StudyNumbers s
        on l.FK_snID=s.PK_snId
    inner join cdb.cdb.Clients c
        on q.FK_clID=c.PK_clID
    left outer join ardb.projects p
        on s.snStudyNumber=p.prProjectNumber
    left outer join b
        on s.snStudyNumber=b.studynumber
where q.quDateWon>''
    and s.snPTWCompletionDate >''
    and p.PK_prID is null
    and l.liCreationDate>'12/31/06'
    and b.studynumber is null
union all

select CAST(ProjectNumber AS int) as ProjectNumber,
    null as CompanyName,
    null as QuoteNumber,
    null as QuoteID,
    null as DateWon,
    null as PTWCompletionDate
from history.ProjectsToProcess a
    left outer join ardb.projects p
        on a.ProjectNumber=p.prProjectNumber
where p.PK_prID is null

order by ProjectNumber desc





end

piani xml: qui

Answer 1

Nel piano lento, il sotto-albero piano che contiene tutte le query remote viene eseguita 2928 volte. Sarebbe stato 3632 volte (il numero di righe sull'ingresso esterno agli anelli nidificati aderire che ha la sub-struttura di query remota sul suo lato interno), ma il Distinct Sort è in grado di riavvolgimento (riutilizzo) risultati previo di iterazione su un numero di occasioni.

Nel piano veloce, il join è un join hash piuttosto che cicli annidati, in modo che il sotto-albero problematica viene eseguito solo una volta. Come al solito, la causa è probabilmente le piccole differenze di stima di cardinalità (visibili nel piano come conteggi stimati riga) e istogrammi derivati ??e le statistiche di distribuzione (non così visibile). Questa variazione è probabilmente dovuto al leggermente diversi campioni prelevati per le statistiche di costruzione sia le statistiche costruite in tempi diversi tra dev e test.

Per convalidare rapidamente questo, si potrebbe aggiungere OPTION (HASH JOIN) alla query. C'è un piccolo rischio che l'ottimizzatore si lamenterà che non può produrre un piano con quel suggerimento. Non ho analizzato il piano abbastanza profondamente da prevedere che, e questo suggerimento è solo a scopo dimostrativo. Non è la mia soluzione suggerita .

Una correzione migliore è quello di rompere la query in sezioni. Refactoring trasformazione sottoalbero query remota in una query separata, e memorizzare i 6737 righe che produce in una tabella temporanea. Probabilmente si desidera utilizzare una tabella #temporary piuttosto che una variabile di tabella, dal momento che si otterrà statistiche generati automaticamente, e si avrà una più ampia gamma di possibilità di indicizzazione, dovrebbe che rivelarsi utile.

query con molti join e query remote hanno un numero molto elevato di possibili accordi. Rompendo la query in modo ragionevole, e fornendo le statistiche (e forse indici) si stanno dando l'ottimizzatore informazioni migliore e una più piccola spazio di ricerca da esplorare. Le vostre probabilità di un buon piano salgono proporzionalmente.

Answer 2

Sembra che il problema potrebbe essere con le Remote Query Operatori Showplan. Essi sono i più costosi, agganciare fuori a 38,9% e 14,5% per le query lente. Puoi darci un po 'più informazioni per quanto riguarda la fonte di tali domande e l'esecuzione basata su di essi?

Esegui una traccia con SQL Profiler per vedere dove le durate più lunghe sono sulla query lenta, e confrontarle con quello della query più veloce. Sarete in grado di individuare le normative / procedure che sono i più costosi e che sarà restringere la risoluzione dei problemi.