Mettre la base de données hors ligne avec restauration immédiate prend une heure pour terminer
Chaque nuit, nous mettons notre base de données de production hors ligne, la détachez, puis la rattachez pour couper toutes les connexions actives avant de commencer nos procédures de sauvegarde. La première commande est:
USE master
ALTER DATABASE thedb SET OFFLINE WITH ROLLBACK IMMEDIATE
Cette commande prenait entre 20 et deux minutes plus tôt, ce qui était acceptable. Depuis quelques semaines, il a fallu de 15 minutes à plus d'une heure pour terminer. Il n'y a eu aucun changement dans l'utilisation de la base de données qui causerait ce problème, et cela ne se produit qu'environ 3/4 du temps.
Pour autant que je sache, nous n'avons modifié aucun paramètre susceptible de provoquer cela. Ma compréhension était AVEC ROLLBACK IMMÉDIATE rompu toutes les connexions et la base de données se déconnecte immédiatement. J'ai essayé d'enquêter sur les points suivants:
- l'intervalle de récupération est défini sur 0 afin que les points de contrôle se produisent toutes les quelques minutes et ne prennent qu'une seconde pour terminer
- Les statistiques ne sont pas mises à jour de manière asynchrone
- aucune requête volumineuse n'est exécutée juste avant la mise hors ligne de la base de données
- vérification de sp_who2 lorsque la base de données hors ligne ne montre aucun utilisateur connecté
- le fichier journal de la base de données est très petit, ~ 30 Mo
Nous exécutons actuellement MSSQL Server 2012 (Standard Edition) en mode de récupération simple sans mise en miroir. La base de données fait environ 300 Go.
Toute aide est appréciée, merci!
Je crois que ce que vous voyez est tout à fait normal.
Chaque nuit, nous mettons notre base de données de production hors ligne, la détachez, puis la recréons pour couper toutes les connexions au début de nos procédures de sauvegarde
Pourquoi fais-tu cela ?. Ce n'est pas toujours la bonne chose à faire et c'est précisément pourquoi vous êtes confronté au problème. Vous pouvez effectuer une sauvegarde de la base de données lorsqu'elle est en ligne et c'est comment vous devez sauvegarder la base de données SQL Server. La sauvegarde complète que vous effectuerez lorsque la base de données est en ligne inclurait toutes les modifications validées apportées à la base de données une fois la sauvegarde terminée. Garder en mode single_user et restricted_user avant l'activité peut ne pas résoudre complètement votre problème.
Cette commande prenait entre 20 et deux minutes, ce qui était acceptable. Au cours des dernières semaines, il a fallu de 15 minutes à plus d'une heure pour terminer.
Vous avez également dit qu'il n'y avait pas de requête longue, pour cela je dirais une triple vérification. Modifier la base de données nécessite un accès exclusif à la base de données et il peut être bloqué par une autre requête, avez-vous vérifié cela.
Avez-vous recherché une transaction exécutée avec begin transaction Et vous avez peut-être manqué la validation. Exécutez DBCC OPENTRAN() pour voir toutes les transactions ouvertes. Errorlog aurait plus d'informations à ce sujet
L'autre chose que je vois est parfois lorsque vous exécutez la commande alter, il n'y a pratiquement pas de requêtes en cours d'exécution qui nécessitent une restauration et donc la commande se termine rapidement tandis que d'autres jours, certaines commandes sont en cours d'exécution qui doivent être complètement restaurées avant que la base de données puisse être rendue hors ligne. Selon la quantité de restauration à effectuer, le temps varie.
Je ne vous suggérerais pas de mettre la base de données en mode hors ligne, je n'en vois aucune utilité.
Tout d'abord, je ne comprends pas pourquoi la base de données est conservée en mode de récupération simple, si votre base de données est une base de données de production, il est fortement recommandé de garder la base de données en mode de récupération complète et de prendre une sauvegarde différentielle ainsi que la sauvegarde du journal en fonction du volume de transaction. ainsi que sur la base des exigences commerciales de votre SLA pour la perte de données ou de point de récupération. Vous pouvez comprendre plus ici:
https://www.sqlshack.com/backup-and-restore-sql-server-disaster-recovery/
Dans le cas où vous n'effectuez actuellement qu'une sauvegarde complète dans la nuit et aucune autre sauvegarde (sauvegarde différentielle, car la sauvegarde du journal ne peut pas être effectuée étant donné que le mode de récupération est simple), si votre base de données se bloque pendant la journée - vous perdrez toutes les modifications apportées à votre base de données après la dernière sauvegarde complète réussie. Donc, mon premier conseil serait de changer le mode de récupération et de prendre la sauvegarde différentielle ainsi que la sauvegarde du journal.
Sur votre point de rompre les connexions avant de prendre la sauvegarde - ce n'est pas nécessaire du tout, vous pouvez très bien prendre une sauvegarde à chaud et cela peut être fait lorsque la base de données est en mode multi-utilisateurs et que les utilisateurs travaillent activement (bien qu'il soit conseillé de faire moins de sauvegarde heure de circulation). Et s'il est difficile et rapide de fermer toute la connexion avant la sauvegarde, vous devez mettre votre base de données en mode mono-utilisateur avant de la mettre hors ligne à l'aide de la commande fournie.
Afin de vérifier toute transaction active, vous pouvez utiliser la très célèbre procédure stockée sp_whoisactive de M. Adam Machanic, cela vous donnerait toutes les informations sur l'exécution de la session et de nombreux autres détails qui ne sont pas réalisables pour utiliser sp_who ou sp_who2. Vous pouvez planifier cette procédure juste avant votre sauvegarde et rediriger la sortie vers une table pour y faire référence plus tard. Vous pouvez également utiliser DBCC OPENTRAN () pour vérifier toute transaction active comme suggéré dans la réponse ci-dessus.
Dans l'ensemble, le problème semble être ici avec le processus qui est suivi pour effectuer la sauvegarde. Veuillez nous faire savoir si cela a aidé.