L'assistant de restauration de la base de données ne s'ouvre pas dans SSMS 2014
Sur une machine de développement exécutant Windows Server 2012 R2, je viens de mettre à niveau SQL Server de 2012 à 2014.
À l'aide de SQL Server Management Studio 2014, lorsque je clique avec le bouton droit sur une base de données et accède à Tasks -> Restore -> Database... Rien ne se passe. L'assistant de restauration de la base de données n'apparaît pas comme prévu.
Aucune erreur ou plantage n'est dans l'Observateur d'événements. Le curseur ne se transforme même pas en sablier.
L'utilisation de T-SQL pour restaurer fonctionne très bien, et si je reviens en arrière et utilise SSMS 2012, cela fonctionne très bien. Des idées sur la façon de faire fonctionner l'assistant dans SSMS 2014?
Je me connecte à la même instance de SQL Server dans les deux versions de SSMS et j'ai essayé d'exécuter SSMS en tant qu'administrateur.
Il s'agit du Service Pack 1:
Microsoft SQL Server Management Studio 12.0.4100.1
Microsoft Analysis Services Client Tools 12.0.4100.1
Microsoft Data Access Components (MDAC) 6.3.9600.17415
Microsoft MSXML 3.0 5.0 6.0
Microsoft Internet Explorer 9.11.9600.18125
Microsoft .NET Framework 4.0.30319.34209
Operating System 6.3.9600
J'ai moi-même vu ce comportement dans SSMS 2012 et SSMS 2014. Ce que cela signifie généralement, c'est que l'historique de sauvegarde/restauration de la base de données est très long et qu'il faut beaucoup de temps pour que l'assistant apparaisse, car il doit lire toute l'histoire.
Assurez-vous d'avoir un plan de maintenance qui tronque l'historique. Pour le savoir, exécutez cette requête:
SELECT TOP 1 backup_start_date
FROM msdb.dbo.backupset WITH (NOLOCK)
ORDER BY backup_set_id ASC
Cette requête sera rapide, car elle est triée par la clé en cluster primaire de la table. Si vous avez plus d'un mois ou deux d'histoire, il est probablement temps de l'effacer. (Gardez à l'esprit que l'effacement de l'historique impliquera des verrous, donc cela peut être un processus lent si vous effectuez des sauvegardes en même temps, ou si votre MSDB est sur un stockage lent.)
J'ai trouvé cela sur un autre fil et cela a fonctionné pour moi:
SQL Server Studio 2014 n'aime pas l'erreur "Impossible de créer un plan de restauration en raison d'une interruption de la chaîne LSN". Et ne parvient pas à ouvrir la boîte de dialogue de restauration. Correction de la chaîne LSN en émettant une sauvegarde complète. Après cette boîte de dialogue de restauration devrait fonctionner.
Dans mon cas, je voulais juste restaurer une base de données à partir de l'appareil (sauvegarde complète, copie uniquement). Cette solution de contournement a donc fonctionné pour moi. Faites un clic droit sur "Bases de données" et allez dans "Restaurer la base de données ..." (au lieu de sélectionner la base de données). Cela devrait ouvrir l'assistant car il n'y a pas d'historique à charger.
Dans les options, j'ai sélectionné "Remplacer la base de données existante" et j'ai désélectionné "Prendre la sauvegarde du journal de fin avant la restauration".
Si quelqu'un a toujours le même problème
Rien de ce qui est décrit ici ne m'aide à résoudre mon problème, mais j'ai pu contourner le problème en effectuant une sauvegarde de ma base de données vide, puis comme par magie le bouton Ajouter a fonctionné et m'a permis de faire une restauration à partir de mon fichier bak
Mon environnement est:
- Windows 10 entreprise, installation propre
- SQL Server 2017 express edition, nouvelle installation
- SQL Server Management Studio Ver 18.1, nouvelle installation
Je ne sais pas pour les faits, mais je pense que la cause première de mon problème est: lors de l'installation, j'ai défini un chemin différent pour les fichiers de données (pas la valeur par défaut sous "/ program files", et SQL ou SSMS essayait probablement d'accéder à la emplacement par défaut (inexistant) la première fois.