Developpez.com
Accueil
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 !
David BARBARIN (Mikedavem)
MVP SQL Server
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 :
Le partage réseau n’est plus accessible dans mon cas. Il faut donc trouver un nouveau path.
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.
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.
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 :
Une fois le changement de quorum changé la ressource qui nous gênait a bien été supprimée.
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.
Bonne configuration de quorum !
David BARBARIN (Mikedavem)
MVP SQL Server
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 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 :
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 :
Ecriture aléatoire :
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.
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.
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
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
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.
…
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).
Une fois installée il suffit de lancer les commandes suivantes pour :
Ce qui nous donne les fichiers suivants :
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) :
,
Vérification de la création correcte de notre certificat à l’aide de la vue système sys.certificates :
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
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 :
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 :
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 :
Sur le serveur principal :
Sur le serveur miroir :
Sur le serveur principal :
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
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 :
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 
David BARBARIN (Mikedavem)
MVP SQL Server
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 
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) :
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.
David BARBARIN (Mikedavem)
MVP SQL Server
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 :
… à utiliser de la manière suivante :
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
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
