Pass Summit 2014: c’est parti

Mis en avant

C’est la première fois que je vais au Pass summit cette année. L’édition 2014 sera donc le début de mon expérience Pass summit. Cette année j’y vais avec mon collègue Stéphane Haby (MVP SQL Server). Il est 07:30 du matin et nous sommes déjà au centre de conférence à bureau d’enregistrement …

Lire la suite ( en anglais )

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server et fuite mémoire: Etes-vous bien sûr ?

Mis en avant

Récemment j’ai rencontré un problème avec l’un de mes clients (oui je recontre beaucoup de problèmes à vrai dire …) qui m’expliquait que leur instance Server 2008 R2 avait une fuite de mémoire . Waaou une fuite mémoire! Le serveur posède 64 Go de RAM et l’instance de SQL Server concernée est limitée à 54 Go selon l’option de serveur de mémoire serveur max (GB ) . Cependant, il avait remarqué que SQL Server utilise 60 Go de mémoire, ce qui ne correspond pas à l’option serveur « max server memory (MB) ». Qu’Est-ce qui passe ici ? Je vous propose de voir cela dans le billet.

Lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server failover cluster, VSphere & les cauchemards de la réservation SCSI-3

Mis en avant

Lorsque je dois installer une instance SQL Server FCI chez un client dans un environnement virtualisé, la plupart du temps voir quasi tout le temps l’environnement est déjà paramétré et prêt à être utilisé. Je suppose que c’est la même chose pour la plupart des consultants SQL Server. Si vous avez un peu de temps n’hésitez pas à partager votre expérience :-) Cependant il faut avouer que nous manquons de pratique et que certaines fois nous avons pas la connaissance des bonnes pratiques de configuration à appliquer à la couche virtuelle concernant les infrastructures SQL Server FCI.

Il y a quelques jours, j’ai eu un cas assez surprenant à vrai dire où j’ai du aider un client à configurer la couche virtuelle de stockage sur VSphere 5.1. Je voulais profiter de l’occasion pour remercier le client ( qui se reconnaîtra si jamais il lit le blog ) qui m’a permis de remettre les mains dedans. L’histoire commence avec une un problème de basculement aléatoire de l’instance SQL Server FCI après avoir basculé les volumes disques de VMFS vers RDM …

Pour lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server: comportement d’une bascule forcée avec les groupes de disponibilités

Mis en avant

Il y a quelques temps chez un de mes clients concernant la mise en place d’une infrastructure AlwaysOn et les groupes de disponibilités, nous avons eu ensemble une discussion intéressante. Celle-ci concernait les impacts d’une bascule manuelle avec une perte potentielle de données entre 2 réplicas asynchrones. La grande question de cette discussion était la suivante: est-ce que SQL Server est capable de resynchroniser automatiquement les bases de données hautement disponibles si certaines transactions sont perdues durant la bascule ?

La réponse est oui mais une autre question plus intéressante est sans doute comment SQL Server procède pour opération cette synchronisation ? Si la réponse vous intéresse c’est par ici

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014: commit classique vs commit et delayed durability & I/Os

Mis en avant

Lorsque vous apprenez à administrer SQL Server, vous entendrez vous dire qu’une validation de transaction est une oération synchrone and vous pouvez avoir confiance en cela! Dans ce billet, je vous propose cependant de vous fournir quelques détails sur ce que nous qualifions de synchrone dans ce cas. La raison de billet est que quelque fois, lorsque je parle de cette nouvelle fonctionnalité il me semble percevoir quelques confusions à ce sujet avec le raccourci suivant: écrire dans le journal est une opération synchrone alors que réaliser la même opération avec cette nouvelle fonctionnalité est asynchrone. Ceci n’est pas totalement faux rassurez-vous mais tout dépend de quoi on parle en réalité …

Lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Saturday 323: SQL Server AlwaysOn et les groupes de disponibilités – les slides

Mis en avant

Cette édition qui se déroulait à Paris dans la tour Montparnasse est maintenue terminée. Ce fut un grand cru avec beaucoup de speakers français mais aussi internationaux. Il y eu également un grand nombre de participants et peut être que la tour Montparnasse y a été pour quelque chose .. allez savoir !

Quoi qu’il en soit j’ai été ravi de pouvoir animer 2 sessions et je remercie les organisateurs ainsi que les participants sans qui cet événement n’aurait finalement que très peu d’intérêt.

Vous pouvez trouver les slides de ma session sur le slideshare du GUSS ou sur mon blog dbi-services

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014: DBCC CHECKDB et ReFS support

Mis en avant

Pour ceux qui ont déjà testé SQL Server 2014 vous avez peut être remarqué que la commande DBCC CHECKDB avait quelque peu changé son comportement vis-à-vis de l’utilisation des fichiers sparses ? Je l’ai découvert complétement par hasard durant mes tests. Si vous prêtez attention, vous verrez que des fichiers étranges apparaissent pendant l’exécution de la commande DBCC CHECKDB …

Lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server: DBCC CHECKDB et corruption non détectée

Mis en avant

Au cours de mes audits clients, il arrive encore de trouver des bases de données avec une option de vérification de page configurée à NONE. J’ai toujours alerter mes clients sur ce type de configuration parce qu’elle peut avoir un impact certain sur l’intégrité des bases de données concernées. Un de mes clients me disait justement que de toute façon la vérification d’intégrité via les plans de maintenance pouvaient étaient faite pour cela mais est-ce vraiment le cas ?

Pour le savoir c’est par ici (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Saturday Paris Septembre 2014

Mis en avant

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 !

image 

 

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014: sys.dm_exec_query_profiles, une fonctionnalité prometteuse

Mis en avant

Parmi les fonctionnalités cachées de SQL Server 2014 il y a une nouvelle DMV intéressante nommée sys.dm_exec_query_profiles. En effet, cette dernière permet aux administrateurs de bases de données et aux développeurs expérimentés de pouvoir diagnostiquer les requêtes longues en temps réel. Je suis sûr que vous avez déjà eu à répondre à ce genre de questions: Quand est-ce que cette requête va se terminer ? Quel est le pourcentage de progression de cette requête ? Quelles étapes ont pris le plus de temps ? Avant SQL Server 2014, autant dire que cela était impossible.

Cependant je dois admettre que cette nouvelle DMV a suscité pas mal de questions et d’étonnement de ma part. Je partagerais avec vous cela durant ce billet.

Pour lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014 : basculement de groupes de disponibilités impossible avec le gestionnaire de clusters

Mis en avant

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

SQL Server 2014 : améliorations concernant tempdb

Mis en avant

SQL Server 2014 est définitivement conçue pour la performance et je vais essayer de le démontrer durant ce billet. Je parlerais des fonctionnalités un peu cachées concernant la performance parce qu’en général celles-ci n’exigent aucun changement applicatif contrairement à d’autres fonctionnalités plus connues comme les tables in-memory par exemple.

Pour lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014 : Statistiques incrémentales

Mis en avant

Est-ce que vous utilisez le partitionnement SQL Server ? Si oui, ce post est fait probablement pour vous parce qu’il y a une bonne nouvelle avec le partitionnement SQL Server 2014 ! Je me souviens d’une ancienne mission avec un client dans le domaine de la santé ou nous avions décidé d’implémenter une stratégie de partitionnement pour une grosse table d’archivage contenant des entrées médicales. Nous utilisions SQL Server 2005 et nous devions déjà relever certains défis comme la mise à jour de statistiques. Les administrateurs de bases de données savent de quoi je parle …

Lire la suite (en anglais)

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SELECT INTO et exécution en parallèle

Mis en avant

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

In-Memory tables, Bw-Tree, and stockage

Mis en avant

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

TDE, gestion des clés de chiffrement et stratégie de sauvegardes

Mis en avant

Transparent Data Encryption requières la création d’une clé de chiffrement de bases de données. Cette clé fait elle même partie d’une hiérarchie de chiffrement de clé utilisée par SQL Server. Cette hiérarchie offre une certaine souplesse dans la gestion des clés qui comprend la restriction des clés aux personnes autorisées, la sauvegarde des clés vers un stockage sécurisé et la rotation des clés de chiffrements pour éviter que celles-ci soient compromises par une personne malveillante. Comme vous pouvez l’imaginer un aspect important de cette gestion des clés est l’alignement de rotation des clés avec la stratégie de sauvegarde des bases de données.

>> Pour lire la suite

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014 : Buffer pool extension .. une fonctionnalité intéressante

Mis en avant

La sortie de SQL Server 2014 a été annoncée pour le 1er avril 2014 .. non ce n’est pas un poisson d’avril .. et je pense que l’une des fonctionnalités les plus intéressantes à utiliser hormis Hekaton bien sûr l’extension du buffer pool sur des disques de type solid-state. J’ai voulu tester et comprendre cette fonctionnalité afin de voir ce qu’il en était réellement et ce qu’elle apporterait dans des environnements serveurs où l’extension de mémoire peut être problématique pour diverses raisons.

>> Lire la suite

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014: Supprimer les fichiers sur disque associés à une table In-Memory

Mis en avant

Est-ce que vous ne vous êtes jamais demandé ce qui se passerait si les fichiers d’une table Hekaton étaient accidentellement supprimés du système de fichier ? Est-ce que cela compromettrait le fonctionnement global de la table voir même de l’instance SQL Server ? J’ai souvent entendu cette question au cours des événements auxquels j’ai pu assister mais sans jamais vraiment avoir de réponse. Dans ce billet (en anglais) je vous propose de voir ce qu’il en est.

Bonne lecture !

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server 2014 : SELECT ALL USERS SECURABLES & DB admins

Mis en avant

Microsoft a introduit 4 nouvelles permissions. L’un d’entre elles (SELECT ALL USERS SECURABLES) peut permettre à un administrateur de bases de données de pouvoir gérer une instance SQL Server sans forcément voir les données sensibles. Cependant cette phrase est à prendre avec du recul pour éviter des erreurs d’interprétations.

Lire la suite (en anglais)

Bonne lecture !

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

Tables in-memory, indexes hash et paramétrage du nombre de buckets

Mis en avant

Je n’ai jamais posté quelque chose sur les tables in-memory depuis que SQL Server 2014 est sortie en preview. C’est chose faite et je l’ai réalisé en anglais sur le blog de ma nouvelle société (dbi services). Pour les francophones pas de souci, la lecture se fait bien et dans notre métier il est presque devenu normal de pouvoir lire de l’anglais technique :-)  A l’avenir vous trouverez mes billets de blog soit sur dbi services  soit ici en fonction du contexte et de mes envies mais il y aura toujours un lien vers les billets de blog dbi services depuis mon blog personnel.

Vous trouverez donc mon premier sur les tables Hekaton à cette adresse : http://www.dbi-services.com/index.php/blog/entry/sql-server-2014-hekaton-memory-optimized-tables-hash-indexes-and-bucket-counts

Bonne lecture !

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server AlwaysOn : Considérations sur l’ajout d’un fichier de bases de données

Mis en avant

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 :

 

image

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 :

image 

Côté groupe de disponibilité voici ce que nous avons :

image

 

Ajoutons maintenant un fichier supplémentaire …

image

et voilà le résultat côté groupe de disponibilité :

image

… et côté instance :

image

 

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 :

image

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 :

image

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 :

image

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 :

image

et en ajoutant à nouveau la base de données au groupe de disponibilité pour le réplica concerné

image

… ainsi de suite pour les autres réplicas et le tour est joué :

image

… avec une répartition qui respecte la convention en vigueur :

image

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

SQL Server 2014 : AlwaysOn, chiffrement TDE et chiffrement des sauvegardes

Mis en avant

SQL Server 2014 commence à pointer le bout de son nez avec la CTP2. Cette nouvelle version va apporter pas mal de nouveautés côté moteur notamment la plus attendue Hekaton mais d’autres seront également de la partie comme une amélioration continue de la haute disponibilité avec SQL Server AlwaysOn, la sécurité avec le chiffrement des sauvegardes ou encore la limitation des actions possibles pour un administrateur de bases de données, les index columstore index pouvant être mis à jour et bien d’autres. Dans ce billet j’ai choisi de parler de SQL Server AlwaysOn et du chiffrement des bases de données et des sauvegardes. Un premier billet sur la possibilité de chiffrer les sauvegardes avec SQL14 a déjà par Christophe Laporte. Je vous invite à le lire si vous voulez en savoir un peu plus sur cette fonctionnalité.

En testant SQL Server 2014, AlwaysOn et le chiffrement certaines questions me sont venus à l’esprit.  Ces questions sont les suivantes :

  • Est-ce qu’une table Hekaton (In memory) est chiffrée si la base de données qui l’héberge utilise TDE ?
  • Est-ce qu’il est possible d’implémenter TDE avec une base de données déjà membre d’un groupe de disponibilité ?
  • Quel avantage à avoir du chiffrement de sauvegardes de bases de données si celles-ci le sont déjà avec TDE ?

 

icon_arrow Est-ce qu’une table Hekaton (In memory) est chiffrée si la base de données qui l’héberge utilise TDE ?

Tout dépend ici de quoi l’on parle. Une table Hekaton réside en mémoire mais selon sa durabilité les données la concernant peuvent être stockées sur disque. TDE chiffre les données sur disque et pas en mémoire. Un processus de chiffrement et déchiffrement opère en temps réel sur les fichiers de données et journaux de transactions (cf la BOL) . Donc ici on peut se demander si le chiffrement s’effectue pour les tables Hekaton durables car celles-ci utilisent des fichiers de données et des fichiers delta afin de pouvoir remonter les données en cas de problème.

 

alwayson_tde_0

Activons maintenant TDE sur la base de données AdventureWorks2012.

alwayson_tde_01

… et là SQL Server nous donne rapidement la réponse attendue :

alwayson_tde_03

Les tables Hekaton durables en réalité reposent sur un stockage de type filestream. On peut le voir sur l’image ci-dessous :

alwayson_tde_04

Un coup d’œil sur la documentation en ligne de SQL Server à propos de TDE nous permet de confirmer que le chiffrement n’est pas valable pour ce type de conteneur. Cela est également confirmé par ce lien pour SQL14. –> TDE n’est donc pas supporté avec l’utilisation des tables Hekaton.

 

icon_arrow  Est-ce qu’il est possible d’implémenter TDE avec une base de données déjà membre d’un groupe de disponibilité ?

Nous avons implémenté une belle architecture AlwaysOn et une des bases de données d’un groupe de disponibilité requiert maintenant d’être chiffré pour des raisons de sécurité. Comment dois je procéder dans ce cas ? Est-ce qu’il suffit d’activer TDE sur la base de données située sur le réplica primaire ? Dois-je effectuer des manipulations sur les secondaires ? Dois-je repartir de zéro en supprimant cette base de données du groupe de disponibilité, chiffrer la base de données et refaire tout le processus d’ajout à un groupe de disponibilité (backup, restauration sur les secondaires et ajout au groupe de disponibilité) ?

Soyons un peu feignant et partons du principe que tout est à faire depuis le réplica primaire et que tout sera répliqué par la suite par AlwaysOn .. après tout ca sert à cela la réplication non ? :-) . Précédemment nous avons implémenté TDE sur la base de données AdventureWorks2012 qui faisait parti d’un groupe de disponibilité lst_adv. On pourrait conclure que tout est fini mais si l’on jette un rapide coup d’œil à l’état de synchronisation de notre groupe de disponibilité on s’aperçoit vite qu’un problème est survenu suite à la mise en place de TDE et que la base de données Adventureworks2012 est même dans un état suspect sur les serveurs secondaires sur SSMS.

alwayson_tde_1

 

Parfait … on active TDE et on se retrouve avec une base de données suspecte !! Bravo TDE !! :-) Ne paniquons pas et regardons un peu plus loin dans les logs d’erreurs SQL on peut voir ceci :

alwayson_tde_2

La cause du problème est la suivante : après avoir chiffré notre base de données sur le réplica primaire, les réplicas secondaires ne trouvent pas le certificat dont l’emprunte correspond à celle utilisé par le certificat créé initialement pour le chiffrement TDE. Dans ce cas la réplication du flux de données du réplica primaire vers réplicas secondaires est donc naturellement suspendue. Ce comportement est tout à fait normal puisque nous essayons de répliquer une base de données chiffrée vers une base de données qui ne peut pas être chiffrée. Ce fameux certificat est hébergé dans la base de données master et n’est pas répliqué automatiquement par AlwaysOn contrairement à la clé de chiffrement de bases de données située dans la base de données AdventureWorks2012. Il ne nous reste plus qu’à sauvegarder ce certificat, le restaurer sur les réplicas secondaires et relancer la réplication des données pour AdventureWorks2012 :

alwayson_tde_05

Après quelques secondes ou minutes (en fonction de la quantité de données à répliquer car l’état de synchronisation est suspendue) on peut voir sur le dashbord du groupe de disponibilité lst_adv que tout est rentré dans l’ordre :

alwayson_tde_3 

Pour résumé, il est possible d’implémenter TDE sur une topologie AlwaysOn existante à condition de bien penser à restaurer le certificat servant au chiffrement de la clé de chiffrement de la base de données pour TDE. Le mode feignant est donc à proscrire :-)

 

icon_arrow Quel avantage à avoir du chiffrement de sauvegardes de bases de données si celles-ci le sont déjà avec TDE ?

La documentation en ligne concernant TDE explique qu’une sauvegarde provenant d’une base chiffrée par TDE est également chiffrée par le même certificat de serveur. Quel intérêt à chiffrer de nouveau le média de backup par la nouvelle fonctionnalité de chiffrement proposée avec SQL Server 14 si celle-ci est déjà initialement chiffrée par TDE ? Je me suis posé la question en pensant qu’une fois qu’une base était chiffrée par TDE, le chiffrement des sauvegardes n’avaient aucun effet. Mais je me trompais bien sûr : le chiffrement des sauvegardes avec SQL14 agit indépendamment de TDE et chiffrera une seconde fois le média de sauvegarde. Cela nous permet d’ajouter une protection supplémentaire au média de sauvegarde à savoir que chaque chiffrement peut utiliser un algorithme différent. Voyons comment cela se passe.

