Desmistificando o buffer de registro no HANA: Por que é crucial entender seu funcionamento?

Registro de Redo (também conhecido como buffers de registro)

Para garantir a recuperação do banco de dados sem perda de dados em caso de falhas, o SAP HANA registra cada transação na forma de uma entrada de registro de redo. Cada serviço do SAP HANA escreve seus próprios arquivos de redo log separadamente. Os tamanhos típicos de blocos de escrita variam de 4KB a 1MB. Durante as transações de escrita, todas as mudanças nos dados são capturadas no redo log. O HANA persiste de forma assíncrona o redo log com operações de E/S de 4KB a 1MB de tamanho em arquivos de segmento de log no volume de log (no disco). As transações que escrevem um commit no redo log aguardam até que o buffer que contém o commit tenha sido escrito no volume de log. Para evitar que os volumes de log fiquem cheios, os segmentos de log são arquivados quando estão cheios (dependendo do tamanho do logsegment_size_mb) ou após um intervalo de tempo específico. Este é um conceito básico de banco de dados!

O logshipping_async_buffer_size não tem nada a ver com isso! Este buffer especial desempenha um papel apenas na replicação do sistema SAP HANA que é executada no modo de replicação ASYNC ! Na replicação do sistema SAP HANA, o redo log mencionado anteriormente, que é criado durante as transações de escrita, é sempre enviado imediatamente para o sistema secundário (além de ser persistido no sistema primário nos volumes de log). Dependendo do modo de replicação (SYNC, SYNCMEM ou ASYNC), o secundário confirma o recebimento do redo log ao sistema primário (por favor, consulte aqui, por exemplo, para obter detalhes sobre os modos de replicação: https://www.sap.com/documents/2017/07/606a676e-c97c-0010-82c7-eda71af511fa.html) .

Na replicação do sistema ASYNC, o primário não espera uma confirmação do secundário sobre a chegada do redo log. No modo de replicação ASYNC , o escritor de log copia os buffers de redo log primeiro em um buffer de memória intermediário (de tamanho logshipping_async_buffer_size ) e continua processando a transação de escrita no primário. Uma thread separada lê os buffers de log deste buffer de memória intermediário e os envia para o lado secundário de forma assíncrona através da rede. Nesta configuração, o primário continua trabalhando e não espera a confirmação do secundário. A partir deste buffer em memória, o redo log é enviado para a rede para o secundário de forma assíncrona. O parâmetro logshipping_async_buffer_size determina quanto log pode ser armazenado intermediamente. Este buffer é especialmente útil em momentos de alta demanda; quando o log é gerado mais rapidamente no primário do que é enviado para o site secundário. Se o buffer for grande, ele pode lidar com picos por um período de tempo mais longo.

Obrigado denys.kempen .

Isso ajuda. Vejo que me desviei um pouco com minhas perguntas 😊 .

Olá Sumit,

Permita-me tentar novamente ; -)

P: Como evitar o aumento do logshipping_async_buffer_size (256MB) em situações de log cheio?

R: Ver resposta de Mechtild: logshipping_async_buffer_size não tem nada a ver com isso . Como fazer minha barba crescer mais rápido bebendo mais café? Não fará. Não há relação.

P2: O número de segmentos de log pode ser no máximo 10240. Existe algum parâmetro semelhante para a quantidade de buffers de log também?

R: Verifiquei

• 2186744 - Perguntas frequentes: Parâmetros do SAP HANA
• 2600030 - Recomendações de parâmetros em ambientes do SAP HANA

e encontrei log_buffer_count, log_buffer_size_kb

com mais informações em

• 2215131 - Relação de contagem de espera de mudança de registro de alerta

Então sim, existe.

P3: Por que é necessário copiá-lo para o buffer?

R: Arquitetura do sistema. Pode ser para garantir que a replicação do sistema não interfira nas operações de persistência de log (sem dependências).

P4: Por que não envia os segmentos de log para o secundário em vez disso?

R: Mesma resposta que para P3.

Espero que isso esclareça suas perguntas. É bom ser curioso. Obrigado.