none
Problèmes de performance suite à la migration d'une application SGBD Oracle > SQL Server RRS feed

 > 

  • Discussion générale

  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour, j'ai migré une base de données d'un SGBD Oracle 11gR1 vers SQL Server 2008 R2 SP2. Derrière cette base de données se trouve une application utilisée par des dentistes.

    Hier matin, lors du démarrage, les dentistes se sont directement plaints de lenteurs. Voici un petit résumé : 

    

    Application

    -          150 PC clients, 300 sessions (2 sessions par PC)

     

    Ce qui reste :

    -          Machine virtuelle VMWare

    -          Config standard de la vm.

                   

    Ce qui change :

    -          Hardware : 1CPU => 2CPUs

    -          OS (Red Hat Linux 5.3 => Windows Server 2008 R2 SP2)

    -          RDBMS : Oracle vs SQL Server

    • 1Go (min et max) RAM dédié Oracle VS min 3 Go, max 7Go dédié SQL Server

    -          Requêtes de l'application toutes ré-écrites.

                   

    Symptômes :

    -          Rapport « Long Running Queries » avant évènement d’attente principal : RESOURCE_SEMAPHORE_QUERY_COMPILE : 

            La preuve en est : ErrorLog : Event 8628 50x sur la journée

    RESOURCE_SEMAPHORE_QUERY_COMPILE      222

    SOS_SCHEDULER_YIELD                                   212

    BROKER_RECEIVE_WAITFOR                               37

    TRACEWRITE                                                       19

    PREEMPTIVE_OS_GETPROCADDRESS                  19

    WRITELOG                                                           11

    PAGEIOLATCH_EX                                                  1

    PAGELATCH_EX                                                     1

    ASYNC_NETWORK_IO                                            1

    BACKUPTHREAD                                                     1

    -          Utilisation CPU proche des 100%

    -          Rapport "Memory Usage" :


    • Part principale dédiée à des pages de type stolen
    • (parfois, toute la partie FREE du camembert est STOLEN)

                   

    -          Compteurs Windows :

                                  

     

    Actions :

                    (2014 02 10)

                   

    -          Mise en place du Resource Governor. Effet immédiat sur l'utilisation.

    • % Memory mis à 75% au lieu de 100%                                                
    • Problème NON RESOLU : reprise du problème vers 13h30

    -          Paramètre 'max worker thread' mis à 512 suivant les recommandations de la page :

    -          Paramètre de mémoire minimale par requête en Ko passé à 512 au lieu de 1024.


    Auriez-vous d'autres pistes ?


    D'avance, merci.


    Bien à vous,


    Jefferson Elias.


    mardi 11 février 2014 06:19
    |

