Mantenimiento de la base de datos

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Administración del Sistema Bizagi > Mantenimiento y administración >

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

 

 

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

 

Recomendaciones básicas al ejecutar tareas de diagnóstico (perfilamiento)

Cuando se lleven tareas enfocadas al diagnóstico y seguimiento de un problema específico, y se desee usar un perfilamiento, considere estos lineamientos:

 

1. No ejecutar el perfilamiento (profiler) desde el mismo servidor de base de datos.

 

2. De manera similar y cuando aplique, ejecute un perfilamiento cuando el servidor no se encuentre en horas muy ocupadas (horario crítico de operaciones).

Podrá ser útil generar una traza sobre el horario crítico si el escenario lo amerita, sin embargo, podrá considerar primero un muestreo para evitar afectar el rendimiento del servidor.

 

3. Siempre incluya filtros en el perfilamiento.

 

4. Capture solamente la información relevante y necesaria en las trazas en cuanto a los eventos de información que se graban.

Por ejemplo, en SQL Server, podrá considerar los procedimientos almacenados: RPC:Completed y TSQL--SQL:BatchCompleted.

 

5. Capture solamente la información relevante y necesaria en las trazas en cuanto a las columnas de información.

Analice qué aspectos son clave para indicar el estatus del rendimiento de su base de datos.

Por ejemplo, en SQL Server, podrá considerar: el consumo de CPU, la cantidad de escrituras –

writes-, lecturas, y el tiempo de inicio y de fin.

 

6. De acuerdo a lo anterior, también podrá usar filtros para alertar las transacciones potencialmente problemáticas.

Por ejemplo, puede iniciar por obtener sólo aquellas cuya duración es mayor a 3 segundos o cuyo número de registros afectados es muy alto.

 

Notas adicionales

Tenga en cuenta que además del afinamiento y monitoreo a la base de datos, usted también deberá considerar las tareas de monitoreo sobre otros aspectos relacionados que interfieren en el funcionamiento adecuado de la base de datos (p.e configuración del dominio si son parte de una configuración en clúster, la red entre sus servidores de base de datos y otros elementos de la arquitectura del sistema como por ejemplo la SAN o el mismo servidor de Bizagi).

Para mayor información consulte Monitoreo.

 

note_pin

Tenga en cuenta que no se recomienda que los software Antivirus realicen un escaneo sobre los archivos físicos de la base de datos.

Lo anterior puede conllevar a bloqueos y demoras de la aplicación al intentar persistir la información a la base de datos.