On commence donc par créer un certificat dédié aux chiffrement des sauvegardes dans la base de données master :

image

On effectue une sauvegarde de notre base de données AdventureWorks2012 avec le nouveau mot clé ENCRYTION pour la commande BACKUP :

image

On a maintenant un média de sauvegarde doublement chiffré. Si maintenant on tente de lire le contenu de ce média depuis une nouvelle instance SQL on se retrouve avec le message d’erreur suivant :

alwayson_tde_6

La lecture de l’entête du média de sauvegarde est impossible si le serveur SQL ne possède pas un certain certificat avec l’emprunte décrite ci-dessus. Par déduction, on peut aussi affirmer que la restauration ne sera pas impossible pour le moment.

Restaurons le certificat utilisé pour le chiffrement des sauvegardes dans la base de données master de la nouvelle instance SQL et essayons à nouveau de lire le contenu du média de sauvegarde :

alwayson_tde_7

Cela ne fonctionne toujours pas … on peut remarquer que l’emprunte du certificat manquant est différent cette fois. Il correspond en réalité à celle du certificat créé initialement pour activer TDE sur AdventureWorks2012. Après avoir restauré ce certificat il est possible de lire le contenu du média de sauvegarde et donc de restaurer notre base de données :

alwayson_tde_4 

Pour un nouveau réplica AlwaysOn, il faudra donc bien penser à restaurer tous les certificats nécessaires à la restauration d’une base de données avant de la joindre au groupe de disponibilité concerné.

Bon chiffrement !!

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Server FCI et AlwaysOn et configuration quorum … de Windows 2008 à Windows 2012 R2

Mis en avant

Après quelques missions d’architecture sur l’implémentation d’architectures AlwaysOn chez divers clients il est temps de faire un point sur les possibilités de configuration du quorum du cluster Windows. En effet, pour rappel SQL Server AlwaysOn ou SQL Server FCI  se basent tous les 2 sur une couche Windows Failover Cluster Service (WFCS). Par conséquent le bon fonctionnement des groupes de disponibilités AlwaysOn ou des instances en cluster SQL reposent en quelque sorte sur celui du cluster Windows. Lorsqu’on parle de cluster Windows on arrive très vite à parler de quorum. La notion même de quorum n’est d’ailleurs pas uniquement associée au cluster. On peut la retrouver également lorsqu’on parle d’architecture en miroir avec SQL Server en mode synchrone et basculement automatique. Le but de ce billet est simplement de parcourir un peu les différentes possibilités de configuration du quorum avec WFSC à partir de 2008 R2 et de faire un focus sur les dernières innovations proposées par Windows Server 2012 et Windows Server 2012 R2.

 

icon_arrow Windows Server 2008 R2

Au fur et à mesure des versions Microsoft a fait évoluer ses modèles de quorum dans un processus continue d’amélioration de disponibilité du cluster Windows dans des scénarios de plus en plus divers. Par exemple on est passé de 2 modèles de quorum avec Windows 2003 à 4  à partir de Windows 2008. Windows 2008 a plus tard introduit la notion de paramétrage des poids de vote (avec l’application du KB2494036) qui peut s’avérer très utile dans des scénarios de type  “géo-cluster”. Cependant si le paramétrage du poids de vote se révèle très utile dans certains cas il n’en reste pas moins que celui-ci reste statique. En fonction de la situation c’est à l’administrateur de cluster de changer la configuration des poids de vote afin de garantir le quorum lors de la défaillances de nœuds.

L’image suivante montre 3 scénarios pour une architecture cluster Windows et pourquoi la nature statique du paramétrage du poids de vote peut poser problème :

 

quorum_1

 

Dans cette architecture le nœud 4 est sur un site distant. Comme nous ne voulons pas que ce nœud influence le vote du quorum en cas de coupure réseau entre les 2 sites nous pouvons lui supprimer la possibilité de voter dans l’établissement du quorum.

Scénario 1 :

Dans ce scénario il nous reste donc 3  nœuds qui peuvent voter (node 1, node 2 et node 3). Dans ce cas nous avons la possibilité d’utiliser le modèle de quorum “nœuds majoritaire” parce que le nombre de nœuds est impair ici. Dans cette configuration nous pouvons perdre jusqu’à 2 nœuds : le nœud 4 qui n’influence pas le vote du quorum via notre configuration et un des nœuds restants. Dans le cas où le nœud 4 aurait un vote nous ne pourrions perdre qu’un seul nœud.

Scénario 2 :

Dans ce scénario nous perdons le nœud 2 suite à une défaillance matérielle. Dans ce cas le cluster reste en ligne puisqu’il faut au minimum 2 nœuds pour effectuer le quorum. Cependant la perte d’un autre nœud risque à ce moment de compromettre la disponibilité du cluster. Dans ce cas l’administrateur du cluster Windows a 2 plusieurs possibilités :

  • Changer le quorum en ajoutant un témoin pour augmenter le nombre de votes possibles afin d’avoir la majorité en cas de défaillance d’un nœud
  • changer le nombre de votes possible à 1 seul nœud et en cas de défaillance du nœud 1 le cluster resterait en ligne (Dans notre exemple le nœud 3 perd sa possibilité de voter lors du quorum).

Scénario 3 :

Le nœud 2 a été réparé et est à nouveau opérationnel. Il faut de nouveau changer la configuration de poids de vote des nœuds pour augmenter la disponibilité du cluster en cas défaillance. En effet le vote étant ciblé uniquement sur un seul nœud, il devient le SPOF de cette topologie haute disponibilité. L’administrateur du cluster doit à nouveau activer le vote pour les nœuds 2 et 3 afin de garder en ligne le cluster Windows.

Pour résumer, le but du jeu ici est de jouer avec le poids de votes des nœuds tout en gardant à l’esprit qu’il faut garder plus 50% des votes pour garder le quorum en ligne !!

 

icon_arrow Windows Server 2012

Windows Server 2012 a changé la donne et a introduit le concept de quorum dynamique. Cette nouvelle fonctionnalité est intéressante car elle permet au cluster de recalculer à la volée le nombre de votes nécessaires pour que le cluster reste au maximum disponible. Ainsi il est possible d’avoir un cluster en ligne avec moins de 50% des nœuds restants.  A noter qu’il est toujours possible d’exclure des nœuds dans le vote du quorum avec un recalcul automatique qui ne tiendra compte uniquement que des nœuds restants.

En reprenant les scénarios décrits précédemment :

Scénario 1 :

quorum_2

On peut voir qu’il existe une nouvelle propriété appelée DynamicWeight. Le nœud 4 ne dispose pas de poids de vote (NodeWeight = 0) et par conséquent celui-ci ne sera pas pris en compte dans le calcul dynamique du quorum (dynamicweight=0) contrairement aux autres nœuds (NodeWeight et Dynamicweight = 1).

Scénario 2 :

quorum_3

On voit ici que le nœud 2 a subit une défaillance (State = Down) et que le calcul dynamique du quorum a été effectué par le cluster Windows. Par conséquent seul le nœud 3 possède un poids de vote ce qui permettra de garder en ligne le cluster en cas de défaillance d’un autre nœud de la topologie (nœud 1 ou 3).

quorum_4

L’arrêt du nœud 3 a déclenché à nouveau le recalcul du quorum par le cluster Windows. Ce dernier a transféré le poids de vote au seul nœud restant en ligne (nœud 1).

quorum_5

Les nœuds 2 et 3 ont été remis en ligne et à nouveau le cluster Windows a recalculé le poids de vote des nœuds pour le quorum.

Même si cette fonctionnalité présente des avantages certains, elle n’est cependant pas parfaite. En effet pour que le quorum se recalcule correctement, il faut que la défaillance des nœuds soit séquentielle dans le temps et que le recalcul du quorum ait eu le temps de s’effectuer. De plus l’introduction d’une ressource témoin avec Windows Server 2012 reste inchangé par rapport à Windows Server 2008 R2 à savoir que le témoin possède un poids de vote statique dans tous les cas ce qui diminue paradoxalement la disponibilité du cluster dans certains cas. Modifions notre architecture en y ajoutant un nœud supplémentaire de la façon suivante :

 

quorum_6

L’ajout d’un nœud pose ici un problème quant à l’établissement du quorum en cas de défaillance d’un des nœuds autre que nœud 5. Celui-ci comme dans l’architecture précédente n’est pas pris en compte dans le vote du quorum, ce qui laisse un nombre pair de nœuds qui peuvent voter. Dans cette configuration et sans quorum dynamique la défaillance de 2 nœuds ferait tomber à coup sûr l’ensemble du cluster Windows. En d’autres termes, la défaillance d’un seul nœud est supportée dans cette configuration. L’ajout d’une ressource témoin permet de pallier ce problème en ajoutant un vote supplémentaire afin d’augmenter le nombre de nœuds qui peuvent être défaillants à 2. Cependant avec l’utilisation du quorum dynamique, le recalcul se fera en tenant compte uniquement les nœuds du cluster restants en ligne. Le nombre de vote final sera donc composé de celui des nœuds restants + celui de la ressource témoin. Que se passera-t-il au moment où il restera un seul nœud en ligne et si l’on perd notre ressource témoin ? Malheureusement le quorum ne pourra être établi car il faudrait avoir au minimum 2 votes.

 

quorum_7

 

Ci-dessous un extrait de ce que l’on peut retrouver dans les logs du cluster Windows dans le cas où l’on perd une ressource témoin et par la suite le dernier nœud permettant au cluster Windows de rester en ligne.

Ici la ressource témoin est un dossier partagé qui n’est plus accessible ([RES] File Share Witness … Failed to create / Failed to validate etc …). Cependant le cluster peut encore rester en ligne puisque 2 nœuds sont encore présents pour faire le quorum (2 votes sur 3).

quorum_10

Cependant si l’on perd le dernier nœud (ici SQL122) comme montré ci-dessous …

quorum_11

… le début des problèmes commence puisque le cluster, malgré l’utilisation du quorum dynamique, se base encore sur le vote de la ressource témoin comme montré ci-dessous (File Share Witness is quorum and we’re one off quorum …). En effet à ce moment il n’existe plus qu’un seul vote sur 3 pour réaliser le quorum ce qui n’est plus suffisant. Après quelques secondes le cluster Windows

quorum_8

quorum_9

 

icon_arrow Windows Server 2012 R2

C’est ici que Windows Server 2012 R2 va avoir toute son utilité avec l’utilisation du témoin dynamique. Cette fonctionnalité permet de pallier au problème que nous venons de voir précédemment. Le vote du témoin est maintenant lui aussi dynamique et le cluster Windows recalcule le nombre de votes en fonction de la situation en tenant compte de ce nouvel élément.

L’image suivante montre la même situation que précédemment avec une topologie SQL Server 2014 décrite-dessus avec 5 nœuds dont un qui n’aura pas de vote pendant l’établissement du quorum. Au final nous avons 4 nœuds avec un poids de vote à 1.

image

On a également une ressource témoin de type FileShareWitness mais avec une nouvelle propriété WitnessDynamicWeight reflétant le caractère dynamique de la ressource témoin.

quorum_13

quorum_14

Que se passe-t-il si l’on perd la ressource témoin ?

quorum_15

On peut voir que la répartition des votes octroyés aux nœuds du cluster a changé dynamiquement. Premièrement le système a supprimé le vote de la ressource témoin et il a ensuite recalculé les votes de chaque nœud en supprimant celui octroyé au nœud 2 (SQL142). Cette nouvelle configuration prend en compte le fait que le nombre de nœuds restants pouvant voter est devenu pair et qu’il faut supprimer un vote à un des nœuds pour que celui-ci devienne impair.

quorum_16

En arrêtant successivement les nœuds 2 et 4 le quorum est de nouveau recalculé comme avec Windows 2012. Le nœud 3 est le seul à posséder un poids de vote car il possède le groupe de ressource système (nom réseau + IP du cluster Windows). Cela permet également en cas de défaillance du nœud 1 (ou éventuellement du nœud 3) de garder le cluster Windows en ligne

 

quorum_17

 

L’utilisation du témoin dynamique est également intéressante dans des configurations géo-clusters où le nombre de nœuds sur chaque site est équivalent. Prenons par exemple la configuration suivante :

quorum_18

Le cluster Windows possède 4 nœuds répartis par pair sur chaque site. Tous les nœuds du cluster peuvent voter et comme nous sommes dans une configuration où le nombre de nœuds par site est pair une ressource témoin a été ajouté sur le 1er site pour augmenter la disponibilité du cluster en cas de défaillance du lien réseau inter-sites. En effet sans cette ressource témoin, si une défaillance survenait sur ce lien réseau  nous pourrions être dans un cas de “split brain” avec l’apparition d’un partitionnement du cluster Windows en 2 parties. De plus le nombre de votes dans ce cas ne suffirait plus puisque la perte d’un seul nœud ne serait plus acceptable. Avec l’introduction du témoin nous éliminons du coup ce phénomène de “split brain” et nous augmentons en même temps le nombre global  de nœuds qui pouvant être défaillants soit 2 nœuds. Cependant la perte de cette ressource témoin en mode statique nous ramènerait au problème décrit un peu plus haut dans le billet . L’utilisation du témoin dynamique plus une nouvelle fonctionnalité de Windows Server 2012 R2 appelée “tie breaker” permet de garder le nombre de noeuds restants pouvant voter impair. C’est ce que nous pouvons voir ici après la perte du témoin :

quorum_19

Cependant si ce recalcul dynamique est bénéfique ici il serait intéressant aussi de pouvoir contrôler quels nœuds auront la priorité sur les autres pendant le recalcul. Dans notre cas nous voudrions par exemple garder un maximum de disponibilité sur le site A et donc donner la priorité aux serveurs correspondants. Heureusement pour nous il est possible de configurer des priorités par nœud avec la propriété de cluster  LowerQuorumPriorityNodeID.

quorum_20

quorum_21

On voit ici que l’assignement des poids de vote a changé en fonction de notre paramétrage.

image

Maintenant si nous perdons totalement le site 2 nous pourrons garantir que le cluster Windows sera encore en ligne.

Bonne configuration de quorum !!

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

Cas d’utilisation d’un groupe de disponibilité multi-listeners

Mis en avant

Pour ceux qui ont déjà installé SQL Server AlwaysOn vous avez pu sans doute remarquer qu’il est possible d’avoir uniquement un seul listener pour un groupe de disponibilité. Sur le principe cela n’est pas gênant dans la plupart des configurations mais comment dans le cas où un client cherche absolument à décomissionner un serveur SQL avec une multitude d’application et qu’il est difficile de changer le nom de serveur dans la chaîne de connexion de ces applications.

Prenons un cas concret que j’ai pu rencontrer chez un client lors d’une migration et qui aurait pu poser problème lors du passage à une architecture haute disponibilité SQL Server AlwaysOn :

  • Plusieurs applications installées sur une centaine de postes clients depuis longtemps et qui ne sont plus supportées par les différents éditeurs La chaîne de connexion des applications est codée en dur (pas de chance …) et l’intervention des différents consultants peut coûter cher d’autant plus que ces derniers proposent de mettre à jour l’application pour résoudre le problème. hors le client n’a pas forcément le budget pour cela car il n’a pas pu anticiper ce problème … bref le changement du nom de serveur pour cette application n’est pas envisageable et pourtant il nous faut migrer les bases de données pour décomissionner au plus vite notre ancien serveur SQL vers une infrastructure AlwaysOn

Quelles solutions avons-nous à disposition ?

–> Nous pouvons créer un listener avec l’ancien nom du serveur SQL et son ancienne adresse IP mais deux problèmes se posent :

  • le but est à l’origine est de pouvoir décomissionner l’ancien nom de serveur qui n’est plus conforme à la nouvelle nomenclature générale de nommage et doit être absolument changé dès que possible.
  • le planning de migration nous impose de migrer les applications en douceur et nous impose de garder de migrer les applications facilement modifiables au départ et garder les applications statiques pour la fin. Cette option n’est donc pas envisageable.

–> Nous pouvons utiliser un alias CNAME avec l’ancien nom de serveur qui pointe vers le nouveau listener. Cela suppose que notre ancien serveur soit complètement décomissionné pour pouvoir utiliser notre nouveau listener mais notre planning de migration nous impose encore une fois de garder l’ancien serveur pendant la phase de migration jusqu’à la fin. 

Dans ce cas cas comment faire ? He bien une solution (parmi quelques autres) serait de créer un second listener pour notre groupe de disponibilité. Comment ? En fait l’astuce consiste à passer par le gestionnaire de cluster et de créer un nouveau point d’accès client (Client Access Point) pour le rôle associé au groupe de disponibilité concerné avec un nom réseau et une adresse IP :

aag_new_cllient_access_point

aag_new_cllient_access_point_2

Une fois la ressource associé au nouveau point d’accès client créé il suffit de le mettre en ligne et de configurer les dépendances associées au groupe de disponibilité. L’utilisation d’une logique de dépendance à base de AND est possible mais il est préférable d’utiliser une logique de dépendance à base de OR pour garder le groupe de disponibilité en ligne autant que possible.

aag_new_cllient_access_point_3

Une fois le tout configuré on peut avoir apparaître un nouveau listener dans SQL Server Management Studio.

aag_new_cllient_access_point_4

L’utilisation de la vue système sys.availability_group_listeners nous montre également que le groupe aag possède bien 2 listeners :

image

La colonne is_conformant indique que le listener peut être managé depuis SQL Server. On voit également que pour le moment le listener n’est pas encore exploitable car aucun port d’écoute est configuré. Puisque le listener est configurable depuis SQL Server nous pouvons changer facilement son port depuis SQL Server Management Studio.

image

image

Un test de connexion et le tout fonctionne !!

image 

 

Merci à Qiang Wang pour l’astruce

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

Journées SQL Server 2013 c’est parti

Mis en avant

