Datafly.pro

Les problèmes de conversion de types de données sont un des problèmes de performances trop souvent rencontré.

Vous avez peut-être déjà rencontré des plans d'exécution de requêtes qui, à cause d'une conversion implicite, deviennent inefficaces : parcours de table au lieu d'une recherche indexée, par exemple.

Nous allons voir ici dans quel cas de figure cela se produit.

N'oubliez pas de maintenir vos versions de SQL Server à jour avec les derniers correctifs de sécurité !

Selon le site de Symantec, avant l'invasion de l'Ukraine (profitons en pour afficher notre solidarité), certaines attaques auraient utilisé une vulnérabilité de SQL Server (CVE-2021-1636) sur des serveurs non mis à jour. Cette vulnérabilité est pourtant corrigée depuis janvier 2021.

C'est donc bien le moment de vérifier que tous vos correctifs de sécurité sont à jour. Vous trouverez toutes la liste des builds et correctifs pour les versions de 2012 à 2019 sur ce lien.

Dans SQL Server Management Studio, la liste des serveurs inscrits est une fonctionnalité bien pratique. Ma propre liste comprend près de 300 serveurs : les miens et ceux de mes clients. Maintenant que le travail à distance est une réalité quotidienne, j'ai besoin de transférer tout cela de mon ordinateur portable à mon ordinateur de bureau.

Il existe bien une fonction d'exportation et d'importation dans SSMS, le seul inconvénient est qu'il n'est pas possible de transférer les mots de passe (ceux pour les connexions SQL) : ils sont chiffrés avec la clé de l'utilisateur. En changeant d'ordinateur, l'importation d'un fichier embarquant les mots de passe chiffrés se passe mal (et d'importer un tel fichier peut même faire planter SSMS !).

Je n'ai pas vraiment envie de resaisir 300 mots de passe, et heureusement il existe une solution !

Aujourd'hui, c'était les datafrogs, une journée de conférences organisée par notre ami Rudi Bruchez.

J'ai eu le plaisir de vous présenter une session sur "les bases de données volumineuses" ou VLDB.

En démarrant par un petit sondage auprès des spectateurs :

La vidéo est en ligne !

Par les temps qui courent, la sécurité des accès à nos serveurs devient une forte préoccupation. On veut donc savoir qui tente de se connecter,  échoue ou réussit.

Une configuration courante consiste à enregistrer les échecs de connexion dans l'errorlog de SQL Server. Ce qui est dommage, c'est la pollution que cela génère dans ce journal, encore bien pire si on veut aussi enregistrer les connexions réussies.

Et si nous activions l'audit de SQL Server ? Plutôt que d'enregistrer tout cela dans l'errorlog, on oublie qu'il existe cette fonctionnalité bien plus puissante, qu'on pourrait presque activer par défaut sur tout serveur un peu sensible.

Cet article vous permet de mettre en place cette configuration.