SQL Server 2016, toujours plus

La dernière étude du Gartner sur les bases de données opérationnelles place Microsoft en tant que leader (Operational Database Management Systems – octobre 2015). Même si les préjugés ont la vie dure, en 20 ans, SQL Server a su trouver sa place dans les bases de données d’entreprise.

Et Microsoft ne s’en contente pas et améliore encore et toujours sa base de données SQL Server. Plus de données, plus de sécurité, plus de fonctionnalités, la version 2016 de SQL Server s’inscrit dans cette lignée. Actuellement, nous en sommes à la CTP 3.3 (Community Technical Preview, c’est-à-dire une beta) disponible sur le site de Microsoft. Citons quelques nouveautés de la version 2016 du moteur de base de données.

Les « Temporal Tables » par exemple. Cette nouvelle fonctionnalité permet d’historiser les changements faits sur les données et de pouvoir les requêter en ajoutant juste une clause à sa requête SELECT. Certes, on pouvait implémenter ce comportement avec des technologies comme le CDC (Change Data Capture) ou les Triggers. Mais là, on parle d’une fonctionnalité native de SQL Server et donc totalement transparente que ce soit en écriture ou en lecture.

Autre fonctionnalité intéressante concernant les tables, les « Stretch Tables ». Cette fonctionnalité permet de stocker les données d’une table de façon hybride. La table « s’étend » sur le Cloud de Microsoft dans une base Azure SQL. On parle de données chaudes et données froides, les données chaudes étant locales à l’instance.

On avait en 2014 la possibilité de stocker des fichiers de base de données (MDF, LDF) dans Azure. Ici, on est à une granularité plus fine, la table. C’est SQL Server qui détermine quelles lignes sont chaudes ou froides dans la version beta actuelle. Encore une fois, cette fonctionnalité est transparente à l’usage hormis le temps de latence quand un SELECT ramène des données froides.

(Ces 2 sujets ont été présentés par Stéphane Haby et Nathan Courtine lors d’une session des Journées SQL Server enregistrée, )

Une fonctionnalité de SQL Server 2016, très attendue des DBA, est le Query Store.Le Query Store permet de stocker des informations sur les exécutions de requêtes comme la durée, l’utilisation des ressources (CPU, IO, …) mais aussi les plans d’exécution utilisés. Ces informations d’utilisation sont stockées directement dans la base de données et SQL Server gère lui-même le stockage et la purge de ces méta-données. Une fois encore, le Query Store apporte de façon simple et transparente une solution de monitoring qu’on pouvait implémenter différemment (XEvent, DMV, etc.).

Mais où le Query Store se révèle pleinement, c’est dans les problématiques de régression de performance. En effet, il permet de suivre graphiquement les exécutions et de forcer un plan particulier en cas de changement de performance. Cela permet de mieux appréhender les projets de montée de version ou de migration.

(((IMG8251)))

(Ce sujet a été présenté par Benjamin Vesan et Guillaume Nocent lors d’une session des Journées SQL Server enregistrée)

SQL Server propose des solutions de haute-disponibilité depuis longtemps. Et si vous sondez des DBA, les groupes de disponibilité AlwaysOn en sont la quintessence depuis la version 2012. Comme à chaque nouvelle version, AlwaysOn s’améliore en performance, maintenabilité, monitoring.

Mais cette année, c’est le couple SQL Server 2016 et Windows Server 2016 qui apporte des nouveautés. Avec la version 2016 de AlwaysOn, il y aura moins d’adhérence à Active Directory, ce qui laisse entrevoir des topologies impossibles à mettre en oeuvre actuellement.

On peut aussi noter deux autres nouveautés intéressantes concernant AlwaysOn. La première est le fait de pouvoir faire du Load Balancing entre des noeuds secondaires. La seconde est la disponibilité de AlwaysOn dans l’édition Standard, mais avec quelques limitations qui le rapprochent du Mirroring (dont la fin a été annoncée en 2014).

La sécurité dans SQL Server 2016

Selon le NIST, SQL Server est la base de données la plus sûre depuis 6 ans (il faut comprendre « la moins vulnérable »). Et pourtant Microsoft travaille toujours et encore à renforcer la sécurité de SQL Server. Et cela passe par des nouvelles fonctionnalités.

La première s’appelle Always Encrypted et permet de chiffrer de bout en bout le requêtage d’une base de données. L’idée est simple, on a chiffré une colonne dans une table et on veut que le chiffrement/déchiffrement soit transparent. L’application cliente requête simplement sa base et c’est le driver ADO.NET (dernière version, 4.6) qui s’occupe de chiffrer à l’aller et déchiffrer au retour, sur le poste client.

Cela passe par le partage de certificats entre le client et la base de données. Le développement est, certes, un peu plus complexe mais la sécurité est respectée de bout en bout : seule l’application qui a le certificat peut requêter et lire les données chiffrées. La seconde nouveauté s’appelle RLS pour Row Level Security.

L’idée est encore une fois simple, c’est de sécuriser (ie. filtrer) certaines lignes en fonction de l’utilisateur. Avec RLS, on écrit une fonction qui autorise ou pas les lignes, comme on peut le faire avec une fonction de classification pour le Resource Governor. Le moteur relationnel fait le reste pour rendre cela transparent et performant.

L’application n’a plus qu’à requêter comme avant les tables sans rien changer…sauf qu’un niveau supplémentaire de sécurité a été introduit.

(Les nouveautés sécurité ont été présentées par Stéphane Haby et Nathan Courtine lors d’une session des Journées SQL Server enregistrée). Découvrez la suite de notre tour d’horizon SQL Server 2016 très prochainement sur le site.