Les journées SQL Server 2013 auront lieu le 2 et 3 décembre 2013 au centre des conférences Microsoft à Issy-les-Moulineaux. L’agenda des sessions est disponible ici : http://guss.pro/2013/11/03/agenda-des-journees-sql-server-2013/

 

agenda

 

Comme d’habitude cet événement sera divisé en plusieurs catégories (en couleur) en fonction de vos envies et de vos intérêts. Cette année j’aurai l’opportunité de présenter et de co-animer plusieurs sessions :

 

Remercions une nouvelle fois le GUSS et les sponsors sans qui cet événement ne serait pas possible

Au plaisir de partager avec vous ce moment !

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

Microsoft Certified Master SQL Server 2008 — je suis

Mis en avant

Je profite d’un moment d’absence pour recommencer à écrire sur mon blog dédié à SQL Server. Cela fait un moment que je n’écris plus de billets mais il y avait une bonne raison à cela : la préparation de la certification MCM SQL Server 2008. Et cela a été payant puisque depuis peu je suis officiellement MCM SQL Server 2008 :-)

Je profite de ce billet pour partager rapide mon expérience sur l’obtention de cette certification qui se termine malheureusement bientôt. Bien que cette certification soit vouée à disparaître j’ai quand même voulu relever ce challenge. Pour ma part je suis arrivé tard sur ce programme par manque de temps. Avant de pouvoir la passer j’ai pris au sérieux la préparation de cette certification car l’une de ses grosses difficultés est l’étendue des domaines de connaissances qu’il faut pouvoir maîtriser et comme on peut s’en douter ceux-ci sont nombreux : administration, performance, sécurité, haute disponibilité, développement etc.. La préparation de cette certification m’a pris beaucoup de temps. Je ne saurais dire au total mais je sais que j’y ai sacrifié quelques soirées mais au bénéfice pour moi de revoir certains domaines dans lesquels je n’étais plus forcément familier (je pense que peu de personnes aujourd’hui travaillent simultanément sur tous les domaines sur lesquels on peut travailler avec SQL Server)  et d’approfondir certains. Ce fut l’occasion également d’acquérir encore plus de connaissance. 

Après avoir passé les 2 examens requis (théorique et lab) pour cette certification, je peux maintenant affirmer que le simple bachotage ne suffit pas et heureusement dira-t-on. Ces examens requièrent  une réelle expérience sur l’utilisation de SQL Server et apporte une réelle valeur ajoutée sur le marché. Pour les personnes ayant un certain niveau d’expérience c’est également une bonne occasion de faire le point pour aller plus loin. Je rejoins ainsi le groupe restreint des MCM avec un coup d’oeil particulier à certains MCM français que je connais comme Christophe Laporte ou encore Christian Robert.

MCM_2013(rgb)_1262

Il est maintenant temps de revenir plus activement sur la partie communautaire SQL Server et ceci pour très bientôt !!

 

David BARBARIN (Mikedavem)
MVP et MCM SQL Server

SQL Saturdays 2013 à Paris : les slides

Mis en avant

Comme promis voici les slides de ma session sur les événements étendus. Malheureusement je n’ai pas pu effectuer toutes les démonstrations que je voulais .. eh oui il faut bien commencer par expliquer comment fonctionne les événements étendus et cela m’a pris un peu plus de temps que prévu :-) . Mais ce n’est que partie remise, je garde cette partie pour une session uniquement orientée démonstration. J’espère pouvoir vous la présenter rapidement.

Merci aux personnes qui ont voulu assister à ma présentation et de assister de manière générale à ce premier SQL Saturdays  Paris. Ce fut un bon moment d’échange et de rencontres !

David BARBARIN (Mikedavem)
MVP SQL Server

Analyse des problèmes de basculement survenus sur une infrastructure SQL Server 2012 AlwaysOn

Mis en avant

Récemment j’ai eu à débugger un problème client survenu sur une infrastructure haute disponibilité SQL Server 2012 AlwaysOn. Le problème était le suivant : les connexions sur le réplica primaire ont subitement  cessé vers 12:25 et il n’était plus possible de s’y connecter. Le client, dans la précipitation, a visiblement essayer de basculer le groupe de disponibilité sur le réplica secondaire mais visiblement sans succès. Le but de mon intervention était d’expliquer à mon client pourquoi il n’était plus possible de se connecter aux réplicas et pourquoi le basculement n’a pas eu l’effet escompté. 

Par où commencer ? Analyser un problème sur une infrastructure AlwaysOn n’est pas une mince affaire en réalité. SQL Server 2012 AlwaysOn fonctionne sur une première couche basique de cluster à basculement au niveau du système d’exploitation et une couche applicative au niveau SQL Server. Lorsqu’un problème survient cela peut donc se produire sur l’une des 2 couches voir sur les 2 couches simultanément.

 

Les connexions se sont arrêtées subitement

Commençons dans l’ordre des problèmes. Dans le cas présent les connexions s’effectuent directement en utilisant le listener du groupe de disponibilité concerné. Cela peut vouloir dire que le problème se situe à ce niveau mais aussi au niveau de l’instance SQL Server. Pour cela nous avons à disposition :

  • les logs Windows ou du cluster à basculement Windows
  • les logs SQL Server
  • Les fichiers de diagnostics fournis par la procédure stockée sp_server_diagnostics

 

D’autres outils peuvent nous aider comme les sessions d’événements étendus AlwaysOn mais dans notre cas nous n’en aurons pas forcément besoin. J’essayerai d’effectuer un billet sur le sujet. Revenons à notre sujet : les logs Windows nous révèlent ceci :

billet_alwayson_diag_1

 

On voit ici une série d’erreur à partir de 12:20 relatives au cluster Windows à basculement :

  • Event ID 1562 : Cette erreur décrit un problème au niveau du témoin fichier partagé utilisé dans la configuration AlwaysOn qui nous concerné (2 nœuds + 1 FSW). Le partage servant comme élément de vote pour le quorum n’est plus accessible pour une raison non connue
  • Event ID 1069 : Cette erreur indique simplement qu’il existe un problème au niveau du groupe de ressource "Cluster Group". Dans notre cas cette erreur est provoquée par le partage qui n’est plus accessible.
  • Event ID 1564 : Cette erreur nous informe que le partage de fichier ne pourra pas jouer son rôle d’arbitrage en cas de défaillance d’un des nœuds de la topologie. En effet dans notre configuration le FSW n’étant plus disponible la perte d’un nœud de cluster supplémentaire serait fatale car la majorité ne pourrait pas être atteinte et le quorum ne pourrait pas être formé.

A ce stade on peut simplement conclure que le partage de fichier utilisé en tant que vote pour le quorum n’est plus accessible.

 

On retrouve également des erreurs de type NETLOGON qui nous en dit plus sur la nature de notre problème :

  • Event ID 5783 : Cette erreur indique qu’un problème de connexion aux serveurs DNS ou aux contrôleurs de domaine est survenu. Un redémarrage des serveurs ? Un problème de connexion de réseau entre le réplica primaire et les serveurs DNS ou DC ? Des serveurs ne pouvant plus répondre à cause d’un engorgement des demandes ? Une intervention sur l’infrastructure virtuelle sous-jacente ? Difficile à dire à ce stade … Ce qui est certain est que la résolution de nom ne pouvait pas s’effectuer correctement vers le partage de fichier dans ce cas, ce qui peut expliquer que le FSW n’était plus disponible à ce moment là

 

billet_alwayson_diag_13

 

L’analyse des logs SQL nous dévoilent ceci :

billet_alwayson_diag_2

 

Des informations intéressantes ici qui confirment bel et bien qu’un problème d’infrastructure a bien eu lieu avec une liaison à un contrôleur de domaine défaillante (No authority could be contacted for authentication).

L’erreur Windows nous spécifie la même chose :

billet_alwayson_diag_14

 

Une autre voix d’investigation est possible. Avec SQL Server 2012 AlwaysOn, la ressource DLL SQL Server utilisée par le cluster Windows à basculement exécute une procédure stockée sp_server_diagnostics pour déterminer l’état de santé du réplica primaire utilisé dans une topologie AlwaysOn. Des informations détaillées sont envoyés périodiquement au travers de cette ressource et permet au cluster Windows d’initier un basculement en fonction de ces informations et des règles de basculement associées. Toutes ces informations de diagnostics produites par la procédure stockée sp_server_diagnostics sont enregistrées par défaut dans des fichiers SQLDIAG exploitables directement par la fonction sys.fn_xe_file_target_read_file() ou directement dans SQL Server Management Studio.

SELECT
 xml_data.VALUE('(event/@name)[1]','varchar(max)') AS 'Name',
 xml_data.VALUE('(event/@package)[1]','varchar(max)') AS 'Package',
  xml_data.VALUE('(event/data[@name=''node_name'']/value)[1]','varchar(max)') AS 'Node_Name',
 xml_data.VALUE('(event/data[@name=''instance_name'']/value)[1]','varchar(max)') AS 'Instance_Name',
 xml_data.VALUE('(event/@timestamp)[1]','datetime') AS 'Time',
 xml_data.VALUE('(event/data[@name=''state'']/value)[1]','int') AS 'State',
 xml_data.VALUE('(event/data[@name=''state_desc'']/value)[1]','varchar(max)') AS 'State Description',
 xml_data.VALUE('(event/data[@name=''failure_condition_level'']/value)[1]','int') AS 'Failure Conditions',
 xml_data.VALUE('(event/data[@name=''creation_time'']/value)[1]','datetime') AS 'Creation Time',
 xml_data.VALUE('(event/data[@name=''component'']/value)[1]','varchar(max)') AS 'Component',
 xml_data.VALUE('(event/data[@name=''data'']/value)[1]','varchar(max)') AS 'Data',
 xml_data.VALUE('(event/data[@name=''info'']/value)[1]','varchar(max)') AS 'Info',
 xml_data
FROM (
SELECT
 object_name AS 'event'  ,
 CONVERT(xml,event_data) AS 'xml_data'  
 FROM sys.fn_xe_file_target_read_file('C:\customer_alwayson_issue\primary_replica\*.xel',NULL,NULL,NULL)
) AS XEventData
WHERE  xml_data.VALUE('(event/data[@name=''creation_time'']/value)[1]','datetime') > '20130723 12:15:00'
ORDER BY TIME;

 

billet_alwayson_diag_3

 

On remarque ici 2 choses. La procédure stockée sp_server_diagnostics stipule que le groupe de disponibilité qui nous concerne n’a visiblement pas de problème (premières flèches en rouge) . Les informations fournies ensuite par cette procédure stockée sont classés en catégorie (composants système, ressources, sous système disque, exécution des requêtes et autre évènements utiles notamment extraites des différents ring buffers SQL Server).

Concernant le composant de groupe de disponibilité :

billet_alwayson_diag_4

 

Concernant le composant Events :

billet_alwayson_diag_5

billet_alwayson_diag_6

 

On retrouve ici des informations du ring buffer "security error" dans lequel sont enregistrés les erreurs d’authentification. Celui-ci qui nous indique une erreur survenue lors de l’authentification via les api utilisés par SQL Server et d’autres informations que l’on retrouve dans les journaux d’erreurs Windows. Dans mon cas on retrouve une multitude d’enregistrements de ce genre dans ce ring buffer.

Pour résumer, nous avons donc ici l’origine du problème de connexion : un contrôleur de domaine ou un serveur DNS non joignable qui empêche les authentifications sur le réplica primaire. Passons maintenant à notre problème de basculement qui n’a visiblement pas fonctionné. Après investigation, c’est le processus de basculement manuel qui n’a pas fonctionné via l’interface GUI. En effet l’interface demande une authentification vers le réplica cible avant d’effectuer la bascule et comme le processus d’authentification ne fonctionnait pas avec des comptes de domaine il était alors impossible à ce moment là de basculer. Le serveur SQL a donc été redémarré. On peut le confirmer ici en regardant les informations contenues dans les journaux SQL Server que le service a été arrêté suite à une demande du gestionnaire de service.

 

billet_alwayson_diag_7

 

… Le gestionnaire de réplica démarre, attend que le service de cluster démarre correctement et démarre le réplica local. On voit que l’état du réplica passe de NOT_AVAILABLE à RESOLVING_NORMAL

 

billet_alwayson_diag_12

 

…On voit ici que le réplica local pour le groupe de disponibilité qui nous concerne se prépare à redevenir réplica primaire. L’état du réplica passe donc de RESOLVING_NORMAL à PRIMARY_PENDING

 

billet_alwayson_diag_8

… L’écoute démarre sur le listener associé au groupe de disponibilité  et le réplica passe à son état final PRIMARY_NORMAL.

 

billet_alwayson_diag_9

… Le réplica a bien redémarré mais on voit qu’il existe toujours des problèmes de connexion sur le réplica primaire à cause d’un problème de connexion à une autorité d’authentification (le fameux contrôleur de domaine).

 

billet_alwayson_diag_10

 

Pourquoi le groupe de disponibilité n’a-t-il pas pu basculer vers notre réplica secondaire ? Les règles de basculement étaient pourtant bien paramétré avec un niveau de condition par défaut (3). Les logs du cluster Windows sur le réplica secondaire nous donne la réponse :

billet_alwayson_diag_11

 

L’event id 1254 correspond à un nombre de basculement qui a dépassé le seuil autorisé pour un groupe de ressource. Dans notre cas le groupe de ressource correspond bien à notre groupe de disponibilité. Le basculement de ce dernier était donc impossible ici. C’est la raison pour laquelle le groupe de disponibilité a redémarré sur le réplica 1 après son redémarrage manuel.  La boucle est donc bouclée !!

 

Bonne investigation !

 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Saturday à Paris 2013 le 14 septembre 2013 – Rappel

Mis en avant

Il est temps de dévoiler un peu le contenu de la session que je présenterai au cours des SQL Saturdays et de faire par la même occasion une piqure de rappel Sourire

Je pense que le titre de la session est assez parlante : SQL Trace vs Extended Events … Les évènements étendues sont devenus avec SQL Server 2012 un outil de diagnostic extrêmement puissant mais pourtant je pourrais parier que la majorité des développeurs ou des DBA utilisent encore le profiler de SQL Serve car ce dernier reste encore très pratique à utiliser. Pourtant les possibilités du profiler sont loin d’égaler celles offertes par les évènements étendues et ce c’est que je tenterai de montrer lors de cette session.

Les sessions sont les évènements étendues ne sont pas nouvelles. David Baffaleuf ou encore Nicolas Souquet en ont parlé avant moi et le but ne sera pas de faire doublon avec leur excellent travail. La grande majorité de la session sera donc dédiée à une présentation concrète de cas pratique où les évènements étendues auront un grand intérêt !

En espérant vous voir nombreux Sourire

N’oublions les autres sessions très intéressantes présentées par Christophe Laporte avec IO Fusion ou encore celle présentée par Hugo Kornelis sur les index columstore pour la partie DBA … que du bonheur !

 

SQLSAT251_web_thumb1

 

David BARBARIN (Mikedavem)
MVP SQL Server

Détecter un basculement automatique avec SQL Server 2012 AlwaysOn

Mis en avant

Après avoir installé une infrastructure SQL Server 2012 AlwaysOn, il peut être intéressant d’être alerté lorsqu’un groupe de disponibilité basculement automatiquement d’un réplica à un autre pour une raison quelconque. Alors que pour les architectures en mirrroring nous avons built-in tout ce qu’il faut avec DATABASE_MIRRORING_STATE_CHANGE et des états en sortie qui nous permettent de savoir si un basculement manuel ou automatique a été effectué, c’est une autre paire de manche avec les infrastructures AlwaysOn. La documentation en ligne nous propose différentes outils comme  System Center, SQL Server Management Studio, les compteurs de performances ou encore Transact-SQL. Je rajouterai également PowerShell qui peut nous aider ici ou encore les outils tiers qui viendront compléter cette liste.

Voici une solution parmi d’autres. Pour ma part j’ai opté pour :

  • Une routine continue en T-SQL qui va chercher les changements d’états survenus sur les groupes de disponibilités présents sur un serveur sql. Si un changement est détecté un email est envoyé via databasemail aux personnes concernées
  • Un job SQL qui démarre et s’exécute lorsque le service de l’agent SQL Server démarre ou redémarre. Ce service est déjà monitoré par des outils tiers et si un problème survient au niveau de l’agent SQL l’information sera de toute façon remontée

 

icon_arrow Le code de la routine à intégrer

DECLARE @t_aag TABLE
(
  group_name SYSNAME NOT NULL,
  primary_replica VARCHAR(128) NOT NULL,
  primary_recovery_health NVARCHAR(80) NULL
);

DECLARE @t_aag_result TABLE
(
  [action] VARCHAR(50) NOT NULL,
  group_name SYSNAME NOT NULL,
  primary_replica_old VARCHAR(128) NULL,
  primary_replica_new VARCHAR(128) NOT NULL,
  primary_recovery_health NVARCHAR(80) NULL
);

 WHILE 1 = 1
BEGIN

  WITH aag
  AS
  (
     SELECT
      g.name AS group_name,
      primary_replica,
      primary_recovery_health_desc
     FROM sys.dm_hadr_availability_group_states AS ags
      JOIN sys.availability_groups AS g
       ON ags.group_id = g.group_id
  )
  MERGE @t_aag AS t_aag
  USING aag
   ON aag.group_name = t_aag.group_name
  WHEN matched AND aag.primary_replica != t_aag.primary_replica
   THEN UPDATE SET primary_replica = aag.primary_replica,
                   primary_recovery_health = aag.primary_recovery_health_desc
  WHEN NOT MATCHED BY TARGET
   THEN INSERT VALUES (aag.group_name, aag.primary_replica, aag.primary_recovery_health_desc)
  WHEN NOT MATCHED BY SOURCE
   THEN DELETE
  OUTPUT $action, inserted.group_name, deleted.primary_replica, inserted.primary_replica, inserted.primary_recovery_health
  INTO @t_aag_result;

  -- insert only when changes on existing data
  INSERT INTO [dbo].[dba_alwayson_failover_logs] (group_name, primary_replica_old, primary_replica_new, primary_recovery_health)
  SELECT
   group_name,
   primary_replica_old,
   primary_replica_new,
   primary_recovery_health
  FROM @t_aag_result
  WHERE [action] = 'update';

  -- Reset work table
  DELETE FROM @t_aag_result;

  -- Send email if failover is detected
  EXEC dbo.dba_alwayson_mail;

  WAITFOR DELAY '00:00:10';
