Internos de backup - O que acontece quando uma tarefa de backup está em execução - em termos de bloqueio e sobrecarga de desempenho no SQL Server?

Para o MySQL, eu sei que o backup do banco de dados é feito tabela por tabela nas Instruções SQL, isso resulta em bloqueio e, se você atualizar colunas durante o backup, poderá acabar com problemas de integridade.

Para meu entendimento, isso não se aplica ao Microsoft SQL Server, mas como o SQL Server lida com isso? Existe algum congelamento interno para manter o banco de dados consistente?

Também ouvi dizer que o backup é de thread único, o que significa que ele usa apenas um núcleo, supondo que você faça backup em um único arquivo. Supondo também que você tenha uma máquina multicore, por exemplo, 16 núcleos ou pelo menos um número maior e significativo que um.

Pela minha experiência pessoal, nunca tive problemas ao fazer backups, nem problemas de bloqueio nem de sobrecarga, mas minha experiência é limitada. É por isso que eu sempre recomendo ativar a compactação de backup nas propriedades do servidor.

Então, o que acontece quando um trabalho de backup está em execução? E também existem diferenças significativas para as diferentes versões? por exemplo, 2008,2012 e 2014 (não as licenças).

Todos os seus pontos são abordados nos mitos dos backups - por Paul Randal

30-01) operações de backup causam bloqueio

Não. As operações de backup não usam bloqueios nos objetos do usuário . Os backups causam uma carga de leitura muito pesada no subsistema de E / S; portanto, pode parecer que a carga de trabalho está sendo bloqueada, mas na verdade não está. Está apenas sendo desacelerado. Há um caso especial em que um backup que precisa capturar extensões registradas em massa terá um bloqueio de arquivo que pode bloquear uma operação de ponto de verificação - mas o DML nunca é bloqueado.

Também ouvi dizer que o backup é de thread único, o que significa que ele usa apenas um núcleo, supondo que você faça backup em um único arquivo.

Um backup quando feito em um único arquivo ou dispositivo utilizará 1 encadeamento de gravador. Portanto, se você estiver fazendo backup em vários arquivos / dispositivos (sejam vários arquivos .bak), haverá um encadeamento de gravador por arquivo / dispositivo.

A maneira mais fácil de melhorar o desempenho do backup é permitir a paralelização da operação de backup, conhecida como distribuição de backup. Por padrão, há um único thread do leitor de dados para cada letra de unidade ou ponto de montagem que está sendo lido e um único thread do gravador de dados para cada dispositivo de backup que está sendo gravado.

Verifica

1. Vídeos de preparação do Microsoft Certified Master (MCM) do SQL Server 2008, especialmente os internos de backup.
2. Um olhar sobre os internos de backup e como rastrear o rendimento do backup e restauração (parte 1) - Por: Jonathan Kehayias
3. Um olhar sobre os backups internos e como rastrear o desempenho de backup e restauração (parte 2) - Por: Jonathan Kehayias

O artigo escrito por Paul sobre os internos de backup é excelente e você deve lê-lo. Adicionando ao que os outros disseram e enfatizando parte específica da sua pergunta

Também ouvi dizer que o backup é de thread único, o que significa que ele usa apenas um núcleo, supondo que você faça backup em um único arquivo. Supondo também que você tenha uma máquina multicore, por exemplo, 16 núcleos ou pelo menos um número maior e significativo que um.

A operação de backup, can use parallelismmas lembre-se de que este não é o paralelismo impulsionado pelo Optimizer no SQL Server, é impulsionada pelo número de discos envolvidos, de onde o backup deve ler o arquivo de dados e onde o backup grava o arquivo de dados e a quantidade de arquivos de backup criados.

Você não pode usar a MAXDOPdica ao fazer o backup do SQL Server

Você não pode gerar plano de execução no SSMS para operação simples de backup TSQL.

O paralelismo conduzido pelo otimizador de consultas no SQL Server é basicamente para os operadores envolvidos (na verdade, é mais complexo, mas por uma questão de simplicidade, é possível), pois a operação de backup não envolve nenhum operador e, portanto, não pode usar o paralelismo impulsionado pelo otimizador.

Escrevi um artigo no Technet Wiki sobre Backup e paralelismo em que usei exemplos simples para explicar o paralelismo durante o backup do SQL Server. A seguir está a conclusão

1. Se os arquivos do banco de dados estiverem em vários discos, a operação de backup será iniciada no encadeamento por unidade de dispositivo para ler os dados. Da mesma forma, se a restauração for feita em várias unidades / pontos de montagem, a operação de backup iniciaria um encadeamento por unidade / ponto de montagem

2. Mesmo se você estiver despejando várias cópias de backup na mesma unidade, teremos um encadeamento por arquivo de backup despejado.

3. O paralelismo associado ao backup está relacionado às faixas. Cada faixa recebe seu próprio encadeamento de trabalho e essa é realmente a única parte do backup / restauração que se deve considerar como operações paralelas.

4. O grau máximo de paralelismo não afeta a operação de backup.

Eu tenho uma opinião de especialistas sobre isso de Paul e Bob Dorr.

Então, o que acontece quando um trabalho de backup está em execução? E também existem diferenças significativas para as diferentes versões? por exemplo, 2008,2012 e 2014 (não as licenças).

Eu sugiro que você leia este artigo blog.msdn de Bob Dorr. Alguns pontos importantes que ele enfatizou são

1. Quando um backup é iniciado, ele cria uma série de buffers, alocados da memória fora do pool de buffers. O destino geralmente é de 4 MB para cada buffer, resultando em aproximadamente 4 a 8 buffers. Detalhes sobre o cálculo estão localizados em: http://support.microsoft.com/kb/904804/en-us

2. Os buffers são transferidos entre as filas livre e de dados. O leitor puxa um buffer livre, preenche-o com dados e coloca-o na fila de dados. Os gravadores puxam buffers de dados preenchidos da fila de dados, processam o buffer e retornam à lista livre.

3. Você obtém um gravador por dispositivo de backup, cada um recuperando da fila de dados. Portanto, um comando de backup com quatro (4) especificações de disco terá quatro gravadores e um leitor. O leitor usa E / S assíncrona para acompanhar os gravadores.

Você pode ativar trace flags 3213 and 3605, os dois não estão documentados; portanto, use-o no ambiente de teste e veja que mensagem interessante é despejada no log de erros do SQL Server. Algo como abaixo apareceria

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

Não estou ciente de alterações significativas no código de backup para várias versões; essas coisas não estão documentadas. Eu sei apenas sobre o aprimoramento introduzido em SQL Server 2012 SP1 Cumulative Update 2,habilitar backup e restauração do serviço de armazenamento de Blob do Windows Azure do SQL Server usando TSQL ou SMO. Leia aqui

Basicamente, o SQL Server faz uma cópia suja de todas as páginas no disco. É provável que essas páginas sejam inconsistentes se houver atividade simultânea ou se houver atividade não pontual anteriormente.

Em seguida, o SQL Server também copia a parte necessária do log de transações necessária para trazer as páginas desatualizadas para a versão mais recente e tornar tudo consistente na restauração.

Não consigo falar com o multithreaded da operação de backup. Eu espero que seja paralelo. De que outra forma você poderia fazer backup de um banco de dados de 10 TB em um subsistema de 10 GB / s de E / S?