Mantenimiento de la base de datos

Introducción

Una tarea muy importante en el mantenimiento y administración del Sistema Bizagi, es realizar un mantenimiento constante a la base de datos, de manera que se pueda velar por el correcto funcionamiento y óptimo desempeño del sistema.

Tenga en cuenta que cada motor de base de datos (SQL Server u Oracle) ofrece las herramientas necesarias para realizar monitoreo pro-activo, diagnósticos (herramientas de perfilamiento), o acciones de afinamiento sobre la base de datos.

Lineamientos para el monitoreo y afinamiento

Recomendamos al DBA lo siguiente:

1. Ejecute un monitoreo contínuo sobre el rendimiento de la base de datos.

Nótese que los motores de bases de datos en sí, proveen las herramientas especializadas que permiten un monitoreo, ejecutar diagnósticos e interpretar resultados para el posterior afinamiento (además de archivos de log correspondientes).

A través del monitoreo proactivo, usted puede anticiparse a una situación no deseable (table scans, bloqueos o demoras, etc), y evidenciar aspectos que requieren de afinamiento.

Por ejemplo, la detección de un table scan sugerirá que las consultas/estadísticas no están al día de manera óptima, o que se necesita mantener los índices (crear nuevos o redefinir los existentes).

Aspectos relevantes a monitorear ya sea para revisar la configuración o las características del hardware e infraestructura, incluyen: los cuellos de botella que se puedan presentar por falta de memoria, por esperas en la lectura y escritura a disco, o incluso un alto tráfico de red.

Las siguientes métricas son recomendadas:

PhysicalDisk(_Total)\Avg. Disk sec/Read

PhysicalDisk(_Total)\Avg. Disk sec/Write

Contadores de tiempo promedio de Escritura cuando se usa el Disco. No debería ser mayor de 20ms para Discos duros o 5ms para unidades SSD.

Processor(_Total)\% Processor Time

 Indica el porcentaje de uso del procesador, el uso ideal debe ser entre el 30% y 80%.  Cuando está por encima indica que se requieren más recursos de procesamiento y puede generar tiempos de espera que pueden hacer lento el funcionamiento de la aplicación.

Memory\Available MBytes

Indica la memoria disponible en el servidor de base de datos, si el nivel de memoria es bajo indica que la base de datos no tiene suficiente espacio en memoria e inicia a hacer operaciones con memoria virtual en disco, que hacen la base de datos lenta.

Paging File(_Total)\% Usage

Este indicador está ligado a la memoria disponible y a la memoria máxima asignada a SQL Server ,e indica si se están procesando datos en disco en vez de la memoria.

System\Processor Queue Length

Indica si hay procesos que tienen que esperar por recursos de CPU, si se presenta un número mayor que 0 indica que los procesadores o núcleos no son suficiente para el procesamiento de las operaciones solicitadas.

Network interface\Bytes total/sec

Permite monitorear las interfaces de red, si se mantiene por encima del 80% las aplicaciones pueden presentar problemas en el tráfico de red.

SQLServer:Access Methods\Forwarded Records/sec

 Permite saber que tan fragmentadas estan las tablas que no tienen un indice clustered (heap tables) cuando la fragmentación es alta hace que se creen apuntadores que ejecutan operaciones de I/O que pueden hacer lenta la operación.

SQLServer:Access Methods\Page Splits/sec

Permite conocer si las tablas se están fragmentado constantemente en indica que hay división páginas y movimiento constante de filas y esta es una operación que se podría optimizar.

SQLServer:Buffer Manager\Buffer cache hit ratio

Es un indicador que mide los aciertos al cache en procesamiento de datos. Un numero alto indica que se está haciendo un alto uso de memoria y se reducen las operaciones de I/O.

SQLServer:Buffer Manager\Page life expectancy

Permite monitorear si el tiempo de vida de las paginas en el cache, es decir si los datos en cache se liberan muy rápido debido que se requiere cargar otros datos.  Si este indicador es menor de 300 pueden haber problemas de consultas que procesan muchos datos y se requiere más memoria.

SQLServer:SQL Statistics\SQL Compilations/sec

SQLServer:SQL Statistics\SQL Re-Compilations/sec