END

 

Le script fonctionne de manière suivante :

  • 2 tables de travail @t_aag et @t_aag_result qui vont respectivement contenir la configuration des groupes de disponibilités présents sur le serveur SQL et le delta éventuel dans une configuration existante (action = update) qui impliquerait un basculement dans notre cas
  • Une boucle continue de détection de basculement avec une temporisation de 10 secondes
  • 1 table [dbo].[dba_alwayson_failover_logs] qui contiendra une ligne de données pour chaque  basculement de groupes de disponibilité détecté. Une procédure stockée dbo.dba.alwayson_mail se servira ensuite de cette table d’historique pour l’envoi des emails.
  • Une instruction MERGE utilisée ici pour mettre à jour en continue la configuration des groupes de disponibilités sur le serveur SQL concerné (les ajouts, les mises à jour et les suppressions de groupes de disponibilités) avec insertion d’une ligne de données en cas de mise à jour du réplica primaire pour un groupe de disponibilité (when matched and aag.primary_replica <> t_aag.primary_replica)

 

icon_arrow Le code de la table d’historique

CREATE TABLE [dbo].[dba_alwayson_failover_logs](
     [event_time] [datetime] NOT NULL DEFAULT GETDATE(),
     [group_name] [sysname] NOT NULL,
     [primary_replica_old] [VARCHAR](128) NULL,
     [primary_replica_new] [VARCHAR](128) NOT NULL,
     [primary_recovery_health] [nvarchar](80) NULL,
     [sent_by_email] [bit] NULL
) ON [PRIMARY]

 

Je ne mets pas ici volontairement le code la procédure d’envoi d’email car elle est plutôt spécifique à notre environnement de script. La logique est assez simple et consiste simplement à :

  • 1- parcourir la table d’historique [dbo].[dba_alwayson_failover_logs] et vérifier les lignes de données non traitées par la routine d’envoi d’email.
  • 2- Mettre à jour la valeur de colonne sent_by_email à 1 une fois l’email envoyé.

 

Et vous comment faites-vous ?

Bonne détection de basculement !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Gérer les erreurs générées par la commande DBCC CHECKDB dans un script T-SQL

Mis en avant

La vérification d’intégrité des bases de données s’effectue par la commande DBCC CHECKDB. Le résultat de cette commande est assez verbeuse par défaut et peut poser problème lorsque la vérification d’intégrité est  utilisé dans des scripts T-SQL personnalisés de maintenance par exemple.

 

Posons un peu le contexte et le pourquoi de ce billet. En réalité j’ai eu l’occasion de travailler (comme beaucoup je pense) sur la création de plans de maintenance "custom". L’idée a été de construire un jeu de script permettant de pouvoir gérer l’ensemble des tâches que l’on peut avoir à utiliser pour la maintenance des bases de données. Une de ces tâches concerne la vérification d’intégrité des bases. Cette vérification se fait à l’aide de la commande bien connue DBCC CHECKDB. Dans notre contexte l’idée est de pouvoir exécuter une tâche de maintenance et d’enregistrer dans une table de log les données suivantes :

  • Nom de la tâche
  • Nom de la base concernée
  • Durée de la tâche
  • Statut de la tâche (OK ou en échec)
  • Envoi par mail des tâches en échec à posteriori avec le détail de l’erreur

Ceci nous permet d’avoir une traçabilité des tâches de maintenance par la suite et pouvoir les consommer à des fins d’analyse.

Lorsque l’on scripte une vérification d’intégrité à l’aide de la commande DBCC CHECKDB on s’aperçoit rapidement que la gestion des erreurs liées à cette commande n’est pas triviale. C’est que nous verrons dans le cadre de ce billet.

 

icon_arrow Une sortie verbeuse

Voici la sortie d’une commande DBCC CHECKDB sur une base de données corrompue :

DBCC CHECKDB ('DemoCorruptMetadata')

DBCC results for ‘DemoCorruptMetadata’.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=1) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=2) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
DBCC results for ‘sys.sysrscols’.
There are 872 rows in 9 pages for object "sys.sysrscols".
DBCC results for ‘sys.sysrowsets’.
There are 124 rows in 1 pages for object "sys.sysrowsets".
DBCC results for ‘sys.sysclones’.
There are 0 rows in 0 pages for object "sys.sysclones".
DBCC results for ‘sys.sysallocunits’.
There are 138 rows in 2 pages for object "sys.sysallocunits".
DBCC results for ‘sys.sysfiles1′.
There are 2 rows in 1 pages for object "sys.sysfiles1".
DBCC results for ‘sys.sysseobjvalues’.
There are 0 rows in 0 pages for object "sys.sysseobjvalues".
DBCC results for ‘sys.syspriorities’.
There are 0 rows in 0 pages for object "sys.syspriorities".
DBCC results for ‘sys.sysdbfrag’.
There are 0 rows in 0 pages for object "sys.sysdbfrag".
DBCC results for ‘sys.sysfgfrag’.
There are 0 rows in 1 pages for object "sys.sysfgfrag".
DBCC results for ‘sys.sysdbfiles’.
There are 2 rows in 1 pages for object "sys.sysdbfiles".
DBCC results for ‘sys.syspru’.
There are 0 rows in 0 pages for object "sys.syspru".
DBCC results for ‘sys.sysbrickfiles’.
There are 0 rows in 0 pages for object "sys.sysbrickfiles".
DBCC results for ‘sys.sysphfg’.
There are 1 rows in 1 pages for object "sys.sysphfg".
DBCC results for ‘sys.sysprufiles’.
There are 2 rows in 1 pages for object "sys.sysprufiles".
DBCC results for ‘sys.sysftinds’.
There are 0 rows in 0 pages for object "sys.sysftinds".
DBCC results for ‘sys.sysowners’.
There are 14 rows in 1 pages for object "sys.sysowners".
DBCC results for ‘sys.sysdbreg’.
There are 0 rows in 0 pages for object "sys.sysdbreg".
DBCC results for ‘sys.sysprivs’.
There are 136 rows in 1 pages for object "sys.sysprivs".
DBCC results for ‘sys.sysschobjs’.
There are 2180 rows in 29 pages for object "sys.sysschobjs".
DBCC results for ‘sys.syscolpars’.
There are 698 rows in 11 pages for object "sys.syscolpars".
DBCC results for ‘sys.sysxlgns’.
There are 0 rows in 0 pages for object "sys.sysxlgns".
DBCC results for ‘sys.sysxsrvs’.
There are 0 rows in 0 pages for object "sys.sysxsrvs".
DBCC results for ‘sys.sysnsobjs’.
There are 1 rows in 1 pages for object "sys.sysnsobjs".
DBCC results for ‘sys.sysusermsgs’.
There are 0 rows in 0 pages for object "sys.sysusermsgs".
DBCC results for ‘sys.syscerts’.
There are 0 rows in 0 pages for object "sys.syscerts".
DBCC results for ‘sys.sysrmtlgns’.
There are 0 rows in 0 pages for object "sys.sysrmtlgns".
DBCC results for ‘sys.syslnklgns’.
There are 0 rows in 0 pages for object "sys.syslnklgns".
DBCC results for ‘sys.sysxprops’.
There are 0 rows in 0 pages for object "sys.sysxprops".
DBCC results for ‘sys.sysscalartypes’.
There are 34 rows in 1 pages for object "sys.sysscalartypes".
DBCC results for ‘sys.systypedsubobjs’.
There are 0 rows in 0 pages for object "sys.systypedsubobjs".
DBCC results for ‘sys.sysidxstats’.
There are 130 rows in 1 pages for object "sys.sysidxstats".
DBCC results for ‘sys.sysiscols’.
There are 317 rows in 3 pages for object "sys.sysiscols".
DBCC results for ‘sys.sysendpts’.
There are 0 rows in 0 pages for object "sys.sysendpts".
DBCC results for ‘sys.syswebmethods’.
There are 0 rows in 0 pages for object "sys.syswebmethods".
DBCC results for ‘sys.sysbinobjs’.
There are 23 rows in 1 pages for object "sys.sysbinobjs".
DBCC results for ‘sys.sysaudacts’.
There are 0 rows in 0 pages for object "sys.sysaudacts".
DBCC results for ‘sys.sysobjvalues’.
There are 134 rows in 13 pages for object "sys.sysobjvalues".
DBCC results for ‘sys.syscscolsegments’.
There are 0 rows in 0 pages for object "sys.syscscolsegments".
DBCC results for ‘sys.syscsdictionaries’.
There are 0 rows in 0 pages for object "sys.syscsdictionaries".
DBCC results for ‘sys.sysclsobjs’.
There are 16 rows in 1 pages for object "sys.sysclsobjs".
DBCC results for ‘sys.sysrowsetrefs’.
There are 0 rows in 0 pages for object "sys.sysrowsetrefs".
DBCC results for ‘sys.sysremsvcbinds’.
There are 0 rows in 0 pages for object "sys.sysremsvcbinds".
DBCC results for ‘sys.sysxmitqueue’.
There are 0 rows in 0 pages for object "sys.sysxmitqueue".
DBCC results for ‘sys.sysrts’.
There are 1 rows in 1 pages for object "sys.sysrts".
DBCC results for ‘sys.sysconvgroup’.
There are 0 rows in 0 pages for object "sys.sysconvgroup".
DBCC results for ‘sys.sysdesend’.
There are 0 rows in 0 pages for object "sys.sysdesend".
DBCC results for ‘sys.sysdercv’.
There are 0 rows in 0 pages for object "sys.sysdercv".
DBCC results for ‘sys.syssingleobjrefs’.
There are 156 rows in 1 pages for object "sys.syssingleobjrefs".
DBCC results for ‘sys.sysmultiobjrefs’.
There are 107 rows in 1 pages for object "sys.sysmultiobjrefs".
DBCC results for ‘sys.sysguidrefs’.
There are 0 rows in 0 pages for object "sys.sysguidrefs".
DBCC results for ‘sys.sysfoqueues’.
There are 0 rows in 0 pages for object "sys.sysfoqueues".
DBCC results for ‘sys.syschildinsts’.
There are 0 rows in 0 pages for object "sys.syschildinsts".
DBCC results for ‘sys.syscompfragments’.
There are 0 rows in 0 pages for object "sys.syscompfragments".
DBCC results for ‘sys.sysftsemanticsdb’.
There are 0 rows in 0 pages for object "sys.sysftsemanticsdb".
DBCC results for ‘sys.sysftstops’.
There are 0 rows in 0 pages for object "sys.sysftstops".
DBCC results for ‘sys.sysftproperties’.
There are 0 rows in 0 pages for object "sys.sysftproperties".
DBCC results for ‘sys.sysxmitbody’.
There are 0 rows in 0 pages for object "sys.sysxmitbody".
DBCC results for ‘sys.sysfos’.
There are 0 rows in 0 pages for object "sys.sysfos".
DBCC results for ‘sys.sysqnames’.
There are 100 rows in 1 pages for object "sys.sysqnames".
DBCC results for ‘sys.sysxmlcomponent’.
There are 100 rows in 1 pages for object "sys.sysxmlcomponent".
DBCC results for ‘sys.sysxmlfacet’.
There are 112 rows in 1 pages for object "sys.sysxmlfacet".
DBCC results for ‘sys.sysxmlplacement’.
There are 19 rows in 1 pages for object "sys.sysxmlplacement".
DBCC results for ‘sys.sysobjkeycrypts’.
There are 0 rows in 0 pages for object "sys.sysobjkeycrypts".
DBCC results for ‘sys.sysasymkeys’.
There are 0 rows in 0 pages for object "sys.sysasymkeys".
DBCC results for ‘sys.syssqlguides’.
There are 0 rows in 0 pages for object "sys.syssqlguides".
DBCC results for ‘sys.sysbinsubobjs’.
There are 3 rows in 1 pages for object "sys.sysbinsubobjs".
DBCC results for ‘sys.syssoftobjrefs’.
There are 0 rows in 0 pages for object "sys.syssoftobjrefs".
DBCC results for ‘sys.queue_messages_1993058136′.
There are 0 rows in 0 pages for object "sys.queue_messages_1993058136".
DBCC results for ‘sys.queue_messages_2025058250′.
There are 0 rows in 0 pages for object "sys.queue_messages_2025058250".
DBCC results for ‘sys.queue_messages_2057058364′.
There are 0 rows in 0 pages for object "sys.queue_messages_2057058364".
DBCC results for ‘sys.filestream_tombstone_2089058478′.
There are 0 rows in 0 pages for object "sys.filestream_tombstone_2089058478".
DBCC results for ‘sys.syscommittab’.
There are 0 rows in 0 pages for object "sys.syscommittab".
DBCC results for ‘sys.filetable_updates_2121058592′.
There are 0 rows in 0 pages for object "sys.filetable_updates_2121058592".
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘DemoCorruptMetadata’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

 

On se rend vite compte que la quantité d’information qui nous intéresse ici reste négligeable par rapport à la quantité totale d’information produite en sortie par notre commande. Ici la commande DBCC CHECKDB a produit 162 lignes d’information alors que  moins de 10 lignes nous intéresse ici. Heureusement pour nous, nous pouvons jouer avec les options NO_INFOMSGS et ALL_ERRORMSGS pour limiter le nombre d’informations produites par DBCC CHECKDB. Pour rappel NO_INFOMSGS permet d’éliminer les messages d’information produites en sortie et ALL_ERRORMSGS permet d’afficher toutes les erreurs rencontrées lors d’une opération de vérification de bases de données. Par défaut seulement les 1000 premiers messages d’erreur sont affichés depuis SQL Server Management Studio.

 

icon_arrow Utilisation des options NO_INFOMSGS, ALL_ERRORMSGS

DBCC CHECKDB ('DemoCorruptMetadata') WITH NO_INFOMSGS, ALL_ERRORMSGS

 

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=1) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=2) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘DemoCorruptMetadata’.

 

On a ici bien réduit le nombre de lignes produites par notre commande DBCC CHECKDB avec l’affichage du détail des erreurs rencontrées et 2 messages d’information qui ne sont ni plus ni moins qu’un récapitulatif de ces erreurs.

 

icon_arrow Gestion de la sortie de la commande DBCC CHECKDB dans un script T-SQL

Après avoir limité le nombre d’information utiles comment nous en servir pour construire une logique de maintenance par script ? L’idée ici est simplement de pouvoir détecter un problème d’intégrité et de prévenir les personnes concernées (notamment l’équipe DBA) qu’un problème est survenu à ce moment là

A priori 2 voies d’exploitation évidentes peuvent être prises en compte :

  • On peut utiliser la variable @@ERROR et vérifier que celle-ci soit différente de 0
  • On peut utiliser les blocs de gestions d’erreur TRY CATCH

 

Avec la variable @@ERROR :

dbcc checkdb('DemoCorruptMetadata') WITH no_infomsgs, all_errormsgs;
IF @@ERROR  <>0    
BEGIN    
 print '';    
 print '--> error during dbcc checkdb';    
END

 

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=1) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row (object_id=1977058079,column_id=2) in sys.columns does not have a matching row (object_id=1977058079) in sys.objects.
CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘DemoCorruptMetadata’.
 
–> error during dbcc checkdb

 

La variable @@ERROR nous permet effectivement de pouvoir détecter les erreurs engendrées par la commande DBCC CHECKDB. Il suffit ensuite de coder la logique de maintenance qui nous intéresse. Cependant si on utilise notre script T-SQL dans un job SQL Server, les erreurs produites impliqueront une étape de job en échec. La question est donc de savoir ce résultat est attendu ou non ? Effectivement ce n’est pas parce qu’une commande DBCC CHECKDB produit une erreur qu’un job SQL Server doit forcément partir en échec. En réalité tout dépendra de la logique d’exécution globale concernée par ce script. On peut tout à fait traiter l’erreur de job et effectuer une surveillance sur l’état de ce job par envoi d’alerte ou via des outils tiers par exemple. On peut aussi vouloir enregistrer l’erreur sans que le job parte en échec, avec l’exécution d’étapes supplémentaires sans pour autant avoir une logique d’exécution complexe du style "si étape 1 échec –> aller à l’étape 3 sinon aller à l’étape 2 etc … A mon humble avis les jobs SQL Server ne sont pas vraiment désignés pour gérer des logiques complexes de workflow . Dans le cadre de notre script nous avons retenu une solution générique et simple : si une tâche génère une erreur alors celle-ci est enregistrée dans une table de log et l’information pourra être envoyé à posteriori par email. Le choix est laissé à l’utilisateur final. 

 

Avec le bloc de gestion d’erreur BEGIN TRY, CATCH :

BEGIN try    
 dbcc checkdb('DemoCorruptMetadata') WITH no_infomsgs, all_errormsgs;    
END try    
BEGIN catch    
 print '--> error during dbcc checkdb';    
END catch

 

CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.
CHECKDB found 0 allocation errors and 2 consistency errors in database ‘DemoCorruptMetadata’.

 

Comme on peut le remarquer le bloc de gestion TRY , CATCH ne va malheureusement pas nous être d’une grande utilité ici car les dernières lignes d’information produites par la commande DBCC CHECKDB empêchent notre bloc de gestion d’erreur de détecter les erreurs produites par notre commande DBCC CHECKDB quelques lignes plus haut.

 

Avons nous une autre alternative dans ce cas ? La réponse est oui. Il est également possible d’enregistrer les erreurs produites lors d’une vérification d’intégrité dans une table SQL en utilisant l’option TABLERESULTS de cette manière :

 

