Reprise du message précédent :

Oui, niveau interface et gestion centralisé, Kaspersky c'est bien foutu. Mais payes derrière la conso réseau, CPU et RAM...
D'un certain côté, ça a même poussé au remplacement partiel du parc utilisateurs sous Windows vers du Linux, tellement cela devenait ingérable  
 
Toujours à mon ancien taf, "ils" (la DSI à Paris) avaient eu l'idée de passer sur Kaspersky, 3 ans après avoir signé le contrat et au moment où je me barrais, la version Linux promise pour les serveurs de fichiers on l'attendait toujours. En parallèle les serveurs de fichiers sous Windows (2003 mais suffisant pour l'utilisation), eux aussi attendaient leur version de Kaspersky, et étaient du coup avec un antivirus sans mise à jour depuis 2 à 3 ans !
Et là avoir des machines sous Windows et Linux avec du serveurs de fichiers sous Linux, c'est la situation typique où il faudrait justement un antivirus efficace au niveau du serveur de fichiers.
Quand j'y repense, si un jour on a du gros scandale informatique qui sort à ce niveau avec des fichiers confidentiel défense qui circule sur internet, j'éclaterais de rire

 
Moi, tu l'auras compris, rien ne m'étonnes niveau AV
 
Par contre, je ne vois pas ce qu'il y a à reprocher à KAV particulièrement.
Niveau ressource, il est comme les autres. Perso je désactive tous les composants à la con qui vérifient tout (BDR, analyse d'activité, antispam, parefeu, intrusion, etc.).
Je ne garde que la partie AV pure.

> La gestion plus lourde...

Et les DSI qui ne feront pas aussi fin que toi, ShonGail.
Fais l'essai à l'occasion en le mettant en place un jeudi soir, et pars en très long week-end

Bonjour,

J'ai 6 serveurs en productions accessibles uniquement sur le port 80, pour faire tourner une application en webservices, ils ont chacun un SGBD pour les données, et je n'ai aucun antivirus.
Ca fait 7 ans, jamais eu un seul problème. Et je ne compte pas foutre un AV (à quoi il servirait ? Rien).

Bref, je rejoins complètement ShonGail, un AV sur un serveur cloisonné (pas un serveur de fichiers) et encore plus sur un SGBD ça sert strictement à rien, car les AV ne s'amusent pas à analyser la mémoire pour lire les données que manipule le SGBD (ou alors, bonjour la chute de perf).

Ah et, je suis tellement un malade que sur mon PC perso, je n'ai jamais installé le moindre AV (et ça fait genre longtemps). Jamais eu de soucis non plus.

 
 
Ahhh un comparse
 
Par contre perso, je place des AV sur les postes clients, y compris le mien. Pourtant il est vrai que l'AV sur mon PC se tourne les pouces.

D'un certain côté aussi, si ta bécane perso est sous Linux ou MacOS X, les risques sont déjà plus faibles que sous Windows

Ca me fait penser à un truc, à savoir existe t il un antivirus où la partie admin/gestion serveur antivirus serait sur un linux et pourrait administrer des postes Windows ? ça existe ça ?

Rien ne l'interdit vu que ce sont de simples échanges TCP/IP entre clients et serveur.

J'ai pas trop tâté mais... Kaspersky le propose sous la forme d'une console web  
eTrust disposait aussi d'une console web en Java utilisable sous RedHat, mais ça date...
F-Secure en a une.
Chez Symantec, une console web sous Java est dispo.
Mais bon ce qui est ballot, c'est que ClamAV ne dispose pas de console centralisée

Ok très bien, ça me parait sympa, faut voir c'est quoi les avantages dans la réalité (avantages et puissance des outils) mais why not ...

Une solution de sécurité basée sur JAVA c'est pas antinomique comme truc ?

Je ne préférerais pas m'étendre sur le sujet

Pas lu tous les échanges mais en réaction au premier poste :
 
- Dans le monde réel, un serveur SGBD n'est pas isolé, tant au niveau réseau qu'au niveau soft. Il fait partie d'un domaine, il possède des softs de monitoring, de backup, de management etc, et encore là on parle d'un serveur que l'on contrôle en terme de sécurité/configuration, ce qui n'est pas toujours le cas.
Accesoirement rôles et applicatifs évoluent aussi dans le temps.
Donc même un serveur spécialisé est vulnérable et doit être protégé.
 
- Il n'y a pas que les serveurs SGBD qui consomment des ressources   Les serveurs Web, messagerie etc. font pareil, et ils ont des antivirus eux  
 
- Ca fait quand même quelques années qu'on parle de malwares et non plus de virus, qui sont finalement relativement inoffensifs par rapport aux derniers malwares (on peut même parler d'applicatifs) recensés comme Flame. Et ces derniers ne vont pas gentiment vous prévenir qu'ils ont infecté vos serveurs, un de leur but est d'être le plus discret possible.
 
- Si un serveur sans antivirus est infecté, il servira de zombie pour infecter les autres. Rien que pour cela ça vaut le coup d'installer un AV.
 
Bref tous les arguments présentés sont très approximatifs.
 
Maintenant un antivirus demande un minimum de connaissances pour être configuré et optimisé, ce n'est pas du next-next-finish.
 
La base de la base, c'est de construire des templates d'exclusions par rôle, et sur un SGBD cela consiste à exclure d'office toutes les bases SQL.

...et les logs

nebulios ->

ce sont les arguments que tu avances que je trouve approximatifs voir hors de propos plus exactement.

Qu'un serveur SGBD ne soit pas isolé, c'est l'axiome de mon 1er post. Je tente justement d'aller au delà du "il n'est pas isolé" pour définir ce que cela signifie techniquement.
Tu mentionnes qu'il est vulnérable à cause des logiciels qu'on peut installer dessus (monitoring, management, etc.)
Il est certain que si tu vas chercher ces softs sur emule, tu as besoin d'un AV sur le serveur. Mais si ce sont des softs de provenance plus sûre ou vérifiés préalablement, je ne vois pas en quoi un AV est nécessaire pour installer des logiciels d'administration, de monitoring ou quoi que ce soit d'autre.
IDEM pour des rôles qui n'installent pas de virus mais différentes fonctionnalités.

Ensuite, les I/O et la criticité des I/O sur un SGBD, c'est autre chose qu'un serveur de fichiers ou de messagerie
Mon email, s'il doit rester en spool 20 secondes le temps qu'un AV le scan, c'est autre chose qu'un requête SQL qui doit s'effectuer dans le temps le plus infime possible.

Le malware est un terme générique qui englobe les virus. Flame est un virus et donc un malware. Il est là pour infecter et se reproduire. Plus sophistiqué, il ne diffère en rien des menaces prises en compte dans mon post. Il se reproduit en attaquant des failles ou en se copiant sur des espaces de stockage.
Si mon SGBD n'est à l'écoute que sur le port SQL, à moins que Flame ne renferme du code pour exploiter une faille 0day sur le service précis à l'écoute, le serveur ne va pas se retrouver infecté.
Et puis Flame c'est un nombre infime de postes infectés à travers le monde. Rien à voir avec les exemples que j'ai pris. Ce n'est parce qu'il est gros et espionne à tout va qu'il est plus à craindre.

Enfin tu sembles penser qu'un serveur avec AV ne peut pas être infecté. Si l'AV ne contient pas les signatures pour repérer le virus ou l'éradiquer avant que celui-ci ne le repère et s'y adapte, il ne servira à rien. Et le système sera infecté.

Après qu'un AV se configure, c'est bien de le dire, on n'y avait pas pensé

Tu n'as pas tout compris, non seulement ces softs rajoute de la maintenance, mais ils nécessitent également l'ouverture de ports supplémentaires, des privilèges souvent conséquents, sont gérés par d'autres équipes etc...bref ils fragilisent la sécurité d'un serveur par leur présence (tout en étant indispensables) et accentuent la nécessité d'un antivirus.
Et ce n'est pas parce qu'ils sont signés qu'ils sont 100% sûrs, l'utilisation de certificats officiels par des malwares devient courante (Flame utilisait des certificats Microsoft, et à provoquer une mise à jour de l'agent Windows Update en réponse).
Quand à la mention sur Emule, on parle de contexte pro ici, pas du PC de Jean-Kevin.
 

Renseignes-toi sur le fonctionnement d'un serveur mailbox Exchange, et tu verras que ce n'est pas très différent d'un SGBD.
Tu oublies juste de parler de dimensionnement dans ton argumentation. Un SGBD peut avoir une empreinte I/O minime selon ses tâches et sa configuration, et certainement moindre que des serveurs FS/messagerie plus importants, donc parler de rôle/applicatif ne suffit pas.
 

Flame n'est pas un virus, renseignes-toi sur la différence entre virus/ver/troyen etc.
Et on en revient au post n°1, dans la vie réel tu auras d'autres ports ouverts que le port SQL.
De mémoire Stuxnet exploitait au moins 4 failles 0 day et s'était propagé depuis environ deux avant sa découverte (sans compter les sous-composants type Flame/Duqu etc.).  
Si tu crois que ta notion d'invulnérabilité tient encore, et qu'il s'agit d'un nombre de postes infimes alors qu'on parle de propagation initiale sur plusieurs pays,  
il est temps de revenir à la réalité.
 
La base de la base en matière de sécurité, c'est de ne jamais se croire invulnérable. Il y a encore 5 ans, un malware de niveau Stuxnet/Flame ne se trouvait que dans les ouvrages de fiction.
 

Tu m'inventes des propos, et tu as des connaissances visiblement très limitées en matière d'antivirus.
 
Un serveur protégé par un antivirus sera forcément moins vulnérable qu'un serveur sans, mais pas (jamais) invulnérable. Un serveur invulnérable n'existe pas dans un environnement de production.
Pour la partie antivirus, celui-ci ne se contente pas de se baser sur ses signatures, il utilise une analyse heurisitique pour détecter et bloquer les comportements à risque. Et on ne parle plus d'antivirus pur depuis quelques années, mais de solutions antivirales qui regroupent tout un ensemble de techniques pour contrer les malwares à différentes niveaux (ce qu'on appelle la "in-depth defense" ).
Donc si le malware n'est pas présent dans les signatures l'antivirus peut détecter des anomalies au niveau registre, réseau etc. et au moins limiter ses actions.
 
 

Vu que tu préfères enlever l'antivirus comme un bourrin plutôt qu'ajouter simplement des exclusions à des bases SQL, oui je pense qu'il était important de le préciser  
 
Edit : typo

nebulios ->

on sent que tu t'y connais, c'est sur.
Tant mieux, le but de ce topic, c'est de discuter et je ne suis qu'un humble élève.

Mais plutôt que de me bassiner avec des différences de vocabulaire juste utile à s'imaginer faire partie des connaisseurs (je vais y revenir), tu pourrais approfondir le risque lié à des logiciels de gestion sur des serveurs.
Chez moi, tous les logiciel de monitoring, backup ou de surveillance du matériel et du système d'un serveur ne nécessitent pas d'ouvrir de ports.
Ensuite, pour ceux qui fonctionnent en client/serveur, l'ouverture du port peut-être limitée au seul serveur avec qui échanger.
Et le risque qu'un malware s'attaque à une faille dans Openmanage par exemple est quasi inexistante puisque ce dernier présente un très faible moyen de propagation. C'est aussi vrai pour un agent backup exec ou je ne sais quoi encore, spécifique et trop peu répandu.
Ensuite, je ne cause pas de vérification des signatures d'un package d'installation avant installation mais bien de le passer à la moulinette d'un AV ou d'être sûr qu'il provient d'une source qui garantie son innocuité (tu te méfies toi du téléchargement d'un 7zip sur Sourceforge ?)

Concernant les I/O, il est évident que la BDD d'un logiciel de compta pour cinq users nécessite moins de perfs qu'un Exchange de grosse société.
Mais la base Oracle du SAP ou de l'ERP de cette même grosse société va avoir d'autre besoin en I/O que leur Exchange.
Arrive un moment où l'utilité d'un antivirus devient tout simplement bien moindre que les besoins de perfs et de stabilité.

Arrivons au plus croustillant : Flame qui n'est pas un virus. En fait on s'en contrefout !
Que ce soit un ver et que le ver soit différencié du virus ne change rien à mon histoire : comment éviter que ces programmes se propagent et quels sont leurs moyens de propagation.
Alors on peu gloser sur les caractéristiques de tel ou tel type de programme, c'est un autre topic.
Flame est bien, comme déjà indiqué, conforme aux cas déjà mentionnés (Confiker, Blaster, etc.), il exploite des failles ou des medias pour se propager. Y'a que ca qui nous intéresse dans ce topic.

Et oui Flame ca fait peur. Et oui Flame on fait croire qu'il est différent et magique. Et oui vite il faut un AV.
Mais il n'en est rien : http://www.atlantico.fr/decryptage [...] 75415.html

Enfin, non un serveur sans AV n'est pas nécessairement moins vulnérable qu'un serveur avec.
Dans beaucoup de cas, ce sera vrai. Mais pour certains serveurs à l'accès particulièrement restreints, le gain de l'AV est si minime qu'il en devient inexistant.
Et si on vient à considérer les problèmes de performances qu'il peut apporter (d'autant plus que comme tu le soulignes, les AV ne se contentent plus d'être des AV mais scrutent tout de manière opaque à travers x composants qui s'intercalent à différents niveaux de l'OS) on décide définitivement de l'oublier.
Et tu sais quoi ? Ben les serveurs tournent. Et autour, il arrive que des matériels soient infectés (souvent les postes des users) mais pas ces serveurs.
Parce que pénétrer une machine pour y exécuter du code, cela ne sa fait pas comme ça.

ça me parait bien léger et contraignant la théorie du pare feu bien configuré.
On parle bien de réduire la surface d'exposition, il y a toujours une surface exposé, un service donc un faille potentielle
 
La brique contrôle des applications permet de vérifier qu'il n'y a pas d'appli qui tournent et qui pourraient très bien communiquer sur des  ports ouverts pour des services légitimes
Les "Endpoint protection" sont beaucoup plus que des antivirus, il n'y a pas que l'attaque virale a prendre en compte.
 
Bien entendu les situations diffèrent suivant les SI
moi je gère tout seul, j'ai pas de temps pour un solution parfaitement maitrisée donc empiler plusieurs couches de securité ça me va bien, ça engage aussi une réflexion suivant plusieurs angles d'attaques.

Pas de question de bassiner, il s'agit de définir rigoureusement de quoi on parle. Pomme, poire, ce n'est pas la même chose, virus, ver, troyen non plus.
L'informatique est une science, s'appuie sur des données techniques concrètes et normées, pas des incantations magiques.
 

Ce raccrochage aux branches surpuissant    La centralisation des informations, c'est un concept-clé de ce genre d'outils. Alors dire qu'ils fonctionnent de façon autonome    
Donc oui ils ouvrent des ports avec un ou plusieurs hôtes distants, ce qui augmente la vulnérabilité du serveur. Dans quelques proportions, ça c'est effectivement une autre histoire.
Et là , on ne parle que de la partie réseau. Ces logiciels (qui ont des failles) ont parfois des prérequis qui eux-mêmes ont des failles (par exemple, on a découvert récemment chez un client qu'un soft de monitoring du RAID installait un client Java (obsolète) au passage).
 

Relis mon poste : la problématique, c'est qui garantit ta source ? Dois-je faire une confiance aveugle à n'importe éditeur, au point de retirer un des éléments de protection-clé de mes serveurs ? Pour l'instant ta réponse me semble "oui".
Ensuite tu parles d'une "moulinette" d'un AV, mais techniquement, c'est quoi ? un hash ?
 

Par conséquent, tu admets déjà que l'on est ici un cas ultra-spécifique (des BDD de très grandes tailles ultra-sollicitées) alors qu'au début tu généralisais à tous les SGBD.
Ensuite, tu ne te bases sur aucun bench ou démonstration technique pour valider l'existence de ce "moment". Concrètement, l'installation d'un antivirus va diminuer les perfs d'une machine, quelle qu'elle soit (vu que l'on ajoute une couche logicielle supplémentaire, gourmande en ressources et ayant un fort impact sur le système).
Donc la problématique, c'est est-ce cette perte de performance (plus le risque ajouté en cas de crash lié à l'antivirus) s'avère moins coûteuse que la perte/fuite de données/coupure du service résultant d'une infection ?
 
Edit : je nuance mes propos. Dans le cas très particulier que tu mentionnes, une logique purement comptable pourrait effectivement préconiser de ne pas installer d'antivirus, puisque c'est rajouté du code, des failles, de la perte de perfs, des risques système importants etc...masi à condition que cela coûte moins cher que les effets d'une éventuelle infection.
 
Dans le cas particulier que tu cites, on peut parler de chiffres à 5 ou 6 zéros. Largement supérieur au prix d'une licence et à la perte de performances/crash éventuels à mon avis .
 

Justement, comme leur fonctionnement diffère, les méthodes de propagation, le périmètre impacté et les méthodes de défense ne sont pas les mêmes.
 
 

Désolé ce n'est pas un article bourré d'égo, d'approximations et de contre-sens (affirmer que Flame est le produit d'un codeur du dimanche, il faut oser) qui risque de me convaincre. Surtout que techniquement, il est vide (un peu comme tes arguments).
 
 