Estos contadores se incrementan cuando SQL Server tiene que compilar o recompilar los planes de consulta porque el plan en caché ya no es válido o no hay un plan en caché para esta consulta, esto aumenta el consumo de procesador de la base de datos.

SQLServer:General Statistics\Processes blocked

Permite medir el nivel de bloqueos que ocurren en la base de datos y si este contador tiende a incrementar respecto a una línea base indica que hay muchos escalamientos de bloqueos de fila a bloqueos de página y puede llegar a bloqueos de tabla.

SQLServer:SQL Statistics\Batch Requests/sec

Permite medir el nivel de transacciones que se estan ejecutando en la base de datos.  Este contador se debe mantener en un rango normal de operación diaria y si se evidencian variaciones se debe investigar si hay procesos ocasionales que generan esa carga.

2. Lleve a cabo un afinamiento de manera periódica, y siguiendo mejores prácticas.

Para procesos en los que se espera la producción de una gran cantidad de casos, o gran cantidad de actividades por día, el afinamiento de la base de datos se recomienda como mínimo de manera semanal.

Las mejores prácticas incluyen que el afinamiento se realice en horarios no laborales, y de manera planeada (considerando que estas tareas pueden tomar un tiempo significativo), al igual que otras recomendaciones que sean instruidas por el fabricante del motor de la base de datos.

Los principales aspectos sujetos al afinamiento son:

•Verificar la integridad de la base de datos.

•Actualizar las estadísticas

•Reorganizar y mantener los índices actualizados (recrear los que estén altamente fragmentados o reorganizarlos de acuerdo al orden las columnas consultadas -especialmente para índices compuestos).

•Reducir la base de datos (shrinks).

•Monitorear los filegroups, de manera que su configuración (tamaño, incremento, tamaño máximo, volumen de disco usado, etc) sea la adecuada de acuerdo a su comportamiento de crecimiento.

Dependiendo de las características de hardware en sus nodos de base de datos (p.e el número de discos duros, número de procesadores y cores), podrá configurar los data files y archivos de log de manera óptimizada (escalar estos archivos).

Por ejemplo y de acuerdo a lo anterior, usted podría decidir beneficiarse de las operaciones de entrada y salida de disco en paralelo (I/O) al contar con múltiples volúmenes de datos si decide separar los data files y filegroups (ubicando los archivos de log, o tempdb en su propio volumen, o incluso un data file dedicado con las tablas transaccionales más usadas -en un volumen con mejor velocidad).

Sobre tempdb, se recomienda configurarlo con múltiples data files y filegroups, que tengan un tamaño predefinido (todos homogéneamente) y evitando el crecimiento automático (auto-growth). Así se podrá usar un data file por CPU/core.

Al realizar la configuración del tamaño predefinido, considere recomendaciones como: Deshabilitar el crecimiento automático (auto-growth) en los data files, hacer que los data file y los archivos de log no usen más del 90% del espacio disponible en disco, hacer que los archivos de log tengan el doble del tamaño de un único data file, y permitir el crecimiento automático (auto-growth) para el archivo de log file a cierto tamaño dado.

Dentro del modelo de datos de Bizagi, considere prestar especial atención al comportamiento de las siguientes tablas:

(además de cualquier otras del negocio que se detecten crezcan rápidamente).

•Aquellas relacionadas al almacenamiento diario de trabajo como: Workitem, Workitemcl, Wfcase, y Wfcasecl.

•Otras similares adicionales, que dependen de qué tanto se usen en su proyecto como: Asynchwiretry y Asynchworkitem.

•Aquellas almacenando logs como: AttribLog, EntityLog, Wistatelog, Transitionlog, Factlog, Casestatelog, Authlog, Attribcharlog, Assignationlog, Joblog (especialmente cuando su proyecto involucra frecuentemente los trabajos), Alarmjobrecipientlog (especialmente cuando su proyecto involucra frecuentemente las alarmas), Wfcaseabortreason (especialmente cuando en su proyecto se aboirtan casos frecuentemente de manera manual) y Reassignlog (especialmente cuando en su proyecto se realizan reasignaciones frecuentemente de manera manual).

Nótese que también se puede optar por separar estas tablas de log en un filegroup aparte.

