locked
2 servidores sql server 2005 con una misma ubicacion para datos

    Pregunta

  • Hola, tengo un servidor con Sql Server 2005 y varias bases de datos instaladas. Tengo también en otro servidor Reporting Services configurado al cual se accede por IIS. Resulta que hay determinados informes realizados con RS que colapsan al servidor, por lo que quiero realizar una réplica del servidor con la base de datos a otro servidor de base de datos. Es decir, la estructura se quedaría así: DBSERVER1 (base de datos), DBSERVER2 (replica de la base de datos), RSSERVER (servidor con Reporting Services). Las bases de datos en DBSERVER1 se encuentran en una cabina de discos, no en el propio servidor.

    Al realizar la réplica (transaccional continua) tengo que definir una carpeta para las instantáneas, y por supuesto una ubicación para la base de datos en DBSERVER2. Me interesaría bastante que tanto las instantáneas de la réplica como la base de datos destino estuvieran también en la cabina de discos, pero claro, entonces tengo en la misma unidad la bd del DBSERVER1, la bd de DBSERVER2 y la carpeta de réplicas, todas con la misma información.

    ¿Podría gastar la misma ruta de la base de datos de DBSERVER1 para la base de datos de DBSERVER2? Es más que nada por no tener información replicada en la misma unidad.

    Saludos,
    miércoles, 06 de mayo de 2009 13:32

Respuestas