icon_arrow Utilisation de l’option TABLERESULTS

 

DBCC CHECKDB('DemoCorruptMetadata')
WITH NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

 

dbcc_checkdb_tableresults

 

Il suffit ici d’extraire les informations produites dans la table et de gérer sa propre logique de maintenance. Dans mon cas je remplis une variable de table avec le résultat de la commande DBCC CHECKDB et l’option TABLERESULETS et je vérifie qu’au moins une ligne existe pour détecter la présence d’une erreur (la commande DBCC CHECKDB ne produit aucune ligne d’erreur si aucun problème d’intégrité n’est détecté).  L’information est ensuite enregistrée dans une table de log avec le numéro d’erreur et sera envoyé par mail à postériori.

 

L’option TABLERESULTS est-elle là solution miracle ? Malheureusement non car la commande DBCC CHECKDB peut produire certaines erreurs propres à son exécution et qui stopper franchement le script en cours d’exécution. C’est le cas de certaines erreurs sévères rencontrés par la commande DBCC CHECKDB.

 

icon_arrow Gestion des erreurs liées à l’exécution même de la commande DBCC CHECKDB

Voici quelques cas où l’exécution de la commande DBCC CHECKDB provoquera une erreur grave et un arrêt net du script T-SQL en cours d’exécution.

 

- Après avoir corrompu la page PFS (page id = 1)  à l’aide d’un éditeur hexadécimal de ma base DemoCorruptMetada le script SQL se stoppera net avec le message d’erreur suivant :

Msg 0, Level 11, State 0, Line 0
A severe error occured on the current command. The results, if any, should be discarded

 

- De la même manière Après avoir supprimer une ligne dans la table système sys.syscolpars en redémarrant l’instance SQL Server en mode mono utilisateur et se connectant en mode administrateur dédié la commande DBCC CHECKDB génère le message suivant :

 

Msg 0, Level 20, State 0, Line 0
A severe error occured on the current command. The results, if any, should be discarded

 

Pour une description des niveaux d’erreurs voir la documentation en ligne SQL Server (section "Understanding DBCC errors messages"). Dans ce cas il faudra effectivement gérer l’erreur de manière différente. Dans mon cas au début de chaque tâche une ligne est enregistrée dans une table de log. Si le script T-SQL est arrêté a date de fin de la tâche ne sera pas renseigné. Un email est envoyé pour les cas suivants :

  • Le statut de la tâche est égale à false
  • Le statut de la tâche est inconnu ou la date de fin d’une tâche n’est pas renseignée

 

Bonne gestion d’erreur !!

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Saturday à Paris 2013 le 14 septembre 2013

Mis en avant

C’est fait les SQL Saturdays arrivent en France ! Cet évènement se déroulera le samedi 14 septembre 2013 entre 10H et 17H à Paris au sein du campus des écoles informatiques bien connus EPITA et EPITECH. Celui-ci sera axé de 3 pôles spécifiques :

  • Business Intelligence
  • Administration de bases de données
  • Etudiant

 

SQLSAT251_web_thumb1

 

Cet évènement aura la particularité d’accueillir des speakers anglophones tels que Jen Stirrup, Allan Mitchell ou Hugo Kornelis (donc préparer votre anglais) mais aussi et en grande majorité des speakers français comme Jean-Pierre Riehl, Christophe Laporte, Phillipe Geiger, Patrick Guimonet et d’autres . Je vous laisse découvrir leurs noms sur le site dédié à l’évènement. Pour le planning c’est par ici.

J’aurai l’opportunité de lancer les hostilités pour le track pour DBA avec une session sur les traces SQL vs les évènements étendus. Ce sera également l’occasion de pouvoir partager nos différentes expériences entre jeunes et moins jeunes Sourire

A noter que cet évènement a été à l’initiative du GUSS

 

guss

 

Rien de tel pour préparer sa rentrée Sourire 

 

David BARBARIN (Mikedavem)
MVP SQL Server

Considération sur les listeners associées aux groupes de disponibilités avec SQL Server 2012 AlwaysOn

Mis en avant

Lorsqu’on crée un groupe de disponibilité avec SQL Server et AlwaysOn on l’associe par la suite à un listener. Lorsque ce dernier est créé plusieurs objets lui sont associées :

  • Un objet d’ordinateur dans l’annuaire active directory
  • Une entrée DNS de type A
  • Une ressource cluster associée à au groupe de ressource créé et qui représente le groupe de disponibilité

 

Dans l’exemple suivante un groupe de disponibilité nommé AdventureWorks2 a été créé. Le listener associé s’appelle LST_ADVW2

 

alwayson_aag_lst

 

icon_arrow Les différents objets associés

 

L’objet d’ordinateur dans l’annuaire :

alwayson_ad_object

 

… l’enregistrement DNS :

alwayson_dns_record

 

… Le groupe de ressource lié au groupe de disponibilité :

alwayson_cluster_resource

 

… et les ressources qui le composent :

alwayson_cluster_resource2

 

Jetons un coup d’œil aux dépendances existantes entre les ressources du groupe de ressource AdventureWorksGrp2 :

alwayson_cluster_dependencies

 

Ici on vient bien les dépendances existantes : le groupe de disponibilité AdventureWorksGrp2 dépend de la ressource "nom réseau" qui représente notre listener (LST_ADVW2) qui elle même dépend de la ressource "Adresse IP" qui vous l’aurez devinez, correspond à l’adresse IP de notre listener.

 

icon_arrow Port d’écoute du listener

Est-ce qu’un listener doit écouter sur le même port que les réplicas du groupe disponibilité ?  Est-ce possible ? C’est une question qui s’est posé rapidement dans mon cas lorsqu’il a fallu installer des réplicas n’écoutant pas sur le port qui n’écoutaient pas sur le port par défaut (1433). On peut même aller à l’extrême et prendre le cas où chaque réplica écoute sur un port différent. Dans ce cas quel port dois-je paramétrer pour mon listener ? Un listener peut tout à fait écouter sur un port différent que les réplicas. Le choix du numéro de port dépend évidement de vos besoins, contraintes de sécurité etc …  Prenons un exemple avec 2 réplicas qui écoutent sur 2 ports différents (1499 et 1500) et un listener qui écoute sur le port 1433.

 

[AlwaysOn Instance]

Cette configuration fonctionne parfaitement. Par curiosité on peut voir ce que cela donne sur une trace réseau via NetMon par exemple.

alwayson_netmon0

On peut voir ici une connexion depuis SQL Server Management Studio vers le listener lst_advw.insentia.lab (IP virtuelle : 192.168.0.61)

 

Dans notre cas le listener écoute sur le port 1433 et la connexion est automatiquement redirigée vers le réplica concerné en toute transparence. Au niveau de la chaine de connexion l’impact est minime : le nom du listener remplace tout simple le nom de l’instance SQL Server. Cependant que se passe-t-il maintenant si nous changeons le port d’écoute du listener vers un port non standard ? En réalité les choses se compliquent un peu et il existe plusieurs cas :

  • On spécifie le numéro de port directement dans la chaine de connexion
  • On a la possibilité d’utiliser le format suivant : [nom listener]\[nom instance] sous certaines conditions :
    • On utilise des instances nommées qui portent le même nom pour l’ensemble des réplicas
    • Le service SQL Browser est démarré et opérationnel sur l’ensemble des réplicas pour effectuer la résolution de nom de l’instance vers le numéro de port adéquat.

icon_arrow Cas de la redirection vers un réplica secondaire en lecture seule

AlwaysOn nous fournit la possibilité d’être redirigé vers un réplica secondaire en lecture seule en se connectant via le listener à condition que les règles de redirection  aient été définies (routes et priorités). Dans ce cas une trace NetMon nous révèle la chose suivante :

alwayson_netmon1

 

On peut constater ici qu’après la phase d’authentification la connexion de SQL Server Management Studio initialement effectuée vers le listener lst_advw.insentia.lab (port 1433) est redirigé vers le réplica secondaire en lecture seule REPLICA2 (port 1498)

 

icon_arrow Kerberos, SPN et redirection vers un réplica secondaire en lecture seule

La documentation en ligne Microsoft stipule que pour utiliser Kerberos dans une architecture AlwaysOn il faut ajouter les SPN correspondants à nos listeners. Cependant je n’ai pas trouvé dans la documentation le cas où le listener effectuait une redirection d’une connexion en lecture seule vers un réplica secondaire en lecture seule. Dans ce cas ajouter les SPN pour les listeners ne suffit pas et l’on doit également ajouter les réplicas secondaires en lecture seule.

Voici une trace netmon d’une tentative de connexion en erreur à un réplica secondaire avec Kerberos :

alwayson_spn_netmon

 

On peut voir ici 2 requêtes TGS depuis ma station cliente (192.168.0.100) vers mon contrôleur de domaine (192.168.0.1) :

  • TGS request vers le service MSSQLSvc/lst_advw.insentia.lab (port 1433) : listener
  • TGS request vers le service MSSQLSvc/replica2.insentia.lab (port 1498) : réplica secondaire en lecture seule

Le contrôleur de domaine répond avec une erreur pour la deuxième demande car il n’y a pas de SPN paramétré pour REPLICA2 dans mon cas (KDC_ERR_S_PRINCIPAL_UNKNOW)

 

icon_arrow Listeners vs alias (DNS / SQL) ?

Une question intéressante surtout lorsqu’on a l’habitude de lier le point de connexion des applications via un alias DNS ou SQL par exemple. Ainsi lorsqu’on change de serveur de bases de données avec un nouveau nom, il suffit d’utiliser de modifier l’alias en conséquence. Le changement est donc relativement transparent pour les applications. Avec SQL Server AlwaysOn, lorsqu’un un listener est créé nous avons vu qu’une entrée DNS est également effectuée. De plus on a la possibilité d’associer plusieurs listeners à un seul groupe de disponibilité ce qui peut tout à fait remplacer les alias. Bien entendu chaque méthode présente des avantages mais aussi des inconvénients. Goden Yao (Program Manager , SQL Server Engine High Availability)  a écrit un billet intéressant à ce sujet.

 

Bon paramétrage de listeners !!

 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server 14 : c’est parti enfin presque …

Mis en avant

Pour ceux qui ont suivi un peu l’actualité, Microsoft a annoncé le 6 Avril la sortie de SQL Server 2014 à l’occasion du TechEd North America. Il est vrai que cette annonce peut surprendre d’autant plus que le 02 avril 2012 SQL Server 2012 sortait. Le planning des sorties des versions s’est en effet réduit. Mais qu’est-ce que nous réserve cette nouvelle version (et pas une R2 cette fois)  ?

Parmi les fonctionnalités les plus attendus et les plus prometteuses :

  • Hekaton : le nom de code du moteur de base de données entièrement in-memory avec un contrôle de concurrence multi-version sans mécanisme de verrouillage (locks et latchs).  On pourra également compiler les procédures stockées directement en code machine pour obtenir des gains de performance supplémentaires. Très prometteur !!!
  • L’extension du cache mémoire aux supports non volatiles avec l’utilisation de disques SSD
  • L’utilisation des index columnstores  avec possibilité de mises à jour, ce qui va étendre les scénarios d’utilisations de ces types d’index
  • L’extension du gouverneur de ressources aux IO. On a maintenant le scope complet de gestion des ressources CPU, RAM et IO
  • L’estimation des cardinalités par l’optimiseur de requêtes améliorée
  • Gestion des statistiques des colonnes et index possibles au niveau partition d’une table
  • Amélioration apportée pour SQL Server AlwaysOn (utilisation possible jusqu’à 8 réplicas, plus de downtime pendant les reconstructions d’index en ligne …)
  • Possibilité de scaling des ressources augmentée avec l’utilisation de Windows Server 2012 R2
  • Plateforme Hybrid-Cloud ready
  • ….

 

Pour plus de détails c’est par ici : SQL Server Blog

Vous avez la possibilité de vous inscrire pour l’obtention de SQL Server 2014 en CTP1 !

 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server 2012 AlwaysOn et plans de maintenance par défaut

Mis en avant

Lors de ma session GUSS du 23 avril 2013 à propos de AlwaysOn on m’a demandé si les plans de maintenance SQL Server pouvaient être utilisés dans ce contexte. J’ai répondu négativement à cette réponse sans pour autant être vraiment explicite. Pourtant lorsqu’on créé un plan de maintenance avec SQL Server 2012 et qu’on utilise une tâche de sauvegarde des bases on peut s’apercevoir que si une base de données est concernée par un groupe de disponibilité une option apparait automatiquement "For availability databases, ignore Replica Priority for Backup and Backup on Primary  Settings". L’apparition de cette option implique que par défaut les plans de maintenance SQL Server ou du mois les tâches de sauvegarde sont en théorie capables de s’aligner sur la politique de sauvegarde dictée par le groupe de disponibilité en question mais malgré ce je persiste à dire que les plans de maintenance par défaut ne sont pas adaptés (du moins encore) aux environnements AlwaysOn et c’est ce que je vais tenter d’expliquer dans ce billet.

 

icon_arrow Des tâches de sauvegardes qui gèrent et prennent en compte les préférences de sauvegarde d’un groupe de disponibilité

Commençons par le début. Effectivement les tâches de sauvegardes des plans de maintenance par défaut détectent l’appartenance ou non d’une base de données à un groupe de disponibilité.

J’ai créé une base de données DUMMY faisait parti du groupe de disponibilité

image

 

J’ai paramétré mes préférences de sauvegarde de la manière suivante :

image

 

Dans un plan de maintenance par défaut je glisse une tâche de sauvegarde de type FULL en choisissant la base de données DUMMY …

image

 

… et on s’aperçoit qu’une option supplémentaire apparait

image

 

Cette option permet de ne pas tenir compte des préférences de sauvegarde configurés dans les groupes de disponibilités pour un réplica. Par défaut cette option n’est pas activée et la tâche de sauvegarde prendra en compte les préférences de sauvegardes des groupes de disponibilités (de préférence sur les secondaires, uniquement sur les secondaires, uniquement sur le primaire, sur n’importe quel réplica).

On peut voir que la commande T-SQL générée utilise la fonction sys.fn_hadr_backup_is_preferred_replica() pour la base de données DUMMY

image

 

Notez également que j’ai activé l’option COPY_ONLY pour les sauvegardes. En effet comme ma politique de sauvegarde stipule que les réplicas secondaires seront utilisés en priorité, seules les sauvegardes avec l’option COPY_ONLY fonctionneront si le réplica concerné sera secondaire au moment de la sauvegarde. Mon plan de maintenance fonctionne parfaitement même après test de failover d’un réplica vers un autre. Cependant comme vous le savez certainement un plan de maintenance n’est jamais aussi simple.

Restons sur notre tâche de sauvegarde et ajoutons-y quelques bases de données utilisateurs en mode de récupération FULL et qui ne font pas parti d’un groupe de disponibilité et c’est la que le premier problème arrive. Ma politique de sauvegarde de type full se fait toujours avec l’option COPY_ONLY dans mon cas puisque mes sauvegardes se feront en priorité sur le secondaire et que ceux-ci ne supportent que les sauvegardes avec l’option COPY_ONLY. Le problème est qu’ici la création d’une base de données utilisateur en mode de récupération FULL fera planté la tâche de sauvegarde des journaux de transactions. Pourquoi ? Tout simplement parce qu’une sauvegarde FULL avec l’option COPY_ONLY ne va pas initialiser la séquence des LSN utiles pour nos sauvegardes des journaux de transactions. Alors bien entendu je peux créer 2 plans de maintenance par exemple :

  • Un plan de maintenance qui concernera uniquement les bases de données en mode de récupération FULL associées à un groupe de disponibilité
  • Un plan de maintenance qui concernera les autres bases de données

Il faudra dans ce cas répartir manuellement les bases de données dans les différents plans de maintenance. On perd ici toute notion de gestion dynamique des plans de maintenance selon moi. Si j’ajoute une base de données par exemple, je n’ai pas forcément envie de modifier ensuite mon plan de maintenance … Bien entendu ce raisonnement ici ne tient que pour les cas où les sauvegardes sont déportés sur le secondaire. Si les sauvegardes sont effectuées uniquement sur le primaire, l’utilisation de l’option COPY_ONLY n’a plus lieu d’être.

Une autre chose à noter ici est le manque de support de l’option CHECKSUM qui permet pour rappel d’une part de vérifier le checksum de chaque page de données sauvegardée d’une base de données (si l’option est bien entendu activée au niveau de celle-ci) et de générer un checksum global pour le média de sauvegarde.

 

icon_arrow La tâche de vérification d’intégrité

Vérifier l’intégrité de ses bases de données avant de les sauvegarder est plutôt une opération recommandée. Mais dans une architecture AlwaysOn on peut se poser la question de savoir où est-ce que je dois lancer cette tâche. Si dans d’autres environnements le choix est plutôt évident car les sauvegardes ne peuvent se faire que sur le serveur "principal" , le raisonnement n’est pas tout à fait le même quand on parle de déplacement des sauvegardes sur un réplica secondaire. En effet, vu que ma politique de sauvegarde gère des préférences et des priorités de réplicas pour les sauvegardes ces dernières peuvent être lancés de n’importe où en fonction de la situation présente et des paramètres de configuration. En plus mes bases de données sont accessibles en lecture écriture depuis un réplica primaire et peuvent être inaccessible depuis mes les réplicas secondaires. Il faut également que je vérifie l’intégrité de ma base à ce niveau. Cela fait potentiellement 2 points de vérification d’intégrité des bases sur n réplicas (n pouvant aller jusqu’à 5 pour le moment mais avec SQL14 on pourra monter jusqu’à 8 !).

Si on regarde de plus près la tâche de vérification d’intégrité des plans de maintenance par défaut de SQL Server on s’aperçoit qu’il n’y a aucun paramètre de gestion des groupes de disponibilités :

image

 

