SQL Server et groupes de disponibilités AlwaysOn: comment isoler le trafic de réplication?

Mis en avant

Il y a quelques jours, j’étais impliqué dans un projet d’implémentation d’une infrastructure de groupes de disponibilités AlwaysOn 2014. Au cours de ce projet, mon client voulait isoler le trafic de réplication du réseau publique. L’idée était de garantir un meilleur contrôle de la bande passante du réseau ainsi qu’une latence minimale en cas de trafic réseau applicatif important ou de sauvegardes.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

sp_cursor_fetch et performance

Mis en avant

Il y a quelques semaines lors d’un audit, mon client me parlait de problèmes de performances identifiés uniquement sur la phase de login de son application. Après des échanges divers entre le client et l’éditeur de logiciel, nous avons constaté que le problème ne se produisait pas lorsque l’application et l’instance SQL Server étaient installées sur le même serveur (moins d’une seconde avec la configuration de l’éditeur contre 10 secondes avec celle du client). A vrai dire, mon client ne possédait pas tout à fait la même configuration qui comprenait un serveur applicatif et un serveur de bases de données distant. Imaginez la déception du client lorsqu’il s’est aperçu que sa configuration matérielle était de loin plus puissante que celle de l’éditeur de logiciel pour ces tests avec un même volume données.

> Pour lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server groupes de disponibilités AlwaysOn et abonnements SSRS

Mis en avant

Il y a quelques jours, j’ai eu l’occasion de travailler sur une infrastructure incluant des groupes de disponibilités AlwaysOn 2014 et un rapport de serveur Reporting Services en mode natif et en scale-out. Gérer Reporting Services dans une infrastructure AlwaysOn n’est pas toujours une tâche facile et cela dépend notamment des fonctionnalités utilisées dans SSRS. Ceci est particulièrement vrai lorsque des planifications et abonnements sont en jeu.

> Pour la lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

N’utilisez pas les paramètres par défaut AUTOGROW!

Mis en avant

Au cours de mes audits clients, j’ai souvent vu les paramètres d’expansion de fichiers par défaut sur les bases de données utilisateurs et comme vous le savez ceci n’est pas forcément une bonne pratique. Laissez moi vous raconter une histoire drôle vécue qui concerne une situation extrême avec un fichier journal et ses paramètres par défaut.

> Pour lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

Index cluster columnstore et gestion de la mémoire

Mis en avant

Il ya quelques semaines, j’ai eu l’occasion de donner une session sur la fonction d’index cluster columnstore (CCI) lors de notre événement In-Memory dédié aux technologies Microsoft SQL Server, Oracle et SAP HANA. Au cours de notre session, j’ai expliqué les améliorations apportées par Microsoft sur SQL Server 2014, avec l’introduction du nouvel index cluster columnstore (CCI).

Le CCI comprend une nouvelle structure qui permet des opérations de mise à jour: le fameux deltastore. En effet, les opérations d’insertion vont directement dans ce magasin. La suppression de données est purement logique et va être également répertorié dans une partie du deltastore appelée deleted bitmap. Enfin la mise à jour de données va se transformer en 2 opérations élémentaires INSERT et DELETE. En réalité, j’étais très intéressé de savoir comment s’articulait ces deux structures spécifiques (deltastore et columnstore) et comment SQL Server gérait la mémoire la mémoire dans ces différents scénarios. Ce blog est simplement le résultat de mes études et concerne probablement ceux qui aiment regarder sous le capot de SQL Server. Pour être tout à fait honnête, l’idée m’est venue lorsque je discutais avec un de mes amis « Oraclien » et qui me posaient des questions intéressantes sur la gestion du CCI.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server 2016 : groupes de disponibilité AlwaysOn et nouveau support pour le catalogue SSIS

Mis en avant

Il y a quelques semaines de cela, je participais à un projet d’infrastructure SSIS avec SQL Server 2014. Comme vous le savez, l’architecture SSIS a fondamentalement changé depuis SQL Server 2012 et a conduit à une nouvelle façon d’administrer cette fonctionnalité par les administrateurs de bases de données. Ceci est particulièrement vrai lorsque nous devons prendre en compte une architecture AlwaysOn avec le nouveau catalogue de SSISDB depuis SQL Server 2014 ..

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server 2016 : groupes de disponibilités AlwaysOn et support des index columnstore sur les secondaires

Mis en avant

Après avoir fait le tour des quelques améliorations du côté de la fonction d’index columnstore, j’ai été étonné de voir la section suivante

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server 2016 : groupes de disponibilités AlwaysOn et équilibrage de charge

Mis en avant

Dans cet billet, je parlerai des réplicas secondaires en lecture seule et le nouveau support d’équilibrage de charge qui sera fourni par SQL Server 2016.

Avec SQL Server 2014, il y avait déjà eu quelques améliorations sur la disponibilité des secondaires en lecture seule (lorsque le réplica primaire tombait). Cependant, la redirection en lecture seule vers un secondaire restait basique, car elle ne concernait que le premier réplica qui était configuré dans la liste de priorité. A moins d’utiliser un outil tiers dans cas, il n’était pas envisageable de maximiser l’utilisation des ressources disponibles depuis les secondaires. Heureusement, la prochaine version de SQL Server va changer la donne en introduisant des capacités d’équilibrage de charge natives.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server 2016 : groupes de disponibilités AlwaysOn et amélioration du basculement automatique

Mis en avant

Cette fois, nous allons parler de la possibilité d’inscrire un 3ème réplica pour le basculement automatique. Cela implique bien sûr de configurer la réplication synchrone entre 2 paires de réplicas et cela certainement au prix d’une dégradation de la performance globale. Mais il semble que dans ce domaine nous pouvons nous attendre à avoir également quelques améliorations. Peut-être une autre étude à venir …

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server 2016 : groupes de disponibilité Alwayson et support potentiel en édition standard

Mis en avant

Dans mon premier blog sur les groupes de disponibilité avec SQL Server 2016, j’ai pu parler rapidement d’une nouvelle option intéressante: DB_FAILOVER. Dans ce billet, je vais continuer avec une autre potentielle bonne nouvelle (à ce stade rien n’est encore confirmé): le support des groupes de disponibilité en édition standard. Cela semble être en effet une grande nouvelle car cela permettra d’accroître le champ d’action des groupes de disponibilités vers de nouveaux clients potentiels. Cependant gardons à l’esprit que nous parlons de l’édition standard et que l’on peut s’attendre à quelques limitations.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server