1 votes

Erreur de SQL Server 2005 liée à l'agent SQL et aux restaurations de bases de données

J'ai restauré des bases de données sql 2005 d'un serveur à un autre (spécifications similaires, même version et service pack etc.) et j'ai rencontré le problème suivant.

Le problème commence avec la restauration de la base de données - Le processus de restauration fonctionne bien. J'utilise le Management Studio et j'effectue une restauration qui se termine sans problème, toutes les données sont présentes et peuvent être utilisées. Cependant, lorsque j'essaie d'exécuter une sauvegarde de plan de maintenance existant, j'obtiens l'erreur suivante :

L'exécution a échoué. Voir les journaux d'historique des travaux du plan de maintenance et de l'Agent SQL Server pour plus de détails. Informations supplémentaires -> Le job 'Full_Backup.Subplan_1' a échoué. (SQL ManagerUI) Les informations supplémentaires me donnent ce qui suit Emplacement du programme : at Microsoft.SqlServer.Management.SqlManagerUI.MaintenancePlanMenu_Run.PerformActions()

J'ai alors essayé de recréer le plan de maintenance, mais lorsque j'arrive à choisir les bases de données à inclure dans une sauvegarde complète, la base de données que je viens de restaurer est absente du panneau de sélection.

J'ai reproduit ce problème sur deux serveurs "neufs", tous deux avec de nouvelles installations de SQl Server 2005. À mon avis, l'opération de restauration est le coupable, donc s'il y avait un moyen de tracer ce qu'il fait, peut-être à l'une des bases de données du système, je pourrais alors enquêter.

C'est un problème qui dure depuis quelques semaines et toute aide serait appréciée.

1voto

FoleyIsGood Points 330

Il semble que je sois tombé sur la réponse. Il semblerait que le serveur SQL d'origine ait été mis à jour de 7 à 2000 puis à 2005 ! C'est fou mais apparemment il est utilisé depuis 8 ans, bien avant mon époque.

Le problème semble être lié à la compatibilité de la base de données, voir l'article de msoft suivant

texte du lien

"Les bases de données définies au niveau de compatibilité 70 ou inférieur ne sont pas affichées"

J'ai testé cela en changeant le niveau à 90 et bien sûr, cela fonctionne maintenant.

merci à tous ceux qui ont répondu, ce site va être très utile.

0voto

Paul Points 714

Un des problèmes peut être les utilisateurs qui existent dans ces bases de données et qui peuvent ne pas avoir le même SID que sur l'autre serveur. Il se peut que le plan de maintenance soit exécuté en utilisant les informations d'identification d'un utilisateur orphelin. MS SQL dispose d'une procédure stockée qui permet de réparer ces utilisateurs orphelins : sp_change_users_login.

Il suffit d'aller de SQL Management Studio à la base de données sur le nouveau serveur, aller à la sécurité et voir quels sont les logins que vous avez sur cette base de données. Ensuite, exécutez la commande de réparation comme ci-dessous pour chaque utilisateur.

utiliser la base de données

Allez sur

sp_change_utilisateurs_login 'auto_fix' , 'nom d'utilisateur'.

Allez sur

-- Où "base de données" est le nom de votre base de données restaurée.

0 votes

Merci pour cela, j'ai essayé mais cela n'a rien donné..... L'utilisateur avec lequel je me connecte est l'administrateur local du serveur et je me connecte à Management Studio en utilisant les informations d'identification Windows.

0voto

Sean Howat Points 1849

Comme ces bases de données sont déplacées d'un serveur à l'autre, vous pourriez peut-être vérifier la table sysdatabases dans Master pour voir s'il y a des incohérences. Si les dbids ne sont pas synchronisés, il est possible que les anciens plans de maintenance aient des difficultés à visualiser les bases de données restaurées.

0 votes

J'ai vérifié l'ancien serveur Sql et le nouveau, vous avez raison, les DBID ne sont pas les mêmes car je n'ai pas restauré exactement les mêmes bases de données, de plus le serveur de destination avait déjà quelques bases de données existantes. Je n'ai jamais rencontré ce niveau de sql auparavant et je vais devoir vérifier la signification des DBID.

0voto

JohnMcG Points 5062

Vous constaterez peut-être qu'il suffit de rafraîchir l'explorateur d'objets après avoir restauré la base de données. SSMS met en cache beaucoup d'informations afin de ne pas avoir à retourner sans cesse au serveur pour obtenir les mêmes données, sans parler de l'amélioration des performances due au fait que les données sont déjà en cache. La création d'un plan de maintenance est probablement l'un des endroits où les informations mises en cache sont lues.

0 votes

Merci pour cela, j'ai testé cela sur plusieurs machines différentes avec Management Studio installé ainsi qu'un serveur complètement neuf + SSMS dessus, avec les mêmes problèmes.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X