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 …
Archives mensuelles : juin 2012
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.
Changer la connexion locale ou le propriétaire d’un plan de maintenance après sa migration
our ceux qui ont déjà tenté l’expérience, la migration d’un plan de maintenance sous SQL Server réserve quelques surprises. En effet, la connexion locale associée au package n’est pas modifiable et il faut à posteriori créer une nouvelle connexion et modifier les tâches du plan en conséquence pour qu’elles prennent en compte la nouvelle connexion. Il va sans dire que cela n’est pas forcément pratique et bien souvent on préfère recréer le plan de maintenance sur le nouveau serveur soit "from scratch" soit avec des copier-coller. De la même manière si on veut changer le propriétaire d’un job lié à un plan de maintenance on se retrouve rapidement confronté à quelques difficultés. Le fait de changer le propriétaire d’un job est plutôt facile en soi mais si on modifie et revalide le plan de maintenance par la suite celle-ci écrase notre changement de propriétaire. L’astuce consiste à changer le propriétaire du package SSIS associé au plan de maintenance concerné. Voici une procédure qui vous permettra de changer rapidement ces 2 paramètres après migration.
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.