Mantenimiento de la base de datos de SQL

Esta información se proporciona únicamente como guía. Se recomienda que siga las mejores prácticas estándar de la industria y que busque recomendaciones de un administrador de base de datos experimentado. Esta información debe utilizarse teniendo en cuenta el impacto más amplio en el entorno general.

Se deben mantener las siguientes bases de datos:

  • InteractDB

  • InteractCacheDB

  • IadaDB

  • AuthenticationServerDB

  • HubDB

  • AuditDB

  • NotificationCenterDB

  • LicenceManagerDB

  • FileServiceDB

  • EmailServiceDB

  • BluePrismDecisionDB

  • ImsDB

  • FileServiceDB

    • CacheDB fue reemplazado por FileServiceDB del Hub 4.4.

Recomendaciones generales para el mantenimiento de la base de datos

Se recomienda que usted:

  • Establezca el crecimiento automático correctamente para todas las bases de datos. Los valores recomendados son 1024 MB para el archivo de datos y 2048 MB para el registro de transacciones.
  • Restablezca el valor para el crecimiento automático a medida que aumenta el tamaño de la base de datos para minimizar la frecuencia de los eventos de crecimiento automático.

    • No utilice el % de crecimiento de archivos, sino que aumente en una cantidad fija de megabytes.

  • Elimine cualquier fragmentación excesiva del archivo de registro de transacciones. Para obtener más información, consulte la ayuda en línea de Microsoft.
  • Active la inicialización instantánea de archivos. Para obtener más información, consulte la ayuda en línea de Microsoft.
  • Desactive las operaciones de reducción automática, configure la verificación de página para todas las bases de datos en suma de comprobación y active AUTO_CREATE_STATISTICS y AUTO_UPDATE_STATISTICS. Implemente un proceso regular para actualizar las estadísticas.

    • Puede establecer el siguiente T-SQL para cada una de las bases de datos instaladas por Hub e Interact para este propósito:

    ALTER DATABASE [DatabaseNameHere] SET AUTO_CLOSE OFF;

    ALTER DATABASE [DatabaseNameHere] SET AUTO_SHRINK OFF;

    ALTER DATABASE [DatabaseNameHere] SET AUTO_UPDATE_STATISTICS ON;

    ALTER DATABASE [DatabaseNameHere] SET AUTO_CREATE_STATISTICS ON;

    ALTER DATABASE [DatabaseNameHere] SET PAGE_VERIFY CHECKSUM;

  • Tener un proceso regular para ejecutar DBCC CHECKDB: se recomienda que se ejecute un trabajo de agente de SQL como mínimo una vez al día durante períodos de poca o ninguna utilización del sistema. Los resultados deben verificarse para detectar corrupción. Puede ser beneficioso crear alertas de agente de SQL para notificar a un grupo de operadores de los siguientes errores:

    • 823 - Corrupción de I/O dura

    • 824 - Corrupción de I/O blanda

    • 825 - Leer/reintentar la corrupción

    • 9100 - Corrupción de índices

    • Gravedad 19-25 Errores

  • Optimizar para cargas de trabajo ad-hoc = ENCENDIDO

  • Valor predeterminado de compresión de copia de seguridad = ACTIVADO

  • Valor predeterminado de suma de comprobación de copia de seguridad = ACTIVADO

  • Límite de costo para el paralelismo: 50 es un buen punto de partida.

  • Grado máximo de paralelismo: depende de la configuración de NUMA del servidor SQL, pero no más que el número de núcleos para un único nodo NUMA.

  • Establecer cierre automático = ENCENDIDO

  • Memoria de servidor mín.: diferente según el servidor SQL, pero se debe configurar.

  • Memoria de servidor máx.: diferente según el servidor SQL, pero se debe configurar.

Recomendaciones de diseño de disco

Se recomienda utilizar unidades separadas para los archivos de registro de datos y transacciones, bases de datos temporales y copias de seguridad.

Crear un plan de mantenimiento

Asegúrese de tener un plan de mantenimiento para realizar copias de seguridad regulares. Utilice el plan de mantenimiento preferido de su organización para realizar copias de seguridad de las bases de datos de SQL. Si su organización no tiene un plan de mantenimiento, se recomienda que investigue las mejores prácticas de la industria y seleccione un plan de mantenimiento que se adapte a las necesidades de su organización.

Tomar copias de seguridad

Las copias de seguridad deben diseñarse en función de los objetivos de punto de recuperación (RPO) y tiempo de recuperación (RTO) de su organización.

  • RPO: el momento en el que puede recuperar sus datos después de un error. Esto determina cuántos datos se pierden.
  • RTO: la cantidad de tiempo que tiene para recuperar sus datos después de una falla. Esto determina la cantidad de tiempo que la plataforma no está disponible.

Al crear un plan de copia de seguridad y recuperación para las bases de datos de Blue Prism, es importante considerar e implementar los siguientes puntos:

  • Definir tanto el RPO como el RTO.
  • Utilizar el modelo de recuperación COMPLETA para permitir copias de seguridad de registros de transacciones, diferenciales y completas en línea con su RPO y RTO.
  • Utilizar las opciones CON SUMA DE COMPROBACIÓN y SOLO LO VERIFICADO en todas las copias de seguridad para verificar que las copias de seguridad sean válidas y se puedan restaurar si es necesario.
  • Utilice la opción CON COMPRESIÓN para ahorrar espacio en el disco y reducir el tiempo necesario para realizar copias de seguridad de las bases de datos y, opcionalmente, restaurarlas.
  • Documentar el proceso de copia de seguridad y recuperación.
  • Verifique que sus copias de seguridad sean confiables intentando restaurarlas regularmente.

La frecuencia con la que realice estas copias de seguridad depende del tamaño de su organización y del monto y valor del riesgo de los datos.

Se recomienda realizar copias de seguridad completas durante el tiempo de inactividad absoluto. Se pueden realizar copias de seguridad incrementales sin detener ningún servicio con el riesgo de que se pierdan algunos datos.

Resolver la fragmentación del índice

La fragmentación del índice de la base de datos reduce el rendimiento de la consulta con el tiempo. Para evitar esto, reconstruya los índices tan frecuentemente como lo permita el tiempo de inactividad de la base de datos. También se recomienda reconstruir los índices después de tomar copias de seguridad y/o eliminar grandes cantidades de datos. También se recomienda que reconstruya los índices antes de realizar una copia de seguridad completa de la base de datos para minimizar la fragmentación de los índices en caso de tener que restaurar una copia de seguridad completa.

Los límites recomendados para el mantenimiento del índice de reconstrucción/reorganización son: < 30 % de reorganización y > 30 % de reconstrucción.

La reconstrucción de índices de base de datos se puede programar para ejecutarse como un trabajo dentro del servidor de base de datos y/o agregarse al plan de mantenimiento de base de datos. Se recomienda que los ejecute durante períodos de baja actividad del sistema y que estén programados para evitar superponerse con la copia de seguridad y el mantenimiento de DBCC CHECKDB.