Developpez.com
Accueil
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
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
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
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
Il y a quelques semaines, j’ai discuté d’un cas intéressant avec un de mes amis qui a fait face à un problème étrange (en surface) avec une instance SQL Server qui a manqué de threads de travail. Je ne peux malheureusement pas dévoiler le vrai contexte client ici mais j’ai décidé de reproduire le même problème afin de partager avec vous certaines informations intéressantes. La prochaine partie de ce blog se réfère uniquement à mes propres tests qui représentent dans sa plus grande partie le problème cité ci-dessus.
> Lire la suite (en anglais)
David Barbarin
MVP & MCM SQL Server
Les SQL Saturdays sont de nouveau présents en France pour une seconde édition. A cette occasion j’aurais l’immense plaisir d’animer une pré-conférence en collaboration avec Christophe Laporte le vendredi 12 septembre sur la thématique du stockage et des sauvegardes. Les pré-conférences sont payantes et peuvent être assimilées à des formations traditionnelles.
De plus le samedi 13 septembre je présenterais une session sur des concepts avancées concernant les architectures hautes disponibilités avec AlwaysOn et les groupes de disponibilités. D’autres sessions intéressantes auront également lieu en fonction de vos affinités avec les différentes thématiques que l’on peut retrouver avec SQL Server.
Il est encore temps de vous inscrire
Au plaisir de vous retrouver lors de cet événement !
Comme d’habitude un grand merci aux partenaires de l’événement !
David BARBARIN (Mikedavem)
MVP et MCM SQL Server
Il y a quelques semaines, je travaillais pour un client qui voulait implémenter une solution de haute disponibilité avec SQL Server 2012 AlwaysOn avec les groupes de disponibilités. Nous avons effectués une batterie de tests de basculement et le client a tenté de basculer les groupes de disponibilités installés au travers de la console de gestion de clusters. Bien entendu, je lui ai dit que cela n’était pas une bonne pratique parce que celui-ci n’était pas au courant de l’état de synchronisation d’un groupe de disponibilité. Mais avec SQL Server 2014, ceci a visiblement complétement changé de ce que j’ai pu constaté. Je voudrais partager cette information avec vous.
Pour lire la suite (en anglais)
David BARBARIN (Mikedavem)
MVP et MCM SQL Server
Il y a peu de temps, en tant que consultant j’ai dû fournir quelques bonnes pratiques en terme d’architecture pour un environnement dont l’activité d’écriture était prédominante avec un import de données depuis différents sources dans des tables SQL Server. Au cours d’une discussion mon client m’a demandé quelles étaient les nouvelles fonctionnalités de SQL Server qui pourraient potentiellement améliorer la vitesse du processus d’import. J’ai eu en tête une amélioration intéressante proposée autour de la commande SELECT INTO qui est souvent utilisé dans des environnements avec ETL. En effet, il est maintenant possible d’exécuter cette commande avec exécution parallèle …
>> Pour lire la suite (en anglais)
David BARBARIN (Mikedavem)
MVP et MCM SQL Server
SQL Server 2014 a introduit les indexes hash avec les tables in-memory. J’ai décrit certaines de leurs caractéristiques dans un blog précédent.
Ces indexes sont vraiment efficaces pour des opérations de recherche ciblées mais possèdent quelques limitations pour d’autres comme les opérations de balayage, les prédicats à base d’inégalités ou encore les balayages triés dans un ordre spécifique. Il existe maintenant un autre type d’index (index non cluster ou Bw-Tree) qui permet de répondre à cette problématique et tout comme les indexes hash ils incorporent également une chaîne de données dans leur structure au niveau feuille.
Dans ce billet je voudrais partager avec vous certains aspects intéressants du stockage qui les concernent.
>> Pour lire la suite (en anglais)
David BARBARIN (Mikedavem)
MVP et MCM SQL Server
Ce billet fait suite à quelques discussions échangés lors d’un cours sur SQL Server AlwaysOn que j’ai pu donner ces derniers temps. Une des parties du cours ciblaient certaines tâches qu’un administrateur pouvait avoir à effectuer sur une base de données concernée par un groupe de disponibilité dans un environnement complètement asymétrique. Je tiens à dire tout de suite que Microsoft conseille d’avoir des environnements similaires entre réplicas pour une administration plus simple. Maintenant que cela est dit, prenons une situation où un administrateur de bases de données doive ajouter un fichier de données supplémentaire à une base de données faisant parti d’un groupe de disponibilité dont l’architecture en place est la suivante :
Une architecture avec 4 réplicas. Je précise de suite que cette architecture est tout à fait fictive et que le placement de fichier pas forcément optimale pour une telle architecture mais le principe est de bien comprendre les problèmes qu’impliquent une telle asymétrie dans notre architecture. La convention de placement de fichier suivante : <LETTER>:\<SQLSERVER>\<INSTANCE>\<TYPEF_FICHIER>. Pour l’instance SQL141\IRONMAN pour les fichiers de données qui seront hébergés sur le disque E: nous aurons le placement suivant E:\SQLSERVER\IRONMAN\DATA.
L’ajout du fichier doit se faire en respectant la convention de placement en place. La question à 1 euros est-ce que je peux ajouter un fichier de données sans perturber l’architecture en place ?
…….
….
.
Pour le savoir rendez-vous dans la suite de ce billet !
La base de données concernée se nomme AGDB avec le schéma de répartition suivant :
Côté groupe de disponibilité voici ce que nous avons :
Ajoutons maintenant un fichier supplémentaire …
et voilà le résultat côté groupe de disponibilité :
… et côté instance :
Comme dirait l’autre, ça c’est fait !!! Bon reprenons nos esprits et regardons un peu ce qui se passe dans le journal des erreurs SQL Server d’une des instances SQL Server concernées :
On voit rapidement que le problème est la convention de placement des fichiers de données. En effet SQL Server tente de propager la création de fichier depuis le primaire vers les secondaires qui n’ont pas du tout les mêmes chemins de fichiers. Une erreur est levée et tant que le problème n’est pas réglé la réplication est suspendue.
Ok … que doit-on faire ici ? Réinitialiser le tout en supprimant la base de données AGDB du groupe de disponibilité et repartir d’une nouvelle sauvegarde en prenant soin de changer les chemins de fichiers ? Possible mais cela veut dire qu’il faut tout rependre … avec des bases de données de petite taille c’est jouable mais imaginez seulement une base de données de plus d’une centaine de Go, le tout multiplié par 3 car nous avons 3 réplicas secondaires … Une autre solution ? En fait oui .. on peut récupérer une sauvegarde de journal et la restaurer sur chacun des réplicas. Mais comment faire car il n’est pas possible d’appliquer des sauvegardes sur une base de données d’un groupe de disponibilités sur un réplica secondaire. En fait il faut supprimer la base de données du groupe de disponibilité sur chaque secondaire de la manière suivante :
Il se peut que des messages d’erreurs apparaissent stipulant un problème de création de fichiers sur un mauvais chemin mais on peut les ignorer. L’important est de pouvoir retrouver nos bases de données sur les réplicas secondaires en mode de restauration :
On peut maintenant appliquer une restauration du journal effectuée après avoir rencontré notre problème en veillant à restaurer notre fichier (AGDB2) qui pose problème vers le bon chemin :
et en ajoutant à nouveau la base de données au groupe de disponibilité pour le réplica concerné
… ainsi de suite pour les autres réplicas et le tour est joué :
… avec une répartition qui respecte la convention en vigueur :
Bien qu’il est possible de revenir à une situation pérenne plus ou moins facilement cela reste à mon avis fortement déconseillé car ce genre de configuration ne peut que compliquer l’administration courante d’un administrateur de bases de données. Ici nous avons ajouté un fichier de données mais que se passerait-il si nous devions ajouter en urgence un fichier journal en urgence dans un environnement SQL Server AlwaysOn complètement asymétrique ? …
David BARBARIN (Mikedavem)
MVP et MCM SQL Server
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