Tu réalises à quel point tu te contredis ?
"un serveur sans AV n'est pas moins vulnérable,mais en fait si"
"un serveur SBGD nécessite un antivirus, mais dans le cas ultra-rare X, en fait non"
 
Tu pars d'une situation ultra-spécifique (et qui n'existe pas en réalité comme je te l'ai montré) pour en faire une généralité. C'est si difficile que ça à comprendre ?

Et si on parle des fruits dans leur ensemble, sur leurs caractéristiques communes, a quoi sert le gars qui vient te causer du fait que les fruits, c'est les pommes, les poires, les mandarines, etc ?
Mis à part vouloir prouver qu'il s'imagine fin connaisseur en agriculture, c'est quoi l'utilité ?
En quoi différencier un virus d'un ver ou d'un troyen change t'il l'analyse du problème quant à protéger ou non un serveur ?
Moi le terme que j'utilise pour tous les programmes malveillants, c'est "virus". Le reste c'est de la littérature pour précieux qui va devenir inutile puisque l'évolution des virus s'oriente vers ne pas respecter les cases absurdes et étroites des "experts".
(HS : dans les fruits, on y est aussi, par génétique on peut te coupler une banane avec une pomme. On a pas l'air con du coup à s'arc-bouter sur la différenciation "banane" et "pomme" )

