¿Qué son tablas participadas? El jue., 9 abr. 2020 0:01, <[email protected]> escribió:
> por que no miras "Tablas Particionadas", nosotros tenemos una base de > 3.200.000.000 de registros y las tenemos separadas por periodo del asiento > (AAAMM) y la verdad es que andan muy rapido, al margen que a la hora de > depurar dichas tablas, tambien es rapido > > > Saludos > > > > > > [image: Mailtrack] > <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;> > Remitente > notificado con > Mailtrack > <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=signaturevirality5&;> > 08/04/20 > 18:52:24 > > El mié., 8 abr. 2020 a las 17:06, datil400 (<[email protected]>) > escribió: > >> Hola Jesús, >> >> He de reconocer que nunca he tenido el tiempo suficiente para ponerme al >> día en temas como asesor de índices o de rendimiento de la BBDD, a parte de >> que se ma hace cuesta arriba. >> >> Gracias por tus comentarios. >> >> El vie., 3 abr. 2020 9:44, Jesus Maria Arzak (DHL ES) < >> [email protected]> escribió: >> >>> Buen Dia >>> >>> >>> >>> Una cosa muy importante que has de tener en cuenta a la hora de utilizar >>> el Sql es que cuando utilices un índice tengas en el Where los campos del >>> índice, no hace falta que tengas todos pero los que estén sean del índice. >>> >>> >>> >>> Además es muy muy importante que los pongas ordenados según el orden del >>> índice. >>> >>> >>> >>> En el momento que aparecen desordenados o tienes un campo de selección >>> que no está en el índice el rendimiento baja espectacularmente. >>> >>> >>> >>> Quizá ya lo sepas pero no lo he visto mencionado . >>> >>> >>> >>> Un saludo >>> >>> >>> >>> >>> >>> *Jesús Mª Arzak Capilla* >>> >>> Solutions Management >>> >>> *DHL Parcel Iberia, S.L.U.* >>> >>> Paseo Mikeletegi, nº 65 >>> Parque Tecnológico de San Sebastián >>> E-20009 San Sebastián >>> >>> Phone: +34 943 37 81 37 >>> >>> >>> * [email protected] <%[email protected]>* >>> >>> www.dhlparcel.es >>> >>> *GO**GREEN – Environmental protection with DHL* >>> *Por favor, ten en cuenta el medio ambiente antes de imprimir este >>> correo* >>> >>> >>> >>> >>> >>> >>> >>> *From:* Forum.help400 [mailto:[email protected]] >>> *On Behalf Of *Juan Carlos Paredes >>> *Sent:* jueves, 2 de abril de 2020 21:55 >>> *To:* forum.help400 <[email protected]> >>> *Subject:* Re: Cómo optimizar la consulta a una vista SQL >>> >>> >>> >>> Por eso te digo que evites las subselect. Trata de filtrar en la select >>> final. >>> >>> Mira a ver qué te dice el Visual Explain. >>> >>> Otra opción es que arranques un monitor de rendimiento sobre el trabajo >>> y revises las anotaciones. Una de las tareas más pesadas el la apertura y >>> cierre de ODPs. >>> >>> Revisa qué está haciendo el motor de DB2 con eso. >>> >>> Obtener BlueMail para Android <http://www.bluemail.me/r?b=15824> >>> >>> En 2 abr. 2020, en 21:47, datil400 <[email protected]> escribió: >>> >>> Los índices ya están creados, incluso aquellos que aconseja el asesor. >>> >>> >>> >>> Desde mi punto de vista, son tantos los registros que hay que resumir en >>> cada subselect (todos?), que es lo que provoca la falta de rendimiento. >>> >>> >>> >>> Gracias Juan Carlos >>> >>> >>> >>> El jue., 2 abr. 2020 21:21, Juan Carlos Paredes <[email protected]> >>> escribió: >>> >>> >>> >>> Si el valor inicial y final son el mismo en ambas tablas, yo crearía un >>> índice por ese campo en ambas tablas y otro por la clave de la join. >>> >>> Y luego >>> >>> Select * from tabla1 join tabla2 on clave1 = clave2 where valor between >>> valor_inicial and valor_final. >>> >>> Espero que ayude. >>> >>> Salud y paciencia >>> >>> #yomequedoencasa >>> >>> Juan Carlos. >>> >>> En 2 abr. 2020, en 20:57, datil400 <[email protected]> escribió: >>> >>> El tema de los índices está más que revisado, no mejoran el rendimiento. >>> >>> >>> >>> Los subselects siempre revisan todos los registros. ¿Cómo lo sé? Una >>> consulta de un tramo pequeño está tardando entrr 30 y 45 minutos. Si >>> incorporo en los subselects el mismo filtro, tarda segundos. >>> >>> >>> >>> Me toca aprender cómo se puede transformar un procedimiento almacenado >>> en una vista. Si fuera posible, ¡claro! >>> >>> >>> >>> Gracias por tu aportación. >>> >>> >>> >>> El jue., 2 abr. 2020 18:31, Nicolas Silva <[email protected]> escribió: >>> >>> Hola Javier: >>> >>> >>> >>> Yo me inclinaria para un Stored Procedure debido a que en tu seleccion >>> tienes parametros, en este caso fechas, y no puedes dejarlos predispuestos >>> en la vista. >>> >>> Tambien, intentaria agregar un indice tipo EVI sobre las tablas para >>> mejor seleccion de las fechas. >>> >>> >>> >>> Si el asesor de indices no te lo indica, puedes ejecutar el visual >>> explain para ver mejor los indices a crear. >>> >>> >>> >>> Espero puedas resolverlo. >>> >>> >>> >>> Saludos !!!! >>> >>> >>> >>> >>> >>> El jue., 2 abr. 2020 a las 11:08, datil400 (<[email protected]>) >>> escribió: >>> >>> Hola a tod@s, >>> >>> >>> >>> no he sabido expresar de mejor manera la consulta que quiero haceros. >>> >>> >>> >>> Espero que todos vosotros, vuestros familiares y conocidos estéis bien y >>> viviendo el confinamiento de la mejor manera posible. >>> >>> >>> >>> Tengo una vista que resume información de varios archivos que contienen >>> millones de registros, no hable de uno o dos millones, hablo de 200 >>> millones. Por muchos índices y consejos del asesor de índices no consigo >>> que se ejecute en un tiempo razonable. >>> >>> >>> >>> Antes de crear un archivo de acumulados o una tabla materializada que me >>> mantenga siempre calculados los datos quiero probar otras alternativas (si >>> las hay). >>> >>> >>> >>> En esos 200 millones de registros sólo quiero tratar un grupo reducido, >>> por ejemplo el último mes o el último año. Aunque en el select sobre la >>> vista siempre selecciono el rango que quiero, realmente lo estoy haciendo >>> sobre el resultado de los cálculos que hace la vista, que siempre los hace >>> sobre el total de los registros de las tablas. >>> >>> >>> >>> Además, son cálculos que se hacer por partes dentro de la cláusula WITH. >>> >>> >>> >>> Lo que intento es que la vista sólo seleccione el grupo de registros de >>> cada una de las tablas. Un pequeño ejemplo: >>> >>> >>> >>> WITH >>> >>> RESUMEN_TABLA1 >>> >>> AS ( >>> >>> SELECT * FROM TABLA1 WHERE campo BETWEEN <valor_inicial> AND >>> <valor_final> >>> >>> ), >>> >>> RESUMEN_TABLA2 >>> >>> AS ( >>> >>> SELECT * FROM TABLA2 WHERE campo BETWEEN <valor_inicial> AND >>> <valor_final> >>> >>> ) >>> >>> SELECT >>> >>> * >>> >>> FROM >>> >>> TABLA >>> >>> LEFT JOIN >>> >>> RESUMEN_TABLA1 ON clave1 = clave >>> >>> LEFT JOIN >>> >>> RESUMEN_TABLA2 ON clave2 = clave >>> >>> ; >>> >>> >>> >>> En la consulta de la vista >>> >>> >>> >>> SELECT >>> >>> * >>> >>> FROM >>> >>> VISTA >>> >>> WHERE >>> >>> <valor_inicial> = '2020-01-01' AND <valor_final> = '2020-03-31' >>> >>> >>> >>> Realmente esto no se puede hacer en SQL pero simularlo. Se me ocurren >>> algunas soluciones: >>> >>> >>> >>> 1. Variables globales >>> >>> >>> >>> Cargar los valores de selección en variables globales que utilice la >>> vista internamente. Inconveniente, dos trabajos o usuarios distintos no >>> podrían hacer una consulta concurrente. >>> >>> >>> >>> 2. Procedimiento almacenado o UDTF >>> >>> >>> >>> Utilizar el paso de parámetros para seleccionar las filas de los >>> subselects, pero no sé cómo incoporarlas en una vista para que el usuario >>> pueda utilizar un Query, ODBC, etc. sin tener que utilizar el procedimiento >>> o UDTF. >>> >>> >>> >>> No sé si he sido capaz de explicarme (creo que no), pero ¿alguno >>> vosotros me puede dar alguna pista de cómo podria hacer lo que propongo? >>> >>> >>> >>> O simplemente estoy alucinando y es imposible hacerlo. >>> >>> >>> >>> Saludos a todos y gracias por vuestros comentarios. >>> >>> >>> >>> Javier >>> >>> ____________________________________________________ >>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 © Publicaciones Help400, S.L. >>> >>> ____________________________________________________ >>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 © Publicaciones Help400, S.L. >>> >>> ------------------------------ >>> >>> >>> �nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 � Publicaciones Help400, S.L. >>> >>> ____________________________________________________ >>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 © Publicaciones Help400, S.L. >>> >>> ------------------------------ >>> >>> >>> �nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 � Publicaciones Help400, S.L. >>> >>> CONFIDENTIALITY NOTICE: This message is from DHL and may contain >>> confidential business information. It is intended solely for the use of the >>> individual to whom it is addressed. If you are not the intended recipient >>> please contact the sender and delete this message and any attachment from >>> your system. Unauthorized publication, use, dissemination, forwarding, >>> printing or copying of this E-Mail and its attachments is strictly >>> prohibited. >>> ____________________________________________________ >>> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >>> Forum.Help400 © Publicaciones Help400, S.L. >> >> ____________________________________________________ >> Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) >> Forum.Help400 © Publicaciones Help400, S.L. > > ____________________________________________________ > Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) > Forum.Help400 © Publicaciones Help400, S.L.
____________________________________________________ �nete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 � Publicaciones Help400, S.L.