Dans ce cas comment puis-je faire pour lancer ma tâche ? On peut prendre le cas extrême qui dit qu’il faut lancer cette tâche de vérification des bases sur tous les réplicas .. et pourquoi pas après tout ?

Je vois déjà 2 problèmes à cela :

  • Même si la vérification d’intégrité initiée par la commande DBCC CHECKDB ne génère pas de verrou par défaut (utilisation des snapshots de bases de données) celle-ci peut avoir un impact négatif sur les performances IO et sur l’augmentation de la REDO queue sur les réplicas secondaires. Une augmentation de cette file d’attente sur les secondaires peuvent avoir un impact sur le RPO et RTO en fonction du type de réplication choisi.
  • On peut tout à fait utiliser un réplica secondaire pour faire des sauvegardes et second réplica secondaire en standby uniquement pour effectuer du failover ou dans une procédure de disaster recovery. Dans ce cas la tâche de vérification d’intégrité des bases des plans de maintenance par défaut SQL Server étant incapable de savoir si la base de données concernée fait parti ou non d’un groupe de disponibilité et si la base de données en question est accessible en lecture seule ou non provoquera une erreur dans le plan de maintenance en fonction de la situation

 

icon_arrow Les tâches de mise à jour des statistiques et des indexes

On a exactement le même problème ici. En regardant les tâches du plan de maintenance associées aux statistiques et aux indexes il n’y a aucun paramètre de configuration lié aux groupes de disponibilité. Dans une architecture AlwaysOn on ne peut mettre à jour les indexes et les statistiques  d’une base que sur le réplica primaire. Je peux également avoir des bases de données qui ne sont pas concernées par un groupe de disponibilité. Dans ce cas il est tout à fait possible qu’un réplica secondaire d’un groupe de disponibilité soit l’instance principale d’une autre base de données. Je peux effectivement créer un plan de maintenance spécifique pour cela et activer / désactiver les jobs SQL Server associées en fonction du cas mais encore une fois cela m’oblige à gérer manuellement les bases de données à répartir dans les plans de maintenance …

De plus dans ce genre d’architecture l’utilisation des tâches par défaut de maintenance des indexes ne sont pas forcément conseillés car elles peuvent être excréments couteuse en écriture journalisée et de bande passante pour la réplication de ces écritures vers les autres réplicas. En effet, et beaucoup d’articles l’expliquent déjà, il n’y a pas la possibilité de définir des seuils de réorganisation ou de reconstruction d’indexes. La politique du tout ou rien ici n’est pas forcément très approprié.

 

Pas besoin d’aller plus loin je pense pour vous dire que les plans de maintenance SQL Server ne sont pas adaptés pour SQL Server 2012 AlwaysOn. Que fais-t-on dans ce cas là ? Pour le moment pour ma part j’ai créé un jeu de script de maintenance des bases de données pour des architectures AlwaysOn installées chez nos clients. Je n’ai pour le moment pas trouvé d’outil tiers permettant de gérer la maintenance des bases de données de A à Z pour ce type d’environnement mais je reste à l’écoute si jamais vous avez plus d’information là dessus Sourire

 

Bonne maintenance de vos architectures AlwaysOn !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Webcast sur SQL Server 2012 AlwaysOn pour les fermes Sharepoint 2013 : les slides et la vidéo sont disponibles

Mis en avant

Un billet en retard pour dire que les slides et la vidéo de la session GUSS que j’ai eu l’occasion d’animer sur SQL Server 2012 AlwaysOn et SharePoint 2013 sont disponibles sur le site du GUSS

>> http://guss.fr/2013/06/01/webcast-guss-avril-2013-les-bases-alwayson/

 

guss

David BARBARIN (Mikedavem)
MVP SQL Server

Créer un serveur lié avec une connexion en lecture seule vers un réplica secondaire SQL Server 2012 AlwaysOn

Mis en avant

Petite question que je me posais aujourd’hui vu qu’en ce moment je travaille souvent sur des environnements haute disponibilité avec SQL Server 2012 et AlwaysOn. Est-il possible de créer un serveur lié qui se connecte sur un réplica secondaire en lecture et profiter du coup d’une redirection transparente en cas de changement de rôle de réplica lors d’un basculement automatique par exemple ?

Le meilleur moyen de le savoir est de faire un test.

Créons tout d’abord un serveur lié en utilisant le provider SQL Server Native Client 11.0 pour pouvoir utiliser le paramètre de connexion applicationintent=readonly. Le script de création du serveur lié est le suivant :

 

EXEC master.dbo.sp_addlinkedserver    
 @server = N'LST_APPLIX',
 @srvproduct=N'',    
 @provider=N'SQLNCLI', -- Provider SQL Native Client    
 @datasrc=N'LST_APPLIX', -- Availability group listener    
 @provstr=N'applicationintent=readonly', -- Readonly intent parameter    
 @catalog=N'ApplixEnterprise' --Target database to connect

 

icon_arrow Mon groupe de disponibilité est composé de 3 réplicas avec :

  • REPLICA1 (réplica primaire)
  • REPLICA2 (réplica secondaire en lecture seule utilisé en priorité)
  • REPLICA3 (réplica secondaire en lecture seule utilisé si REPLICA2 n’est plus joignable)

 

icon_arrow Mon serveur lié est quant à lui configuré sur un serveur standalone à part.

 

La requête suivante illustre l’état de note scénario :

 

SELECT  
 g.name AS group_name,    
 r.replica_server_name,    
 rs.role_desc,    
 rs.operational_state_desc,    
 ro.replica_server_name AS replica_ro_server_name,    
 rol.routing_priority,    
 r.secondary_role_allow_connections_desc    
FROM sys.dm_hadr_availability_replica_states AS rs    
 JOIN sys.availability_groups AS g    
  ON rs.group_id = g.group_id    
 JOIN sys.availability_replicas AS r    
  ON r.replica_id = rs.replica_id    
   AND r.group_id = rs.group_id    
 JOIN sys.availability_read_only_routing_lists rol    
  ON rol.replica_id = r.replica_id    
 JOIN sys.availability_replicas AS ro    
  ON ro.replica_id = rol.read_only_replica_id    
WHERE g.name = 'ApplixGrp'    
 AND r.replica_server_name = 'REPLICA1'

 

image

 

Tentons de retrouver le serveur sur lequel le serveur lié pointe :

SELECT *    
FROM OPENQUERY(LST_APPLIX, 'SELECT @@SERVERNAME AS SERVER_NAME');

qui donne

image

 

Ok visiblement cela fonctionne. En utilisant le listener la requête est automatiquement redirigée vers le REPLICA2 comme le stipule notre configuration.

 

On lance maintenant un basculement manuel de groupe de disponibilité ApplixGrp de REPLICA1 vers REPLICA2. REPLICA2 devient donc le nouveau primaire.REPLICA1 et REPLICA3 deviennent les réplicas secondaires. On exécute à nouveau nos requêtes :

 

SELECT  
 g.name AS group_name,    
 r.replica_server_name,    
 rs.role_desc,    
 rs.operational_state_desc,    
 ro.replica_server_name AS replica_ro_server_name,    
 rol.routing_priority,    
 r.secondary_role_allow_connections_desc    
FROM sys.dm_hadr_availability_replica_states AS rs    
 JOIN sys.availability_groups AS g    
  ON rs.group_id = g.group_id    
 JOIN sys.availability_replicas AS r    
  ON r.replica_id = rs.replica_id    
   AND r.group_id = rs.group_id    
 JOIN sys.availability_read_only_routing_lists rol    
  ON rol.replica_id = r.replica_id    
 JOIN sys.availability_replicas AS ro    
  ON ro.replica_id = rol.read_only_replica_id    
WHERE g.name = 'ApplixGrp'    
 AND r.replica_server_name = 'REPLICA2'

 

image

 

et

SELECT *    
FROM OPENQUERY(LST_APPLIX, 'SELECT @@SERVERNAME AS SERVER_NAME');

qui donne

image

 

Comme on peut le voir l’utilisation d’un serveur lié vers une architecture SQL Server 2012 AlwaysOn avec une redirection des connexions en lecture seule vers les réplicas secondaires fonctionne très bien !

 

Bon paramétrage de serveurs liés

SET TRANSACTION ISOLATION LEVEL READ COMMITTED et NOLOCK = pas de verrous ?

Mis en avant

Chez un de mes clients on est venu me dire la chose suivante : visiblement lorsque j’utilise le hint NOLOCK ou un niveau de transaction READ UNCOMMITED lorsque j’exécute une requête je vois quand même des verrous posés sur mes tables alors que je croyais le contraire et du coup ma requête en lecture doit bloquer les mises à jour … A cela j’ai répondu : la vérité est ailleurs Sourire

Plus sérieusement, la bonne question à se poser est la suivante : est-ce que le fait d’utiliser un hint NOLOCK ou un niveau de transaction permettant la lecture sale veut dire que aucun verrou n’est posé ?

 

Pour répondre prenons un exemple simple avec une requête dans la base de données AdventureWorksDW2012 :

SELECT *  
FROM dbo.FactInternetSales AS f  
CROSS JOIN dbo.FactInternetSales AS f2

 

Voyons les verrous posées par cette requête à l’aide de la DMV sys.dm_tran_locks :

SELECT  
 resource_database_id,    
 resource_type,  
 resource_subtype,    
 request_mode,  
 request_type,    
 request_status,    
 request_owner_type    
FROM sys.dm_tran_locks    
WHERE request_session_id = "session"

 

icon_arrow Avec un niveau d’isolation de transaction en read committed (niveau d’isolation par défaut) :

image

 

icon_arrow  Avec un niveau d’isolation de transaction en read uncommitted :

image

 

On voit d’abord que le niveau d’isolation de transaction en mode read uncommitted ne veut pas dire qu’il n’existe plus de verrou. Le 1er verrou (de type SHARED_TRANSACTION_WORKSPACE) nous intéresse moins ici car c’est un verrou posé lorsqu’il existe une connexion sur une base de données (en l’occurence database_id = 6 ici). Cela permet de protéger la base de données contre les suppressions accidentelles par exemple lorsqu’il existe une connexion sur cette dernière.

Les verrous suivants sont plus intéressants dans notre cas. On voit que la différence notoire est qu’il existe des verrous de type IS et type S dans un cas (read committed) et plus de verrou de ce type dans l’autre cas  (read uncommitted). Le niveau d’isolation de transaction par défaut utilisé par SQL Server garantit une lecture propre des données c’est la raison pour laquelle il existe des verrous de type S et IS à différents niveaux (OBJECT et PAGE) . Avec le niveau d’isolation permettant de la lecture sale ces verrous n’existent évidemment plus mais d’autres verrous existent cependant comme celui que l’on voit dans la dernière image : verrou de type Sch-S. Ce verrou protège la table contre les modifications pendant qu’une lecture est effectuée même si celle-ci n’est pas propre.

 

Faisons le même test avec une table HEAP (sans index cluster) avec la requête suivante :

SELECT *  
FROM dbo.DatabaseLog AS f    
CROSS JOIN dbo.DatabaseLog AS f2

 

… et voyons les verrous posées :

icon_arrow Avec un niveau d’isolation de transaction en read committed (niveau d’isolation par défaut) :

image

 

icon_arrow  Avec un niveau d’isolation de transaction en read uncommitted :

image

 

La aussi on peut voir qu’avec les verrous de type S ne sont plus présents sur les objets de type PAGE ou OBJET avec un niveau d’isolation de transaction en read uncommitted.  On a néanmoins un type de verrou supplémentaire que l’on n’avait pas  avec une table possédant un index cluster à la ligne 2 (resource_type = HOBT et resource_subtype = BULK_OPERATION). Ce type de verrou n’est présent que sur les tables HEAP pour protéger les lectures contre les pages potentiellement mal formatés via des opérations BULK (merci à Paul Randal pour la précision).

 

On vient donc de voir que la lecture sale sur SQL Server engendrait certains types de verrous. Cependant on peut pousser le raisonnement plus loin. Qui dit verrou veut dire aussi latch pour accéder aux structures physiques en mémoire … on peut essayer de voir si une requête avec un niveau d’isolation en read uncommitted produit des latchs. Pour cela on peut utiliser la DMV sys.dm_os_waiting_tasks comme ceci :

-- Création à la volée d'une table temporaire pour les tâches en attente    
SELECT TOP 1 *  
INTO #waiting_tasks    
FROM sys.dm_os_waiting_tasks;    
GO

-- On vide la table avant le test  
TRUNCATE TABLE #waiting_tasks;    
GO

-- Récupération des tâches en attente générées par la requête de test    
WHILE 1 = 1    
BEGIN    
 INSERT #waiting_tasks    
 SELECT *    
 FROM sys.dm_os_waiting_tasks    
 WHERE SESSION = "session"  
END

 

En parallèle la requête suivante est lancée :

SELECT *  
FROM dbo.DatabaseLog AS f  
CROSS JOIN dbo.DatabaseLog AS f2

 

Après avoir lancé une des requêtes avec un niveau d’isolation de transaction en read uncommitted on peut constater que cette dernière a effectivement générée des latchs de type SH dans notre cas :

image

 

On peut regarder à quel objet appartient la page 154 par exemple :

DBCC TRACEON(3604);  
GO    

DBCC PAGE(6, 1, 154) WITH TABLERESULTS;    
GO

 

image

image

 

Pour conclure l’idée que l’utilisation de la lecture sale avec SQL Server ne génère pas de verrous est faussée. Certains les verrous de type S pouvant gêner les écritures sont absents mais  on a pu constater au cours de ce billet que d’autres types de verrous étaient et bien présents ainsi que des latchs pouvant même aboutir à une potentielle contention !!

Bonne utilisation de lecture sale Sourire 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server 2012 : Installation et intégration des mises à jour

Mis en avant

Pour ceux qui ont eu à installer SQL Server 2012, vous avez sans doute remarqué que le processus d’installation incorporait maintenant des mises à jour avant même d’installer SQL Server. Cette petite nouveauté est en réalité très pratique lorsque l’on doit installer des binaires dans une certaine version et que l’on doit installer un service pack ou un cumulative update. On remplace les fameuses installations "slipstream" où l’incorporation d’un service pack dans des binaires d’installation était une opération plutôt laborieuse. De plus il existe 2 méthodes de mise à jour : l’une permet de récupérer les mises à jour via internet et l’autre permet de spécifier un dossier dans lequel il est possible de placer les mises à jour d’installation à incorporer durant l’installation d’une instance SQL Server. Par exemple il est tout à fait possible d’incorporer en même temps le service pack 1 de SQL Server 2012 et le cumulative update 3. Si plusieurs cumulative update sont présent l’installation ne prendra que le dernier en vigueur !

 

icon_arrow J’ai créé ici un dossier nommé SQL2012_SP1_CU3 où j’ai placé les fichiers d’installation du service pack1 de SQL Server 2012 et 2 cumulatives updates : CU1 et CU3

 

sp1_et_cu1_et_cu3

 

icon_arrow Il suffit ensuite d’utiliser les paramètres supplémentaires fournis avec SQL Server 2012 (/UpdateEnabled et /UpdateSource). J’effectue ici une installation en ligne de commande

 

image

 

icon_arrow Lorsque l’installation se lance on peut remarquer que l’installation détecte les mises à jour et ne prend que le service pack 1 et le dernier cumulative update (CU3)

 

install_gui_product_updates

 

Le cumulative update 3 correspond au KB 2812412 :

kb_cu3

 

icon_arrow Une fois l’installation terminée une petite vérification de la version :

 

result_after_install

 

Bonne installation !!

David BARBARIN (Mikedavem)
MVP SQL Server

A propos de l’erreur 33203 : SQL Server audit could not write to the security log

Mis en avant

Lors de la mise en place des audits de sécurité je me suis heurté à cette fameuse erreur 33203 sur une instance nommée qui indique explicitement que SQL Server ne peut pas écrire dan le journal de sécurité Windows.  Ma configuration est la suivante : SQL Server 2012 SP1  et Windows 2012 Server.

Je précise avant de commencer que les prérequis de fonctionnement des audits avec le journal de sécurité Windows sont respectés. La conséquence directe de l’erreur 33203 est qu’au évènement n’est enregistré dans le journal de sécurité Windows, ce qui est plutôt gênant pour des audits. De plus les journaux des erreurs Windows et SQL Server ne sont pas spécialement bavards quant à la cause de cette erreur.

 

image

 

Dans ce cas comment savoir ce qui empêche SQL Server d’écrire dans le journal ? Je dois dire que les outils sysinternals sont bien utiles dans ces moments et en particulier procmon.

Une capture procmon me donne ceci lorsque j’active un objet d’audit depuis SQL Server :

 

image

On peut remarquer ici que SQL Server tente un accès à la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security et que cet accès lui est visiblement refusé. Un message est également inscrit dans le journal des erreurs SQL. Pas de souci, nous allons configurer les permissions adéquates sur cette clé de registre.

 

image

 

Le paramétrage des permissions a visiblement permis à l’instance SQL Server de créer une nouvelle clé de registre dans HKLM\System\CurrentControlSet\Services\EventLog\Security :

image

 

image

 

Me croyant sauvé, j’active mes audits mais je me heurte à une nouvelle erreur. Une nouvelle trace procmon me révèle le problème suivant :

 

image

 

SQL Server tente de lire le fichier C:\Windows\System32\LogFiles\Sum\Api.log mais encore un fois ce dernier se voit refuser l’accès. Le paramétrage en lecture seule du fichier Api.log me permet enfin d’activer mes audits et de valider que les évènements soient bien enregistrés dans le journal de sécurité Windows. Ce deuxième problème visiblement a été remonté chez Microsoft et est toujours d’actualité. A noter que je n’ai eu ce souci que pour mon instance nommé dans mon cas.

 