Es-tu au courant qu'un logiciel peut communiquer avec l'extérieur sans être lui-même à l'écoute ?
Lorsque mon openmanage m'envoie un email, j'ai pas eu besoin d'ouvrir le port 25 sur mon serveur Et même si l'idée saugrenue de le faire me prenait. Je n'ai pas de service à l'écoute sur le port 25.
Donc inutile d'ouvrir des ports pour que certains applicatifs sur un serveur communiquent sur le réseau.
Et comme tu le reconnais, même si j'ouvre un port pour administrer mon openmanage depuis un autre, il est très peu probable voir quasi certain qu'un virus n'exploitera pas une supposée faille sur ce service. Les concepteurs de virus s’intéressent à la propagation la plus large possible. Pas question de s'appuyer sur un soft qu'on va trouver dans 0.0001% des cas.
le jour où un virus exploitera une faille dans openmanage, c'est que le concepteur se sera fait chier à s'intéresser à ce service très précisément parce que sa cible est très précise et qu'il a connaissance qu'elle possède ce service.
En ce qui concerne JAVA, on sort du contexte des failles de processus qui écoutent sur le réseau pour celui des failles dans des processus qui traitent des données locale.
Un JAVA avec faille peut-être installé sur mon serveur sans que jamais je lui fournisse du code qui exploitera sa faille.
Mais JAVA est trop attaqué et faillible. Il faut l'éviter autant que possible sur les serveurs critiques. Donc exit le soft qui l'utilise.

