"Période de délai de requête de verrouillage dépassée" lors de la publication de bases de données SQLServer en parallèle
Je travaille sur un environnement d'intégration continue utilisant SQLSERVER2014. Là, j'ai besoin de publier simultanément de nombreuses bases de données SQLSERVER sur le même exemple. Notre processus de publication utilise un fichier .SQLPROJ exécuté par MSBUILD, qui génère un script de publication.
Parfois, lors de ce processus de publication, nous avons eu une erreur: " la période de délai de requête de la requête dépassée ". Il arrive lorsque deux ou plusieurs scripts de publication sont exécutés en parallèle, plus spécifiquement sur la procédure sp_fulltext_database.
Recherche d'explications plus poussées, j'ai découvert que la limite de délai de verrouillage par défaut est -1, qui est illimité. Malgré tout, l'erreur continue à montrer. Essayer de changer la limite du délai d'attente de verrouillage à 20 secondes à travers la requête:
SET LOCK_TIMEOUT 20000;
L'erreur n'a plus eu lieu.
Ma question est la suivante: est-ce le seul moyen de résoudre le problème? Changer le LOCK_TIMEOUT? Étant donné que le processus de publication est effectué par un script généré automatiquement, je ne pense pas que ce soit une bonne idée de changer le script manuellement.
Edition: À l'aide du profileur SQLServer pendant un déploiement, j'ai découvert que quelque chose change le délai de verrouillage à 5 secondes. Cette commande n'existe pas dans mon script de publication, alors je suppose qu'une commande ou une configuration interne le fait. Aller au studio de gestion SQL Server et en cliquant avec le bouton droit de la souris sur le serveur> Propriétés> Avancé> Parallélisme J'ai trouvé des configurations, mais ils ne semblent pas affecter cette définition automatique de 5 secondes.
En regardant la documentation MSDN pour sp_fulltext_database Nous voyons la note suivante:
N'a aucun effet sur les catalogues de texte intégral dans les versions SQL Server 2008 et ultérieures et est prise en charge pour la compatibilité rédaction uniquement. sp_fulltext_database ne désactive pas le moteur de texte intégral pour une base de données donnée. Toutes les bases de données créées par l'utilisateur dans SQL Server 20 xx sont toujours activées pour l'indexation de texte intégral.
Le "xx" dans "20 xx" ci-dessus change en fonction de la version de la documentation que vous examinez, mais commençant par SQL Server 2008, que xx sera: "08", "12" ou "16".
Vous êtes sur SQL Server 2014, alors je me demande pourquoi EXECUTE sp_fulltext_database 'disable'; montre même dans vos scripts de déploiement générés par la SSDT. Je viens de faire des tests et il semble que peu importe la "plate-forme cible" du projet, le script de déploiement génère toujours des lignes pour:
IF fulltextserviceproperty(N'IsFulltextInstalled') = 1
EXECUTE sp_fulltext_database 'enable';
Le "Activer" ou "Désactiver" est contrôlé par "Réglage de la base de données ..." dans l'onglet "Paramètres du projet" des propriétés du projet, dans l'onglet "Divers".
Le seul moyen de se débarrasser de ces 2 lignes consiste à décocher l'option "Déployer les propriétés de la base de données", sous "Options de déploiement" dans l'onglet "Débogage" des propriétés du projet. Mais si vous décochez cette option, cela n'appliquera pas les propriétés de la base de données. Alors:
- Si vous êtes pas Utilisation du déploiement SSDT pour appliquer les propriétés de la base de données, allez-y et décochez cette option. Si vous n'avez pas fait d'autres modifications depuis la dernière version, ce changement seul ne mettra pas à jour le script de déploiement, auquel cas vous devez faire une "reconstruction".
- Si vous SONT Utilisation du déploiement SSDT pour appliquer les propriétés de la base de données, supprimez-les tous deux manuellement ou trouvez un moyen de le faire par programme.
Je ne sais pas pourquoi il y a un appel à une procédure stockée du système inutilisée en dehors de celui-ci étant probablement une priorité faible à supprimer car elle ne brise rien et la plupart des gens ne font pas de déploiement parallèle ;-).