Mantenimiento de la base de datos

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automation Server > Automation Server - configuración y administración > Mantenimiento y monitoreo del sistema >

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.
 

 

User_DBA

 

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.

 

note_pin

Si el DBA detecta que el motor de base de datos no cuenta con un óptimo desempeño (no ejecuta las consultas bajo buenos tiempos de respuesta), recuerde que podrá escalar verticalmente la base de datos en cualquier momento (o escalar horizontalmente si se utiliza un esquema de clúster activo-activo como Oracle RAC).

 

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).

 

note_pin

Recuerde realizar el afinamiento de base de datos después de ejecutar acciones de mantenimiento de Bizagi (p.e las realizadas por el Programador, u otras opciones desde utilitarios adicionales como Archiving).

 

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).

 

SnapshotIsolation

 

note_pin

Los siguientes lineamientos proveen un punto de partida así como también recomendaciones útiles para las tareas de monitoreo, diagnóstico y afinamiento de base de datos.

Sin embargo, estos lineamientos no abarcan extensivamente todas las tareas que un DBA debe realizar para un mantenimiento de la base de datos (la información siguiente es enunciativa y no exhaustiva o taxativa).

 

Deberá llevar a cabo las tareas de afinamiento adicionales que promueva el fabricante del motor de base de datos por sí, y tal como sean identificadas por el uso de las herramientas especializadas (de lo observado en trazas y logs).

 

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 portad 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.

Login_SQLAuth

 

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

 

Login_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.

 

Login_mappings

 

note_pin

Los mapeos de usuarios db_datareader, db_datawriter, public, rlBA_SQL_BizagiWebApp y rlBA_SQL_ExecuteBizagiSPs aplican para la base de datos de su proyecto. Esto quiere decir que debe realizar estos mapeos cuando la base de datos de su ambiente de producción ha sido creada.

 

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

 

Login_enabled

 

Solución de problemas y diagnostico

Cuando necesite solucionar o diagnosticar un problema en su base de datos, usted puede decidir si:

Usar en una herramienta especial de Bizagi para este propósito. Para más información de esta opción consulte la sección Herramienta de diagnóstico de Bizagi (Diagnostics).

Usar 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.