CROSS Massive JOIN in SQL Server 2005
https://stackoverflow.com/questions/354981
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sono porting di un processo che crea una massiccia CROSS JOIN di due tavoli. La tabella risultante contiene record 15m (sembra il processo rende una croce 30m join con una tabella 2600 riga e un tavolo 12000 fila e poi fa qualche raggruppamento che deve diviso a metà). Le file sono relativamente stretti - appena 6 colonne. E 'stato in esecuzione per 5 ore senza alcun segno di completamento. Ho appena notato la discrepanza conteggio tra il noto buono e ciò che ci si aspetterebbe per il cross join, quindi la mia uscita non ha il raggruppamento o deduping che dimezzare il tavolo finale - ma questo sembra ancora non sta andando per completare qualsiasi momento presto.
Per prima cosa ho intenzione di cercare di eliminare questo tavolo dal processo se possibile - ovviamente potrebbe essere sostituito unendo ad entrambe le tabelle singolarmente, ma in questo momento non ho la visibilità in tutto il resto viene utilizzato <. / p>
Ma dato che il processo attuale lo fa (in meno tempo, su una macchina meno potente, usando il linguaggio FOCUS), sono delle opzioni per migliorare le prestazioni dei grandi <=> s in SQL Server (2005) (hardware lì in realtà non è un'opzione, questa casella è un 64-bit a 8 vie con 32 GB di RAM)?
dettagli:
E 'scritto in questo modo a fuoco (sto cercando di produrre la stessa uscita, che è un CROSS JOIN in SQL):
JOIN CLEAR *
DEFINE FILE COSTCENT
WBLANK/A1 = ' ';
END
TABLE FILE COSTCENT
BY WBLANK BY CC_COSTCENT
ON TABLE HOLD AS TEMPCC FORMAT FOCUS
END
DEFINE FILE JOINGLAC
WBLANK/A1 = ' ';
END
TABLE FILE JOINGLAC
BY WBLANK BY ACCOUNT_NO BY LI_LNTM
ON TABLE HOLD AS TEMPAC FORMAT FOCUS INDEX WBLANK
JOIN CLEAR *
JOIN WBLANK IN TEMPCC TO ALL WBLANK IN TEMPAC
DEFINE FILE TEMPCC
CA_JCCAC/A16=EDIT(CC_COSTCENT)|EDIT(ACCOUNT_NO);
END
TABLE FILE TEMPCC
BY CA_JCCAC BY CC_COSTCENT AS COST CENTER BY ACCOUNT_NO
BY LI_LNTM
ON TABLE HOLD AS TEMPCCAC
END
Quindi la potenza richiesta in realtà è un CROSS JOIN (è aderire ad una colonna vuota da ogni lato).
In SQL:
CREATE TABLE [COSTCENT](
[COST_CTR_NUM] [int] NOT NULL,
[CC_CNM] [varchar](40) NULL,
[CC_DEPT] [varchar](7) NULL,
[CC_ALSRC] [varchar](6) NULL,
[CC_HIER_CODE] [varchar](20) NULL,
CONSTRAINT [PK_LOOKUP_GL_COST_CTR] PRIMARY KEY NONCLUSTERED
(
[ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [JOINGLAC](
[ACCOUNT_NO] [int] NULL,
[LI_LNTM] [int] NULL,
[PR_PRODUCT] [varchar](5) NULL,
[PR_GROUP] [varchar](1) NULL,
[AC_NAME_LONG] [varchar](40) NULL,
[LI_NM_LONG] [varchar](30) NULL,
[LI_INC] [int] NULL,
[LI_MULT] [int] NULL,
[LI_ANLZ] [int] NULL,
[LI_TYPE] [varchar](2) NULL,
[PR_SORT] [varchar](2) NULL,
[PR_NM] [varchar](26) NULL,
[PZ_SORT] [varchar](2) NULL,
[PZNAME] [varchar](26) NULL,
[WANLZ] [varchar](3) NULL,
[OPMLNTM] [int] NULL,
[PS_GROUP] [varchar](5) NULL,
[PS_SORT] [varchar](2) NULL,
[PS_NAME] [varchar](26) NULL,
[PT_GROUP] [varchar](5) NULL,
[PT_SORT] [varchar](2) NULL,
[PT_NAME] [varchar](26) NULL
) ON [PRIMARY]
CREATE TABLE [JOINCCAC](
[CA_JCCAC] [varchar](16) NOT NULL,
[CA_COSTCENT] [int] NOT NULL,
[CA_GLACCOUNT] [int] NOT NULL,
[CA_LNTM] [int] NOT NULL,
[CA_UNIT] [varchar](6) NOT NULL,
CONSTRAINT [PK_JOINCCAC_KNOWN_GOOD] PRIMARY KEY CLUSTERED
(
[CA_JCCAC] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
Con il codice SQL:
INSERT INTO [JOINCCAC]
(
[CA_JCCAC]
,[CA_COSTCENT]
,[CA_GLACCOUNT]
,[CA_LNTM]
,[CA_UNIT]
)
SELECT Util.PADLEFT(CONVERT(varchar, CC.COST_CTR_NUM), '0',
7)
+ Util.PADLEFT(CONVERT(varchar, GL.ACCOUNT_NO), '0',
9) AS CC_JCCAC
,CC.COST_CTR_NUM AS CA_COSTCENT
,GL.ACCOUNT_NO % 900000000 AS CA_GLACCOUNT
,GL.LI_LNTM AS CA_LNTM
,udf_BUPDEF(GL.ACCOUNT_NO, CC.COST_CTR_NUM, GL.LI_LNTM, 'N') AS CA_UNIT
FROM JOINGLAC AS GL
CROSS JOIN COSTCENT AS CC
A seconda di come questa tabella viene successivamente utilizzato, dovrebbe essere in grado di essere eliminati dal processo, semplicemente unendo a entrambe le tabelle originali utilizzati per costruire. Tuttavia, questo è un estremamente grande sforzo di porting, e potrebbe non trovare l'uso della tabella per qualche tempo, quindi mi chiedevo se ci fossero trucchi per <=> ing grandi tavoli del genere in modo tempestivo (specialmente dato che il processo esistente in Focus è in grado di farlo più rapidamente). In questo modo ho potuto convalidare la correttezza del mio palazzo della query sostituzione e poi fattore fuori con vista o qualsiasi altra cosa.
Inoltre sto pensando di factoring fuori la manipolazione UDF e stringhe ed eseguendo il CROSS JOIN primo a rompere il processo un po '.
risultati finora:
Si scopre che le UDF contribuiscono molto (negativamente) alla performance. Ma ci sembra anche essere una grande differenza tra una fila 15m croce uniscono e 30m fila trasversale aderire. Non ho diritti SHOWPLAN (boo hoo), quindi non posso dire se il piano si sta usando è meglio o peggio dopo aver cambiato gli indici. Non ho ancora refactoring, ma sto aspettando l'intera tabella di andare via a breve.
Soluzione
Esaminando tale query mostra solo una colonna utilizzata da una tabella, e solo due colonne utilizzate dalla tabella. A causa delle molto basso numero di colonne utilizzate, questa ricerca può essere facilmente migliorata con indici di copertura:
CREATE INDEX COSTCENTCoverCross ON COSTCENT(COST_CTR_NUM)
CREATE INDEX JOINGLACCoverCross ON JOINGLAC(ACCOUNT_NO, LI_LNTM)
Ecco le mie domande per un'ulteriore ottimizzazione:
Quando si inserisce la query in Query Analyzer e colpire il pulsante "Mostra stimato esecuzione piano", mostrerà una rappresentazione grafica di quello che sta per fare.
Join Type: Ci dovrebbe essere un join ciclo nidificato in là. (Le altre opzioni sono merge join e hash join). Se si vede ciclo nidificato, quindi OK. Se si vede fondersi aderire o hash join, fateci sapere.
Ordine di accesso tabella: andare fino in fondo verso l'alto e scorrere tutta la strada a destra. Il primo passo dovrebbe essere accede a una tabella. Quale tavolo è quello e quale metodo viene utilizzato (indice di scansione, scan indice cluster)? Quale metodo viene utilizzato per accedere all'altro tavolo?
Parallelismo: Si dovrebbe vedere le piccole frecce jaggedy su quasi tutte le icone nel piano che indica che il parallelismo è in uso. Se non vedi questo, v'è un grosso problema!
Questo udf_BUPDEF mi preoccupa. Ha letto da altre tabelle? Util.PADLEFT mi preoccupa di meno, ma ancora .. cosa si tratta? Se non è un oggetto di database, allora considerare l'utilizzo di questo, invece:
RIGHT('z00000000000000000000000000' + columnName, 7)
Ci sono trigger su JOINCCAC? Come sugli indici? Con un inserto questo grande, ti consigliamo di eliminare tutti i trigger e gli indici su quel tavolo.
Altri suggerimenti
Continuando su ciò che gli altri un modo di dire, le funzioni di DB che conteneva le query che vengono utilizzati in un prescelto sempre fatto le mie domande estremamente lento. Fuori della parte superiore della mia testa, credo che ho avuto una query eseguire in 45 secondi, poi ho tolto la funzione, e quindi risultato è stato 0 secondi:)
Quindi controllare udf_BUPDEF non sta facendo qualsiasi domanda.
abbattere le query per rendere una semplice croce pianura aderire.
SELECT CC.COST_CTR_NUM, GL.ACCOUNT_NO
,CC.COST_CTR_NUM AS CA_COSTCENT
,GL.ACCOUNT_NO AS CA_GLACCOUNT
,GL.LI_LNTM AS CA_LNTM
-- I don't know what is BUPDEF doing? but remove it from the query for time being
-- ,udf_BUPDEF(GL.ACCOUNT_NO, CC.COST_CTR_NUM, GL.LI_LNTM, 'N') AS CA_UNIT
FROM JOINGLAC AS GL
CROSS JOIN COSTCENT AS CC
Vedi quanto è buono è la semplice croce associarsi? (Senza funzioni applicati su di esso)
