Les miroirs Microsoft SQL Server 2012 se déconnectent

J'ai des miroirs Microsoft SQL Server 2012, sans témoin en mode asynchrone, qui entrent sporadiquement en mode déconnecté. J'exécute SQL Server 2012 11.0.5058. En regardant les journaux sur le côté miroir, je vois

Impossible d'allouer des BUF: FAIL_BUFFER_ALLOCATION 1

Il y a tout un tas de messages de commis de mémoire

Erreur: 802, gravité: 17, état: 0.

La mémoire disponible dans le pool de mémoire tampon est insuffisante.

Erreur: 1454, gravité: 16, état: 1.

La mise en miroir de la base de données sera suspendue. L'instance de serveur «instance» a rencontré l'erreur 802, état 0, gravité 17 lorsqu'elle agissait en tant que partenaire miroir pour la base de données «base de données». Les partenaires de mise en miroir de bases de données peuvent essayer de récupérer automatiquement à partir de l'erreur et reprendre la session de mise en miroir. Pour plus d'informations, consultez le journal des erreurs pour des messages d'erreur supplémentaires.

Toute aide sur ce qu'il faut vérifier pour savoir pourquoi les miroirs sont suspendus puis déconnectés à la suite de cette chaîne d'événements serait appréciée. Je peux rétablir les miroirs après cela et ils fonctionnent très bien pendant quelques jours, puis ça recommence.

sql-server-2012 mirroring buffer-pool

— John Wesley Gordon
source

Quelle est la mémoire maximale définie? Utilisez-vous également Service Broker par hasard?

— Kin Shah

Sur miroir et primaire, 2147483647 Mo. Ne pas utiliser Service Broker.

— John Wesley Gordon

Ok. C'est une chose pour le rendre non par défaut - sinon le serveur SQL va utiliser toute la mémoire affamant votre système d'exploitation. Pouvez-vous le définir sur une valeur sensible? Comme bon point de départ, vous pouvez utiliser cette référence. En outre, pouvez-vous revérifier les 11.0.5048sons de votre génération SQL Server incorrects?

— Kin Shah

Typo, c'était 11.0.5058

— John Wesley Gordon

Donc SP2 RTM, qui a un an et demi - avez-vous envisagé de passer au SP3 (et éventuellement CU1)? Je ne sais pas si cela résoudra votre problème, mais il existe de nombreux autres correctifs qui pourraient être utiles.

— Aaron Bertrand

Réponses:

J'ai rencontré un problème très similaire dans ma précédente entreprise. La mise en miroir de bases de données était périodiquement suspendue avec la même erreur que vous. La mise en miroir ne s'est jamais jamais reconnectée d'elle-même, mais j'ai généralement pu la reprendre en utilisant:

ALTER DATABASE <Database Name> SET PARTNER RESUME

Après quelques semaines, nous avons compris que même s'il y avait suffisamment de mémoire sur le serveur et suffisamment de mémoire allouée à l'instance, notre charge de travail était très inégalement répartie et parfois 100% de la mémoire était utilisée. Comme la plupart du temps, nous avions suffisamment de mémoire, nous n'étions pas autorisés à en acheter davantage. J'ai fini par augmenter le fichier d'extension du pool de tampons et le placer sur l'un des SSD qui se trouvait avoir suffisamment d'espace vide pour l'accueillir. Le problème de mise en miroir n'est jamais revenu. Je ne peux pas garantir que cela fonctionnera pour vous, je partage principalement mon expérience.

— QWE
source

Peu de questions à poser et à commencer le dépannage
1.Combien de bases de données effectuez-vous en miroir
2.Combien de RAM est disponible pour le serveur SQL
3.Quelle est la taille de la base de données en miroir

Voici les estimations approximatives des exigences de mise en miroir lorsque la mise en miroir est activée

sur Prinicipal:
4 Mo par base de données pour les tampons d'envoi DBM plus 4 Mo pour les tampons d'écriture de journal

Sur le miroir:
1 Mo pour les tampons d'écriture de journal et 1 Mo pour le tampon REDO de journal

Vous pouvez également vérifier la consommation de mémoire par base de données sur l'instance miroir pour voir quelle base de données est le goulot d'étranglement et commencer le dépannage

Utilisation de la mémoire par base de données - SQL Server

— TheGameiswar
source

J'ai 3 bases de données en miroir. Le serveur principal dispose de 16 Go de mémoire et le miroir de 20 Go de mémoire. La plus grande utilisation de mémoire sur le miroir actuellement est de 3,8 Mo pour les miroirs. La base de données miroir a ses propres primaires. Le plus gros primaire est 9301 Mo. Le total de toutes les bases de données sur le serveur miroir est de 9593,75 Mo. Cela ne semble pas se rapprocher de la marque de 20 Go. Le primaire est encore moins, n'utilisant que 6765 Mo.

— John Wesley Gordon