SQL Server groupes de disponibilités AlwaysOn et abonnements SSRS

Mis en avant

Publié le par
Répondre

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

Publié le par
1

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

Publié le par
Répondre

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

SQL Server 2016: groupes de disponibilités AlwayOn et nouvelle option DB_FAILOVER

Mis en avant

Publié le par
Répondre

Continuons la découverte de SQL Server 2016, avec l’un de mes sujets favoris: les groupes de disponibilité AlwaysOn. Il y a eu effectivement encore eu quelques améliorations.

Tout d’abord, introduisons cette nouvelle option en se souvenant du comportement des groupes de disponibilité avec les versions précédentes de SQL Server. Une idée fausse qui existe encore est qu’un groupe de disponibilité peut basculer en cas de défaillance d’une base de données alors qu’en réalité ce n’est pas le cas. Non, ce n’est pas une blague, mais bien la réalité. Les groupes de disponibilités sont conçus uniquement pour détecter les problèmes au niveau de l’instance de SQL Server et ceci jusqu’à l’introduction de SQL Server 2016.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server