Non tu n'es pas obligé de faire confiance à l'éditeur. Tu n'es pas obligé non plus de télécharger les packages d'installation sur le serveur ou insérer le CD d'install dans le serveur.
Tu peux le faire sur un poste muni d'un AV puis les transférer sur le serveur. C'est même la bonne méthode.
Et si ton AV sur ton poste ne détecte pas un problème, que va faire l'AV sur le serveur de plus ?

Bien sûr qu'on est dans des cas spécifiques. Qui a vu et où que je défendais l'idée que l'AV est inutile dans l'absolu ?
Un je cause des SGBD et deux pas de toutes. CF mon 1er post :
"Bien sûr je ne cause pas de la petite base avec quelques utilisateurs. Même avec des perfs dégradées, cela peut être transparent pour les users.
Je cause des SGBD avec de vrais besoins de perfs."

Bien que je ne sois pas sûr d'avoir saisi ta dernière phrase, je crois qu'on se rapproche. Tout est possible
Il s'agit de mettre sur la balance des arguments et de peser le pour et le contre.
Dans la majorité des cas, on ne se pose pas la question de l'AV. Ca ne coûte rien (en terme de licence), ca peut rendre service et niveau perf, personne nous emmerde. Donc dégradée ou pas par rapport à un optimum, on s'en fout.
J'ai des tas de serveurs avec des AV depuis des années qui n'ont jamais servi à rien. Pas grave, ils n'ont pas nuit non plus.
Mais sur des serveurs très peu ou pas exposé, aux besoins de perfs critiques, comme les grosses SGBD, l'AV pose plus de problème qu'il ne sert.