Quelques remarques supplémentaires :

  • Le fait d’enlever le compte de service SQL des permissions de la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security ne semble plus être gênant à partir du moment où la nouvelle clé a été créé.
  • Il n’est pas possible cependant d’enlever les permissions sur le fichier C:\Windows\System32\LogFiles\Sum\Api.log sous peine d’avoir dans le journal des évènements Windows le type d’erreur suivant et plus d’évènement d’audit enregistré. A voir si le problème sera résolu plus tard par Microsoft (dans un CU4 peut être ?) avec Windows Server 2012. L’ensemble des problèmes répertoriés concerneraient Windows Server 2012.
  • Je ne pense pas que le problème soit lié à la version de SQL Server. Si j’ai le temps je testerai sur une version SQL Server 2008 R2 et mettrait à jour mon blog.

 

image

 

Bonne activation d’audit !! Sourire

 

David BARBARIN (Mikedavem)
MVP SQL Server

Problème d’utilisation de l’option WITH EXECUTE AS dans une procédure stockée avec les serveurs liés

Mis en avant

L’emprunt d’identité peut s’avérer nécessaire lorsque l’on commence à vouloir faire de la sécurité à un niveau granulaire relativement bas. Par exemple la politique de sécurité en vigueur peut nous contraindre à restreindre l’accès aux données via des procédures stockées. Cependant si ces données sont distantes et implique l’implémentation d’un serveur lié pour y avoir accès, cela peut donner matière à plus de réflexion. En effet, dans ce cas il va falloir donner les droits adéquates aux utilisateurs concernés sur le serveur distant pour accéder aux données, ce qui risque pour le coup d’augmenter la surface d’exposition. Un utilisateur A devra pouvoir exécuter une procédure stockée et sélectionner les données sur le serveur distant. L’utilisateur A peut par conséquent passer outre la procédure stockée et se connecter directement au serveur distant pour accéder aux données. Pour éviter cela on peut tout à fait utiliser le mécanisme d’emprunt d’identité dans une procédure stockée à l’aide de WITH EXECUTE AS et associer l’utilisateur dédié à cette tâche à un utilisateur sur le serveur distant. On bénéficie ainsi d’un contrôle d’accès beaucoup fort et maitrisé.

 

Le schéma ci-dessous illustre bien notre problématique :

 

icon_arrow Dans le 1er cas un mapping est nécessaire pour chaque utilisateur qui va vouloir accéder aux données du serveur distant Instance 2, ce qui signifie qu’il devra exister les mêmes logins sur le serveur distant Instance 2. Comme je l’ai évoqué au début cela implique également que les utilisateurs concernés pourront directement accéder aux données du serveur distant avec leurs informations de connexion.

 

image

 

icon_arrow Dans le 2ème cas nous mettons en place un mécanisme d’emprunt d’identité via l’option WITH EXECUTE AS USER dans la procédure stockée. L’idée ici est de n’autoriser que cet utilisateur à avoir accès aux données distantes.

 

image

 

La mise en place d’un tel mécanisme dans le contexte des serveurs liés nécessitent un certain paramétrage :

  • L’activation obligatoire de l’option de bases de données trustworthy. Malheureusement seule cette option est viable lorsqu’il s’agit d’accès inter instances. L’utilisation des certificats dans ce cas ne fonctionne pas.
  • Différer l’exécution de la procédure stockée concernée. Je n’ai pas trouvé d’article Microsoft sur le sujet mais simplement un item connect. C’est ce point que je vais détailler ici.

 

Si l’on utilise directement l’option WITH EXECUTE AS dans une procédure stockée de la manière suivante :

 

CREATE PROCEDURE dbo.GetRemoteData
WITH EXECUTE AS 'USER1'
AS

SELECT col1, col2
FROM [linked_server].[DATABASE].[schema].[TABLE]
GO

 

… avec l’appel suivant …

 

EXEC dbo.GetRemoteData

 

… il y a de grandes chances que cela ne fonctionne pas surtout si l’on a définit le contexte d’authentification de serveur lié suivant :

 

image

 

Dans ce cas seul le mapping défini pour l’utilisateur USER1 fonctionnera et aucun autre login ou aucun autre type d’authentification ne fonctionnera.

 

Si maintenant j’exécute ou je crée la procédure stockée dbo.GetRemoteData dans le contexte d’un utilisateur différent de l’utilisateur USER1 ayant les droits de création et d’exécution je peux me retrouver avec le message suivant :

 

image

 

Pourtant me direz-vous que nous avons bien défini l’emprunt d’identité dans la procédure stockée et qu’ici visiblement SQL Server n’est pas capable de trouver le mapping défini dans les options de sécurité du serveur lié. En réalité il faut bien comprendre ce qui se passe lorsqu’une procédure stockée est compilée et lorsque celle-ci est exécutée (run-time context). SQL Server compile une procédure stockée avec les credentials de l’appelant de la procédure et non ceux de l’utilisateur associée à l’emprunt d’identité. C’est pendant l’exécution de la procédure que le mécanisme d’emprunt d’identité jouera tout son rôle. Lorsqu’on accède aux données aux travers d’un serveur lié la compilation va générer l’erreur 7416 si l’appelant de la procédure n’a pas un mapping inter-instances configuré (SQL Server va vérifier lors de la compilation l’accès aux différents objets du serveur distant).

Pour contourner ce problème on peut user de 2 mécanismes qui permettent de différer l’exécution de la procédure stockée et de laisser le mécanisme d’emprunt d’identité opérer en premier lieu :

  • Créer une nouvelle procédure stockée qui va scinder l’exécution de notre procédure stockée initiale en 2 étapes
  • Encapsuler le code à exécuter de la procédure stockée avec EXEC( »), ce qui permettra au final de faire la même que dans la 1ère solution.

 

Par exemple :

CREATE PROCEDURE dbo.GetRemoteDataWithImpersonate
WITH EXECUTE AS 'USER1'  
AS

EXEC dbo.GetRemoteData
GO

ou encore :

CREATE PROCEDURE dbo.GetRemoteData    
WITH EXECUTE AS 'USER1'    
AS

EXEC('SELECT col1, col2 FROM [linked_server].[database].[schema].[table]')    
GO

 

Le choix de la méthode dépendra bien du contexte.

 

Bonne programmation !

David BARBARIN (Mikedavem)
MVP SQL Server

Prochain évènement GUSS le 24 avril – 19h00 : Webcast sur SQL Server 2012 AlwaysOn pour les fermes Sharepoint 2013

Mis en avant

J’aurai le plaisir d’animer le prochain évènement du GUSS sous un nouveau format. Le principe est simple : où que vous soyez, vous pouvez rejoindre le webcast en ligne avec le son, la vidéo et un chat pour poser des questions.

 

Ce webcast sera composé de 2 sujets de 30 minutes :

 

icon_arrow  Always-On : rappel des bases
La première session rappellera le fonctionnement et les bases de la Haute-Disponibilité avec AlwaysOn (avantages, architecture, groupes de disponibilités, type de réplications de données, etc.).

 

icon_arrow AlwaysOn dans les fermes sharepoint 2013
Mise en pratique avec une implémentation d’AlwaysOn avec SharePoint, produit très consommateur de SQL Server et avec des topologies souvent complexes. L’idée ici est d’avoir une vision beaucoup plus orientée base de données et analyser les avantages mais aussi les impacts à utiliser AlwaysOn avec Sharepoint (création / supression d’applications, authentification, utilisation des connexions readonly, maintenance des bases de données, monitoring …)

 

Les informations de connexion vous seront communiqués la veille sur le site du GUSS. En espérant vous voir nombreux !

 

David BARBARIN (Mikedavem)
MVP SQL Server

MVP SQL Server : Quatrième chapitre pour l’année 2013

Mis en avant

Pas de poisson d’avril et une vraie bonne nouvelle de la part de Microsoft aujourd’hui : le renouvèlement de mon titre de MVP SQL Server pour la 4ème fois.

J’en profite pour remercier Martine Tiphaine et Microsoft une nouvelle fois !

 

mvp

 

David BARBARIN (Mikedavem)
MVP SQL Server

Cluster Windows et fileshare quorum : comment changer le chemin de partage du quorum

Mis en avant

Sur une installation SQL Server 2012 Always-On avec un cluster composé d’un quorum nœuds et partage de fichiers majoritaire j’ai eu à changer le chemin de partage du quorum. Avec surprise j’ai pu m’apercevoir rapidement que le changement du chemin au travers de la console de gestion du cluster était bien pris en compte mais restait actif sur l’ancien partage. J’ai pu reproduire ce problème sur mon environnement de test

Voici donc la situation initiale :

image

 

image

 

Le partage réseau n’est plus accessible dans mon cas. Il faut donc trouver un nouveau path.

image

 

image

 

Cependant une fois configurée on peut remarquer que la nouvelle ressource est effectivement créée et pire que l’ancienne ressource est toujours utilisée comme faisant parti du quorum.

image 

 

A ce stade l’interface graphique ne nous empêche de supprimer la ressource concernée. Si on tente l’opération en passant par les cmdlets powershell du cluster nous nous heurtons également à un message d’erreur qui stipule qu’une ressource cluster core ne peut être supprimée.

image

 

Donc comment faire en sorte que notre changement de chemin soit pris en compte par le cluster. En réalité l’astuce consiste tout simplement à supprimer temporairement ce type du quorum de cluster et de revalider le nouveau chemin une nouvelle fois comme ceci :

image

 

image

 

Une fois le changement de quorum changé la ressource qui nous gênait a bien été supprimée.

image 

 

On peut également supprimé dans notre cas la ressource fileshare restante. Enfin il ne reste plus qu’à revalider notre type de quorum avec le nouveau chemin en suivant la procédure décrite un peu plus haut.

image

 

Bonne configuration de quorum !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Virtualisation et SQL Server 2012 : disques non reconnus avec VSphere 5.X

Mis en avant

Lors d’une installation SQL Server 2012 chez un de mes clients j’ai été confronté à un problème surprenant. La machine virtuelle comportait 3 disques avec les partitions C, D et E et SQL Server ne reconnaissait uniquement que le premier disque. Après avoir cherché un petit moment et notamment des problèmes aux niveaux des permissions de compte de service SQL nous nous sommes aperçu que le problème venait en réalité des types de disques que VSphere présentait au système d’exploitation. Les disques D et E étaient vus comme périphériques amovibles ce qui peut être gênant pour SQL Server !!

L’astuce consiste donc à désactiver cette option au niveau de la machine virtuelle (devices.hotplug = false).

>> Le KB VMWARE pour plus de précision

 

Bonne installation !!

David BARBARIN (Mikedavem)
MVP SQL Server

Instant File Initialization et SetFileValidData()

Mis en avant

Instant File Initialization est une option connue des DBA et permet d’accélérer certaines opérations faisant de la réservation d’espace disque. Avec SQL Server cela se traduit par les opérations de création, restauration de bases de données ou encore ajout de fichiers, modification de taille ou encore expansion de fichiers … Bref cette option est souvent très bénéfique pour les performances mais celle-ci exige quelques prérequis qui sont les suivants :

  • Le fichier n’est pas un fichier journal d’une base de données
  • Le système d’exploitation supporte l’utilisation de la fonction SetFileValidData()
  • Le compte de service SQL possède le privilège SE_MANAGE_VOLUME_NAME
  • Le fichier n’est pas un fichier sparse
  • Le fichier n’est pas concernée par du chiffrement TDE
  • Trace flag 1806 n’est pas activé sur l’instance SQL (ce traceflag désactive l’utilisation de cette fonctionnalité)

 

Ce qui nous intéresse ici c’est l’utilisation de la fonction SetFileValidData(). Nous voila donc plongé dans la documentation des  API Windows et de notre fonction SetFileValidData(). Voici ce que la documentation nous propose :

Sets the valid data length of the specified file. This function is useful in very limited scenarios. For more information, see the Remarks section.

Dans la section remarques nous avons :

The SetFileValidData function sets the logical end of a file. To set the size of a file, use the SetEndOfFile function. The physical file size is also referred to as the end of the file.

Each file stream has the following properties:

  • File size: the size of the data in a file, to the byte.
  • Allocation size: the size of the space that is allocated for a file on a disk, which is always an even multiple of the cluster size.
  • Valid data length: the length of the data in a file that is actually written, to the byte. This value is always less than or equal to the file size.

The SetFileValidData function allows you to avoid filling data with zeros when writing nonsequentially to a file. The function makes the data in the file valid without writing to the file. As a result, although some performance gain may be realized, existing data on disk from previously existing files can inadvertently become available to unintended readers

A caller must have the SE_MANAGE_VOLUME_NAME privilege enabled when opening a file initially

 

Pour résumer : cette fonction va nous permettre d’éviter le remplissage de zéros dans un fichier lorsque les écritures ne sont pas séquentielles

Pourquoi pour des opérations non séquentielles ?  Effectivement si l’on écrit de manière séquentielle dans un fichier la phase d’écriture de zéro est relativement rapide puisque l’on écrit toujours à la suite des données précédentes

Cependant si l’on écrit de manière aléatoire, le problème est tout autre. Imaginez que l’on écrive la première au début du fichier et la 2ème fois à la fin, il va donc falloir remplir de zéros le fichier de la première écriture jusqu’à la 2ème. La documentation le stipule bien : chaque fichier doit posséder notamment une propriété Valid data length qui correspond à la longueur des données écrites dans le fichier.  Cette opération, vous l’avez compris, peut prendre du temps en fonction de la longueur à initialiser. SQL Server écrit de manière aléatoire dans le fichier même lors de son initialisation. C’est la raison pour laquelle l’utilisation de cette option est très intéressante ici.

 

Ecriture séquentielle :

 

image

 

Ecriture aléatoire :

 

image

 

L’utilisation de procmon peut nous permettre de visualiser l’utilisation des fonctions SetEndOfFile() et SetFileValidData(). J’ai simplement créé une base de données simple avec le fichier de données TestIntantFileInitializationWith.mdf.

 

  • Dans le cas où Instant File Initialization n’est pas activé

 

image

 

On ne voit ici que l’utilisation de la fonction SetEndOfFile(). Cette fonction est utilisée dans tous les cas pour fixer physiquement la fin du fichier. Dans le cas présent la fin du fichier est fixée à 10485760 octets soit 10Go.

 

  • Dans le cas où Instant File Initialization est activé

 

image

 

Une fonction supplémentaire est utilisée ici SetFileValidDate() qui permet de valider la longueur des données dans le fichier mdf :  ValidDataLength : 10485760 (10Go de données dans un fichier de 10Go)

 

David BARBARIN (Mikedavem)
MVP SQL Server

Techdays 2013 à Paris : Je serais présent en tant qu’ATE SQL Server

Mis en avant

techdays_ate

ATE sur les Microsoft TechDays 2013

 

J’aurais le plaisir d’être ATE sur la technologie SQL Server aux techdays 2013 à Paris les 13 et 14 février prochain. Ca sera l’occasion pour moi d’échanger autour de SQL Server avec vous !

Au plaisir de vous voir !

David BARBARIN (Mikedavem)
MVP SQL Server

Utiliser le même certificat pour chiffrer les connexions SQL Server en SSL et pour TDE ?

Mis en avant

Lors d’une de mes dernières interventions nous avions implémenté chez un client le chiffrage des connexions SQL Server via SSL avec la mise en place d’un certificat. Ce même client m’ a demandé s’il était possible d’utiliser ce même certificat pour chiffrer une de leurs bases de données via TDE au lieu d’utiliser un certificat auto-signé. Vu de loin on pourrait penser que oui et que l’implémentation du certificat dans SQL Server est une chose aisée mais il n’en est rien. La raison est la suivante : l’export du certificat avec la clé privée au travers du magasin de certificat Windows génère un fichier avec l’extension .pfx qui n’est pas exploitable directement par SQL Server. Il faut donc trouver un moyen d’extraire de ce fichier le certificat et la clé privée dans 2 fichiers .cer et .pvk. Pour cela nous allons utiliser openssl.

 

Pour commencer et après avoir exporté le certificat du magasin certificat, on se retrouve avec un fichier ayant l’extension .pfx. Ce fichier stocke notre certificat, la clé publique et la clé privée.

image

image

 

Ensuite j’ai utilisé la version light de SSL (Win32_OpenSSL_v1.0.1c_light) et j’ai installé au préalable les composants redistribuables C++ 2008 (prérequis à l’installation de openSSL).

image

 

Une fois installée il suffit de lancer les commandes suivantes pour :

  • Extraire dans un fichier PEM la clé privée et le convertir dans un format compréhensible pour SQL Server (fichier pvk)

openssl.exe pkcs12 –in cert_ssl.pfx –nocerts –nodes –out cert_ssl_pvk.pem
openssl.exe rsa –in cert_ssl_pvk.pem –outform PVK –pvk-strong –out cert_ssl.pvk

 

  • Extraire dans un fichier PEM  le certificat et le convertir dans un format compréhensible pour SQL Server (fichier cer)

openssl.exe pkcs12 –in cert_ssl.pfx –nokeys –out cert_ssl_cer.pem
openssl.exe x509 –outform DER –in cert_ssl_cer.pem –out cert_ssl.cer

 

Ce qui nous donne les fichiers suivants :

image

 

Il suffit ensuite de créer le certificat correspondant dans SQL Server dans le contexte de la base master avec le certificat et la clé publique (.cer) et la clé privée correspondante (.pvk) :

,

CREATE CERTIFICATE TDE_CERT_2
FROM FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\cert_ssl.cer'
WITH PRIVATE KEY
(
 FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\cert_ssl.pvk',
 DECRYPTION BY PASSWORD = 'P@$$w0rd'
);

 

Vérification de la création correcte de notre certificat à l’aide de la vue système sys.certificates :

 

image

 

Bien entendu j’avais déjà créé la clé de service master (SERVICE MASTER KEY) sur le serveur SQL. C’est donc en toute logique que la clé privée du certificat que je viens de créer soit chiffrée par la clé master ici.  Il ne reste ici plus qu’à créer la clé de chiffrement de la base de données qui sera elle même chiffrée par notre certificat.

Bon chiffrement !

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server mirroring : Ajout d’un fichier de bases de données et impact

Mis en avant

