Cet article inaugure le début d’une nouvelle série: les checklists. Une série de points de contrôle à utiliser comme pense bête lors de telle ou telle occasion. Bien entendu tout commentaire est le bienvenu afin de les parfaire: je n’ai aucune prétention à l’exhaustivité , ceci n’est que le produit de mon expérience et de ma mémoire vieillissante et vos contributions sont les bienvenues.
Nos serveurs SQL sont parfois des auberges espagnoles où se cotoient les bases les plus diverses: développées maison, dérivées de produits Microsoft (CRM, SharePoint etc etc etc) ou encore liée a des applications tierces. Ce sont ces dernières qui vont faire l’objet de ce post. Quelles sont les bonnes questions à se poser quand on envisage d’acheter un logiciel fabuleux pourfairelecaféduchefàdistance et qui fonctionne uniquement sur un serveur dédié enterprise avec 256 Gb de ram.
La configuration recommandée
Voila une information intéressante et oh-tellement classique- cependant il vaut mieux y regarder à deux fois. Vous pouvez déjà accorder un bon point à ceux qui décrivent plusieurs types de configurations en fonction des charges prévues. Et 5 points supplémentaires à ceux qui délivrent en plus une worksheet ou un calculateur. Un certain nombre d’éditeurs on tendance à surestimer largement les besoins de leur logiciels. Penchons-nous donc un instant sur leurs exigences et ce qu’elles pourraient révéler.
Instance dédiée : La montagne qui accouche d’une souris.
Ce que ca pourrait cacher : on limite les risques en isolant complètement l’application. Ce n’est pas une critique, ca peut être un choix pragmatique ne sachant pas si l’acheteur dispose d’un DBA qualifié. Ca peut aussi être une application portée et non optimisée.
Rappelons en ces heures de consolidation les critères qui devraient pourraient vous amener à consacrer un serveur à une seule application. Je vous recommande de valider chacun de ces points auprès de l’éditeur. La qualité de ses réponses sera déjà un indicateur précieux de sa rigueur et de son (futur) support. Ca vous permettra aussi de trancher éventuellement entre différentes solutions.
- Securité L’application fonctionne en mode authentification SQL ce qui est contraire a votre police de sécurité, ou elle requiert des privilèges incompatible avec vos autres bases de données
- Collation la collation de niveau serveur détermine celle qui sera utilisée par les bases de données systèmes tels que model ou tempdb.Il faut donc s’assurer que les application et leur db sous jacentes qui utiliseront tempdb possèderont une collation compatible afin d’éviter les conflits lors des opérations de jointure par exemple.
- Ressources consommées (processeurs, disques, réseau, mémoire) pourraient mettre à mal les autres db et applications . Notons que depuis 2008 nous avons la possibilité d’établir des lignes de partage pour le CPU et la Mémoire grace au Resource Governor ; sans mentionner que 2014 y ajoute l’IO (et ca c’est TROP chouette )
- SLA (Service Level Agrement) peut exiger des solutions de DR et d’HA particulières
- Version particulière non alignée avec votre parc existant.
Edition Express : séduisant mais…
Il n’est pas rare quand vous faites un inventaire de tomber sur une pléthore de SQL Express ou autre MSDE /LocalDB. Il y a le modèle sournois non renseigné et il y a le modèle gracieusement offert et installé pendant le setup du logiciel. Evidemment sur la machine de l’application elle-même. A nouveau l’avantage éditeur est que tout est pacakagé, emballez c’est pesé. Mais voici une série de raison pour lesquelle les DBA restent suspicieux face à ces moutons égarés dans un monde de production.
- Pas de SQL agent donc pas de job system
- Multiplication d’instances
- Limitation des ressources mais si ca devient sympa pour un produit gratuit.
- Pas de Haute disponibilité… (sauf pour des exercices de styles clin d’oeil)
- Comment aussi intégrer votre instances express dans vos Policies ? Vos data tiers application ? Votre
Utility Control Point ? Pas de Data Collector etc etc bref pas d’industrialisation aisée.
Licences
Ceci découle en droite ligne des points précédents: in fine où allez vous héberger cette base de donnée et quel impact cela aura-til sur votre plan de licence. Pour éviter des surcoûts donc intéressez-vous de près aux exigences affichées pour couvrir des besoins réalistes en vous appuyant sur ce qui précède et sur ce qui suit!
Connectivité
Il vous arrive parfois dans des quarts d’heures de nostalgie de vous remémorer les fabuleux fichiers .INI d’antan avec le SA mot de passe à blanc par defaut…Que de chemin parcouru…Oh oui! ouiiiiiii!Pourtant ce matin recu fraîchement d’un fichier xml non protégé d’une nouvelle application – avec comme un petit air vintage- cette jolie string
<add name=”lenomdelappli” connectionString=”App=blablabla Management Service;User ID=saSQL_blabla;Initial Catalog=blablaDB;Integrated Security=true;Persist Security Info=True;Data Source=svSomeserver.test.gaga;Password=motdepasse;” providerName=”System.Data.SqlClient”/> So cute! bref..investiguez donc…
- Intégrée ou pas ? Sécurité encore
- Version du client SQL utilisée ? C’est votre tuyau de plomberie, on y revient toujours…un driver n’est pas l’autre! mmmh les joies du component checker
- usage de DSN en mode client server a l’ancienne
- gestion de la perte de connexion et du basculement ? (une application moderne doit gérer ca avec la grace d’une ballerine souriante en toute circonstances “transparente”! )
- …
Ram, IOPS etc
N’hésitez pas à confonter les architectures proposées à vos habitudes bonnes pratiques et standards, à poser des questions sur le pourquoi du comment. Obtenir des metrics sur le fonctionnement live de l’application est un point plus qu’intéressant. Des exigences élevées tout comme la demande d’une instance dédiée doivent soulever votre méfiance : Pourquoi autant de mémoire ? Quid de l’organisation des disques recommandées .Planifiez un test de charge éventuel ou obtenez les IOPS attendu que vous communiquerez avec délices a votre administrateur de SAN . Si les résultats vous semblent inquiétant plongez plus loin dans la db (voir point suivant)
Le code
Oupsss je l’ai dit. Bien entendu je ne vous suggère pas de faire un code review de toute l’application, conservez votre fougue pour vos applications maisons et votre team interne. Il peut être intéressant néanmoins de faire quelques coups de sonde. Pas mal d’application sont portées du monde Oracle au monde SQL sans réelles adaptations par exemple. D’autres sont écrites à l’ancienne avec un usage constant de dynamic SQL ou de curseur etc. J’ai vu aussi des tables indexées dans tous les sens pour “sic” couvrir tous les cas de figures etc etc. Des schémas de type “abnormal” form. Bref la routine 🙂
Gourmandises et particularités
Vérifiez les points exotiques : connectique via un “serveur lié” à un obscur fichier access antédiluvien, usage de xp_cmdshell (l’eau bénite vite) , extended procedure (so vintage)
CLR or not…
Les services impliqués
Votre logiciel peut vouloir s’appuyer sur d’autres services SQL que simplement le database engine. Fournir des rapports et dashboards sur SSRS, Utiliser des pacakges SSIS et même un cube en arrière plan. Ces points sont importants et méritent d’être planifiés correctement , si possible rapatriés sur vos instances existantes : ordre et méthode.
Finalement
Ca reste du gros bon sens: vous devez passer au crible de vos pratiques le futur logiciel. Tout en faisant preuve de souplesse et d’ouverture il n’y a aucune raison de se laisser intimider parce que ce développement est packagé dans un logiciel commercialisé.
Pointez ses points faibles et rendez un avis. Une fois déployé ce sera a vous d’assumer son fonctionnement au mieux.
Comme je suis bavarde cette checklist est assez verbose, j’en ai donc fait une vraie sous Excel à downloader ICI (trèèès simple) et à personnaliser à votre gout.
DatAtypical 