none
SSIS Deployment & Processing en paralelo de varios cubos dentro de la misma BD

    Pregunta

  • Hola,

    Estoy trabajando con SQL Server EE 2016 en SSAS con Modelos multidimensionales.

    Desde el SSIS pretendo ejecutar en paralelo el Deployment & Processing de 5 Cubos que se encuentran en la misma base de datos desde el Integrations Services.

    ¿Eso es posible?

    ¿Pudieran entrar en conflicto y bloquearse los cubos? 

    ¿Es recomendable?

    Son cubos muy grandes y con mucha información.

    ¿Si se bloquean? - ¿Como desbloquearlos? ¿Pudiera perder los cubos?

    Gracias de antemano
    lunes, 5 de febrero de 2018 19:19

Respuestas

  • Entiendo el processing, el deployment menos.

    Si mal no recuerdo, el deployment si que puede tener interbloqueos, aunque dudo que lleguen a ser un problema. 

    En cuanto al processing, tu lanzarás N actualizaciones en paralelo, y se pondrán todos los recursos a tope, no se si al final la estrategia hará que tarden mas o menos, depende de donde se encuentren los cuellos de botella. Si las consultas que lanzan los Analisys services responden más rápido que Analisys services en procesar, esta máquina estará a todo lo que de, si las consultas con mas lentas y hay que esperar a que se resuelvan ,, pues será al revés.

    Lo que si que haría siempre es separar el proceso de deploy del procesado.  Deploy solo se hace cuando se cambia la estructura, procesar cada vez que quieras actualizar los datos y además en procesado hay muchas estrategias distintas. 


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    martes, 6 de febrero de 2018 7:50
    Moderador
  • Cuando hablo de estrategias hablo de particiones, puedes crear particiones por fecha por ejemplo y no reprocesar todo el cubo sino solo los periodos que hayan sufrido modificaciones. Cada partición además puede tener una estrategia de almacenamiento distinto (MOLAP-ROLAP-HOLAP) (si es que eso fuera necesario) y el resultado de procesar una partición más pequeña es menos tiempo de procesado. 


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    jueves, 8 de febrero de 2018 7:12
    Moderador

Todas las respuestas

  • Entiendo el processing, el deployment menos.

    Si mal no recuerdo, el deployment si que puede tener interbloqueos, aunque dudo que lleguen a ser un problema. 

    En cuanto al processing, tu lanzarás N actualizaciones en paralelo, y se pondrán todos los recursos a tope, no se si al final la estrategia hará que tarden mas o menos, depende de donde se encuentren los cuellos de botella. Si las consultas que lanzan los Analisys services responden más rápido que Analisys services en procesar, esta máquina estará a todo lo que de, si las consultas con mas lentas y hay que esperar a que se resuelvan ,, pues será al revés.

    Lo que si que haría siempre es separar el proceso de deploy del procesado.  Deploy solo se hace cuando se cambia la estructura, procesar cada vez que quieras actualizar los datos y además en procesado hay muchas estrategias distintas. 


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    martes, 6 de febrero de 2018 7:50
    Moderador
  • Gracias Miguel por tus comentarios, 

    ok, entonces entiendo que el precio de correr en paralelo el precio es el performance mas que el conflicto de bloqueo entre los cubos.

    Para el performance por supuesto es importante, pero son procesos que corre el SQL Server automaticamente durante la madrugada. En mi BD tengo 7 cubos. Los cuales dos de ellos tardan varias horas en procesar, pero el resto son relativamente cortos. El cuello de botella sería al inicio, luego poco a poco quedan listos los pequeños y quedan los grandes al final.

    Lo que busco es que al inicio del día los 7 cubos estén listos. En caso de que alguno presente algún problema no obstaculice a los demás.

    Mencionas que hay varias estrategias para actualizar los datos, me pudieras orientar que opciones existen. Quizas eso me pueda ayudar.

    Gracias de antemano

    Alejandro 

    miércoles, 7 de febrero de 2018 9:01
  • Cuando hablo de estrategias hablo de particiones, puedes crear particiones por fecha por ejemplo y no reprocesar todo el cubo sino solo los periodos que hayan sufrido modificaciones. Cada partición además puede tener una estrategia de almacenamiento distinto (MOLAP-ROLAP-HOLAP) (si es que eso fuera necesario) y el resultado de procesar una partición más pequeña es menos tiempo de procesado. 


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    jueves, 8 de febrero de 2018 7:12
    Moderador
  • Saludos Miguel,

    Gracioso que menciones eso pues tengo un caso similar, existe alguna manera de limitar el uso de CPU en un DWH que esta leyendo para el proceso, me supondre que talvez con el gobernador de recursos?

    Estoy de acuerdo con tu punto sobre que procesar en paralelo no me parece una buena opcion por la gran carga a los cpus principalmente y al subsistema de IO.


    Blog: www.sqlservertoolbox.blogspot.com.mx

    jueves, 8 de febrero de 2018 14:30
  • El resource gobernor ayudará, si lo configuras a limitar el uso de recursos. En cualquier caso en los escenarios en que tengo ese tipo de presión procuro poner el servidor de procesado aislado y luego uso técnicas como sincronize(genera muchos bloqueos, particularmente en versiones antiguas) o incluso cambiar los ficheros en los servidores dedicados a explotación de datos. Vamos que se puede diseñar una arquitectura con un servidor de procesado y varios nodos de consulta. de esa forma especializamos el procesado. 

    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    viernes, 9 de febrero de 2018 7:13
    Moderador
  • Lastimosamente no tengo ingerencias a ese nivel para cambiar el diseño sobre esto, lo maneja otra area por eso preguntaba por el gobernador que es parte de lo que puedo hacer y mover un poco el parelelismo, es un servidor dedicado.

    Tendras documentacion de lo que sincronize, es un 2012 o 2008 r2 no me acuerdo de momento.


    Blog: www.sqlservertoolbox.blogspot.com.mx

    sábado, 10 de febrero de 2018 4:58