Introduction :

Tout d'abord un petit tour dans la version du 8 août 2008.

Voyons quelques menus :

Tiens, tiens, des nouveaux menus ...

Essayons Sélectionner les 1000 lignes

   Msg 6263, Niveau 16, État 1, Ligne 2

L'exécution du code utilisateur dans le .NET Framework est désactivée. Activez l'option de configuration "clr enabled".

Bon visiblement cela utilise le CLR embarqué: je ne vois pas pourquoi dans ce cas, mais bon, autorisons le :

    sp_configure 'clr enabled',1

    go

    reconfigure

Le script généré :

    /****** Script de la commande SelectTopNRows à partir de SSMS ******/

    SELECT TOP 1000 [NO_COURSE]

         ,[CATEGORIE]

         ,[NOM_CATEGORIE]

         ,[PAR_DEFAUT]

         ,[HOMME]

         ,[TEMPS_MINIMUM]

         ,[ANNEE_DEBUT]

         ,[ANNEE_FIN]

         ,[DT_MAJ_USR]

     FROM [DigitimeNet].[dbo].[CATEGORIE] 

Faisons quelques modifications de ce script :

Voilà ce que nous attendions ! l'Intellisense est activée ...

Cela aide bien, n'est-ce pas ?

Compression de données:

Voilà quelque chose qui va intéresser ceux qui ont du volume à gérer..

Voyons cela :

Deux modes de compression sont disponibles :

• par ligne
• par page (les fameux 8Ko)

On peut avoir une estimation immédiate du volume gagné :

Avec une compression ligne par ligne.

Avec une compression par page.

Sur cette table, le mode page a l'air beaucoup plus performant, reste à voir les performances en lecture/en mise à jour avec et sans compression :

Des lectures sans compression :

    set statistics io on

    go

    set statistics time on

    go

    select distinct ville

    from COUREUR

    where NATIONALITE = 'FRA'

(28065 ligne(s) affectée(s))

Table 'Worktable'. Nombre d'analyses 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

Table 'COUREUR'. Nombre d'analyses 3, lectures logiques 10290, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

SQL Server \endash Temps d'exécution :

, Temps UC = 783 ms, temps écoulé = 655 ms.

Des mises à jour sans compression :

    update coureur set ville = ville + '>'

    go

Table 'COUREUR'. Nombre d'analyses 1, lectures logiques 24127, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

SQL Server \endash Temps d'exécution :

, Temps UC = 4078 ms, temps écoulé = 4922 ms.

(396142 ligne(s) affectée(s))

Allons-y pour la compression par page

qui génère le script suivant :

    USE [DigitimeNetNonCompressee]

    ALTER TABLE [dbo].[COUREUR] REBUILD PARTITION = ALL

    WITH

    (DATA_COMPRESSION = PAGE

    )

Après compression, la lecture :

    select distinct ville

    from COUREUR

    where NATIONALITE = 'FRA'

(28065 ligne(s) affectée(s))

Table 'Worktable'. Nombre d'analyses 0, lectures logiques 0, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

Table 'COUREUR'. Nombre d'analyses 3, lectures logiques 4559, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

SQL Server \endash Temps d'exécution :

, Temps UC = 876 ms, temps écoulé = 720 ms.

et la mise à jour :

    update coureur set ville = ville + '>'

    go

Table 'COUREUR'. Nombre d'analyses 1, lectures logiques 45348, lectures physiques 0, lectures anticipées 0, lectures logiques de données d'objets volumineux 0, lectures physiques de données d'objets volumineux 0, lectures anticipées de données d'objets volumineux 0.

SQL Server \endash Temps d'exécution :

, Temps UC = 8484 ms, temps écoulé = 11297 ms.

(396142 ligne(s) affectée(s))

La consommation CPU supplémentaire est surtout sensible en mise à jour…

L'algorithme de compression utilisant la redondance de caractères, il est logique que le mode page soit plus efficace : la probabilité de trouver une même ville (ou un début de ville) est plus forte sur la page.

Sans surprise, on voit que les ios diminuent avec la compression : il y a moins de pages à lire car elles sont plus pleines...

De même, on constate une légère augmentation du CPU : les opérations de compression/décompression à la volée ont bien sûr un coût !

Conclusion :

Il faudra examiner au cas par cas les tables à compresser, car, dans le cas contraire on risquerait de charger inutilement le CPU pour des opérations peu rentables.

Le facteur 2 obtenu sur cette table est très prometteur !