SQL Server: ¿grupo de archivos solo para tablas del sistema?

11

Uno de nuestros estándares corporativos es tener un grupo de archivos / archivo separado para tablas / índices de usuario. Esto se establece como predeterminado, por lo que no es necesario calificar las instrucciones CREATE TABLE.

Entonces se ve así

fileid 1 = tablas del sistema, MDF
fileid 2 = t-log = LDF
fileid 3 = material de usuario = NDF

¿Alguien puede ayudarme a comprender la justificación original de por qué esto fue obligatorio?

Iré limpio y diré que creo que es vudú. ¿ Me equivoco ...?

Editar: Soy consciente de cómo usar grupos de archivos para la separación de índices / particiones / archivos, así como de cómo restaurar por partes. Esta pregunta trata sobre el uso de un grupo de archivos separado en el mismo volumen solo para tablas del sistema.

sql-server filegroups disk-structures

— gbn
fuente

9

El libro de capacitación 70-432 de Microsoft dice: "La razón principal para no colocar ninguno de sus objetos en el grupo de archivos principal es proporcionar el mayor aislamiento posible en la E / S. Los datos en los objetos del sistema no cambian con tanta frecuencia como los datos en sus objetos. Al minimizar la actividad de escritura en el archivo de datos primario, reduce la posibilidad de introducir daños debido a fallas de hardware. Además, debido a que el estado del grupo de archivos primario también determina el estado de la base de datos, puede aumentar la disponibilidad de la base de datos puedo minimizar los cambios realizados en el grupo de archivos principal ".

Así que tomar esto como se quiere. Otros dicen que esto no es necesario en ciertas circunstancias y, por supuesto, es más para mantener. Solo pensé en proporcionar el razonamiento de Microsoft.

— Jared
fuente

Razonable, alguna justificación escrita para ello. Aceptaré esto

— gbn

1

Otra razón es que una restauración de base de datos PARCIAL permite la restauración del grupo de archivos PRIMARIO más otros grupos de archivos seleccionados, lo que permite una recuperación más rápida de un VLDB diseñado correctamente. Permitir que los grupos de archivos archivados / secundarios se restauren más tarde.

— MartinC

@ MartinC: sé sobre restauraciones parciales, etc., pero nunca entendí la lógica de separar explícitamente las tablas del sistema. Grupos de archivos para rendimiento, archivo, mantenimiento, particionamiento, etc. ¿Pero las tablas del sistema? Jared ofreció la mejor explicación hasta ahora ..

— gbn

Si la base de datos en su conjunto es muy grande, el grupo de archivos primario podría tener una copia de seguridad más regular que los datos principales. La restauración solo requeriría una copia de seguridad del registro de cola y la restauración del grupo de archivos primario y los registros de transacciones desde la copia de seguridad del grupo de archivos más la cola. Como las tablas del sistema son pequeñas, este sería un proceso de recuperación más rápido en comparación con hacerlo para toda la base de datos, por lo que puede reducir el tiempo de inactividad en caso de un problema.

— MartinC

12

No es una ganancia de rendimiento para esto, hay una ganancia de recuperación que se puede hacer. Si se daña el archivo en las tablas del sistema, se pierde la base de datos. Si mantiene los datos del usuario en un grupo (o grupos) de archivos separado, puede restaurar solo esos archivos manteniendo el resto de la base de datos en línea durante la restauración (suponiendo aquí la Edición Enterprise).

Si es por eso que afirman esto, no puedo decirlo, pero esto sería un beneficio de tener múltiples grupos de archivos con solo los objetos del sistema en el grupo de archivos PRIMARIO.

Sin embargo, debe patear la basura por decir que AutoShrink debería estar habilitado.

— mrdenny
fuente

Para obtener más información sobre esto, puede buscar Restauración gradual en línea en Books Online.

— Brent Ozar

1

Siempre he pensado que esto también es vudú dado que los 2 grupos de archivos están en el mismo volumen (en una SAN). ¿Es tan alto el riesgo de corrupción? (Los DBA operativos reales establecen AutoShrink falso)

— gbn

Lo más probable es que si hay corrupción, será una sola página dentro de un solo archivo, ya que el almacenamiento se acumulará al escribir la página en el disco. Algo así como el 99.9999% de la corrupción de la base de datos es un problema de almacenamiento. La mitad del resto de los problemas son mala memoria, el resto son errores de SQL. A medida que las bases de datos se hacen más grandes (TB múltiple) esto se vuelve más importante, ya que la restauración de una base de datos TB múltiple tomará varios días.

— mrdenny

¿No estaría en lo cierto al pensar que si los objetos del sistema están solo en el grupo de archivos primario si lo necesitara en el futuro, podrá hacer lo siguiente? Cree x archivos adicionales en otro grupo de archivos. ¿Proporciona estos archivos proporcionalmente migrando sus datos de su archivo de datos existente?

— Ally Reilly

4

No estoy seguro de entender, ¿está pidiendo a alguien que justifique su estándar corporativo? Creo que quien escribió ese documento de normas para su empresa podría arrojar algo de luz sobre por qué se haría esto.

Dicho esto, no es inusual que algunas tiendas quieran separar los datos del sistema de los datos del usuario. Y si se usa junto con conjuntos de discos dedicados, podría obtener algunas ganancias de rendimiento.

— SQLRockstar
fuente

Gracias. No lo justifique, pero explíquelo. Este es el mismo equipo de DB Engineering que dice AutoShrink. Dado que las tablas del sistema ocupan unos pocos MB y estarán en la memoria de todos modos, ¿cree en alguna ganancia de rendimiento?

— gbn