Avalados por :
Estoy esforzándome por comprender los detalles técnicos de las operaciones de HANA. Tengo algunas consultas:
1) Entiendo el búfer de registro de HANA (que reside en la memoria) y el segmento de registro (que reside en el volumen de registro). Los detalles del registro se escriben desde el búfer de memoria a los segmentos de registro.
Muchas veces, cuando llega la situación de registro completo de HANA, SAP me sugirió aumentar el tamaño del búfer de envío de registro asíncrono (por defecto es de 64 MB). No pude encontrar ninguna razón por la cual este tamaño de búfer evitará la generación de segmentos de registro (por defecto, 1 GB). ¿Alguien puede ayudarme a entender?
2) El número máximo de segmentos de registro puede ser de 10240. ¿Existe algún parámetro similar para la cantidad de búferes de registro también?
3) Según la descripción de logshipping_async_buffer_size ( https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/0cd257970d514abd8ddf9ee1f4... ) , " el escritor de registros copia primero los búferes de registro en un búfer de memoria intermedio y continúa procesándolos. Un hilo separado lee los búferes de registro de este búfer de memoria y los envía al sitio secundario de forma asíncrona a través de la red"
¿Por qué es necesario copiarlo a la memoria intermedia?
4) En caso de HSR, es el búfer de registro el que se envía, persiste y se reproduce en la memoria en el secundario. Un hilo lee el búfer de memoria (o búfer de registro pero no datos de segmento de registro) y envía al secundario. ¿Por qué no se envían los segmentos de registro al secundario en su lugar?
Gracias mechthildbore por tomarte el tiempo de escribir esta extensa respuesta. Siempre es bueno saber de ti.
Registro de Redo (también conocido como búferes de registro)
Para garantizar la recuperación de la base de datos sin pérdida de datos en caso de fallos, SAP HANA registra cada transacción en forma de una entrada de registro de redo. Cada servicio de SAP HANA escribe sus propios archivos de redo log por separado. Los tamaños típicos de escritura de bloques van desde 4KB hasta 1MB. Durante las transacciones de escritura, todos los cambios en los datos se capturan en el redo log. HANA persiste de forma asíncrona el redo log con órdenes de E/S de 4KB a 1MB de tamaño en archivos de segmento de log en el volumen de log (en disco). Las transacciones que escriben un commit en el redo log esperan hasta que el búfer que contiene el commit haya sido escrito en el volumen de log. Para evitar que los volúmenes de log se llenen, los segmentos de log se respaldan cuando están llenos (dependiendo de su tamaño de logsegment_size_mb) o después de un intervalo de tiempo específico. ¡Este es un concepto básico de base de datos!
El logshipping_async_buffer_size ¡no tiene nada que ver con esto! Este búfer especial solo juega un papel en la replicación del sistema SAP HANA que se ejecuta en modo de replicación ASYNC ! En la replicación del sistema SAP HANA, el redo log mencionado anteriormente, que se crea durante las transacciones de escritura, siempre se envía inmediatamente al sistema secundario (además de persistirse en el sistema primario en los volúmenes de log). Dependiendo del modo de replicación (SYNC, SYNCMEM o ASYNC), el secundario confirma la recepción del redo log al sistema primario (por favor, consulte aquí, por ejemplo, para obtener detalles sobre los modos de replicación: https://www.sap.com/documents/2017/07/606a676e-c97c-0010-82c7-eda71af511fa.html) .
En la replicación del sistema ASYNC, el primario no espera una confirmación del secundario sobre la llegada del redo log. En el modo de replicación ASYNC , el escritor de log copia los búferes de redo log primero en un búfer de memoria intermedio (de tamaño logshipping_async_buffer_size ) y continúa procesando la transacción de escritura en el primario. Un hilo separado lee los búferes de log de este búfer de memoria intermedio y los envía al lado secundario de forma asíncrona a través de la red. En esta configuración, el primario sigue trabajando y no espera la confirmación del secundario. Desde este búfer en memoria, el redo log se envía a la red al secundario de forma asíncrona. El parámetro logshipping_async_buffer_size determina cuánto log puede ser almacenado intermedio. Este búfer es especialmente útil en momentos de alta demanda; cuando el log se genera más rápido en el primario que se envía al sitio secundario. Si el búfer es grande, puede manejar picos durante un período de tiempo más largo.
Gracias denys.kempen .
Esto ayuda. Veo que me desvié un poco con mis consultas 🙂 .
Hola Sumit,
Permíteme intentarlo de nuevo ; -)
P: ¿Cómo evitará el aumento de logshipping_async_buffer_size (256MB) las situaciones de log lleno?
R: Ver respuesta de Mechtild: logshipping_async_buffer_size no tiene nada que ver con esto . ¿Cómo hará que mi barba crezca más rápido beber más café? No lo hará. No hay relación.
P2: El número de segmentos de log puede ser un máximo de 10240. ¿Existe algún parámetro similar para la cantidad de búferes de log también?
R: He verificado
y encontré log_buffer_count, log_buffer_size_kb
con más información en
Así que sí existe.
P3: ¿Por qué es necesario copiarlo a memoria intermedia?
R: Arquitectura del sistema. Podría ser para garantizar que la replicación del sistema no interfiera con las operaciones de persistencia de log (sin dependencias).
P4: ¿Por qué no envía los segmentos de log a secundario en su lugar?
R: Misma respuesta que para P3.
Espero que esto aclare tus preguntas. Es bueno ser curioso. Gracias.
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
