none
Mejor opción de respaldo. RRS feed

  • Pregunta

  • Saludos

    Tengo una base de datos que tiene como único propósito guardar reportes de unidades de localización. Pueden llegar a ser 300 reportes por segundo. (Con una tasa de crecimiento de 0,5% mensual aprox.) De manera que son 300 inserciones por segundo, no hay updates, ni deletes.

    La base de datos está dividida en varias tablas ubicadas en grupos de archivos distintos. Debo crearle un plan de mantenimiento y respaldo a esa BD.

    La pregunta es: ¿Qué opciones de respaldo son buenas considerar en este ambiente? ¿Qué opciones de mantenimiento? Se necesita la disponibilidad de la Data con un máximo de una hora de pérdidas de reportes en caso de desastre y recover.

    Los reportes ocurren durante las 24 horas, pero en menor medida en las noches (Las unidades de localización están en reposo la mayoría)

    He pensado en un respaldo diario de madrugada FULL cada madrugada. (A eso de 02:00 AM) y respaldos diferenciales cada 1 hora. el resto del día a partir del respaldo FULL de madrugada. El log pienso respaldarlo una vez al día. A eso de 05:30 AM. El Log le tengo un tamaño fijo tiende a crecer bastante por la característica de la base de datos.

    No se que tan bueno sea el respaldo FULL diario (La base de datos es grande. Unos 200 Gigas de Data y tardaría en respaldar) . El servidor tiene 2 procesadores Intel Xeon 2,50 GHz y 16 Gigas de memoria RAM. Es un servidor dedicado a SQL Server 2008 para esta tarea. No corre más nada. Toda la memoria procesadores están dedicado a SQL Server 2008 (Bueno y a Windows 2008 Server claro)

    No se qué tanto debo considerar en el respaldo del Log.

    Otra cosa son los planes de mantenimiento. La gran cantidad de inserciones imagino que hace que los índices dejen de ser útiles en el corto plazo. No creo que haya muchos problemas de integridad o falta de consistencia de la data. (La escritura es centralizada). Qué opciones debería tomar para reorganizar índices y páginas de datos)

     

    Gracias de antemano,

     

    jueves, 2 de septiembre de 2010 15:12

Respuestas

  • En un entorno así, yo probablemente haría lo siguiente:

    • backup completo semanal
    • backup del log cada hora. Esto garantiza ese RPO (lo que te han dicho que como máximo se puede perder)
    • backup diferencial diario

    En caso de desastre, habría que:

    1. primeramente backup de la cola del log si es factible
    2. restaurar el último backup completo
    3. restaurar el último diferencial (sólo el último)
    4. restaurar todos los backups del log desde ese último diferencial (incluyendo el del paso 1 si pudiste hacerlo)

    El tiempo de backup dependerá principalmente de tu sistema de disco; si este es rápido, el backup será rápido.

    En cuanto a lo de la fragmentación de los índices, pues dependerá de los valores que se inserten. Por ejemplo, si los valores son siempre secuenciales (aunque haya saltos) como son los campos IDENTITY, no existirá fragmentación; si por el contrario tienes un índice sobre el número de teléfono, entonces sí que habrá (probablemente) mucha fragmentación. En cualquier caso un plan de mantenimiento no se limita a una reorganización de los índices; te recomiendo el script de Ola Hallengren (http://ola.hallengren.com/) que te permite realizar dicho mantenimiento de forma mucho más efectiva que lo que proporciona SQL Server Management Studio.

    jueves, 2 de septiembre de 2010 15:27

Todas las respuestas

  • En un entorno así, yo probablemente haría lo siguiente:

    • backup completo semanal
    • backup del log cada hora. Esto garantiza ese RPO (lo que te han dicho que como máximo se puede perder)
    • backup diferencial diario

    En caso de desastre, habría que:

    1. primeramente backup de la cola del log si es factible
    2. restaurar el último backup completo
    3. restaurar el último diferencial (sólo el último)
    4. restaurar todos los backups del log desde ese último diferencial (incluyendo el del paso 1 si pudiste hacerlo)

    El tiempo de backup dependerá principalmente de tu sistema de disco; si este es rápido, el backup será rápido.

    En cuanto a lo de la fragmentación de los índices, pues dependerá de los valores que se inserten. Por ejemplo, si los valores son siempre secuenciales (aunque haya saltos) como son los campos IDENTITY, no existirá fragmentación; si por el contrario tienes un índice sobre el número de teléfono, entonces sí que habrá (probablemente) mucha fragmentación. En cualquier caso un plan de mantenimiento no se limita a una reorganización de los índices; te recomiendo el script de Ola Hallengren (http://ola.hallengren.com/) que te permite realizar dicho mantenimiento de forma mucho más efectiva que lo que proporciona SQL Server Management Studio.

    jueves, 2 de septiembre de 2010 15:27
  •  

    Gracias. Tomaré en cuenta tus recomendaciones. Monté algo parecido mientras leo y pruebo al mismo tiempo. Me tomó esto de imprevisto y yo soy es programador :s

     

     

    viernes, 3 de septiembre de 2010 13:16