none
Problème de performance sur SQL Server CE 3.5 RRS feed

  • Question

  • Bonjour,

    je travaille actuellement sur un application .NET adressant une base de donnée SQL Server CE 3.5. Les performances globales de l'application lorsque la base est vide sont très satisfaisantes et la plupart des installations fonctionnent correctement même après plusieurs mois d'usage.

    J'ai cependant un cas particulier que je ne parviens pas à corriger/expliquer. Sur cette installation l'insertion de nouveaux enregistrements est particulièrement longue: jusqu'à 5 secondes là où l’échelle de performance est de l'ordre de la milliseconde.

    La base de données ne fait que 28Mo, et les accès à la base de données sont faits au travers de Table Adapter adressés en C#. La base de données est régulièrement compactée via un Shrink, je suppose qu'il doit y avoir un rapport de cause à effet... si tel est le cas comment puis-je récupérer des performances correctes sans supprimer de données ?

    Auriez-vous une piste à me suggérer ?

    Merci
    vendredi 5 septembre 2014 09:40

Toutes les réponses

  • Bonjour

    Vous indiquez que la base est compacté via shrink régulièrement. Il est fortement possible que le problème vienne de la. Je m'explique, une opération de shrink a pour but de récupérer du volume perdu, si l'opération de shrink est réalisé sans l'option TRUNCATEONLY, la récupération de place des pages seront déplacées provoquant une fragmentation sur les objets contenus dans le fichier.

    Pour défragmenter, il est nécessaire de réaliser une rebuild des objets
    /!\ Le rebuild d'index n'est pas une opération anodine en terme de consommation de ressource et de verrouillage des objets.

    vendredi 5 septembre 2014 09:59
  • Plus de détail sur le shrink :

    Sur fichier de log :

    Le shrink de log est une opération sans incidence et peut s’opérer facilement. La seule incidence est la nécessité de réallouer (growth up) pour les prochaines transactions, ce qui peut être couteux surtout avec une mauvaise configuration de l’autogrowth des fichiers

    Une opération de shrink sur les fichiers de log peut être justifiée par une activité sortant de l’ordinaire générant une augmentation de la taille du fichier de log ou en cas d’urgence sur un problème d’espace disque sur un serveur.

    Sur fichier de data

    Le shrink sur un fichier de data est vraiment à éviter, car ce type d’opération génère une importante fragmentation sur les pages de données.

    Le shrink sur fichier et sur base de données utilise la même méthodologie :

    • DBCC SHRINKFILE
    • DBCC SHRINKDATABASE

    Voici comment fonctionne, l’opération de shrink (sans l’option TRUNCATEONLY) :

    • Sur un environnement parfaitement construit avec au finale une fragmentation proche de 0% (1)
    • Suite à la suppression d’une table ou de beaucoup de données, des pages de données disparaissent (2) :


    -          Un volume réservé est donc inutilisé.

    En cas de shrink voici ce qu’il va se passer :

    Algo :

    L’opération de shrink fonctionne sur un seul fichier à la fois et utilise le GAM bitmaps (Global Allocation Map) pour trouver la page la plus « haute » (dernière pages allouée). Le shrink déplace la dernière page allouée dans au début de l’espace réservé et répète cette opération jusqu’à atteindre une page qui n’est pas déplaçable.

    Illustration :


    Ce qui peut générer une importante fragmentation.

    Il est donc important de ne pas configurer une base de données en auto-shrink et d'envisager un rebuild des objets de la base après un shrink de fichier de data.

    vendredi 5 septembre 2014 10:07
  • Merci pour votre réponse.

    La méthode Shrink que j'utilise n'est pas paramétrable, je dois donc utiliser les options par défaut

    http://msdn.microsoft.com/fr-fr/library/system.data.sqlserverce.sqlceengine.shrink(v=vs.100).aspx

    Pourriez-vous m'indiquer comment réaliser ce rebuild des objets ?

    merci.

    vendredi 5 septembre 2014 10:55
  • Pouvez lancer des requêtes SQL sur la base de données ?

    Si oui, il suffit de suivre ce lien : lien

    La commande basic : 

    ALTER INDEX [MonIndex] ON [MonSchema].[MaTable]
    REBUILD

    Si vous voulez être sur que le probleme est du à de la fragmentation : 

    USE AdventureWorks2008
    SELECT OBJECT_NAME(db.object_id), idx.name AS idx
    , db.index_type_desc
    , Avg_fragmentation_in_percent AS [Fragmentation externe moyenne]
    , Avg_page_space_used_in_percent AS [Fragmentation interne moyenne]
    FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL , 'SAMPLED') db 
    INNER JOIN sys.indexes idx
    	ON db.object_id = idx.object_id
    	AND db.index_id = idx.index_id

    Définition des fragmentation : 

    • La fragmentation interne (ou logique) se produit lorsque des pages ne sont pas totalement remplis
    • La fragmentation externe (ou physique) se produit lorsque les pages de l’index ne sont pas contiguës 

    vendredi 5 septembre 2014 11:07
  • Quel efficacité ! Merci pour vos réponses rapides. Je ne connais pas le nom du schema de la base de données... Et je viens de m'apercevoir qu'aucun index n'a été ajouté aux tables avec lesquelles des lenteurs importantes sont constatées. La seconde requête ne me sera pas accessible dans la mesure où le Transact-SQL sous CE est très limité.

    Y'aurait-il d'autres piste qu'il faudrait que j'explore parallèlement ?

    Merci.

    vendredi 5 septembre 2014 13:15
  • Les indexs sont indispensables pour avoir une bonne lecture mais si j'ai bien compris, le probleme ici est la lenteur a l'écriture.
    vendredi 5 septembre 2014 13:21
  • Bonjour,

    merci de votre mobilisation sur cette question. Même si je vais faire en sorte que cette base de données disposent d'index performant à l'avenir, le problème venait visiblement d'un problème de performances du serveur qui hébergeait l'application (Windows Update + processus Idle consommaient énormément de CPU...). Une migration a suffit pour obtenir des performances satisfaisantes...

    J'aurais du commencer par là, désolé pour le dérangement et merci encore !

    • Proposé comme réponse Pechouille mardi 9 septembre 2014 13:30
    mardi 9 septembre 2014 13:25
  • Bonjour

    Je vous suggère cependant d'explorer la possibilité d'utiliser d'autres éditions de SQL Server (standard, voire express) en fonction de vos besoins.

    Mais n'attendez pas de miracles de SQL Compact ...

    Christophe


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

    mardi 23 septembre 2014 23:41