Experiencia de implementación de NSE | Blogs de SAP
By s4pcademy
Experiencia en implementación de NSE
**Todas las capturas de pantalla las tomé yo de una de nuestras implementaciones de HANA.
Introducción:
NSE es un almacén de datos tibios completamente funcional en la base de datos de HANA, que podemos aprovechar para mover los datos a los que se accede con menos frecuencia sin cargarlos completamente en la memoria.
Esta es una característica muy buena, en la que podemos evitar aumentar la capacidad del servidor y, por lo tanto, controlar los costos de hardware.
Por ejemplo, uno de nuestros clientes tiene una instancia de producción de 2 TB en Azure y tiene un consumo de memoria promedio de 1,7 a 1,8 TB. Para aumentar la capacidad del hardware, manteniendo un tamaño de CPU similar, necesitamos tomar una VM más grande de alrededor de 4 TB, que está sobredimensionada de acuerdo con la tasa de crecimiento actual de la base de datos; por lo tanto, los clientes terminarán pagando más por una máquina virtual más grande, aunque no se utilice por completo.
Ejemplo, el precio de Azure es el que se muestra a continuación.
Para mantener el mismo tamaño de la VM y controlar el uso de la memoria, tenemos las siguientes opciones.
- Reduzca el tamaño de la base de datos mediante el archivado: este es uno de los procedimientos estándar disponibles independientemente del tipo de base de datos; sin embargo, esto debe tener en cuenta los requisitos de la política de retención para satisfacer las necesidades de auditoría de los clientes.
- Antigüedad de datos: la antigüedad de datos es otra buena característica, pero tiene ciertas limitaciones con la reversión de la antigüedad, la adopción de código personalizado para acceder a datos antiguos.
- NSE: NSE es una oferta muy útil de SAP para HANA DB y cubre los inconvenientes del envejecimiento y el archivado. NSE se puede revertir fácilmente y no se requiere la adopción de un código personalizado.
- Teniendo en cuenta los costos, no hemos explorado los nodos de extensión.
Por lo tanto, elegimos NSE como una opción para reducir la utilización de la memoria de la base de datos.
Análisis previo a la implementación:
Antes de comenzar la implementación de NSE, debemos identificar las tablas potenciales que se pueden mover a NSE y descargar de la memoria.
Para conocer la lista de tablas, necesitamos definir los criterios para elegirlas. El criterio preferido es descargar tablas que tienen una gran cantidad de cambios como INSERCIONES, ELIMINACIONES, ACTUALIZACIONES, etc., pero muy pocas LECTURAS.
Podemos usar lo siguiente para encontrar las tablas que satisfacen los criterios anteriores.
- Estadísticas de llamadas de la tabla ST10
- HANA SQL HANA_Tables_TableStatistics_1.00.100+
- Mesas principales por memoria
- Asesor NSE
Según la definición de SAP, NSE Advisor es una herramienta que determina la temperatura de los datos y utiliza algoritmos basados en reglas (umbral de temperatura de datos, patrón/frecuencia de acceso, densidad de datos) para derivar estas recomendaciones, en particular para identificar caliente y objetos cálidos como candidatos para cargarse en páginas o en columnas.
NSE Advisor debe ejecutarse en el sistema de producción durante unos días para capturar las estadísticas de llamadas de la tabla y proporcionar recomendaciones. Esto puede causar una sobrecarga en la base de datos; sin embargo, no hemos notado un aumento significativo en el consumo de CPU/memoria, por lo que activamos NSE Advisor.
Nota : revise el consumo de recursos en su base de datos de HANA en un sistema de calidad para comprender el impacto, antes de activarlo en Producción. Las métricas clave para monitorear son la CPU de la base de datos, el uso de la memoria de la base de datos, el uso de subprocesos de HANA, el tiempo de ejecución del trabajo, etc.
Activación del asesor NSE :
ALTERAR SISTEMA ALTERAR CONFIGURACIÓN (‘indexserver.ini’,’system’) SET (‘cs_access_statistics’,’collection_enabled’) = ‘true’
CON RECONFIGURACIÓN;
Esto activará NSE con la configuración predeterminada. Podemos configurar NSE Advisor para que se centre en tablas que son más grandes que un tamaño específico para evitar el ruido en el conjunto de resultados.
Parámetros de configuración adicionales de NSE Advisor:
MIN_OBJECT_SIZE: Controle el tamaño mínimo de objeto (BYTE) para que un objeto sea considerado
por recomendación
ALTERAR SISTEMA ALTERAR CONFIGURACIÓN (‘indexserver.ini’, ‘SYSTEM’) SET
(‘cs_nse_advisor’,’min_object_size’) = ‘YYY’
CON RECONFIGURACIÓN;
–valor predeterminado 1048576 = 1 MiB
Reemplace YYY por un número en bytes para fijar el tamaño mínimo del objeto.
HOT_OBJECT_THRESHOLD_PERCENT: Controla el porcentaje de tablas, según fila
recuento y tamaño de escaneo, a tener en cuenta al calcular el umbral de objetos calientes
COLD_OBJECT_THRESHOLD_PERCENT: Controla el porcentaje de tablas, según fila
recuento y tamaño de escaneo, a tener en cuenta al calcular el umbral de objetos fríos
ALTERAR SISTEMA ALTERAR CONFIGURACIÓN (‘indexserver.ini’, ‘sistema’) SET
(‘cs_nse_advisor’,’hot_object_threshold_rel’) = ‘YY’
CON RECONFIGURACIÓN; –valor predeterminado 10
ALTERAR SISTEMA ALTERAR CONFIGURACIÓN (‘indexserver.ini’, ‘sistema’) SET
(‘cs_nse_advisor’,’cold_object_threshold_rel’) = ‘YY’
CON RECONFIGURACIÓN; –valor predeterminado 10
Nota: la suma de HOT_OBJECT_THRESHOLD_PERCENT y COLD_OBJECT_THRESHOLD_PERCENT
no debe exceder de 100.
Una vez que NSE Advisor está activado, podemos permitir que se ejecute durante algunas semanas, cubriendo la mayoría de los períodos de actividad del usuario.
Una vez que se ejecuta durante algunas semanas, apáguelo usando la siguiente instrucción SQL:
ALTERAR SISTEMA ALTERAR CONFIGURACIÓN (‘indexserver.ini’,’system’) SET
(‘cs_access_statistics’,’collection_enabled’) = ‘falso’
CON RECONFIGURACIÓN;
Revise las recomendaciones de NSE Advisor usando la consulta:
SELECCIONE * DESDE M_CS_NSE_ADVISOR
Resultados del asesor NSE:
Después de revisar los resultados de NSE Advisor, hemos decidido mover las siguientes tablas a PÁGINA CARGABLE para descargarlas de la memoria.
- Tablas de infosistemas de archivos ZARIX*
- CDHDR/CDPOS
- EDIDC/EDIDS
Esto nos da un ahorro de 250GB y con un ahorro potencial de alrededor de 500GB.
Implementación:
Como primer paso, movimos las tablas ZARIX* a PÁGINA CARGABLE.
ALTER TABLE SAPABAP1.ZARIXBC1 PÁGINA CASCADA CARGABLE
ALTER TABLE SAPABAP1.ZARIXBC2 PÁGINA CASCADA CARGABLE
ALTER TABLE SAPABAP1.ZARIXBC3 PÁGINA CASCADA CARGABLE
Después de una semana de monitorear el caché del búfer, movimos las tablas de Documentos de Cambio a PÁGINA CARGABLE.
Antes de pasar a PÁGINA CARGABLE, hemos decidido aprovechar la partición y mover todos los datos históricos antiguos a PÁGINA CARGABLE y mantener solo la partición ACTUAL en la memoria.
Entonces, particionamos CDHDR/CDPOS en base a UDATE y CDPOS por CHANGENR.
ALTER TABLE SAPABAP1.CDHDR PARTICIÓN POR
RANGO(ACTUALIZAR)
((PARTICIÓN ‘20170101’ <= VALORES < '20180101',
PARTICIÓN ‘20180101’ <= VALORES < '20190101',
PARTICIÓN ‘20190101’ <= VALORES < '20200101',
PARTICIÓN ‘20200101’ <= VALORES < '20210101',
PARTICIÓN ‘20210101’ <= VALORES < '20220101',
PARTICIÓN OTROS
))
ALTER TABLE SAPABAP1.CDPOS
PARTICIÓN POR
RANGO (CAMBIO)((
PARTICIÓN ‘0000000000’ <= VALORES < '0010000000',
PARTICIÓN ‘0010000000’ <= VALORES < '0050000000',
PARTICIÓN ‘0050000000’ <= VALORES < '0100000000',
PARTICIÓN ‘0100000000’ <= VALORES < '0200000000',
PARTICIÓN ‘0200000000’ <= VALORES < '0300000000',
PARTICIÓN ‘0300000000’ <= VALORES < '0400000000',
PARTICIÓN ‘0400000000’ <= VALORES < '0500000000',
PARTICIÓN ‘0500000000’ <= VALORES < '0600000000',
PARTICIÓN ‘0600000000’ <= VALORES < '0700000000',
PARTICIÓN ‘0700000000’ <= VALORES < '0800000000',
PARTICIÓN ‘0800000000’ <= VALORES < '0900000000',
PARTICIÓN ‘0900000000’ <= VALORES < '1000000000',
PARTICIÓN OTROS))
La partición puede llevar tiempo según el tamaño de la tabla y se puede usar la siguiente consulta SQL para averiguar el progreso.
SELECCIONE * de M_JOB_PROGRESS
Mientras realiza la partición, tenga en cuenta el impacto en el rendimiento de la base de datos y siga monitoreando las alertas de Solution Manager, si ya lo tiene configurado.
Durante el proceso de partición, hemos recibido las siguientes alertas, pero no hay un impacto grave en el rendimiento ya que la partición se realiza en un período de baja actividad. Pero, se recomienda tener una configuración de monitoreo.
- Uso de la memoria de HANA: uso de la memoria de los servicios
- Versiones de MVCC
- Porcentaje de transacciones bloqueadas
- Transacciones de escritura no confirmadas de ejecución prolongada
Una vez particionado, mueva las particiones históricas a PÁGINA CARGABLE.
Declaración ‘ALTER TABLE SAPABAP1.CDHDR ALTER PARTITION 1 PAGE CARGABLE’
ejecutado correctamente en 1:08,042 minutos (tiempo de procesamiento del servidor: 1:07,851 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDHDR ALTER PARTITION 2 PAGE CARGABLE’
ejecutado correctamente en 1:08,998 minutos (tiempo de procesamiento del servidor: 1:08,811 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDHDR ALTER PARTITION 3 PAGE CARGABLE’
ejecutado correctamente en 1:12,009 minutos (tiempo de procesamiento del servidor: 1:11,830 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDHDR ALTER PARTITION 4 PAGE CARGABLE’
ejecutado correctamente en 1:04,275 minutos (tiempo de procesamiento del servidor: 1:04,094 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 1 PAGE CARGABLE’
ejecutado con éxito en 3,513 segundos (tiempo de procesamiento del servidor: 3,238 segundos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 2 PAGE CARGABLE’
ejecutado correctamente en 2:19,986 minutos (tiempo de procesamiento del servidor: 2:19,805 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 3 PAGE CARGABLE’
ejecutado correctamente en 2:14,751 minutos (tiempo de procesamiento del servidor: 2:14,573 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 4 PAGE CARGABLE’
ejecutado correctamente en 4:12,651 minutos (tiempo de procesamiento del servidor: 4:12,475 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 5 PAGE CARGABLE’
ejecutado correctamente en 4:56,709 minutos (tiempo de procesamiento del servidor: 4:56,533 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 6 PAGE CARGABLE’
ejecutado correctamente en 7:26,954 minutos (tiempo de procesamiento del servidor: 7:26,776 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 7 PAGE CARGABLE’
ejecutado correctamente en 7:12,293 minutos (tiempo de procesamiento del servidor: 7:12,116 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 8 PAGE CARGABLE’
ejecutado correctamente en 9:15,744 minutos (tiempo de procesamiento del servidor: 9:15,566 minutos) – Filas afectadas: 0
Declaración ‘ALTER TABLE SAPABAP1.CDPOS ALTER PARTITION 9 PAGE CARGABLE’
ejecutado correctamente en 17:31,126 minutos (tiempo de procesamiento del servidor: 17:30,949 minutos) – Filas afectadas: 0
Tamaño de caché de búfer:
Dado que la memoria caché del búfer es el factor clave que contiene las PÁGINAS cuando se accede a ellas, es necesario dimensionarlas correctamente.
Si mantiene el caché del búfer demasiado alto, en su mayoría no se usa.
Si mantiene el caché del búfer demasiado pequeño, pueden ocurrir eventos de desbordamiento del búfer y crear volcados cortos.
De forma predeterminada, Buffer Cache tiene un tamaño del 10% de GAL y podemos personalizarlo usando los parámetros a continuación.
indexserver.ini -> [buffer_cache_cs] -> max_size : Tamaño máximo de caché de búfer en MB
indexserver.ini -> [buffer_cache_cs] -> max_size_rel: tamaño máximo de caché de búfer relativo a GAL en %
Como parte de la actividad de implementación de NSE, descargamos 180 GB de tablas y mantuvimos el tamaño de caché del búfer inicial en 100 MB, que es demasiado bajo para empezar, pero lo mantuvimos así para las pruebas.
Le habíamos pedido a nuestro equipo de datos maestros que cargara algunos datos maestros y habían observado los siguientes volcados breves.
Aumentamos el tamaño de la memoria caché del búfer a 10 GB y no hemos recibido más volcados.
Es necesario supervisar la memoria caché del búfer para revisar la proporción de aciertos, el recuento de reutilización del búfer, etc.
Buffer Cache se puede monitorear usando:
SELECCIONE * DE M_BUFFER_CACHE_STATISTICS
Resultados:
Después de mover algunas tablas a PÁGINA CARGABLE, hemos visto una reducción en el uso de memoria HANA de alrededor de 240 GB, que es una cantidad significativa teniendo en cuenta el tamaño de la base de datos.
Notas importantes de SAP
3123259: Restricciones funcionales de SAP HANA Native Storage Extension 2.0 SPS 06
2927591: Restricciones funcionales de SAP HANA Native Storage Extension 2.0 SPS 05
2799997 – Preguntas frecuentes: Extensión de almacenamiento nativo (NSE) de SAP HANA
