Componentes internos de respaldo: ¿qué sucede cuando se ejecuta un trabajo de respaldo, en términos de bloqueo y sobrecarga de rendimiento en SQL Server?

Para MySQL, sé que la base de datos está respaldada tabla por tabla en sentencias SQL, esto da como resultado el bloqueo y si actualiza las columnas mientras realiza la copia de seguridad, puede terminar en problemas de integridad.

A mi entender, esto no se aplica a Microsoft SQL Server, pero ¿cómo maneja esto SQL Server? ¿Hay algún congelamiento interno para mantener el db consistente?

También escuché que la copia de seguridad es de un solo subproceso, lo que significa que usa solo un núcleo, suponiendo que realice una copia de seguridad en un solo archivo. También suponiendo que tenga una máquina multinúcleo, por ejemplo 16 núcleos, o al menos un número significativamente mayor que uno.

Desde mi experiencia personal, nunca tuve problemas al realizar copias de seguridad, ni bloqueos ni problemas generales, pero mi experiencia es limitada. Es por eso que siempre recomiendo activar la compresión de respaldo en las propiedades del servidor.

Entonces, ¿qué sucede cuando se ejecuta una tarea de respaldo? ¿Y también hay diferencias significativas para las diferentes versiones? por ejemplo 2008,2012 y 2014 (no las licencias).

Todos tus puntos están cubiertos en mitos de respaldo - por Paul Randal

30-01) las operaciones de respaldo causan bloqueo

No. Las operaciones de copia de seguridad no bloquean los objetos del usuario . Las copias de seguridad causan una carga de lectura realmente pesada en el subsistema de E / S, por lo que puede parecer que la carga de trabajo está siendo bloqueada, pero en realidad no lo es. Solo se está ralentizando. Hay un caso especial en el que una copia de seguridad que tiene que recoger extensiones registradas en bloque tomará un bloqueo de archivo que podría bloquear una operación de punto de control, pero DML nunca se bloquea.

También escuché que la copia de seguridad es de un solo subproceso, lo que significa que usa solo un núcleo, suponiendo que realice una copia de seguridad en un solo archivo.

Una copia de seguridad cuando se realiza en un solo archivo o dispositivo utilizará 1 hilo de escritura. Por lo tanto, si realiza una copia de seguridad en varios archivos / dispositivos (ya sea que haya varios archivos .bak) tendrá un hilo de escritura por archivo / dispositivo.

La forma más fácil de mejorar el rendimiento de la copia de seguridad es permitir que la operación de copia de seguridad se paralelice, lo que se conoce como creación de bandas de copia de seguridad. De manera predeterminada, hay un único subproceso de lector de datos para cada letra de unidad o punto de montaje que se lee y un único subproceso de escritor de datos para cada dispositivo de copia de seguridad en el que se escribe.

Cheque

1. SQL Server 2008 Microsoft Certified Master (MCM) Videos de preparación especialmente Backup Internals.
2. Una mirada a lo interno de respaldo y cómo rastrear el rendimiento de respaldo y restauración (Parte 1) - Por: Jonathan Kehayias
3. Una mirada a lo interno de respaldo y cómo rastrear el rendimiento de respaldo y restauración (Parte 2) - Por: Jonathan Kehayias

El artículo escrito por Paul sobre las copias de seguridad internas es excelente y debes leerlo. Agregando a lo que otros han dicho y enfatizando en parte específica de su pregunta

También escuché que la copia de seguridad es de un solo subproceso, lo que significa que usa solo un núcleo, suponiendo que realice una copia de seguridad en un solo archivo. También suponiendo que tenga una máquina multinúcleo, por ejemplo 16 núcleos, o al menos un número significativamente mayor que uno.

Operación de copia de seguridad, can use parallelismpero recuerde que este no es el paralelismo impulsado por Optimizer en SQL Server, sino la cantidad de discos involucrados desde donde la copia de seguridad tiene que leer el archivo de datos y donde la copia de seguridad escribe el archivo de datos y la cantidad de archivos de copia de seguridad creados.

No puede usar la MAXDOPsugerencia mientras realiza la copia de seguridad de SQL Server

No puede generar un plan de ejecución en SSMS para una operación simple de copia de seguridad de TSQL.

