none
MS SQL 2016 : Vérifications des performances et ajustements

    Question

  • Bonjour,

    A partir de la console MS SQL Management Studio, j'ai lancé le moniteur d'activité.

    Comment vérifier que chaque paramètre affiché est correct pour de bonnes performances ?

    Dans la partie "mémoire", des "propriétés du serveur", j'ai affecté 8192 Mo de RAM maxi (sur 16 Go pour le serveur), et 2048 Ko de mémoire maximale par requête.

    Le graphique :
     "Nombre de requête de lots/s : environ égale à 67 sur 100.

    "E/S de la base de données" : 0,1 Mo/s

    "Taches en attente" : 0

    % du temps processeur" : 5 %

    Bref, que faut-il vérifier absolument pour avoir de bonnes performances SQL ?

    Cdlt,


    • Modifié Cerkyr jeudi 31 janvier 2019 09:29
    jeudi 31 janvier 2019 09:26

Toutes les réponses

  • https://social.technet.microsoft.com/Forums/fr-FR/c0554bff-4cc9-4ff1-8589-0c6e3a30f529/pb-de-performance-sur-sql-server?forum=sqlserverfr

    "Regardez aussi si votre base n'est pas affublée de AUTOSHRINK = True."

    Comment vérifier ce paramètre avec la requête sp_helpdb ?

    A priori, il semble recommandé de passer ce paramètre à false; est-ce vrai ?

    jeudi 31 janvier 2019 10:02
  • Recherche des infos sur cette erreur :

    --

    name timestamp timestamp (UTC) id delta_time memory_ratio new_target overall rate currently_predicated currently_allocated previously_allocated broker notification call_stack process_utilization system_idle user_mode_time kernel_mode_time page_faults working_set_delta memory_utilization session_id error_code api_name calling_api_name type source os_error sni_error sni_consumer_error sni_provider state local_port remote_port tds_input_buffer_error tds_output_buffer_error tds_input_buffer_bytes tds_flags total_login_time_ms login_task_enqueued_ms network_writes_ms network_reads_ms ssl_processing_ms sspi_processing_ms login_trigger_and_resource_governor_processing_ms is_client connection_id connection_peer_id local_host remote_host error_number severity user_defined category destination is_intercepted message database_id callstack wait_type opcode duration signal_duration wait_resource sql_text tsql_stack exit_code shutdown_option session_nt_username query_hash client_pid
    security_error_ring_buffer_recorded 2019-01-31 14:09:03.8311027 2019-01-31 13:09:03.8311027 5023 NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL 0x00007FF988EA713A  0x00007FF988D6B10F  0x00007FF988D6D415  0x00007FF988D69FA1  0x00007FF988D69442  0x00007FF988EA7155  0x00007FF988D68DE8  0x00007FF988BA0C43  0x00007FF988F542CD  0x00007FF988D6598A  0x00007FF9AD55520D  0x00007FF9AD5558E5  0x00007FF9AD5556DD  0x00007FF9AD570CC8  0x00007FF9AD570E20  0x00007FF9AD570B07   NULL NULL NULL NULL NULL NULL NULL 57 5023 ImpersonateSecurityContext NLShimImpersonate NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL

    --

    jeudi 31 janvier 2019 13:13
  • Donc l'audit de sécurité, dans les propriétés du serveur SQL, est saturé par "Echecs et réussites de connexion" ?

    Je vais passer cela en "Echecs de connexion uniquement" pour voir si cela continu.

    jeudi 31 janvier 2019 13:38
  • Bonjour

    Tant qu'il n'y a pas de tâche en attente c'est que tout va bien !
    Si il y a de l'attente, il y a un problème - un goulot d'étranglement.

    A voir donc s'il s'agit des classiques IO disque lents, verrouillage, ... A rechercher dans les DMV adéquates.

    Si il n'y a rien d'autre d'installé sur le serveur, pourquoi limiter SQL à 8GB ?
    Dans le même ordre d'idée pourquoi avoir monté à 2MB le min memory par query (et pas max ...). SQL Server augmentera le memory grant si besoin. Au contraire, si vous ne traitez 'que' des petits jeux de données, pourquoi ne pas descendre la valeur à 512KB ? 

    Par contre, n'abusez pas de l'activity monitor. Il consomme à lui tout seul beaucoup de ressources.

    Cdlt
    Christophe


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

    dimanche 10 février 2019 20:29
  • "Bref, que faut-il vérifier absolument pour avoir de bonnes performances SQL ?"

    Tout !
    Et en plus faut comprendre les tenants et aboutissants.

    D'un coté, les mesures que tu donnes sont plutôt correctes, de l'autre si tu pose la question c'est que tu n'es pas satisfait du fonctionnement global.

    La première étape est d'avoir une "vision globale et dans le temps" (baseline) du fonctionnement du serveur. C'est fait grâce à la mise en place de compteurs. Beaucoup d'utilitaires pour ça - faire un tour sur intenet. Au minimum il faut avoir l'équivalent de DATA COLLECTOR.

    La deuxième est d'identifier les points noirs. Imagine que tu soit docteur est que tu es en face d'une personne dont son cœur bat à 55 battements/minute alors qu'il est à terre en tenue de sport : hypoglycémie ou crise cardiaque ?
    Une métrique, sortie de son contexte, est très peu pertinente. A mieux, elle permet d'éliminer des scénarios.

    Maintenant il y a des lieux communs dans l'absence de performance :

    • Absence d'index
    • Contention des verrous

    Si déjà t'as une bonne vision sur ces 2 points alors il faudra chercher de manière plus précise. Encore une fois ce qui va guider c'est la baseline.

    jeudi 18 avril 2019 07:35