Adicional a lo anterior, incluya en sus planes de afinamiento, las tablas del negocio que esperan almacenar una gran cantidad de información.

De acuerdo a lo observado, podrá revisar cómo está fragmentada la información (p.e, los filegroups en SQL Server o los tablespaces en Oracle).

3. Siga los lineamientos de creación de índices de Bizagi.

Al momento de crear y reorganizar índices, considere los siguientes aspectos:

•Podrá crear índices de tipo "no agrupados" (non-clustered).

•Podrá crear índices en las tablas que sean propias del proyecto (es decir, tablas de negocio que no sean del meta modelo de Bizagi).

•Como recomendación usual en las bases de datos, no es provechoso crear índices sobre columnas con pocos posibles valores (p.e tipo booleano o tipo bit).

•No se deben crear índices de manera automática (sin previo análisis), como por ejemplo a través de tareas de Database Engine Tuning advisor de SQL Server, ya que el mismo DBA debe cerciorarse de evaluarlos oportunamente.

Además de un análisis de costo-beneficio para un índice, podrá contemplarlo dentro del plan de ejecución de consulta y estadísticas de uso (p.e a la luz de los index seeks, index scans, index lookups o index updates).

4. Asegúrese de contar con la configuración adecuada de concurrencia en SQL Server.

Realice monitoreo sobre la configuración requerida para que la base de datos de Bizagi maneje concurrencia.

Esto implica verificar que la base de datos de Bizagi tenga habilitado el modo snapshot isolation.

Específicamente:

•Allow Snapshot isolation: True (ALLOW_SNAPSHOT_ISOLATION ON)

•Is Read-committed snapshot isolation on: True (READ_COMMITTED_SNAPSHOT ON)

Nótese que al utilizar los niveles descritos anteriores de snapshot isolation, se vuelve aún más importante que incremente los recursos y refuerce las mejores prácticas para la base de datos tempdb (p.e, el uso de un volumen propio que garantice velocidades óptimas en operaciones I/O).

5. Asegúrese que el usuario de sistema se encuentre habilitado.

Recuerde que el usuario domain\admon es el usuario del sistema que emplea internamente Bizagi (creado por defecto).

No se podrá deshabilitar este usuario dado que es necesario para realizar tareas automáticas como temporizadores o tareas programadas, y se recomienda revisar que este usuario esté siempre habilitado en la base de datos.

Habiendo dicho lo anterior, nótese que se recomienda enfáticamente editar la configuración del usuario para que no tenga acceso de administrador en el Portal de Trabajo.

Para ello, podrá excluir al usuario de la lista de usuarios permitidos en las opciones de administración (p.e, que este usuario no tenga permisos para administrar usuarios, modificar entidades de parametrización, abortar casos, etc).

6. Asegurese que la base de datos tenga los derechos de acceso adecuados

Asegúrese que las credenciales que usan tanto las instancias del Portal de Trabajo como del programador tiene las credenciales de acceso adecuados, como se configuraron en la configuración inicial.

La imagen siguiente muestra las credenciales necesarias para un servidor SQL.

Los roles del servidor especificados para el login deben incluir el rol: publico (public).

Este login debe incluir los siguientes items mapeados por el usuario para la base de datos especifica: db_datareader, db_datawriter, public, rlBA_SQL_BizagiWebApp and rlBA_SQL_ExecuteBizagiSPs.

También es buena idea revisar que este login este habilitado:

Actualizando un proyecto

Cuando actualiza un proyecto adicional de los derechos de acceso mencionados en la sección anterior, necesita lo siguiente:

Privilegios del servidor

Configure al usuario con privilegios para hacer una copia de seguridad y crear la base de datos

GRANT BACKUP DATABASE TO UserName
GRANT CREATE DATABASE TO UserName

Asegurables

Abra la sección Asegurables, seleccione la pestaña Efectivo y asegúrese de tener los siguientes permisos;

CONNECT SQL

VIEW ANY DATABASE

Solución de problemas y diagnostico

Cuando necesite solucionar o diagnosticar un problema en su base de datos use una herramienta especializada de su motor de la base de datos, tal como la herramienta Profiler para SQL Server. Para más información de esta opción consulte la sección to Recomendaciones del Profiler.