El paralelismo impulsado por el optimizador de consultas en SQL Server es básicamente para los operadores involucrados (en realidad es más complejo, pero por simplicidad puede tomar esto) ya que la operación de copia de seguridad no involucra a ningún operador como tal, no puede usar el paralelismo impulsado por el optimizador.

Escribí un artículo en Technet Wiki sobre Copia de seguridad y paralelismo donde usé ejemplos simples para explicar el paralelismo durante la copia de seguridad de SQL Server. La siguiente es la conclusión.

1. Si los archivos de la base de datos están en varios discos, la operación de copia de seguridad se iniciará en el hilo por unidad de dispositivo para leer los datos. Del mismo modo, si la restauración se realiza en múltiples unidades / puntos de montaje, la operación de respaldo iniciaría un subproceso por unidad / punto de montaje

2. Incluso si está volcando varias copias de copia de seguridad en la misma unidad, tendríamos un subproceso por archivo de copia de seguridad volcado.

3. El paralelismo asociado con la copia de seguridad está relacionado con las franjas. Cada banda tiene su propio subproceso de trabajo y esa es realmente la única parte de la copia de seguridad / restauración que se debe considerar como operaciones paralelas.

4. El grado máximo de paralelismo no afecta la operación de respaldo.

Paul y Bob Dorr me dieron una opinión experta sobre esto.

Entonces, ¿qué sucede cuando se ejecuta una tarea de respaldo? ¿Y también hay diferencias significativas para las diferentes versiones? por ejemplo 2008,2012 y 2014 (no las licencias).

Te sugiero que leas este artículo de blog.msdn de Bob Dorr. Algunos puntos importantes que enfatizó son

1. Cuando se inicia una copia de seguridad, crea una serie de buffers, asignados desde la memoria fuera del grupo de buffer. El objetivo suele ser de 4 MB para cada búfer, lo que resulta en aproximadamente 4 a 8 búferes. Los detalles sobre el cálculo se encuentran en: http://support.microsoft.com/kb/904804/en-us

2. Los buffers se transfieren entre las colas libre y de datos. El lector extrae un búfer libre, lo llena de datos y lo coloca en la cola de datos. Los escritores extraen los buffers de datos llenos de la cola de datos, procesan el buffer y lo devuelven a la lista libre.

3. Obtiene un escritor por dispositivo de respaldo, cada uno de los cuales se recupera de la cola de datos. Entonces, un comando de respaldo con cuatro (4) especificaciones de disco tendrá cuatro escritores y un lector. El lector usa E / S asíncrona para que pueda mantenerse al día con los escritores.

Puede habilitarlos trace flags 3213 and 3605, ambos no están documentados, así que úselo en un entorno de prueba y vea qué mensaje interesante se encuentra en el registro de errores de SQL Server. Algo parecido a continuación aparecería

Memory limit: 249MB
BufferCount:                7
Sets Of Buffers:            1
MaxTransferSize:            1024 KB
Min MaxTransferSize:        64 KB
Total buffer space:         7 MB
Tabular data device count:  1
Fulltext data device count: 0
Filestream device count:    0
TXF device count:           0
Filesystem i/o alignment:   512
Media Buffer count:            7
Media Buffer size:          1024KB

No conozco ningún cambio significativo en el código de respaldo para varias versiones, tales cosas no están documentadas. Solo conozco la mejora introducida en SQL Server 2012 SP1 Cumulative Update 2,habilitar la copia de seguridad y restauración desde el servicio de almacenamiento Blob de Windows Azure desde SQL Server usando TSQL o SMO. Leer aquí

Básicamente, SQL Server hace una copia sucia de todas las páginas en el disco. Es probable que esas páginas sean inconsistentes si hay actividad concurrente o si anteriormente hubo actividad sin control.

Luego, SQL Server también copia la parte necesaria del registro de transacciones que se necesita para llevar las páginas desactualizadas a la última versión y hacer que todo sea consistente en la restauración.

No puedo hablar a la multiproceso de la operación de copia de seguridad. Espero que sea paralelo. ¿De qué otra forma podría hacer una copia de seguridad de una base de datos de 10 TB en un subsistema IO de 10 GB / seg?