Mantenimiento de bases de datos del sistema SQL Server

La instalación de SQL Server por defecto crea varias bases de datos del sistema por instancia para mantener y administrar esa instancia. En este artículo, examinaremos estas bases de datos del sistema y entenderemos sus responsabilidades.

Bases de datos del sistema del servidor SQL

En SQL Server, las bases de datos del sistema se crean durante el proceso de instalación para almacenar los detalles de configuración específicos de la instancia de SQL Server para que funcionen normalmente. Cada instalación de SQL Server crea un mínimo de 5 bases de datos del sistema y 1 base de datos del sistema relacionada con la replicación denominada base de datos de distribución que serán creados por los usuarios si la replicación está configurada en esa instancia. Cada base de datos del sistema tiene su propósito y lo investigaremos en detalle más adelante en este artículo.

Las bases de datos del sistema son:

Maestro:instalado de forma predeterminada
Msdb:instalado de forma predeterminada
Modelo:Instalado de forma predeterminada
Tempdb:instalado de forma predeterminada
Recurso:Instalado de forma predeterminada . Introducido en SQL Server 2005 y disponible en versiones posteriores de SQL Server y, por lo tanto, no disponible en SQL Server 2000 y versiones anteriores.
Distribución – Creado por acción del usuario . Los usuarios pueden crear la base de datos de distribución para configurar la replicación.

Para ver la base de datos del sistema instalada en SQL Server, podemos usar SSMS.

Conéctese a su instancia de SQL Server, expanda Bases de datos > Bases de datos del sistema :

¿Ha notado que el Recurso falta la base de datos en la lista anterior? La cuestión es que la base de datos de recursos es una base de datos especial del sistema que no aparece en el Explorador de objetos de SSMS. Sin embargo, podemos consultar los detalles de la base de datos de recursos desde un sistema DMV llamado sys.sysaltfiles y ejecuta la consulta:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

En los resultados, podemos ver las bases de datos del sistema en orden:master, tempdb, model, msdb, distribution y, finalmente, el dbid 32767 que es una base de datos de recursos. Sin embargo, esta base de datos de recursos no muestra ningún nombre de base de datos ya que no tiene una entrada en sys.databases . Excluí un par de bases de datos de usuarios entre dbid 5 y 11 e incluí AdventureWorks_REPL como ejemplo para mostrar que el DMV también puede mostrar bases de datos de usuarios. Más adelante entraremos en más detalles sobre la base de datos de recursos y otras bases de datos del sistema.

Restricciones de las bases de datos del sistema SQL

Dado que las bases de datos del sistema contienen detalles críticos de configuración del sistema, debe haber medidas de seguridad adecuadas para evitar la eliminación accidental de datos. Por lo tanto, las bases de datos del sistema tienen las siguientes restricciones en comparación con las bases de datos de los usuarios:

Las bases de datos del sistema no se pueden desconectar

Podemos desconectar una base de datos de usuario usando el comando ALTER DATABASE como se muestra a continuación:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Sin embargo, si intentamos desconectar cualquiera de las bases de datos del sistema usando el comando anterior, recibiremos un error como se muestra a continuación:

Las bases de datos del sistema no se pueden descartar

Si bien podemos eliminar las bases de datos de los usuarios ejecutando el comando DROP DATABASE

DROP DATABASE AdventureWorks

Si intentamos DROP cualquiera de las bases de datos del sistema, recibiremos el error como se muestra a continuación:

No se puede cambiar el propietario de las bases de datos del sistema

El propietario de la base de datos del sistema es sa por defecto. No se puede cambiar. Los intentos de cambiar el nombre del propietario de la base de datos del sistema provocarán errores.

como sea, hay una excepción. Es posible modificar el propietario del msdb base de datos.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

No se puede cambiar el nombre de la base de datos de las bases de datos del sistema

Si intentamos cambiar el nombre de las bases de datos del sistema, obtendremos un mensaje de error como se muestra a continuación:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

La intercalación de las bases de datos del sistema no se puede cambiar

Las bases de datos del sistema se crean con el nombre de intercalación elegido durante el tiempo de instalación de SQL Server. Una vez instalada, la intercalación de las bases de datos del sistema no se puede cambiar. La única forma de cambiar la intercalación de las bases de datos del sistema es reinstalar la instancia de SQL Server con la intercalación correcta.