Toutes les réponses

  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    Voir cet article sur le même sujet :

    http://social.msdn.microsoft.com/Forums/sqlserver/en-US/ba581d47-df1e-4fe8-80ca-0649aba0a4b7/cpu-utilization-of-sql-server-2008r2-is-high?forum=sqldatabaseengine

    Cordialement,

    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mardi 11 février 2014 14:45
    |
    Modérateur
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour, tout d'abord merci pour votre réponse.

    Ensuite, suite à l'ajout de 4 Go de mémoire RAM au serveur virtuel, la charge CPU constatée a chuté.

    La charge mémoire reste cependant fort importante : SQL Server utilise plus de 4Go de mémoire RAM. La part la plus importante de la distribution des pages tampon est de type STOLEN. (environ 75%), environ 20% sont de type Free et 5% de type Dirty.

    Le composant "principal consommateur de mémoire" est CACHESTORE_SQLCP à hauteur d'environ 80%.

    Auriez-vous une piste pour comprendre le phénomène ?

    jeudi 13 février 2014 06:10
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Comme on parle d'une migration d’Oracle vers MS SQL, je dirais que ça arrive souvent. 

    CACHESTORE_SQLCP  = c'est la mémoire occupée avec des plans d'exécution pour les requêtes  Ad hoc - donc moins de chance de pouvoir les réutiliser.

    La solution c'est de utiliser des paramètres ou pour les requêtes ou des procédures stockées.

    Voir ce thread avec un plus de détails :

    http://social.technet.microsoft.com/Forums/sqlserver/en-US/47d44d7f-7422-4137-98ab-1c8160563395/cachestoresqlcp-using-11gb-in-whole-sql-server-memoryhow-to-resolve-from-memery-bottle-neck?forum=sqldatabaseengine

    Cordialement,

    Aurel BERA, MSFT
    MSDN Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE.
    S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    jeudi 13 février 2014 13:12
    |
    Modérateur
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Si je reprends la requête

    SELECT objtype AS [CacheType]
            , count_big(*) AS [Total Plans]
            , sum(cast(size_in_bytes as decimal(18,2)))/1024/1024 AS [Total MBs]
            , avg(usecounts) AS [Avg Use Count]
            , sum(cast((CASE WHEN usecounts = 1 THEN size_in_bytes ELSE 0 END) as decimal(18,2)))/1024/1024 AS [Total MBs - USE Count 1]
            , sum(CASE WHEN usecounts = 1 THEN 1 ELSE 0 END) AS [Total Plans - USE Count 1]
    FROM sys.dm_exec_cached_plans
    GROUP BY objtype
    ORDER BY [Total MBs - USE Count 1] DESC
    go

    J'obtiens le résultat

    CacheType    Total Plans    Total MBs    Avg Use Count    Total MBs - USE Count 1    Total Plans - USE Count 1
    Prepared    36839    1450.812500    40    692.656250    10041
    Proc    226    88.398437    1112    19.312500    51
    Adhoc    579    45.601562    37    7.937500    137
    Trigger    38    12.671875    268    0.515625    3
    UsrTab    9    0.750000    703    0.000000    0
    Check    9    0.265625    3    0.000000    0
    View    298    24.445312    19    0.000000    0

    Le plus n'est donc pas dans le Adhoc, mais dans le Prepared...

    jeudi 13 février 2014 13:55
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Quelqu'un sait-il diagnostiquer les requêtes de type "Prepared" pour voir si l'utilisation est correcte ?
    mardi 18 février 2014 10:15
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    Votre problème n'est pas forcément trivial en effet.

    Commençons par les basiques : le stockage. Rien à signaler de ce côté sur els métriques système ? Je ne pense pas, mais bon ...

    Ensuite, les migration depuis Oracle conduisent assez fréquemment à des tables stockées sous forme de Heap. Jetez un œil côté fragmentation.

    Regardez également les statistiques, car si votre requête est préparée, le plan est figé jusqu'à des statistiques obsolètes l'invalident.

    Qu'avez vous planifié d'un point de vue maintenance ? Sauvegardes et réindexation ?

    Vous avez une grosse différence entre la total server memory et le target server memory. J'ai noté que vous aviez virtualisé ce serveur SQL. Regardez côté hyperviseur pour utiliser de la mémoire physique et non pas de la mémoire ballooned.

    Cdlt

    Christophe

    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    vendredi 21 février 2014 14:45
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    merci pour votre réponse.

    Du point de vue des tables, il y a en effet beaucoup de tables stockées sous forme de Heap (148 / 466). [ obtenu via :

    select COUNT(*) from sys.indexes where index_id = 0;

    ]

    Auriez-vous une requête pour voir le taux de fragmentation ?


    Du point de vue maintenance, j'utilise la solution MaintenanceSolution de Ola Halengren. J'ai juste planifié les rebuild d'index. La collecte des statistiques est faite en automatique et synchrone.

    Le serveur virtuel est pour l'instant sur un ESX tout seul (avec bcp de RAM, c'est tout ce que je peux dire). Mon gestionnaire système m'a garanti que je n'aurais pas de ballooning possible.

    Bien à vous,

    Jefferson.



    lundi 24 février 2014 08:41
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    Pour s'en assurer regardez les valeur des compteurs de performance. Normalement, vous devriez trouver les compteurs dans VM Memory.

    Les stolen pages représentent les pages du buffer pool qui ne sont pas affectée aux data, comprendre par là les plans d'exécution.

    Mais ce qui est étrange, c'est que vous avez peu de requête adhoc qui peuvent en être la source.

    Avez vous néanmoins active le optimize for ad-hoc workload ? Regardez le use count pour les requêtes préparées. Est-il souvent à 1 ?

    Christophe

    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    mercredi 26 février 2014 14:17
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Bonjour, oui, je l'ai activée, mais la perte en mémoire est due à 40% à des plans d'execution de type prepared avec un use_count à 1.
    mercredi 26 février 2014 17:25
    |