Server MS SQL - Processus de point de contrôle coincé dans SLEEP_BPOOL_FLUSH
Nous semblons avoir un problème qui est sorti de nulle part. Le processus de point de contrôle est bloqué dans sleep_bpool_flush State et ne réduit pas la consommation dans le fichier journal.
Cela n'a jamais semblé arriver auparavant.
Je comprends que SLEEP_BPOOL_FLUSH est une attente normale pour le processus de point de contrôle lorsque le sous-système de disque est occupé. En fait, nous avons toujours eu un sous-système de disque très occupé, donc je ne comprends pas pourquoi cela est devenu un problème.
(Si vous exécutez manuellement une commande de point de contrôle, mêmes résultats ... votre processus utilisateur attend dans SLEEP_BPOOL_FLUSH).
Y a-t-il quelque chose que nous pouvons faire pour repousser le point de contrôle? Les paramètres du point de contrôle peuvent-ils être modifiés afin que cela ne se produise pas?
(SQL Server 2005, sous-système RAID, modèle de récupération simple)
Si le moniteur de ressources indique que SQL Server effectue réellement le point de contrôle (c'est-à-dire que cela fonctionne bien, c'est juste que c'est lent), tout ce que vous pouvez et devrait faire est d'attendre.
Si le sous-système de disque est occupé de toute façon (stockage partagé?), Est-il possible que l'autre charge a augmenté et que le sous-système d'E/S est proche ou à la capacité? Si vous n'êtes pas mesure (enregistrement) des métriques qui vous le diraient, je le recommanderais fortement, en utilisant des perfuns directement ou d'autres tiers. outil. (Cela dépend également de l'architecture de stockage. Le point principal est de pouvoir suivre la charge d'E/S au fil du temps.) Si vous êtes sur un SAN, il y avait un changement dans le sous-système d'E/S lui-même qui serait transparent à votre boîte SQL?
Une chose que vous pouvez envisager est de modifier le paramètre intervalle de récupération , ce qui vous permet de contrôler manuellement à quelle fréquence les points de contrôle se produisent. Notez qu'il s'agit d'une instance . Je recommande vivement de lire minutieusement la documentation avant de le changer, car il est possible que vous puissiez aggraver les choses en évitant la valeur par défaut (en fonction de votre charge de travail).
Lors de la restauration de la base de données de plein et différentiel, j'ai un type d'attente - SLEEP_BPOOL_FLUSH Et restaurer coincé après une restauration complète.
Puis j'ai émis DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR); effacer les attentes.
C'était un succès et j'ai pu restaurer une sauvegarde différentielle.