El grupo de archivos principal de las bases de datos del sistema no se puede configurar en modo READ_ONLY

Dado que la base de datos del sistema captura información crítica relacionada con las instancias de SQL Server, SQL Server no permite que los archivos de datos principales que residen en el grupo de archivos principal se establezcan como solo lectura. .

La función de captura de datos modificados no se puede habilitar en las bases de datos del sistema

Esta función se utiliza para rastrear cada cambio de DML que ocurre en una base de datos en las tablas rastreadas. Si intentamos habilitar la función de captura de datos modificados en cualquier base de datos del sistema, se producirá el error:

use master
GO
exec sys.sp_cdc_enable_db

Ahora que tenemos clara la diferencia entre las bases de datos del sistema y las bases de datos del usuario, podemos examinar los propósitos de cada base de datos del sistema con más detalle.

Base de datos maestra en SQL Server

La base de datos del sistema maestro contiene detalles de configuración clave relacionados con la instancia de SQL Server . SQL Server se basa en ellos cuando inicia una instancia en particular. Si es imposible iniciar la base de datos maestra por alguna razón, la instancia de SQL Server tampoco podrá iniciarse.

Estos detalles clave almacenados en la base de datos maestra incluyen las cuentas de inicio de sesión, los detalles del servidor vinculado, los puntos finales, los ajustes de configuración del sistema y los detalles sobre todas las bases de datos de usuarios.

Ahora viene la pregunta. ¿Cómo sabe el servicio de SQL Server dónde están disponibles los datos y los archivos de registro de la base de datos maestra? La respuesta está en los parámetros de configuración de inicio del servicio SQL Server.

Para ver los parámetros de configuración de inicio de una instancia de SQL Server, primero debemos conocer la herramienta integrada llamada Administrador de configuración de SQL Server . Ayuda a administrar todos los servicios relacionados con SQL Server de todas las instancias disponibles en el servidor en particular. Para ver estos datos, abra el Administrador de configuración de SQL Server y mostrará la lista como se muestra a continuación:

Haga clic en Servicios de SQL Server para ver la lista de Servicios disponibles en este Servidor o PC:

¡Espera un segundo! Parece familiar para services.msc enumera todos los servicios disponibles en el servidor pero muestra solo los servicios relacionados con SQL Server.

Abramos services.msc para ver cómo se ve y verificar las diferencias entre el Administrador de configuración de SQL Server y services.msc para comparar cual es mejor.

El Administrador de configuración de SQL Server muestra el ID de proceso de los servicios que se están ejecutando actualmente. No pudimos encontrar eso en services.msc . Por supuesto, podemos obtener esta información del Administrador de tareas de Windows, pero el Administrador de configuración de SQL Server nos ayudó a ver esto en un solo lugar.

Ahora, echemos una vista detallada. Haga clic derecho en el servicio de SQL Server desde services.msc . Verá los siguientes menús:General , Iniciar sesión , Recuperación y Dependencias .

Desde el Administrador de configuración de SQL Server, haga clic con el botón derecho en SQL Server(MSSQLSERVER) servicio> Propiedades . Enumera los siguientes menús:Iniciar sesión, Servicio. FileStream, Advanced, Alwayson OnAlta disponibilidad y Parámetros de inicio .

Los parámetros de inicio del Servicio que almacena la ubicación de los datos de la base de datos maestra y los archivos de registro solo estaba disponible en el Administrador de configuración de SQL Server .

Haga clic en Parámetros de inicio para ver los detalles - para Existente Parámetros . Verá la siguiente información:

La ubicación física de la base de datos maestra Archivo de datos
La ubicación física de la base de datos maestra Archivo de registro de transacciones
La ubicación física de la carpeta de registro de errores donde se encuentran los errores relacionados con el servicio de SQL Server.

Podemos agregar más parámetros de inicio como Modo de usuario único (-m) , etc. Para eso, necesitamos especificar los valores necesarios en Especificar un parámetro de inicio y haz clic en Agregar .

Hemos notado que el Administrador de configuración de SQL Server no solo muestra detalles avanzados, sino que también nos permite realizar muchas configuraciones avanzadas relacionadas con el servicio de SQL Server. Por lo tanto, personalmente recomendaría usar el Administrador de configuración de SQL Server para detener/iniciar servicios relacionados con SQL Server en comparación con la opción predeterminada Services.msc.