Je trouve au contraire que cet article est à considérer.
Un programme de 20Mo sur 600 postes aux moyen orient uniquement dont le but est de capturer les entrées/sorties des users, je n'appelle pas cela un virus mais un keylogger super amélioré, sans contrainte technique trop forte pour sa propagation, dans le seul but d'espionner des personnes précises.
Avec Flame, on n'est pas du tout dans le cadre des risques posées aux sociétés en général.
Mais j'admet que si j'étais une boite en Iran qui bosse avec le pouvoir, je verrai différemment.
Et si j'étais dans la défense en règle générale aussi. Mais dans ce cas là, ce n'est pas sur l'AV que je m’appuierai car dans le cas de Flame, il a été assez inutile pour les personnes touchées. La découverte a été faite par hasard et bien a posteriori de la propagation.

ça devient passionnant ce genre d'échanges. J'aime quand ça cause sérieux.
Le coup du ver dans la pomme, c'est intéressant aussi comme point à aborder... si un cheval de troie s'attaque uniquement aux SGBD pour les sapper ou les exporter, doit-il être considéré comme virus ?
Idem pour les "sources" des mises à jour : quid par exemple d'un serveur local de mises à jour pour les antivirus et les mises à jour OS ?
Faut-il utiliser 1 seul antivirus (1 seule marque) ou faudrait-il plutôt mixer différentes marques sur le réseau, afin de se prémunir d'une attaque ? (genre du McAffee sur un serveur X avec de l'eTrust sur de la machine cliente Y)

