Microsoft SQL Server propose un ensemble complet d'outils de surveillance des événements dans SQL Server, mais aussi d'affinage de la conception de la base de données physique. Le choix de l'outil dépend du type de surveillance ou d'affinage à effectuer et des événements à surveiller.

Pour plus d'informations, consultez le lien suivant : https://docs.microsoft.com/en-us/sql/relational-databases/performance/performance-monitoring-and-tuning-tools?view=sql-server-2017>

Vous pouvez utiliser une copie des données SQL Server pour restaurer et récupérer les données après un incident. Une sauvegarde des données SQL Server est créée au niveau d'une base de données ou d'un ou plusieurs de ses fichiers ou groupes de fichiers. Il est impossible de créer des sauvegardes au niveau des tables. Outre les sauvegardes de données, le modèle de récupération complète requiert la création de sauvegardes du journal des transactions.

Propriété de base de données qui contrôle la maintenance du journal des transactions sur une base de données. Il existe trois modèles de récupération : simple, complet et avec journaux de transactions. Le modèle de récupération d'une base de données détermine ses exigences en matière de sauvegarde et de restauration.

Un processus en plusieurs étapes qui copie toutes les données et les pages de journal d'une sauvegarde SQL Server spécifique vers une base de données précise, puis restaure progressivement toutes les transactions journalisées dans la sauvegarde en appliquant les modifications journalisées afin de mettre à jour les données.

Pour plus d'informations, consultez les sections

L'évolutivité est la capacité d'une application à utiliser efficacement davantage de ressources afin d'effectuer plus de tâches utiles.

Les bases de données partagées évolutives constituent la solution de mise à l'échelle la plus facile à implémenter dans SQL Server. Dans ce scénario, vous créez une base de données sur un réseau de stockage SAN, et jusqu'à huit instances de SQL Server s'exécutant sur des serveurs différents se lient à la base de données et commencent à gérer les requêtes. Il s'agit de la solution de mise à l'échelle classique de type "disque partagé" : la puissance de traitement est mise à l'échelle, mais une seule image disque des données est utilisée. A ce stade, il est possible que des utilisateurs expérimentés de SQL Server posent, entre autres, la question suivante : "qu'advient-il des verrous ? Je croyais que chaque instance de SQL Server conservait ses propres verrous dans sa propre mémoire". C'est le cas. Chaque instance conservera ses propres verrous de base de données, et aucune instance n'aura connaissance des verrous des autres instances. Cette approche ne fonctionnera que s'il n'existe aucun verrou. C'est pourquoi les bases de données partagées évolutives ne fonctionnent que si la base de données est liée en tant que base de données en lecture seule. Les bases de données partagées évolutives sont ainsi idéales pour les entrepôts de données ou les bases de données de création de rapports, mais elles ne sont pas adaptées aux applications qui mettent à jour les données. Pour revenir à nos caractéristiques de données, les bases de données partagées évolutives ne fonctionnent que si la fréquence de mise à jour est égale à zéro. Ces données sont, par définition, historiques. Il s'agit donc de données de référence.

Dans MSSQL Server, le nombre maximum d'octets d'une clé d'index ne peut pas dépasser 900 octets. Bien qu'une clé puisse être définie à l'aide de colonnes de longueur variable dont la taille maximale cumulée est supérieure à 900, aucune ligne ne doit dans ce cas être insérée avec plus de 900 octets de données dans ces colonnes. ( https://docs.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server?view=sql-server-2014&redirectedfrom=MSDN).