Prácticas recomendadas para la base de datos maestra

Dado que la base de datos maestra almacena detalles críticos sobre la instancia de SQL Server, se recomienda seguir las mejores prácticas al manejar esa base de datos.

Cada cambio de configuración en una instancia de SQL Server se almacenará en la base de datos principal. Por lo tanto, siempre debe realizar una copia de seguridad completa de la base de datos maestra para restaurar al estado más reciente en caso de que estemos restaurando la base de datos maestra desde la copia de seguridad completa, según sea necesario.

Aunque SQL Server permite a los usuarios crear tablas de usuario u otros objetos en la base de datos principal, no se recomienda hacerlo. La base de datos maestra debe permanecer simple y limpia. Si necesita crear objetos de usuario en la base de datos maestra, debe realizar copias de seguridad completas de la base de datos maestra con más frecuencia.

SQL Server admite la opción de procedimiento de inicio para ejecutar ciertos procedimientos almacenados al iniciar una instancia de SQL Server. Utiliza la sp_prooption procedimiento. Tenga cuidado al usar esta opción porque tener un código no óptimo o una lógica recursiva podría afectar el tiempo de inicio de la instancia de SQL Server.

Si SQL Server no pudo iniciarse debido a algún problema con la base de datos maestra, debemos restaurar la base de datos maestra desde la última copia de seguridad buena conocida.

Base de datos modelo en SQL Server

Como su nombre lo indica, la base de datos del sistema modelo actúa como modelo o plantilla para la creación de cualquier base de datos de usuario en cuanto a la ruta del archivo, el tamaño inicial, la configuración de crecimiento automático, el modelo de recuperación y otras opciones de configuración .

Cualquier objeto de usuario como tablas, procedimientos, etc., que se creen en las bases de datos modelo también se crearán automáticamente en las nuevas bases de datos de usuario en esa instancia de SQL Server.

Verifiquemos esto creando una nueva tabla en la base de datos modelo:

Verifiquemos si esta tabla está presente en la base de datos del modelo:

La base de datos modelo también almacena la ruta de archivo predeterminada de las bases de datos de usuario, como se muestra a continuación en las Propiedades de la base de datos. del msdb base de datos.

Según la configuración actual, el Tamaño del archivo inicial de ambos Datos y archivos de registro está configurado en 8 MB con crecimiento automático para ambos configurados en 64 MB.

Si necesita crear una base de datos de usuario en una ruta de archivo diferente en lugar de la ubicación del archivo de la base de datos modelo, podemos modificarla en las Propiedades del servidor de esa instancia de SQL Server.

En SSMS, haga clic derecho en Servidor > Propiedades > Configuración de la base de datos . Ver las ubicaciones predeterminadas de la base de datos:

Cambie la ruta del archivo a la ruta deseada y haga clic en Aceptar . La base de datos de usuarios Datos y Iniciar sesión los archivos se crearán en la nueva ruta que proporcionó.

Vamos a crear una nueva base de datos llamada model_test y verifique las nuevas rutas de datos y archivos de registro de la base de datos junto con las propiedades del archivo inicial y de crecimiento automático y el model_verify tabla en la nueva base de datos.

Verifiquemos el model_test Rutas de datos y archivos de registro. Haga clic derecho en el modelo_prueba base de datos> Propiedades > Archivos :

Como podemos ver, los Datos y Iniciar sesión archivos del modelo_prueba base de datos se crean de acuerdo con la ruta disponible en la base de datos modelo. El valor del tamaño del archivo inicial de los archivos de datos y de registro es de 8 MB. El valor de crecimiento automático es de 64 MB. Estos valores coinciden con la configuración de la base de datos modelo.

Ahora, comprobaremos si model_verify la tabla se crea en el model_test base de datos. Podemos ver esta nueva base de datos.

Además de las tablas, esto se aplica a las vistas, los procedimientos almacenados, las funciones y cualquier objeto creado en las bases de datos del modelo.

Prácticas recomendadas para la base de datos modelo

Dado que la base de datos modelo actúa como una plantilla para la creación de cualquier nueva base de datos de usuario, debemos implementar las siguientes prácticas al tratar con ella:

