En discutant avec un de mes clients, il me demandait s’il fallait forcément supprimer une base de données existante avant de la restaurer. La réponse est évidemment non. En effet, il est possible d’utiliser l’option REPLACE avec la commande RESTORE mais celui-ci se demandait alors s’il y avait au final une différence entre faire une suppression de bases de données via la commande DROP DATABASE suivie d’une restauration et une restauration directe via la commande RESTORE et l’option REPLACE mis à part une simplification du code à écrire. Il y a en effet une voir plusieurs mais nous n’en traiterons qu’une seule dans ce billet et qui peut ne pas être négligeable dans certains cas.
Archives pour la catégorie SQL Server 2005
Explication sur l’erreur 5041 : Msg 5041, Level 16, State 1, Line 1 MODIFY FILE failed. File does not exist.
Un des collègues (qui se reconnaitra ;-)) a rencontré un souci chez un de nos clients qui était plutôt étrange dirons nous. Le client voulait renommer le nom logique d’un de ces fichiers de bases de données et se retrouvait avec l’erreur « Msg 5041, Level 16, State 1, Line 1 MODIFY FILE ‘FileName’ failed. File does not exist. » alors que le fichier existait bien contrairement à ce que disait SQL Server. La version de SQL Server : 2008 R2 SP1. Nous voila parti à résoudre un problème bien curieux …
Scanner le réseau à la recherche d’instances SQL Server
Scanner le réseau pour y retrouver les instances SQL Server installés peut être tâche ardue selon le contexte où l’on se trouve. Il existe bien la commande sqlcmd -L mais celles-ci comportent bien des défauts. En effet cet utilitaire lance un broadcast sur le réseau sur lequel il se trouve et attend la réponse des instances qu’il a pu atteindre. J’insiste bien sur la dernière partie de cette phrase « a pu atteindre ». Il existe bien des cas où aucune réponse ne sera retournée : l’instance SQL est cachée ou encore le service SQL Browser n’est pas activé et des instances nommées écoutent sur un port différent que le port 1433 ou encore d’autres sous réseaux ne peuvent pas être atteint par la requête broadcast etc … bref autant de raisons qui font que l’utilisation de sqlcmd n’est pas forcément judicieuse dans ce cas. Voici un script powershell qui permet de recenser l’ensemble des instances SQL beaucoup plus précisement que la commande sqlcmd ou autre méthode utilisant ce principe.
SQL Server et sécurité : Autoriser et sécuriser les accès cross-databases à l’aide des propriétaires de bases de données
Je travaille de plus en plus souvent dans des environnements dans lesquels la sécurité est devenue primordiale. L’accès entre différentes bases de données dans une instance SQL Server par exemple est plutôt simple à mettre en place dans un cas classique. Il suffit de donner les droits adéquats pour le compte de connexion sur les 2 bases de données concernées au travers des utilisateurs associés. Seulement les choses se compliquent si l’on veut sécuriser ces accès « cross-databases ». En d’autres termes si on veut que ce même compte de connexion ne puisse accéder aux objets de la base de données B qu’au travers d’objets dans la base de données A sans que celui-ci ne possède de droits explicites dans la base de données B il va falloir utiliser d’autres outils que proposent SQL Server.
Performance du stockage SQL Server en milieu virtualisé : HBA Queue Depth et VMKernel Outstanding
Je profite d’un petit moment de libre pour écrire un billet sur un problème de performance que j’ai pu constater il y a quelques avec SQL Server et une baie SAN HP EVA 4000 dans un milieu virtualisé et VMWARE. Je place rapidement le décor : je dois intervenir pour un problème de performance SQL Server. Le client m’explique un peu son architecture et me dit que son instance SQL Server est virtualisée. Les applications qui tournent sur ce serveur ont visiblement des temps de réponse assez important.
MVP SQL Server : Troisième chapitre pour l’année 2012
Changer le nom du serveur dans la chaîne de connexion par défaut dans un plan de maintenance
Lorsque l’on change le nom d’une instance SQL Server celui-ci ne se propage dans les connexions des plans de maintenance. Pour rappel, un plan de maintenance n’est ni plus ni moins qu’un package SSIS lié à un job SQL Server. C’est donc ce package SSIS qui contient la définition des sources de données. Cependant lorsqu’on tente de modifier la source de données par défaut associée au plan de maintenance on s’aperçoit vite qu’il est impossible de la modifier. On ne peut qu’en ajouter et modifier en conséquence chaque tâche qui compose le plan avec la nouvelle connexion. Autant dire que l’opération devient rapidement fastidieuse. Alors comment changer directement la source de données par défaut ?
Ouvrir le gestionnaire de configuration de SQL Server sur une instance distante à partir de la console d’enregistrement des serveurs
La console d’enregistrement des serveurs permet de sauvegarder les connexions des instances SQL Server les plus utilisés. Personnellement c’est une fonctionnalité que j’utilise souvent lorsque je commence à avoir un certain nombre d’instances à gérer. Par ailleurs la console d’enregistrement des instances SQL Server offre des fonctionnalités intéressantes comme identifier une instance ou un groupe d’instances par un code couleur, importer ou exporter la définition des connexion sur d’autres postes etc… Cependant un aspect intéressant mais moins connu est la possibilité de se connecter au gestionnaire de configuration sur une instance distante.
Consolidation des bases de données SQL Server
Consolider est un terme qu’il est impossible de ne plus entendre de nos jours dans nos entreprises. Le nombre de projets informatique autour de la consolidation n’a pas cessé de croître ces dernières années. Les bases de données ne dérogent pas à la règle. On peut alors se poser la question suivante : sommes-nous dans un phénomène de mode ? La réponse est bien entendu non. La consolidation amène son lot d’avantages…
David BARBARIN (Mikedavem)
MVP SQL Server
Quand l’économie d’énergie dans le bios ne fait pas bon ménage avec les performances de SQL Server
Il y a quelques temps j’avais écrit un billet sur les power plans de Windows et l’impact que cela pouvait avoir sur SQL Server. Il y a quelques temps j’ai pu l’observer chez un de mes clients qui souffraient de problèmes de performances de requêtes après avoir acheté un nouveau serveur. Voici ce que nous avons pu voir en comparant deux configurations serveurs différentes.