Microsoft SQLServer 2014

TD2014_Small L'édition 2014 des Microsoft TechDays est le moment d'en savoir un peu plus sur la version 2014 du célèbre SGBD Microsoft SQLServer.
Même si ce produit est à chaque version plus mature, Microsoft a concentré ses efforts cette année sur le moteur. Pas d'innovations côté BI (rien ne change pour AS, RS, SSIS…) ni du côté MDM (Master Data Management).

Je vous propose de découvrir les grandes nouveautés de cette année.

Setup

Afin de préparer des images d'instances SQLServer toujours plus complètes, le SysPrep 2014 s'étoffe des dernières options classiques du setup d'SQLServer qui lui manquait. Ainsi, il vous est désormais possible de SysPréper (si si, du verbe SysPréper…) RS, AS, SSIS, SSMS et même vos clusters !

Par ailleurs, combiné à Windows Server 2012 R2, SQL Server peut adresser les CSV (Clustered Shared Volumes) et dépasser ainsi la bonne veille limite arbitraire des 24 lettres des "attached drives".

Bon je vous l'accorde, nous avons connu des introductions plus folichonnes…

Sécurité

Ce sujet reste incontournable, mais rassurez-vous, vous allez pouvoir continuer encore votre lecture un petit moment avant de tomber de votre chaise.

Même si la gestion de la sécurité dans SQLServer arrive à maturité, il est toujours possible de l'améliorer ou de la compléter par des niveaux plus fins. C'est ce que propose Microsoft dans cette version 2014 en autorisant une séparation des rôles encore plus affinée.

Par exemple, comment procéderiez-vous si vous deviez proposer un compte d'administrateur de base, qui ne soit pas Sysadmin et qui ne puisse pas lire le contenu de vos tables par soucis de confidentialité ? Idem si vous ne souhaitez pas lui donner le droit d'impersonation ?
Rien de bien compliqué en 2014 :

  • Création du login (classique)
  • Création d'un rôle dédié au server (classique)
  • Affectation des droits pour ce rôle (classique)
  • Réaliser un Deny sur le SELECT (nouveau)...et le tour est joué !

Scalabilité

Ahhh, ce doux barbarisme me ravit d'avance ! J'imagine déjà nos chers collègues de l'infra trembler lorsqu'ils verront arriver nos premières demandes d'environnement SQLServer 2014 !
Oui, il est désormais possible d'adresser 64 vCPUs par Instance et 1TB de RAM. Et s'il vous plait, épargnez nous vos jeux de mots à base de Technical Breakfast, il s'agit bien de Tera Bytes.

Maintenant que nous avons commencé à parler "matos", la suite devrait vous plaire. Je suis certain qu'en bon informaticien, vous adorez comme moi monitorer votre système et le pousser dans ses derniers retranchements. Ces dernières années, les progrès et la baisse des coûts de CPU et RAM stressent de nouveau les accès disques : les IOs sont dans la ligne de mire !
SQLServer n'échappe pas à cette règle et oh miracle, Microsoft a pensé à enrichir cette année son SQL Governor d'une capacité d'allocation d'IOs par pool !
Restreindre des pools de connexion en consommation CPU et RAM c'était bien, les restreindre maintenant en consommation d'IOs c'est mieux !

La technique est la suivante (très classique pour les habitués de Governor) :

  • Création de pool
  • Création du WorkloadGroup
  • Création de la Classifier Function (très utile lorsque vous souhaitez changer les critères entre le jour et la nuit par exemple)
  • Ajout de cette fonction au Governor
  • Spécification du Min et Max des IOs pour chaque pool

Easy isn't it ? (plus facile à dire que cette dernière locution pour un frenchy)

Allez, une dernière astuce pour vous extasier devant le résultat : vous pouvez suivre ce que ça donne grâce à votre bon vieux perfmon, en allant dans la rubrique SQLServer Ressource Pool > IOs

Performances

Corolaire de la trouvaille précédente - vous noterez qu'ils ont de sacrées "tronches" chez Microsoft - si les disques c'est pas bien et que la RAM c'est génial : il est temps de revoir notre moteur SGBD pour charger nos tables en RAM !

J'ai presque tout dit. Allez, j'habille tout cela avec le jargon Microsoft pour impressionner mes clients. Microsoft vient de mettre au point une technologie révolutionnaire nommée InMemory OLTP (pour OnLine Transaction Processing). Cette innovation vise à optimiser les soucis d'IOs qui représentent un véritable goulot d'étranglement dans nos infrastructures actuelles.
Et le SSD me direz-vous ? Trop cher et leur durée de vie est trop faible pour du stockage de data.

Bref, le principe est le suivant : vous identifiez les tables sujettes à contention afin de faire abstraction du disque et les monter en RAM. Evidemment, les plus déraisonnables d'entre vous me demanderont pourquoi ne pas systématiquement sélectionner toutes les tables si la RAM est devenue si bon marché niark niark niark… Je prendrai soin de les ignorer afin de garder un peu de tenue dans cet article.

Les tables "élues" vont alors être stockées différemment par le moteur (on oublie complètement les pages et les extends) en utilisant de nouveaux "containers" permettant de reconstruire les records en cas de crash :

  • En mémoire : stockage des records (avec du HashIndex ou du RangeIndex)
  • Sur le disque : Data File + Delta File en écriture séquentielle => NO LOCK / NO LATCHES, et c'est gagné pour les perfs !
  • Ensuite, ne pas oublier de planifier les merges (qui appliquent les deltas sur le data file) ce qui nous fera gagner un temps précieux lors d'un redémarrage d'SQLServer !

Techniquement, ça se fait à la création de la table : CREATE ...<BIDULE>... WITH(MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA)

Autre avantage, plus besoin de réindexer quoi que ce soit avec l'OLTP !

La deuxième grande annonce de Microsoft pour améliorer les performances réside dans le concept des procédures stockées natives !

Vous allez là encore identifier les ProcStock à booster -non les déraisonnables, je ne veux pas vous entendre ! - grâce notamment au nouvel outil AMR pour analyser le Workload avec ses nouveaux rapports, et les flaguer pour que SQLServer en fasse des dll chargées en RAM.

Voilà, si vous ne deviez en retenir que deux ce sont celles-là ! Les autres améliorations regroupent l'apparition du Clustered Column Store Index pour compléter le simple Column Store Index de 2012, avec maintenant la possibilité de modifier la table après la mise en place de l'un de ces index. Il est aussi maintenant possible d'étendre à chaud le data cache des tables standards, sur des SSD par exemple avec une petite commande du genre: ALTER SERVER CONFIGURATION SET BUFFERPOOL…+ nom fichier + taille

Pour le reste, rien de bien nouveau à part de nouvelles "Best Practices" concernant la haute dispo et l'utilisation du Cloud. A ce sujet, le Management Studio 2014 est enrichi de nombreuses options et wizards pour interagir avec Azure !

Chers lecteurs ciqwelers, je vous souhaite de bons benchmarks !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.