MS SQL Server
  1. MS SQL Server
  3. Blocage du tampon de communication: SQL Server 2008 R2 exécutant des procédures stockées pour l'entrepôt de données
Intereting Posts
Comment configurer SQL Server pour qu'il fonctionne avec ASP.NET MVC avec l'authentification Windows? Folie UUID avec mssql Maximum du nombre d'éléments groupés Pourquoi ai-je eu un nombre de lignes plus élevé après LEFT JOIN SQL – Insérer une requête dans un autre insert avec des graines d'identité mises à jour Comment concevoir une dimension d'audit dans le magasin de données à l'aide de SQL Server 2012 Requête SQL pour searchr un nombre Kevin Bacon de 2 Tuer uniquement les process user dans SQL Server Supprimer la duplication de données dans la requête SQL Server SQL Server – modifier le suivi sur datatables de vues SQL Server: regroupement sur la correspondance de text partielle Existe-t-il un moyen de définir un travail SQL Server programmé pour s'exécuter toutes les 30 secondes? Comment puis-je concaténer une string avec un server SQL (documentTitle + Archive) SQL 2005 Écrire des lignes de résultat T-SQL dans des files individuels Comment connecter un nouveau script de requête avec le complément SSMS?

Blocage du tampon de communication: SQL Server 2008 R2 exécutant des procédures stockées pour l'entrepôt de données

Actuellement en cours d'exécution SQL Server 2008 R2 SP1 sur 64 bits Windows Server 2008 R2 Enterprise sur un server Intel double processeur 8 cœurs avec 128 Go de RAM et 1 To de lecteur SCSI interne.

Server exécute nos packages Data Warehouse et Analysis Services depuis 2011. Ce server et cette instance SQL ne sont pas utilisés pour OLTP.

Soudainement et sans avertissement, tous les travaux qui appellent les packages SSIS qui construisent les tables de l'entrepôt de données (à l'aide de procédures stockées) échouent avec les erreurs "Deadlock on communication buffer". Le SP qui génère l'erreur dans le package est différent chaque fois que le process est exécuté.

Toutefois, les travaux s'exécuteront correctement si SQL Server Profiler est en cours d'exécution pour effectuer le suivi au moment où les travaux sont lancés.

Cela s'est d'abord produit sur notre server de développement (même configuration) en juin. Contact avec Microsoft a identifié les problèmes d'E / S de disque, et a suggéré de définir MaxDOP = 8, qui a atténué le problème de blocage, mais a introduit un problème où les process peuvent prendre jusqu'à 3 fois plus longtime à des intervalles randoms.

Cela vient de se produire aujourd'hui sur notre server de production. MaxDOP est actuellement défini sur zéro. Aucune modification n'a été apscope à OS, SQL Server ou aux packages SSIS au cours du mois passé. Les travaux se sont bien déroulés pendant la nuit du 5 septembre, mais ont échoué avec les erreurs du jour au lendemain (6 septembre) et continuent à échouer sur toute nouvelle tentative.

La durée pendant laquelle un travail s'exécutera avant d'échouer n'est pas cohérente et il n'y a pas de cohérence entre les tâches. Les travaux qui durent 2 minutes avant la fin de l'exécution précédente échouent en quelques secondes, alors que les travaux qui durent normalement 2 heures peuvent durer de 30 à 90 minutes avant d'échouer.

Avez-vous envisagé de changer le niveau d'isoloation de la database. Cela peut aider lorsque des lectures et des écritures parallèles se produisent sur la database.