Discussion :

[Papy214]

Bonjour,

Nous sommes en train de changer l'organisation des ordis dans la société.
Les IDE de développement vont être placés dans des machines virtuelles avec Hyper-V. Par exemple, je vais disposer d'une VM pour travailler avec Delphi XE5, d'une autre pour XE3, etc.

Le problème se pose pour SQL SERVER. Je ne vais pas installer autant de SQL Server que de VM. J'ai le choix entre 2 solutions: Installer SQL Server :

• sur mon poste (machine hôte des VM)
• dans une VM Win XP avec une minimum de ressources allouées, qui tournerait en permanence.

Pour la seconde solution, quel serait le minimum à allouer à windows pour que SQL Server 2012 express fonctionne sans problème ? (Les performances importent peu)

Papy !

[darkelend]

Dans la documentation, pour une instance 2012 express, le minimum de RAM est de 512Mo :
"Thirty-two-bit SQL Server 2012 Express, Express with Tools, and Express with Advanced
Services editions have the same processor requirements as the other 32-bit editions but
require
a minimum of 512 MB of RAM and a recommended RAM of 1 GB or more."
(c'est la même chose pour la RAM en 64 bits)

[Invité]

Pour le dev, je mets l'instance de bds sur le serveur applicatif.
Comme ça, je garde la maitrise des bds / application.
Sinon il y a un moment où l'applicatif est supprimé (sans que l'on me prévienne, ça serait trop simple) et je continue à faire des sauvegardes et la maintenance de bds de DEV inutilisées pendant des mois... Et l'avantage, c'est que quand tu fermes la VM, tu gardes tes ressources pour des VM qui sont actives.
Bien sûr, ça dépend de ton contexte, mais c'Est mon retour d'expérience de ces dernières années.
Pour 2008R2, un plafond d'1 Gb de RAM est correct pour les applications, en dessous, ça peut être problématique.

[Papy214]

C'est vrai que l'avantage de lier la VM à l'application et à la base est la solution "simple". Ca fait un bloc cohérent.

Je vais voir ça. Merci à tous les deux

[Invité]

Un autre avantage d'avoir l'instance sur la même VM que l'applicatif est que si une application part en vrille et fait n'importe quoi au niveau bd, au moins, les dev le remarquent tout de suite sans pour autant impacter d'autres bases de données.
Les désavantages, multiplier les instances et leur maintenance.

[SQL_EVAN]

En dév ce sera plus facile d'avoir les serveurs SQL sur les mêmes machines que les applications. Cependant, en production faites attention à ça! Le mélange injection SQL, xm_cmdshell (si activé) et le serveur applicatif et base de données étant sur la même machine peut être une catastrophe.