Siempre que desee implementar cambios en la configuración de la base de datos modelo (p. ej., tamaño de archivo inicial, tamaño de crecimiento automático, creación, modificación o eliminación de objetos de usuario), realice una copia de seguridad completa de la base de datos modelo inmediatamente.

Dado que los objetos de usuario creados en las bases de datos modelo se crean en cualquier base de datos de usuario, tenga cuidado de agregar solo los objetos necesarios. De lo contrario, se crearán muchos objetos innecesarios en todas las bases de datos de los usuarios, y pasará mucho tiempo ordenándolos y limpiando sus bases de datos.

Configure los parámetros Tamaño de archivo inicial y Crecimiento automático para los archivos de datos y de registro. Ayuda a administrar mejor los tamaños de los archivos de datos y registros en las bases de datos de los usuarios y mejorar el rendimiento.

Base de datos MSDB

La base de datos del sistema msdb almacena la siguiente información crítica en las tablas del sistema:

Elementos relacionados con el Agente SQL Server, como trabajos, historiales de trabajos, alertas, operadores, proxies, etc.
Características de SQL Server como Service Broker y Database Mail con los detalles de configuración e historial.
Los detalles de copia de seguridad y restauración de SQL Server se almacenan dentro de las tablas de la base de datos msdb.
Configuraciones de envío de registros, perfiles de agentes de replicación y configuraciones de recopiladores de datos.
Planes de mantenimiento, paquetes SSIS y algunos otros detalles.

En otras palabras, la base de datos del sistema msdb almacena toda la información crítica relacionada con los Servicios del Agente SQL Server y algunos otros servicios relacionados.

Prácticas recomendadas para la base de datos msdb

La base de datos msdb almacena una gran cantidad de información de configuración crítica relacionada con los agentes de SQL Server, los trabajos y el correo de la base de datos. También almacena detalles históricos. Por lo tanto, debemos implementar las siguientes prácticas al tratar con la base de datos msdb:

En una instancia de SQL Server con muchas bases de datos o trabajos configurados, el tamaño de la base de datos msdb aumentará continuamente durante un tiempo. Por lo tanto, las copias de seguridad completas deben implementarse diariamente para las bases de datos msdb junto con otras bases de datos de usuarios. Si msdb recibe mucha información crítica, entonces podemos cambiar el modelo de recuperación de la base de datos msdb a completo y luego implementar también la copia de seguridad del registro de transacciones.

Aunque SQL Server permite a los usuarios crear objetos de usuario en la base de datos msdb, se recomienda no crear ninguna tabla u objeto de usuario en la base de datos msdb y aumentar aún más el tamaño de la base de datos msdb.

Realice una limpieza regular de las tablas del sistema msdb para mantener el tamaño de la base de datos msdb bajo control y evitar los impactos en el rendimiento de tener grandes cantidades de datos en varias tablas.

Base de datos de base de datos temporal

La base de datos del sistema tempdb puede considerarse como un área de trabajo global disponible para todos los usuarios conectados a la instancia de SQL Server para realizar su SELECT u otras operaciones .

La base de datos tempdb contendrá los siguientes tipos de objetos mientras los usuarios realizan sus operaciones:

Los objetos temporales creados explícitamente por los usuarios pueden ser tablas e índices temporales locales o globales, variables de tabla, tablas utilizadas en funciones con valores de tabla y cursores.
Objetos internos creados por el motor de base de datos, como:
- Tablas de trabajo utilizadas para resultados intermedios para carretes, cursores, clasificaciones y objetos grandes temporales (LOB)
- Archivos de trabajo para operaciones Hash Join o Hash agregado
- Resultados de clasificación intermedios al tratar con la creación o reconstrucción de índices si SORT_IN_TEMPDB está configurado en ON y otras operaciones como consultas GROUP BY, ORDER BY o UNION
Almacenes de versiones que admiten la función de control de versiones de filas, ya sea el almacén de versiones común o el almacén de versiones de compilación de índice en línea.

Siempre que el servicio de SQL Server se inicie o reinicie, la base de datos tempdb se creará de nuevo con la ayuda de la base de datos modelo. Por lo tanto, tempdb es la única base de datos del sistema de la que no se puede hacer una copia de seguridad .

Si intentamos hacer una copia de seguridad, recibiremos errores:

Dado que usamos tempdb en casi todas las operaciones de los usuarios, esta base de datos presenta un cuello de botella de rendimiento significativo en varias versiones de SQL Server. A partir de SQL Server 2016, Microsoft implementó varias técnicas de optimización; las analizaremos más adelante.

Antes de entrar en las prácticas recomendadas para la base de datos tempdb, echemos un vistazo rápido a sus archivos de datos en la configuración predeterminada, como se muestra a continuación:

Para mi instancia actual de SQL Server, tenemos 4 archivos de datos y un archivo de registro para la base de datos tempdb.

A partir de SQL Server 2016, tenemos el instalador de SQL Server que nos permite agregar varios archivos a tempdb. Los 4 archivos anteriores con un tamaño inicial de 8 MB y un tamaño de crecimiento automático de 64 MB se crearon con las opciones predeterminadas que se muestran a continuación.

Si tenemos un solo archivo de datos en la base de datos tempdb, todos los núcleos lógicos disponibles en el servidor intentan acceder al mismo archivo de datos de tempdb, lo que genera un cuello de botella en el rendimiento.

Tener múltiples archivos de datos asociará lógicamente ciertos núcleos a un solo archivo. Por lo tanto, tenemos menos disputas sobre los archivos de datos tempdb. Esto mejorará el impacto en el rendimiento de los archivos de datos tempdb.

Prácticas recomendadas para la base de datos tempdb

Dado que la base de datos tempdb es como un área de trabajo global para todas las actividades del usuario, el tamaño de tempdb aumenta según las actividades del usuario. Puede ser un cuello de botella de rendimiento para toda la instancia de SQL Server.

Por lo tanto, debemos implementar las siguientes prácticas:

Coloque los archivos de registro y datos de tempdb en un almacenamiento de alto rendimiento para obtener mayores IOPS para un mejor rendimiento.
Asegúrese de que la base de datos tempdb esté dividida en varios archivos de datos para reducir la contención y evitar cuellos de botella en el rendimiento de la base de datos tempdb.
- Si la cantidad de núcleos lógicos es inferior a 8, podemos tener un archivo de datos tempdb por núcleo lógico. En nuestra instancia de prueba, teníamos 4 núcleos lógicos. Por lo tanto, 4 archivos de datos en tempdb deberían ser suficientes.
- Si la cantidad de núcleos lógicos es superior a 8, comience con 8 archivos de datos y aumente en 4 archivos de datos si se observan problemas de contención y rendimiento en la base de datos tempdb.
- Si la cantidad de núcleos lógicos en un servidor es 32 o 64, podemos comenzar con 8 archivos de datos. Significa que 4 núcleos u 8 núcleos están asociados lógicamente para un solo archivo de datos.
  
  Para mayor claridad acerca de múltiples archivos de datos tempdb, le recomendaría el excelente artículo de Paul Randal.
Asegúrese de que los archivos de datos tempdb estén configurados con un tamaño de archivo inicial óptimo. Idealmente, esto debería lograrse a través de un enfoque de prueba y error. Tempdb con un tamaño de archivo inicial óptimo tiende a crecer menos veces en comparación con tempdb configurado con un tamaño de archivo inicial menor, que tiende a crecer varias veces y conduce a la fragmentación. Por ejemplo, en la configuración actual, todos los archivos están configurados con un tamaño de archivo inicial de 8 MB, que es demasiado pequeño para manejar las cargas de trabajo de SQL. Por lo tanto, aplique el enfoque de prueba y error y establezca el tamaño de archivo inicial en 512 MB o 1 GB, o algún otro valor.
Asegúrese de que todos los archivos de datos de tempdb tengan el mismo tamaño de archivo. Las propiedades de crecimiento automático deben definirse por igual. En nuestro escenario, todos los archivos tienen un crecimiento automático de 64 MB. Establecer el tamaño de crecimiento automático en 512 MB o 1 GB, o cualquier otro valor adecuado, ayuda a reducir el crecimiento automático frecuente en los archivos de datos tempdb.
Asegúrese de que el tamaño del archivo inicial y el crecimiento automático para el archivo de registro tempdb estén configurados en un valor óptimo similar a los archivos de datos tempdb. Dado que el modelo de recuperación de tempdb está establecido en Simple de forma predeterminada y no se puede modificar, debería ser suficiente configurar el tamaño de archivo inicial y la propiedad de crecimiento automático del archivo de registro de tempdb.

