En Microsoft SQL Server se proporciona un conjunto completo de herramientas para supervisar eventos en SQL Server y para ajustar el diseño de la base de datos física. La elección de la herramienta depende del tipo de supervisión o ajuste que se va a realizar y de los eventos específicos que se van a supervisar. Como mínimo, las estadísticas se deben generar a intervalos regulares para garantizar el rendimiento esperado.

Consulte el siguiente vínculo para obtener más información: https://docs.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-2017 >

Se puede utilizar una copia de los datos de SQL Server para restaurar y recuperar los datos después de un fallo. Se crea una copia de seguridad de los datos de SQL Server en el nivel de una base de datos o de uno o varios de sus ficheros o grupos de ficheros. No se pueden crear copias de seguridad en el nivel de tabla. Además de las copias de seguridad de los datos, el modelo de recuperación completa requiere la creación de copias de seguridad del registro de transacciones.

Una propiedad de la base de datos que controla el mantenimiento del registro de transacciones en una base de datos. Existen tres modelos de recuperación: simple, completo y de registro masivo. El modelo de recuperación de la base de datos determina sus requisitos de copia de seguridad y restauración.

Un proceso de varias fases en el que se copian todas las páginas de datos y registro de una copia de seguridad especificada de SQL Server en una base de datos especificada y, a continuación, se ponen al día todas las transacciones registradas en la copia de seguridad mediante la aplicación de los cambios registrados para presentar los datos.

Para obtener más información, consulte

La escalabilidad es la capacidad de una aplicación de utilizar de manera eficaz más recursos para realizar más trabajo útil.

La solución de escala horizontal más fácil para implementar en SQL Server es la de bases de datos compartidas escalables. En este escenario, se crea una base de datos en una SAN, y hasta ocho instancias de SQL Server que se ejecutan en diferentes servidores se conectan a la base de datos y comienzan a gestionar consultas. Esta es la solución clásica de escala horizontal de estilo "disco compartido", donde la potencia de procesamiento se escala horizontalmente, pero solo se utiliza una única imagen de disco de los datos. En este punto, a los usuarios familiarizados con SQL Server pueden surgirles preguntas como: "¿Qué sucede con los bloqueos? Pensé que cada instancia de SQL Server mantenía sus propios bloqueos en su propia memoria". Esto es así. Cada instancia conservará sus propios bloqueos de base de datos y ninguna de las instancias conocerá los bloqueos de otras instancias. La única manera para que funcione es que no haya bloqueos y, por lo tanto, las bases de datos compartidas escalables funcionarán únicamente si la base de datos se conecta como base de datos de solo lectura. Esto significa que las bases de datos escalables son idóneas para data warehouse o bases de datos de informes, pero no son adecuadas para aplicaciones que actualizan datos. Volviendo a las características de los datos, las bases de datos compartidas escalables funcionan solo si la frecuencia de actualización es cero. Estos datos son, por definición, históricos y, por lo tanto, todos son datos de referencia.

En MSSQL Server, el número máximo de bytes de cualquier clave de índice no puede superar los 900 bytes. Sin embargo, se puede definir una clave con columnas de longitud variable cuyos tamaños máximos sumen más de 900, pero en ese caso no se debe insertar ninguna fila con más de 900 bytes de datos en dichas columnas. (https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2014&redirectedfrom=MSDN).