Todas las respuestas

  • Hola.

    Salvo que tu base de datos sea de solo lectura o tengas amplias ventanas de mantenimiento, va a ser difícil montar dos servidores de bases de datos atacando a los mismos ficheros a la vez. Tendrás que duplicarlas (por una réplica transaccional continua, por ejemplo). También es importante que sean volúmenes asignados y dedicados para cada servidor, puede que lo de la misma unidad, dependiendo a qué te refieras, tampoco sea viable.

    Alberto López Grande.


    miércoles, 06 de mayo de 2009 14:33
  • Que es lo que hace colapsar el servidor, el servicio de RS o el servicio de SQL?
    Que mediciones hiciste?

    Si el cuello de botella son los discos no tiene sentido tu propuesta, deberias agregar mas spindles.

    Que significa especificamente colapsa en terminos de saturacion de los recursos (CPU,memoria, disco,red, etc)?


    Saludos


    Ing. Jose Mariano Alvarez http://blog.josemarianoalvarez.com/ Microsoft MVP SQLTotal Consulting Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0 (Cambia los ceros por O y saca lo que sobra) Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase
    miércoles, 06 de mayo de 2009 15:33
  • Lo que se colapsa es el RS y hay que reiniciarlo (no se si es cpu o memoria, pero seguro que uno de estos dos, o ambos), quienes lo programan me han comentado la posibilidad de separarlo en dos, y había pensado en la replicación transaccional continua.

    Claro, no tiene sentido que haya una misma ubicación para dos bases de datos diferentes, no me gustaba la idea de tenerlo todo en la misma unidad (database1 + database2 + carpeta de instantáneas).

    Voy a intentar utilizar otra unidad para la base de datos de réplica, así tendría en la cabina de discos la base de datos original y la carpeta de réplica y en otro volumen la base de datos de réplica.

    ¿Conseguiría mayor rendimiento en la réplica poniendo la carpeta de instantáneas en un servidor o otro, o daría igual? Quiero decir, si la réplica sería más facil poniendo la carpeta de instantáneas en el servidor origen o en el destino.
    miércoles, 06 de mayo de 2009 16:10
  • Hola.

    Si lo que se colapsa no es la parte de base de datos, entonces por mucho que mejores la infraestructura en esa parte, tendrás el mismo problema (o peor incluso). Reporting Services no deja de ser un web que se puede escalar por load balancing, puedes poner varios servidores para responder a los reportes. Y también habría que ver en qué momento se colapsan, ya que a lo mejor hay un informe concreto con un error o con una consulta que vuelca una cantidad enorme de información. 

    Te dejo un link sobre como realizar esta escalación de reporting: http://technet.microsoft.com/en-us/library/ms159114(SQL.90).aspx

    Alberto López Grande.
    miércoles, 06 de mayo de 2009 18:32
  • Es prioritario que antes de agregar más hardware o aplicar replicación agotes otras instancias. Por ejemplo, invierte más tiempo e indentifica en dónde está realmente el problema, nos queda claro que RS se colapsa, pero ¿qué lo ocasiona?. Intenta reunirte con el equipo de desarrolladores y audita aspectos como:
    * Baseline de rendimiento.
    * Medición clave de ejecución de consultas.
      - Recursos requeridos para la ejecución de las consultas.
      - Tiempo requerido para su ejecución.
    * Haz una medición de rendimiento de esas consultas.
      - Performance Monitor
      - Profiler

    A menudo en esta capa se solucionan la mayoria de problemas. Si por aquí no va la cosa, consulta estas ligas sobre las mejores prácticas para sitios de RS con carga intensa.

    Reporting Services Performance Optimizations
    http://sqlcat.com/technicalnotes/archive/2009/01/14/reporting-services-performance-optimizations.aspx

    Reporting Services Scale-Out Architecture
    http://sqlcat.com/technicalnotes/archive/2008/06/05/reporting-services-scale-out-architecture.aspx

    Saludos!
    Anwar Karlier - MCTS SQL 2005
    miércoles, 06 de mayo de 2009 21:59
  • Muchas gracias por las respuestas. Como primera medida estamos analizando los informes de RS para ver si cuando se colapsa es por culpa de algunos en concreto. La opción de agregar un segundo servidor de informes también la teníamos contemplada, de ahí la replicación, el segundo servidor de informes consultaría en la base de datos replicada, pero claro, si lo que se colapsa es RS y ahí el SGBD no tiene nada que ver, consultando sobre la bbdd replicada tendríamos el mismo problema. Voy a probar las auditorías que me proponéis y a ver si podemos identificar el problema más exactamente para encontrar la mejor solución.

    Saludos,
    jueves, 07 de mayo de 2009 7:33
  • Hola, el RS consume recursos de CPU y memoria, si tienen reportes pesados es recomendable escalar y poner otro servidor para RS.
    Si con eso no alcanza podra entonces armar lo que se llama un balanceo de RS agregando mas servidores de RS a un mismo nodo

    --

    ----------------------------------------------------------------- ----
    Maxi Accotto
    Microsoft MVP en SQL Server
    Consultor en SQL Server
    http://blog.maxiaccotto.com
    - --------------------------------------------------------------------
    < /DIV>
    "kiket" escribió en el mensaje de noticias:813a6574-3dc6-4882-9d2c-6e0faba8d3ac...
    Lo que se colapsa es el RS y hay que reiniciarlo (no se si es cpu o memoria, pero seguro que uno de estos dos, o ambos), quienes lo programan me han comentado la posibilidad de separarlo en dos, y había pensado en la replicación transaccional continua.

    Claro, no tiene sentido que haya una misma ubicación para dos bases de datos diferentes, no me gustaba la idea de tenerlo todo en la misma unidad (database1 + database2 + carpeta de instantáneas).

    Voy a intentar utilizar otra unidad para la base de datos de réplica, así tendría en la cabina de discos la base de datos original y la carpeta de réplica y en otro volumen la base de datos de réplica.

    ¿Conseguiría mayor rendimiento en la réplica poniendo la carpeta de instantáneas en un servidor o otro, o daría igual? Quiero decir, si la réplica sería más facil poniendo la carpeta de instantáneas en el servidor origen o en el destino.
    miércoles, 13 de mayo de 2009 0:49
  • Algunas ideas para mejorar el rendimiento de tu servidor (antes de o en adición a mover SSRS a otro servidor):

    1) Ejecutar el Profiler mientras se ejecutan los reportes que te dan los problemas. Luego ejecuta el Index Tunning Wizard dandole como entrada los datos recogidos por el Profiler. El wizard te debe indicar cuáles son los índices que debes crear y los puede crear por ti.

    2) Verifica si has configurado el Max Memory Usage para SQL Server, por defecto SQL Server se comería toda la memoria disponible en el servidor incluso matando los procesos de Reporting Services.

    3) Una de las mejores prácticas es ampliar el tamaño de TempDB y ReportServerTempDB a por lo menos 5GB. Si tienes un arreglo de disco considera en distribuir TempDB y ReportServerTempDB en varios FileGroups según el número de procesadores que tengas y con tamaño de archivos de 1GB aproximadamente.

    4) Para los reportes que no necesitan estar "real time" considera configurarles un tiempo de cache, tal vez 1, 5, 10 minutos o lo que sea apropiado según el informe. Esto marca la diferencia en el tiempo de respuesta de los reportes ya que minimiza el acceso a la base de datos fuente.

    En teoría separar Reporting Services del servidor de tus bases de datos te puede dar mayor escalabilidad y/o tiempos de respuesta pero debes tener en mente los puntos anteriores para que puedas solucionar el problema efectivamente.
    Alan Koo | http://alan-koo.blogspot.com
    miércoles, 13 de mayo de 2009 2:26
  • Bueno, gracias a todos por las respuestas. Para empezar voy a seguir el procedimiento de Alan Koo, para intentar "tunear" la bd.

    Ahora, lo de implementar otro servidor de RS también lo vamos a hacer, pero ¿que licencia necesito para esto? En los otros servidores tengo la licencia Enterprise, y no sé si con la Standard sería suficiente, la diferencia de precio es bastante considerable.

    Saludos,
    viernes, 15 de mayo de 2009 9:01
  • En realidad el escenario que propones es perfectamente posible (Enterprise para SQL y Standard para SSRS), en este caso tienes un par de limitantes de la versión Standard vs la Enterprise (principalmente de escalabilidad), pero probablemente en esta etapa no te signifiquen ninguna desventaja.

    Aquí puedes ver el resumen de las catacterísticas de SSRS con respecto a la versión http://www.microsoft.com/Sqlserver/2005/en/us/reporting-services-features.aspx.

    Saludos,


    Alan Koo | http://alan-koo.blogspot.com
    lunes, 18 de mayo de 2009 15:05
  • Ok, gracias Alan, entonces compraremos la standard, que es bastante menos dinero.

    Otra pregunta: Estoy ejecutando el profiler para crear la traza y luego analizarla en el tunning advisor, pero no me queda claro que eventos debo señalar. He probado con la plantilla Tunning, pero el tunning advisor me saca un aprovechamiento del 1%. ¿Es esto normal? O debería de hacer alguna plantilla configurada con algunos eventos específicos para auditar Reporting Services? No había gastado nunca esta herramienta, y no veo nada referente a reporting services en los eventos seleccionables...

    Saludos,
    miércoles, 27 de mayo de 2009 7:38
  • Hola, ojo con eso, yo no correria el tune advisor asi nomas, lo que hara eso es simplemente indicarte indices a realizar, pero no todo se resuelve asi y ademas tenes que analizar bien la salida porque te va a intentar generar muchos cover index lo cual tendras seguramente un gran numero de indices sobre las tablas lo cual hara mas lentas las operacionesde insert update y delete.

    Yo pondria la plantilla de profiler de performance con un filtro de duration de 5000 que equivale a 5 segundos, osea, todo lo que dura mas de 5 segundos que lo traiga.

    Luego de eso montaria las trazas en una tabla y con un par de querys sacaria los procesos que mas cpu y Reads estan consumiendo, los analizaria y veria las querys primero de los mismos, y luego aplicaria el tunining sobre la query, pero aplicarlo de forma masiva puede traerte mas dolores de cabeza que soluciones si no estas muy ducho.
    Maxi Accotto
    viernes, 29 de mayo de 2009 0:19
  • Hola Maxi, gracias por los consejos. Solo un par de preguntas:

    - ¿La plantilla de performance del profiler te refieres a la de Tunning? No veo ninguna plantilla con el nombre exacto de performance en la lista de plantillas.

    - ¿Como le pongo el filtro de duracion al profiler?

    saludos y gracias
    lunes, 01 de junio de 2009 8:50
  • Bueno, ya he descubierto lo del filtro de duración, se lo he aplicado a SPCompleted. ¿Sería correcto a este evento, o mejor a read?

    Saludos,
    lunes, 01 de junio de 2009 8:57