Tempdb es vital para el rendimiento de la instancia de SQL Server. Echaremos un vistazo detallado a los problemas frecuentes que enfrenta tempdb y cómo reducirlo de manera óptima en nuestros próximos artículos.

Base de datos de recursos en SQL Server

La base de datos del Sistema de recursos es la única base de datos del sistema de solo lectura que no aparece en las bases de datos del sistema en SSMS como se vio anteriormente.

El ID de la base de datos (dbid) de bases de datos de recursos en todas las instancias será 32767, que también es la cantidad máxima de bases de datos admitidas dentro de una instancia de SQL Server. Se puede consultar desde los sys.sysaltfiles sistema DMV. Ejecutando la siguiente consulta SELECT en sys.sysaltfiles devolverá el conjunto de resultados mostrando dónde se encuentran los archivos de datos y registro de la base de datos de recursos:

Podemos ver los archivos físicos de la base de datos de recursos disponibles en la ruta mencionada anteriormente. La fecha de modificación indica la hora de la instalación de la instancia de SQL Server o la última vez que se aplicaron los Service Packs (SP) o la Actualización acumulativa (CU) en esta instancia.

La base de datos de recursos contiene todos los objetos del sistema, como sys.objects , sys.bases de datos , archivos sys.sysalt , etc. físicamente en su interior. Esta base de datos enumera lógicamente todos estos objetos bajo el esquema sys en todas las bases de datos disponibles en la instancia . Dado que la base de datos de recursos es de solo lectura, no se pueden crear objetos de usuario ni datos en ella.

La base de datos del sistema de recursos se introdujo a partir de SQL Server 2005 para hacer que la actualización de SQL Server a una nueva versión de SP o CU sea más rápida. Antes de introducir esa opción, todas esas mejoras y actualizaciones significaban que los cambios se aplicarían en todas las bases de datos, lo que hacía que el proceso de actualización fuera más complicado y lento. Ahora, cualquier actualización de versión de SQL Server o actualización de SP o CU solo actualiza o reemplaza la base de datos de recursos.

Como la base de datos de recursos es de solo lectura y no es visible para los usuarios, no requiere ninguna intervención del usuario. Si desea incluir una base de datos de recursos de copia de seguridad en su planificación de alta disponibilidad o recuperación ante desastres, simplemente haga una copia de seguridad de los archivos mssqlsystemresource.mdf y mssqlsystemresource.ldf después de detener los servicios de SQL Server (el servicio de SQL Server no permitirá copiar los archivos mientras SQL Server Service está en funcionamiento) y guárdelo en una ubicación segura. Tenga doble cuidado de no actualizarlo en ninguna instancia de SQL Server que se ejecute con una versión diferente de los niveles SP o CU, ya que podría causar problemas inesperados.

Base de datos de distribución en SQL Server

La base de datos del sistema de distribución es el corazón de la replicación. Los usuarios pueden crear o configurar una base de datos de distribución como parte de la configuración de la replicación con la ayuda del Asistente para configurar distribución o el Asistente para crear publicación. Describimos los pasos de creación de la base de datos de distribución en detalle como parte de mi artículo anterior sobre SQL Server Transactional Replication Internals.

Prácticas recomendadas para la base de datos de distribución

Dado que la base de datos de distribución es esencial para la funcionalidad de replicación, debemos implementar las siguientes prácticas:

Mueva los datos de la base de datos de distribución y los archivos de registro a la unidad con un buen IOPS para evitar problemas de rendimiento de la distribución.

Configure las propiedades Tamaño de archivo inicial y Crecimiento automático de la base de datos de distribución a un mejor valor para evitar problemas de fragmentación.

Incluya la base de datos de distribución en los trabajos de mantenimiento de la copia de seguridad completa de la base de datos.

Incluya bases de datos de distribución en los trabajos de mantenimiento de índices para evitar la fragmentación y los problemas de rendimiento.

En mi artículo sobre los aspectos internos de la replicación transaccional de SQL Server, también encontrará recomendaciones sobre otras prácticas eficientes.

Conclusión

¡Gracias por leer otro artículo lleno de energía!

Espero que le haya ayudado a aclarar la esencia y los propósitos de las bases de datos del sistema SQL Server y aprender las mejores prácticas para evitar problemas de rendimiento en estas bases de datos.