Lors d’une prestation chez un client, celui-ci m’a demandé s’il était possible d’ajouter un fichier à une base de données concernée par une session en miroir. La réponse est évidement oui mais cette opération nécessite quelques actions supplémentaires pour qu’elle soit également validée sur le serveur en miroir. En effet l’ajout d’un fichier de bases de données va suspendre la session en miroir comme on peut le voir sur l’image ci-dessous :

image

image

 

Le fait de reprendre la session ne changera rien. Si on jette un coup d’œil dans le journal des évènements SQL Server sur l’instance en miroir on peut voir le message suivant :

image

 

La modification du schéma de bases de données n’a pas été répercuté automatiquement sur l’instance en miroir et par conséquence la session en miroir est suspendue. La question évidente ici est comment répercuter la modification de schéma de base sur l’instance en miroir ? L’opération n’est pas très compliquée en réalité : il suffit de :

  • supprimer la session en miroir qui concerne nos bases de données
  • initier une sauvegarde du journal de la base de données sur le serveur principal
  • restaurer la sauvegarde du journal sur la base de données en mode NORECOVERY sur le serveur en miroir (il n’est pas obligatoire de restaurer une sauvegarde complète pour resynchroniser l’instance principale et l’instance en miroir)
  • recréer la session miroir entre les 2 instances concernées

 

Sur le serveur principal :

 -- Désactivation session miroir
ALTER DATABASE DXXXXXX_MIRRORING SET PARTNER OFF;
GO

-- Sauvegarde des données du journal non envoyées sur le miroir
BACKUP LOG DXXXXXX_MIRRORING TO DISK = 'E:\MSSQL\BACKUP\DXXXXXX_MIRRORING.TRN'
WITH INIT;
GO

 

Sur le serveur miroir :

 -- Restauration des données du journal + fichier manquant
RESTORE DATABASE DXXXXXX_MIRRORING
FILE = 'DXXXXXX_2'
FROM DISK = 'E:\MSSQL2\BACKUP\DXXXXXX_MIRRORING.TRN'
WITH MOVE 'DXXXXXX_2' TO 'E:\MSSQL2\DXXXXXX_2.ndf',
     NORECOVERY;
GO
     
-- Réactivation session en miroir
ALTER DATABASE DXXXXXX_MIRRORING SET PARTNER = 'TCP://SQL2008.insentia.lab:5022';

 

Sur le serveur principal :

 -- Réactivation session en miroir
ALTER DATABASE DXXXXXX_MIRRORING SET PARTNER = 'TCP://SQL2008.insentia.lab:5023';
ALTER DATABASE DXXXXXX_MIRRORING SET WITNESS = 'TCP://MCM.insentia.lab:5022';

 

Et voilà cette manipulation permet de pouvoir resynchroniser nos bases de données en miroir sans avoir à effectuer une restauration complète

 

David BARBARIN (Mikedavem)
MVP SQL Server

Journées SQL Server 2012 : Les slides

Mis en avant

Un petit billet pour commencer cette année 2013 comme il se doit ! A disposition les slides des sessions que j’ai présenté aux journées SQL Server 2012 à savoir :

  • SQL Server et stockage interne
  • SQL Server et infrastructure

 

image

 

Merci à vous de laisser vos commentaires. Ceux-ci sont importants pour savoir ce que vous avez pu apprécier ou non. C’est l’occasion pour nous également d’améliorer encore plus nos sessions. Au plaisir de vous revoir aux journées SQL Server 2013 Clignement d'œil

 

David BARBARIN (Mikedavem)
MVP SQL Server

Journées SQL Server 2012 : Bilan

Mis en avant

 

                         

 

La fin d’année approche et c’est l’heure des bilans et plus particulièrement celui des journées SQL Server 2012. En attendant les chiffres officiels, je voulais simplement dire que cette année a été encore un très bon cru avec un bon taux de participation : 300 professionnels du data management avec 45 speakers. Malheureusement cela a été très éphémère pour moi cette année. Arrivé le lundi soir à minuit passé avec un mauvais itinéraire pour arriver à l’hôtel (tout de suite la question : vous venez de la province ? …). Juste le temps de me remettre en tête mes 2 sessions SQL Server : stockage interne et SQL Server et infrastructure et au lit vers 2h30. J’ai pu quand même discuter rapidement et revoir certains MVP (il y en a un certain nombre mais je pense tout de suite à Christophe Laporte, David Baffaleuf, Frédéric Brouard, Christian Robert  …). que j’apprécie de part leur sympathie et leur expertise et j’ai eu l’immense plaisir de pouvoir rencontrer un certain François de Saint Marie (alias fsmrel) sur developpez.com. Je ne t’ai pas oublié Bruno Sourire  C’est donc avec plaisir que je reviendrais l’année prochaine (on croise les doigts) aux prochaines journées SQL Server.

Côté session voici celles qui m’ont ou m’auraient intéressé de voir (en quelque sorte ma perso liste) :

  • Monitoring SQL Server : Attentes et performances (David Baffaleuf et Benjamin Vesan)
  • Réplication transactionnelle et haute disponibilité – Retour d’expérience (EXPACEO)
  • Parallel Data Warehouse vNext (Microsoft)
  • SQL Server v1.1 à v11 (Christian Robert) –> Pour le fun
  • Haute-Disponibilité (Christophe Laporte)
  • Very High Performance  (Christophe Laporte et Frédéric Pichaut)
  • Optimisation pour les nuls (Frédéric Brouard et Arian Papillon)

 

Vous l’aurez sans doute deviner ce sont des sessions très orientés moteur SQL.

A venir prochainement la mise à disposition des présentations de sessions.

 

image

 

David BARBARIN (Mikedavem)
MVP SQL Server

Powershell : scripter la création d’alias SQL Server

Mis en avant

J’ai eu récemment à définir une procédure d’installation de serveurs liés SQL Server pour une application. Cette procédure doit être bien entendu testée en environnement de qualité et en production.  De plus chez mon client, un 2ème environnement de qualité est prévu en parallèle pour installer l’application concernée. Le principal souci ici est que les noms de serveurs liés vont changés et que cela risque d’avoir un impact au niveau du code de l’application. Nous ne pouvions pas nous permettre de mettre à jour l’ensemble du code TSQL applicatif à chaque changement d’environnement. Pour répondre à cette problématique nous avons choisi d’utiliser des alias SQL Server. L’utilisation des alias est beaucoup plus flexible avec les serveurs liés. Il suffit de changer ces noms sans avoir un impact sur le code.

Mais revenons à notre problématique initiale : comment scripter la création des alias SQL Server ? Il n’existe pas de procédure système T-SQL qui permette de faire cela. La solution ici est d’utiliser les classes WMI correspondantes (ici j’utilise un SQL Server 2008). Comme nous sommes à l’air du PowerShell voici le script utilisé permettant la création d’alias sous SQL Server :

param
(
$server=$(throw "Mandatory parameter -instance_name_sot not supplied")
)


# Example script to create an alias
$alias = ([wmiclass] '\\.\root\Microsoft\SqlServer\ComputerManagement10:SqlServerAlias').CreateInstance()
$alias.AliasName = 'SERVER_ALIAS'
$alias.ConnectionString = '1433' #connection specific parameters depending on the protocol
$alias.ProtocolName = 'tcp'
$alias.ServerName = $server
$alias.Put() | Out-Null;

# List existing aliases
Get-WmiObject -Namespace 'root\Microsoft\SqlServer\ComputerManagement10' -Class 'SqlServerAlias' |
    Format-Table -Property 'AliasName', 'ServerName', 'ProtocolName', 'ConnectionString'

 

… à utiliser de la manière suivante :

 & '.\deployalias' –server servername

 

image

 

Vous pouvez tout à fait modifier ce script et le rendre plus paramétrable (nom de l’alias, no de port etc …). Encore une chose, en fonction du besoin vous allez sans doute devoir installer les alias pour les 2 types d’architecteur x86 et x64. Pour se faire il suffit de lancer le script avec Windows PowerShell (x64) et Windows PowerShell (x86).

 

Bon déploiement

David BARBARIN (Mikedavem)
MVP SQL Server

Journées SQL Server 2012 : Ma session Infrastructure SQL Server

Mis en avant

 

Parce que quand il n’y en a plus il y en a encore j’aurai la chance de présenter une 2ème session aux journées SQL Server 2012 sur l’infrastructure SQL Server Sourire . Le sujet est vaste comme vous pouvez vous l’imaginer. L’écosystème de nos instances SQL Server est large. Quels processeurs ? quel modèle de RAM, combien ? Que dois-je acheter comme stockage ? Est-ce que mon serveur va être concerné par la virtualisation ? Si oui comment quels sont les éléments à prendre en compte ? Comment dois-je configurer mon système d’exploitation …. autant de question que nous DBA devons répondre. J’essaierai au cours de cette session de passer en revue les éléments caractéristiques d’une bonne infrastructure SQL Server.

Pour le planning c’est par ici

En espérant vous voir nombreux !

David BARBARIN (Mikedavem)
MVP SQL Server

Journées SQL Server 2012 : Ma session stockage interne SQL Server

Mis en avant

 

Les journées SQL Server 2012 arrivent à grand pas. J’aurai l’occasion d’intervenir le 2ème jour pour présenter une session sur le stockage interne SQL Server. Ce n’est pas forcément un des sujets les plus simples à traiter mais certainement un de ceux (parmi tant d’autres) où il y a beaucoup de choses à dire et un de mes sujets favoris. Je vous conseille lors de cette session de sortir le décodeur hexadécimal. Je vous aurai prévenu Sourire

Pour plus de détails c’est par ici

 

En espérant vous voir nombreux !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Techdays 2012 à Lausanne : compte rendu

Mis en avant

J’ai eu l’occasion d’animer 2 sessions aux techdays 2012 à Lausanne les 06 et 07 novembre sur SQL Server bien entendu Sourire  :

  • Une session orientée développement avec les nouveautés SQL Server 2012 dans ce domaine (session que j’ai eu le plaisir de co-animer avec Oishiiii) . Présentation disponible ici
  • Une session orientée IT avec SQL Server 2012 et Always-On. Présentation disponible ici

 

Cette année nous avons orienté nos sessions sur 80% de démonstration et 20% de présentation.Vous pourrez voir les vidéos sur Channel 9. Pour le moment seule la session orientée développement est présente mais le reste viendra après.

Un petit clin d’œil également à la dream team (voir ci-dessous). C’est vrai que ces 2 jours étaient plutôt sympathiques Sourire

 

 

techdays2012Lausanne

 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server 2012 SP1 disponible en téléchargement

Mis en avant

Le service pack 1 de SQL Server 2012 qui était très attendu est disponible en téléchargement ici.

On a maintenant une forte intégration et un support des fonctionnalités BI comme PowerPivot ou PowerView dans office 2013.  Du côté des fonctionnalités classiques non BI nous retrouvons le support pour la migration cross-cluster et always-on, les index XML sélectifs, un changement de permission pour DBCC SHOW_STATISTICS et autres.

Pour plus détail c’est par ici

 

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Pass : Quelques news

Mis en avant

La keynote du SQLPass a enfin dévoilé le projet Haketon. C’est quoi Haketon ? Il s’agit en réalité d’une base InMemory, pour des traitements OLTP, dont les principaux facteurs de ralentissement ont été supprimés.

On peut visiblement d’après les premiers tests clients triés sur le volet s’attendre à des gains de performance allant de x10 à x50 avec le support complet ACID  et les requêtes T-SQL compilés en code natif ! Cette fonctionnalité apparaitra  dans la prochaine version majeure de SQL Server.

La prochaine version PDW (Parallel DataWarehouse) a été annoncé et est visiblement prévue pour le premier semestre 2013 avec l’apparition de PolyBase. Ce dernier permettra les requêtes de bases de données relationnelles et non relationnelles Hadoop. On se rapproche clairement du BIGDATA !

Enfin une nouveauté qui n’est pas sans importance et qui concerne les index columnstore avec la possibilité de mise à jour des tables si celles-ci contiennent ce type d’index  …

 

David BARBARIN (Mikedavem)
MVP SQL Server

Journées SQL Server : Les inscriptions sont ouvertes !

Mis en avant

 

Si vous avez l’intention de participer aux journées SQL Server et je suis sûr que ca sera le cas Sourire  sachez que les inscriptions pour les journées SQL Server qui se dérouleront le 10 et 11 décembre 2012 sont désormais ouvertes.

Pour rappel voici quelques informations utiles :

Au niveau du contenu :

  • 4 tracks en parallèle
  • Plus de 35 sessions
  • Plus de 35 speakers
  • Des sessions sur la Business Intelligence, les performances SQL, le Cloud, le Big Data, l’ALM, le DataViz, etc.

Pour plus de détails c’est par ici

Le lieu :

Centre de Conférences Microsoft
41 quai du Président Roosevelt
Issy-Les-Moulineaux
Accessible Métro et Tram

Inscriptions :

Web : http://jss2012.fr
Twitter : #jss2012

 

 

En espérant vous voir nombreux !!

 

David BARBARIN (Mikedavem)
MVP SQL Server

Lancement de Windows Server 2012 le 24 octobre 2012

Mis en avant

Ce n’est pas sans intérêt que les administrateurs de bases de données devront suivre cette nouvelle version de Windows Server et des nouvelles fonctionnalités que cette dernière proposera et qui pourront être bénéfiques aux instances SQL Server comme la haute disponibilité, le stockage ou encore le NIC Teaming. Vous pourrez suivre le lancement de cette nouvelle version chez Microsoft France (Issy-les-Moulineaux) le 24 octobre 2012.

Pour le formulaire d’inscription c’est par ici

 

 

David BARBARIN (Mikedavem)
MVP SQL Server

Cluster Resource DTC in clustered service or application ‘Cluster Group’ Failed

Mis en avant

Un problème assez particulier que je viens de rencontrer au cours d’un audit d’un cluster SQL chez un de mes clients. Je vois une multitude d’erreurs dans le journal des évènements 1205 et 1069 liée à une ressource DTC. Le hic c’est qu’il existait bien une ressource DTC sur le serveur mais elle n’était pas concernée. Me voilà bien avancé avec mon erreur …

Pour bien situer le contexte voici l’erreur rencontré dans le journal des évènements:

 

image

 

Seulement en regardant les ressources au niveau du cluster management en mode GUI on voit que la ressource DTC est en ligne et fonctionne correctement. Je passe en mode commande (cluster.exe) et voici ce que je remarque :

 

image

 

J’ai en réalité 2 DTC sur mon cluster SQL. La ressource MSDTC-SQL2005Dtc est la ressource qui a été créée lors de l’installation du cluster SQL. En revanche la ressource DTC (statut failed) est présente dans le groupe Cluster Group mais n’est pas visible dans la console cluadmin.msc. Visiblement c’est cette 2ème ressource qui pose problème. A noter que les ressources qui font parti du groupe Cluster Group ne sont pas visible en mode GUI.

La suppression de cette ressource fera disparaitre le message d’erreur intermittent présent dans les différents journaux d’évènements.

image

 

En vérifiant dans les services de composants on peut s’assurer que c’est bien la ressource cluster qui sera utilisé :

image

 

David BARBARIN (Mikedavem)
MVP SQL Server

Windows Server 2012 et SQL Server partie 1–Dynamic quorum

Mis en avant

Comme vous le savez sans doute Windows Server 2012 est sorti et bien entendu en tant qu’administrateur de bases de données on peut se demander quelles sont les fonctionnalités de cette nouvelle mouture qui pourront bénéficier de près ou de loin à SQL Server. Dans ce premier volet j’ai décidé de commencer par la haute disponibilité. Une des fonctionnalités que j’ai trouvé relativement intéressante dans ce domaine est l’utilisation du quorum dynamique en environnement cluster et par la même occasion de Always-On de SQL Server 2012.

Lire la suite

Présentation SQL Server 2012 Always-On au Pass Suisse Romandie

Mis en avant

Nous relançons pour cette rentrée 2012 les sessions SQL Server en suisse romande avec le groupe Pass Romandie. J’aurai l’occasion de présenter Always-On avec SQL Server 2012 lors de cette première session. Il y aura également une autre session tout aussi intéressante sur SQL Server dans Azure présentée par Thoi Dung de chez Microsoft Suisse. Je vous laisse également découvrir l’ensemble de l’agenda des sessions jusqu’à la fin de cette année. N’hésitez pas à vous inscrire et à réserver les dates !!!

 

10.10.2012

SQLServer sur Azure en machine virtuelle : T. Thoi
Always-On : D. Barbarin
Inscription ICI: http://www.eventbrite.com/event/4365192408

14.11.2012

De la sécurité avec le chiffrement : D. Barbarin
Repousser les limites de SQL Server Express / Pushing SQL Server Express to the max : C. Robert
Inscription ICI: http://www.eventbrite.com/event/4369651746

05.12.2012

Pourquoi mettre en place de la réplication ? / Why using the replication ? : C. Robert
Memory Usage within SQL Server : D. Schmidt
Inscription ICI: http://www.eventbrite.com/event/4369621656

 

Toutes ces séances auront lieu à l’adresse suivante:

Novotel Genève
Rue de Zurich 19
1201 Genève
022 909 90 00

 

David BARBARIN (Mikedavem)
MVP SQL Server

Les journées SQL Server–second volet

Mis en avant

 

 

 

Le premier volet des journées SQL Server a visiblement connu un très grand succès. C’est la raison pour laquelle GUSS s’est relancé dans la préparation d’un second volet qui devrait se dérouler en décembre. Les dates définitives seront communiqués un peu plus tard. Cependant pour que cet évènement soit de nouveau un succès nous avons besoin de vos avis qui se présente sous la forme d’un sondage qui ne vous prendra que quelques minutes de votre temps Sourire et qui nous permettront de mieux cibler vos attentes à tous les niveaux (contenu des sessions, organisation etc …)

Pour le remplir c’est par ici

Merci par avance !!

 

David BARBARIN (Mikedavem)
MVP SQL Server