2 Antivirus différents serveurs /station ça évite de se retrouver cul nul sur l'ensemble du SI en cas de problème avec une solution (les derniers mois ont montrés que ça arrive) , c'est aussi une protection supplémentaire s'ils utilisent des référentiels différents.
ça double le travail de mise en place, mais ça me semble un bon choix.

Tiens je viens justement de faire l'expérience de l'AV sur un serveur DB (et j'ai pas fini vue que je renouvelle 100 serveurs en virtu ... Bonjour le taf)

Histoire :

Nous sommes Full MS. Nous engageons le renouvellement de notre infra matériel sur une virtualisation Hyper-V 3. Pour gérer cette plateforme (Mais pas que !) nous installons toutes les briques de la gamme system center sur un cluster hyper-v en dehors du périmètre, isolé dans une baie. Ce cluster est composé de 3 serveur bi-pro avec 64 Gb de RAM chacun, connectés en iSCSI sur une baie equalogic (24 disques sas 15K en raid 60-11 dont 2 pour le spare).

Systems center utilise forcément des DB SQL Server. Nous avions constaté, malgré le monstre qui compose cette plateforme, une bien pauvre performance sur les applicatifs.

Après avoir déjà fais remonté quelques BUG à MS (une personne chez non est dans le programme TAP MS system center) je me suis penché sur l'AV.

Le RSSI, service secu bien distinct de l'administration, n'avait pas passé les exclusions sur l'AV (Forefront ... Oui oui full MS ). En passant les exclusions préconisés par MS sur ces produits ... Tout est rentré dans l'ordre.

Je peux comprendre l'argumentation de shongail dans le cadre d'une société qui n'a pas forcément les moyens de prévoir l'impact de l'antivirus sur sa plateforme ... Il faut de tout pour faire un monde et si l'environnement est bien sécurisé on MINIMISE le risque, ce qui est déjà une bonne démarche.

Par contre ... Quand on a la possibilité de le faire ... Pourquoi ne pas le mettre ? Déjà ... Quand je vois des prestas installé un SQL Server en faisant suivant/suivant et ne même pas ouvrir la GUI pour paramétré un minima de chose (mémoire alloué, processeurs, fragmentation, régler la croissance de la BASE/LOGS) .... Je me dis qu'avant de virer l'antivirus ... Moi qui ne suis pas du tout un expert SQL ... Certains devraient peut être paramétrer l'application

Voilà, quand ça ne fonctionne pas ou que c'est lent c'est "la faute à l'antivirus" ou "la faute au système d'exploitation" voire "le matériel n'est pas assez performant !"  
En faisant du "suivant suivant suivant terminé" ah c'est sûr ça démarrera rapidement pour la 1ère utilisation mais ensuite ?
 
De la même manière, certains admins réseaux se retrouvent admin DB, alors qu'il s'agit de 2 boulots bien distinct. Pour chercher du taf, quand j'en parle lors des entretiens j'ai en réponse "oui mais le candidat d'avant nous a dit que...". Et 2 mois après comme par hasard soit l'entreprise relance l'annonce sur le même poste (donc celui pris ne faisait pas le taf ou mal, hop viré), soit ils cherchent un admin DB. ça me gonfle d'avoir à faire avec des personnes qui n'y connaissent rien

 
 
Salut, j'ai pas bien pigé : t'as 100 VMs sur trois hôtes 2CPU/64Go de RAM ?
Et niveau expérience SGBD, on cause de celle utilisée par System Center !?

J'ai une centaine de serveurs physique à migrer sur un cluster hyperV à 6 Nœuds, et nous avons monté un autre cluster (physiquement séparé) à 3 nœuds qui héberge toutes la gamme system center Et les SGBD là je ne parle que de system center, puisque l'on a pas encore validé la nouvelle infra de production

 
Tu parles de ces offres où faudrait faire :
- du réseau avancé
- de l'admin Windows
- de l'admin Linux
- de la SGBD
 
et si possible connaitre 12 marques de firewall et faire de la hotline ?
 
Quand je cherchais, je ne répondais même pas à ces offres ... Comment se jeter dans le mur direct

Exactement. Alors que autant admin Windows, Linux et réseau, ça peut à la rigueur se cumuler (et encore, ça bossera bien niveau heures), le gars qui dit "je suis admin SGBD et admin Windows aux 35h" déjà je trouve ça suspect sur son niveau ou sur l'entreprise

 
  Exemple en live: Après avoir accusé l'av, la config du système, puis le matos, maintenant , juste après un upgrade du serveur, (l'appli continue de planter et le serveur de figer régulièrement) avertissement du presta: Faut redémarrer le serveur régulièrement pour améliorer sensiblement les perfs.
Et mon responsable qui valide... ...>> Monster.fr
 
Effectivement le tuning sql est essentiel pour la performance et je plussoie mille fois : DBA c'est un métier a part entière!
Que chacun fasse son job et les perfs seront celles attendues!