Cómo excluir índices de copias de seguridad en SQL Server 2008

19

Nuestras copias de seguridad completas nocturnas (y diferenciales periódicas) se están volviendo bastante grandes, debido principalmente a la cantidad de índices en nuestras tablas; aproximadamente la mitad del tamaño de la copia de seguridad se compone de índices.

Estamos utilizando el modelo de recuperación simple para nuestras copias de seguridad.

¿Hay alguna forma, mediante el uso FileGroupso algún otro método de partición de archivos, para excluir índices de las copias de seguridad?

Sería bueno si esto también se pudiera extender a los catálogos de texto completo.

sql-server backup sql-server-2008 indexes Jarrod Dixon
fuente

Respuestas:

15

Si cambia al modo de recuperación completa, puede hacerlo con grupos de archivos, pero es muy, muy torpe. Deja los datos en el grupo de archivos primario y coloca los índices en un grupo de archivos separado (no predeterminado, esa es la clave).

Luego, escalona sus copias de seguridad para hacer copias de seguridad de grupos de archivos de las primarias todas las noches y copias de seguridad del registro de transacciones cada X minutos.

Cuando ocurre un desastre, restaura el grupo de archivos primario por sí mismo. Los datos están repentinamente en línea, pero los índices no. Sin embargo, para volver a la normalidad, deberá exportar esos datos a una nueva base de datos limpia y agregar índices desde allí. No puede poner la base de datos completamente en línea sin restaurar todos los grupos de archivos, y no puede decir "No necesito ese otro grupo de archivos de todos modos".

Para obtener más información sobre cómo funciona esto, consulte mi video tutorial sobre restauraciones de grupos de archivos.

Brent Ozar
fuente
Jeje, había movido los índices no agrupados a su propio grupo de archivos; El modelo de recuperación simple me bloqueó por completo. Los índices eran en realidad más grandes que los datos, ¡cómo se burlaban de mí! Oh, bueno, tal vez algún tercero lanzará una pista de bala mágica :)
Jarrod Dixon
1
Y tal vez, solo tal vez, obtendrá una licencia gratuita para ello. ;-)
Brent Ozar
5

Honestamente, realmente no quieres hacer esto, incluso si superas los otros problemas que otros plantean aquí.

Cuando restaura la copia de seguridad en una emergencia, no desea esperar a que se reconstruyan los índices, y sufrirá un rendimiento abominable hasta que lo haga.

No puedo pensar en una situación en la que desee restaurar una copia de seguridad sin índices, por lo que en todos los casos realmente querrá hacer una copia de seguridad al mismo tiempo.

Es probable que deba buscar otras soluciones a este problema ...

-Adán

Adam Davis
fuente
1
"no quieres esperar a que los índices se reconstruyan", muy presunto, OMI
Jeff Atwood
2
Sí, pero ten en cuenta que estoy generalizando aquí. No me he convencido de que hay más situaciones en las que es mejor deshacerse de los índices y reconstruir que situaciones en las que es mejor hacer una copia de seguridad de los índices y evitar una reconstrucción. En otras palabras, un caso es generalmente mejor, y a menos que una situación particular lo requiera, uno debería errar por el lado de respaldarlos. Dicho esto, cada situación es diferente. Tengo curiosidad por saber cuánto tiempo lleva reconstruir los índices SO, y cuánto sufre el rendimiento del sitio hasta que finalizan (suponiendo que esté activo durante la reconstrucción).
Adam Davis
El respaldo de archivo a largo plazo es el caso de uso específico que estoy viendo ahora que me llevó a esta pregunta. Tengo un proyecto que está completo y ya no quiero la base de datos en línea, pero tampoco necesito saturar nuestra unidad de red con un archivo de respaldo más grande de lo necesario. No quiero perder las definiciones de índice, pero no me importaría reconstruirlas si alguna vez tuviera que restaurar esto nuevamente.
richardtallent
3

Parece que esto no es compatible. De esta información de informe de error :

Ha habido mucho interés en este, así que entraré en un poco más de detalle sobre lo que está sucediendo detrás de escena y lo que significaría implementar esta funcionalidad. Algunos tipos de páginas de índice se segregan en unidades de asignación separadas, mientras que otros se mezclan con las páginas de datos. Donde actualmente solo miramos el mapa de bits de asignación para ver si se asigna una extensión, ahora tendríamos que entrar e interpretar lo que está almacenado en cada unidad de asignación. Además, ahora no podríamos simplemente hacer un escaneo lineal de los archivos de datos copiando datos, sino que estaríamos omitiendo el archivo. Toda esta interpretación de las estructuras de datos reduciría drásticamente la copia de seguridad. La restauración se vuelve aún más interesante, porque hay muchas estructuras que tendrían que arreglarse para dar cuenta de los agujeros en la copia de seguridad. De lo contrario, tendrías mapas de asignación que apuntan a páginas que no fueron respaldadas, y por lo tanto tienen basura, etc. etc. Ya no lo restauro. La otra faceta a considerar es que esto requeriría una gran cantidad de esfuerzo de ingeniería para hacerlo bien. Si bien ese no es su problema en la superficie, tenga en cuenta que significa que no se construirán otras características que desee ver.

Jon Galloway
fuente
Esto no sería un problema para los índices de texto completo, ¿verdad? Esos tienden a ser bastante grandes.
Michael Teper
1

Puede ser una idea loca, pero aquí va.

  1. suelte sus índices no agrupados que ocupan mucho espacio
  2. hacer una copia de seguridad
  3. volver a crear los índices que dejó caer

Por supuesto, solo puede hacer esto si su base de datos permite algún tiempo de inactividad en el día.

Además, no deje caer sus índices agrupados, ya que SQL Server perderá mucho tiempo convirtiéndolos en un montón.

¿Comprar ese espacio extra en disco parece una solución más fácil todavía?

¿Has considerado hacer copias de seguridad comprimidas ? Esta es una nueva característica de 2008, puede ser una opción para usted.

Nick Kavadias
fuente
Sí, hemos activado la compresión para copias de seguridad, pero la compresión incorporada no es tan buena. De hecho, tenemos una copia de seguridad no comprimida de fin de semana y luego la descomprimimos para que los desarrolladores la eliminemos; es aproximadamente 1/3 del tamaño, ¡pero lleva algún tiempo ejecutarlo!
Jarrod Dixon
En cuanto al tiempo de inactividad de DB, ¿podríamos realmente vivir sin serverfault.com y stackoverflow.com tanto como sea posible? Me estremezco ante ese pensamiento :)
Jarrod Dixon
No lo he probado yo mismo, pero sospechaba mucho. No es muy configurable. Si todavía está buscando la compresión como una opción, eche un vistazo a SQL Lightspeed (costoso, pero impresionante, pero el precio es muy negociable) y la copia de seguridad SQL de RedGate. Resultados muy configurables y excelentes
Nick Kavadias