web-dev-qa-db-fra.com

"Le travail a échoué" dans la copie de la base de données SQL Server 2012

J'essaie de copier une base de données. Lors de l'exécution de l'Assistant Copie de base de données, une erreur d'exécution du travail de l'agent SQL Server s'affiche. Les états d'erreur 

Le travail a échoué. Consultez le journal des événements sur le serveur de destination pour plus de détails.

Opération performante

  • Ajouter un journal pour le package (succès)

  • Ajouter une tâche pour transférer des objets de base de données (Succès)

  • Créer un package (succès)

  • Démarrer le travail de l'agent SQL Server (succès)

  • Exécuter le travail de l'agent SQL Server (erreur)

Erreur:

Le travail a échoué. Consultez le journal des événements sur le serveur de destination pour plus de détails. (Assistant de copie de base de données)

Je n'arrive pas à trouver ce qui cause ce problème. Est-ce que j'utilise l'approche correcte? J'ai juste besoin de copier cette base de données. Merci d'avance.

databasesql-server-2012copyjobsagent
15
mohammad_hasan

si vous essayez de cloner votre base de données sur le même serveur, essayez ceci:

  1. Créez une sauvegarde de la base de données que vous souhaitez copier
  2. faites un clic droit sur Databases et sélectionnez Restore Database
  3. Sélectionnez la base de données que vous souhaitez copier dans la liste déroulante From Database De la section Source for restore
  4. Entrez le nom de la nouvelle base de données dans le champ To database de la section Destination for Restore - il ne peut s'agir du nom d'une base de données existante
  5. Cliquez sur OK
15
safi

Vérifiez le journal des événements Windows. 

  1. Observateur d'événements
  2. Journaux Windows
  3. Application
  4. Recherchez les messages d’avertissement/erreur associés à l’une des opérations suivantes:
    • SQLAgent
    • SQLISPackage
  5. Lire l'erreur.

Voici un exemple.

SQLAgent Related Errror

Voici quelques erreurs et solutions rencontrées.

Impossible de déterminer si le propriétaire (...) du travail ... a un accès au serveur (raison: impossible d'obtenir des informations sur le groupe/utilisateur Windows NT "...", code d'erreur 0x54b. [SQLSTATE 42000] (erreur 15404) ).

Nous devions nous assurer que, lors de l'assistant de copie de base de données, le compte avec lequel nous nous étions connectés au serveur de destination disposait des privilèges appropriés et que ces privilèges pouvaient être obtenus (nous avons finalement utilisé le compte sa.). Cet avertissement a été résolu. 

L'accès est refusé

Nous devions nous assurer que l'agent local SQL Server avait les privilèges appropriés sur le serveur local. Nous avons donc créé l’ouverture de session de l’agent SQL Server en tant que système local. Cela a fonctionné car Local System est un administrateur système dans notre instance SQL Server.

Impossible de lire les métadonnées, probablement en raison de droits d'accès insuffisants.

Nous devions donner davantage de privilèges au compte Système local.

  • De SSMS
  • Faites un clic droit sur le nom du serveur et cliquez sur les propriétés
  • Cliquez sur l'onglet Autorisations
  • Cliquez sur l'utilisateur Système local
  • Sur les autorisations explicites, presque en bas, il y a "Voir n'importe quelle définition". Voyez si cela fonctionnera.

xp_regread () a renvoyé l'erreur 5, "L'accès est refusé".

Cela nous a empêché et nous avons posé une autre question: xp_regread () a renvoyé l'erreur 5, "L'accès est refusé".

9
Shaun Luttin

Cela est généralement dû au fait que votre compte (Service NT\SQLSERVERAGENT ) n’est pas autorisé à accéder au dossier de données (..Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA). Réglez-le sur le contrôle complet est ok

Le compte ci-dessus est la valeur par défaut. Si vous souhaitez vérifier quel compte est activé pour l'agent, accédez à services.msc. vérifier la connexion au compte

6
Grey Wolf

Pour mon problème avec l'Assistant Copie de base de données: Erreur: La valeur ne peut pas être null. Nom du paramètre: database StackTrace: at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.CheckLocalandDestinationStatus

J'avais tout essayé pour que mon assistant de copie de base de données fonctionne selon une planification allant de SQL 2012 à SQL2017 1. J'avais défini le compte d'agent SQL sur un administrateur, même si j'avais déjà configuré un proxy qui était un administrateur système 2. J'avais utilisé des outils de données et essayé de remplacer le nombre maximal d'erreurs par plus d'un.

Les dernières étapes que j'ai prises et qui ont fonctionné sont les suivantes: A. J'ai installé des outils de données sur le serveur 2017 (juste au cas où j'en aurais besoin) B. J'ai ajouté une base de données fictive sur le serveur 2017 afin de pouvoir accéder à l'assistant de copie de base de données à partir de SSMS . C. J'ai démarré l'assistant de base de données opy à partir de mon système NEWER à partir de la base de données fictive, mais j'ai remplacé mon source par le serveur source (au lieu de l'instance SQL locale par défaut), puis ma cible par l'instance SQL de ma machine locale.

D. Je suis allé dans l'assistant pour chaque élément (dans mon cas, il s'agissait d'une option de copie et de remplacement utilisant SSMS (ne pas détacher ni réattacher car je ne pouvais pas supprimer le source en production), et j'ai cliqué sur REFRESH (Réactiver) sur chaque écran d’assistant de copie de base de données APRÈS le changement du répertoire de destination.

(UN CAVIAT SI MIGRANT DES BASES DE DONNÉES SUR SSMS 2017 pour SQL 2017. Assurez-vous de disposer de la dernière mise à jour cumulative pour la version SQL: https://support.Microsoft.com/en-us/help/4342123 vs. select @@ version dans une requête

Assurez-vous également que vos comptes d’agent SQL et de serveur SQL sont autorisés dans le répertoire cible.

Suite à cela, mon script a finalement fonctionné à partir du serveur SQL2017, après avoir été ajouté aux travaux de l'agent SQL.

1
Chip