web-dev-qa-db-fra.com

SQL Server 2019 Performance Pire que 2012 ... Je manque quelque chose?

Nous avons un serveur SQL Server 2012 qui surperformez de loin une base de données SQL Server 2019 sur (autant que je sache) la même infrastructure. Nous accueillons les deux bases de données sur une plate-forme cloud avec les mêmes SLA. Les deux ont 180gb RAM et 16 processeurs.

Cependant, il y a quelques différences clés.

  1. Le serveur de base de données 2012 est l'entreprise, la norme 2019 est standard. Autant que je sache, cela ne devrait pas faire la différence
  2. La base de données de 2012 a été restaurée sur le serveur 2019 et sa version est modifiée à 150 (2019).
  3. MaxDop sur le serveur 2012 était 0, 2019 Server il est défini sur 8, comme recommandé par Microsoft et d'autres.
  4. Seuil de coûts pour le parallélisme = 5 sur le serveur 2012, 20 sur 2019 Server

EDIT: Une autre différence majeure que je viens de réaliser - l'une est Windows Server 2008, l'autre est Windows Server 2019. Il pourrait éventuellement être des paramètres latéraux du serveur ...

La taille de l'unité d'allocation est définie sur 64 Ko pour tous les disques SQL, SQL a les autorisations appropriées pour pouvoir contrôler la taille des fichiers elle-même. Le serveur est défini sur le mode haute performance. Quelque chose d'autre que je devrais changer côté serveur?

D'autres paramètres de base de données n'ont pas été modifiés, les paramètres suivants sont donc par défaut de 2019, je crois:

  • Estimation de cardinalité héritée = off
  • Paramètre reniflant = sur
  • Requête optimiseur fixe = OFF

Principalement, le type de requêtes que nous faisons est de grandes requêtes complexes de jointures multiples pour effectuer des mises à jour et des insertions, avec les petites sélectionnées occasionnelles des utilisateurs. Nous chargons des fichiers volumineux dans la base de données, puis traitons les données dans de grandes requêtes, généralement une à la fois. Entre ces grandes "charges", nous avons des utilisateurs de sélectionner sur d'autres tables de base de données non chargées/traitées en vue de la préparation des étapes de charge/processus futures. En règle générale, nous obtenons des réductions de performance de 30% à 50% du traitement. J'ai pensé que c'était à cause du cadre MaxDop, mais la modifiant à 0 n'a fait aucune différence sur une série de pistes.

Notre majeur Symptôme est que nous obtenons des délais de verrouillage lorsque nous essayons de vous connecter au serveur de 2019 alors qu'il s'agit de traitement occupé, alors que les connexions de services Server Server 2012 sont très lentement. Je pensais à définir le réglage du délai de connexion sur le serveur à un montant élevé, mais je suppose que nous n'obtiendrons toujours pas aux réponses du serveur. C'est comme si ça bloque toutes les nouvelles connexions si c'est même légèrement occupé.

Y a-t-il d'autres choses que je devrais essayer? Ces paramètres de base de données valent-ils la peine de jouer?

Je pourrais plonger plus loin et commencer à regarder les DMVS, mais cela semble être proche d'une mise à niveau de l'environnement "comme" similaire "avec des gouttes considérables de performance. Je viens de vérifier qu'il n'y a pas d'autre que je devrais vérifier avant de faire une plus grande enquête.

sql-serverperformanceupgradesql-server-2019
6
blobbles

Je pense que vous venez de découvrir pourquoi le processus de mise à niveau recommandé consiste à mettre à niveau votre base de données, à activer le magasin de requêtes et à tester avant d'augmenter le niveau de compatibilité de la base de données.

enter image description hereModifiez le niveau de compatibilité de la base de données et utilisez le magasin de requêtes

Si vous avez beaucoup de régressions de plan, vous pouvez continuer à utiliser l'estimateur de cardinalité plus ancien au niveau de compatibilité de la base de données supérieure avec:

ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
10
David Browne - Microsoft

Nous avions une mise à niveau similaire de SQL Server 2012.

Nos problèmes étaient dus à des modifications d'estimateur de cardinalité introduites dans SQL Server 2014

Essayez de changer le paramètre de cardinalité héritée sur dans un environnement de test et comparez les performances des charges de travail

https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-legacy-cardinalité-estimation/

3
dbakerry987

Nous avons eu une mise à niveau similaire à partir de SQL Server 2008 R2 à SQL Server 2019 (niveau de compatibilité 150).

Certains de nos emplois de mise à jour nocturne ont soudainement pris 6 à 7 fois plus de temps pour courir (de 4 minutes à 39 min, et de 1 heure à 6 heures).

Définir le réglage de la cardinalité héritée sur ON _ nous ramena à notre vitesse de mise à jour habituelle.

C'est ce que nous avons fait (Source: https://blog.sqlauthority.com/2019/02/09/sql-server-enabling-older-egacy-cardinalité-estimation/ ):

USE [YourDB]
GO
ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO
2
btb

Une autre possibilité consiste à permettre à Global Trace Flag 9481 et à toute la charge de travail de votre instance utilisera legacy CE

0
Javier Villegas