CROSS JOIN masiva en SQL Server 2005
https://stackoverflow.com/questions/354981
-
21-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy portar un proceso que crea una masiva CROSS JOIN de dos tablas. La tabla resultante contiene registros 15m (parece que el proceso hace una cruz 30m unirse con una fila de la tabla 2600 y una mesa 12000 fila y luego hace algún tipo de agrupación que debe dividir por la mitad). Las filas son relativamente estrecho - sólo 6 columnas. Ha estado funcionando durante 5 horas con ninguna señal de finalización. Sólo he dado cuenta de la discrepancia recuento entre lo conocido bien y lo que se espera para la combinación cruzada, por lo que mi salida no tiene la agrupación o deduping que reducir a la mitad la mesa final - pero esto todavía parece que no va a completar cualquier en el corto plazo.
En primer lugar voy a mirar para eliminar esta tabla del proceso si es posible - es obvio que podría ser sustituido por unirse a ambas tablas de forma individual, pero en este momento no tengo visibilidad en todos los demás sitios se utiliza <. / p>
Sin embargo, dado que el proceso existente hace (en menos tiempo, en una máquina menos potente, utilizando el lenguaje de FOCUS), ¿existen opciones para mejorar el rendimiento de grandes <=> s en SQL Server (2005) (hardware no es realmente una opción, esta caja es una de 8 vías 64 bits con 32 GB de RAM)?
detalles:
Se escribe de esta manera en FOCUS (estoy tratando de producir la misma salida, que es una CROSS JOIN en 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
Así que la salida requerida realmente es unirse a una cruz (que ha de unirse a una columna en blanco de cada lado).
En 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 el Código de 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
En función de cómo se utiliza posteriormente esta tabla, debe ser capaz de ser eliminado del proceso, simplemente uniéndose a ambas las tablas originales utilizados para su construcción. Sin embargo, este es un esfuerzo de portar extremadamente grande, y yo no podría encontrar el uso de la mesa desde hace algún tiempo, así que me preguntaba si había alguna trucos para <=> ing grandes mesas como que en el momento oportuno (especialmente teniendo en cuenta que el proceso existente en el foco es capaz de hacerlo con mayor rapidez). De esa manera podría validar la exactitud de mi edificio de la consulta de reemplazo y luego factorizarlo con puntos de vista o lo que sea.
También estoy considerando factorizar la manipulación UDF y cuerda y realizar el CROSS JOIN primero en romper el proceso un poco.
resultados hasta ahora:
Resulta que las UDF contribuyen mucho (negativamente) a la actuación. Pero también parece que hay una gran diferencia entre una fila 15m combinación cruzada y una fila 30m combinación cruzada. No tengo derechos plan de presentación (Boo Hoo), así que no puedo decir si el plan se está utilizando es mejor o peor después de cambiar los índices. No he reprogramado todavía, pero estoy esperando toda la tabla a desaparecer en breve.
Solución
Examinar que consulta muestra sólo una columna utilizado de una tabla, y sólo dos columnas utilizadas a partir de la otra tabla. Debido a los números muy bajos de columnas utilizadas, esta consulta puede ser fácilmente mejorada con cubriendo índices:
CREATE INDEX COSTCENTCoverCross ON COSTCENT(COST_CTR_NUM)
CREATE INDEX JOINGLACCoverCross ON JOINGLAC(ACCOUNT_NO, LI_LNTM)
Aquí están mis preguntas para una mayor optimización:
Cuando se pone la consulta en el Analizador de consultas y porrazo el botón "Mostrar estimado de ejecución del plan", se mostrará una representación gráfica de lo que va a hacer.
Tipo de combinación: Debe haber un bucle anidado allí. (Las otras opciones son combinación de mezcla y combinación hash). Si ve bucle anidado, a continuación, en Aceptar. Si ves combinación de mezcla o combinación hash, vamos a saber.
Orden de acceso a la tabla: Ir todo el camino hasta la cima y recorrer todo el camino a la derecha. El primer paso se debe acceder a una tabla. ¿Qué tabla es que y qué método se utiliza (índice de exploración, exploración índice agrupado)? ¿Qué método se utiliza para acceder a la otra mesa?
Paralelismo: Debe ver las pequeñas flechas jaggedy en casi todos los iconos en el plan que indica que se está utilizando el paralelismo. Si no ves esto, no es un gran problema!
Eso udf_BUPDEF me preocupa. ¿Se lee de mesas adicionales? Util.PADLEFT me preocupa menos, pero todavía .. ¿qué es? Si no es un objeto de base de datos, entonces considerar el uso de esta forma:
RIGHT('z00000000000000000000000000' + columnName, 7)
¿Hay factores desencadenantes en JOINCCAC? ¿Qué hay de los índices? Con un inserto de este grande, usted querrá eliminar todos los disparadores y los índices en esa mesa.
Otros consejos
Continuando en lo que otros un dicho, las funciones de base de datos que contenía las preguntas que se utilizan en un selecto siempre hacen mis consultas extremadamente lento. De la parte superior de mi cabeza, creo que tenía una consulta correr en 45 segundos, y luego me quita la función, y luego resultado fue 0 segundos:)
A fin de comprobar udf_BUPDEF no está haciendo cualquier pregunta.
Divida la consulta para que sea una simple cruz llana unirse.
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
Ver lo bueno que se unen a la cruz simple? (Sin ningún tipo de funciones aplicadas en él)
