Vote utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

La version 11 de SQL Server (aka MSSQL 2012 ou Denali) introduit un nouveau type d'index permettant de stocker les données en mode colonnes.

Les columnstore index, particulièrement adaptés aux requêtes décisionelles accélèrent ces requêtes pour plusieurs raisons :

  • Les données stockées sont compressées assez fortement, ce qui entraîne moins d'IOs physiques et moins de consommation mémoire.
  • Les données stockées en colonnes permettent un balayage limité des données en fonction des colonnes demandées dans la requête.
Il y a cependant quelques restrictions liées à ce type d'index :
  • Il n'est pas possible d'écrire sur une table ayant un index en colonne. Il est cependant possible de contourner ce type de limitation avec le partitionnement : on écrit dans un table intermdiaire sans index, on créer l'index sur la table intermédiaire, on switch la table intermédiaire avec une partition de la table cible.
  • Il ne peut il y avoir qu'un seul index de type columnstore par table. Vu que c'est un stockage en mode colonne, on aura donc tendance à avoir un index incluant toutes les colonnes utiles de la table.
  • Au moment de la création de l'index, il y a une forte demande de mémoire. La mémoire demander est exterieure au buffer pool (donc en plus du max memory/target)
Voyons comment créer ce type d'index et comparons le à un index classique.
Avec SSMS on voit l'apparition de nouveau type d'index dont le Columnstore Index :

 

Création d'un nouvel index columnstore via SSMS

 

Commentaire (0) Clics: 7188

Vote utilisateur: 4 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles inactives

La version 11 de SQL server (aka Denali) dispose d'un assistant de création pour les "extended events". Ces évènements permettent de suivre et de tracer des points complexes sur le serveur de base de données.

Voyons comment procéder pour créer et tracer ces évènements avec le nouvel assistant intégré à SQL Server Denali.

Le lancement du "session wizard" s'effectue à partir de la section de management dans SSMS

Lancement de l'assitant de création d'un extended events

Commentaire (0) Clics: 6149

Vote utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

Une des difficultées dans la gestion du base de données MSSQL est de controller l'espace de stockage et vérifier si une pénurie d'espace disque ou une limite dans la taille de fichier journal ou de données ne va pas entrainer le blocage des transactions.

Les difficultés résident dans plusieurs aspects :

  • Une base de données peut avoir plusieurs FILEGROUP de données
  • Chaque FILEGROUP peut avoir plusieurs fichiers
  • Chaque fichier peut avoir sa propre gestion de stockage : autoextent, taille illimitée ou limitée avec des tailles potentiellement différentes
  • Chaque base de données peut avoir plusieurs fichiers journaux (même si un seul est actif à un instant t)
  • Les fichiers journaux ou de données peuvent être dispersées sur des volumes différents (disques, partitions, point de montage...) dont les tailles sont différentes.

Comment être alerté avant le blocage avec tous ces paramètres en jeux ?

Je vous propose d'étudier, pour répondre à cette question, les strategies de la base de données SQL Server. Nouveautés de SQL serveur 2008, ces strategies sont très puissantes pour controler des aspects des bases de données et des instances.

Les strategies  de base de données s'appuie sur plusieurs objets :

  • Les facettes : ce sont des objets sur lesquels vont porter des conditions
  • Les conditions : ce sont des tests qui portent sur une facette
  • Les stratégies :  ce sont des conditions appliquées à des cibles (bases, serveurs...) avec ou sans plannification.

 

 

 

 

 

 

 

 

Commentaire (0) Clics: 11944

Vote utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

Suite à un audit de performance chez une entreprise qui cherchait à améliorer les performances MSSQL Server (SSDE 2008 SE 64 bits sur W2K8R2) pour son application CRM (SugarCRM), j'ai constaté un comportement au premier abord étrange sur la gestion des chaînes unicode sur le SGBD de microsoft...
Le consultant spécialiste de l'application (SugarCRM) me fit remarqué que des requêtes très simples à priori n'avaient pas la performance attendue.
En étudiant de près une requête type j'ai constaté un effet étonnant concernant l'utilisation de filtres avec une chaîne unicode : colonne1=N'machaine' alors que la colonne que l'on cherche à filtrer est de type varchar (et non nvarchar).

La requête qui m'a posé problème était une requête très simple d'une durée de 200ms environ. Pas de problème de performance avec 200ms par requête me direz vous, sauf que cette requête était lancée plusieurs dixaines de fois pour certains écrans.

Voici la requête :

 

SELECT 
acc.id, acc.name, con_reports_to.first_name, con_reports_to.last_name
FROM
contacts
LEFT JOIN accounts_contacts a_c ON a_c.contact_id = N'1A9C0C58A81C4195B854739635E435D5' AND a_c.deleted=0
LEFT JOIN accounts acc ON a_c.account_id = acc.id AND acc.deleted=0
LEFT JOIN contacts con_reports_to ON con_reports_to.id = contacts.reports_to_id
WHERE
contacts.id = N'1A9C0C58A81C4195B854739635E435D5'
 

 

On notera sur cette requête les prédicats=N'1A9C0C58A81C4195B854739635E435D5'. Le N qui préfixe la chaîne indique au moteur relationnel de sql server qu'il s'agit d'une chaîne de caractère unicode. Or les colonnes sur lesquelles portent les filtres ne sont pas en nvarchar mais en varchar.En observant les statistiques et le plan d'éxécution on observe ceci :

Commentaire (0) Clics: 11270