SQL Server Express pour les bases de données de production?

Nous sommes sur le point de déployer une double application transactionnelle web / interne où chaque client dispose de sa propre base de données. Chaque base de données est très petite - moins de 50 Mo chacune, donc nous nous demandions s'il serait judicieux d'utiliser SQL Express 2008 au lieu de SQL Server complet.

Cela semble avoir les avantages de distribuer les E / S disque sur les serveurs tout en économisant d'énormes $$$ (car les petits lecteurs 15K et les serveurs dual core utilisés sont tous deux peu coûteux). Si à un moment donné, nous avons besoin de trop de serveurs, nous pouvons passer à SQL Server ... mais avec des dizaines d'utilisateurs internes, cela semble tout simplement trop cher en ce moment (d'autant plus que nous aurions besoin d'une boîte de basculement).

La mémoire de 1 Go et l'utilisation de 4 cœurs sur un seul processeur ne semblent pas trop restrictives compte tenu de nos petites tailles de base de données. Nous n'aurons jamais plus de ~ 200 utilisateurs simultanés, et la plupart des opérations seront plus transactionnelles (ce qui semble favoriser beaucoup de disques à haute vitesse par rapport à la RAM / CPU lourde, non?)

Suis-je absent des avantages de SQL Server Standard qui pourraient justifier l'investissement supplémentaire de 5 à 20 000 $ initialement?

Les autres éditions de SQL Server vous offrent des fonctionnalités telles que l'Agent SQL afin que vous puissiez planifier la maintenance de la base de données et d'autres tâches.

Tant que votre base de données peut s'adapter aux limites de l'édition Express, tout ira bien.

Le serveur SQL aime beaucoup de RAM. Plus c'est mieux. Comme SQL Server ne peut pas charger de données dans le cache, cela ajoutera une charge supplémentaire aux disques. Vous devez consulter l'édition Web ou l'édition Workstation de SQL Server. Ces éditions ont des limites plus élevées que l'édition Express, mais coûtent moins cher que l'édition Standard.

Si vous commencez avec l'édition Express, vous pouvez toujours mettre à niveau ultérieurement vers l'édition Standard après avoir acheté la licence.

Quelques problèmes de production et solutions de contournement que j'ai rencontrés avec l'édition Express:

Sauvegardes planifiées

• Aucun agent SQL
• Solution: utilisez n'importe quel planificateur pour exécuter le script de sauvegarde SQLCMD ou Expressmaint
• Voir aussi: Comment planifier une sauvegarde quotidienne avec SQl Server Express?

SSIS

• SQL Express 2008 dispose de l'assistant d'importation / exportation de données, mais le runtime dtsexec de l'édition Express n'exécutera pas tous les packages SSIS
• Solution: vous pouvez développer des packages SSIS avec l'édition Developer. Si vous avez une édition Standard sur le réseau, vous pouvez planifier et exécuter des packages SSIS à partir de celle-ci. Vous pouvez même exécuter des packages SSIS à partir de l'édition développeur, tant que ce n'est pas contre la licence
• Voir aussi:
  Puis-je exécuter des packages SSIS avec SQL Server 2008 Express / Web ou Workgroup
  SSIS avec Sql Server 2005 express

Profilage

• Pas de profileur SQL
• Solution: essayez SqlProfiler pour Express Edition
• Mise en garde: Je n'ai pas trouvé cela toujours utile pour résoudre les urgences de production, comme lorsque sqlexpress prend 100% de la capacité du processeur du serveur. Je n'ai pas pu obtenir la trace du profileur dans un tel cas.
• Voir aussi: Quel profileur utiliser avec sql express?

1. Si vous lisez la licence SQL Server, vous n'avez pas besoin d'acheter de licence supplémentaire pour le serveur passif s'il est uniquement utilisé pour le basculement et il ne sert pas de requêtes jusqu'à ce que votre premier serveur tombe en panne.

2. Nous utilisons SQL Server Express depuis assez longtemps, et son bon et bien meilleur que MSDE antérieur, nous avons plus de 200 connexions simulées, mais nous n'avons qu'une seule base de données de taille 2 Go, et tout est fluide. Nous n'avons jamais eu de problèmes à condition d'éviter les jointures coûteuses et de bien indexer. Nous utilisons maintenant SQL Standard, mais jusqu'à ce que la taille de votre base de données soit supérieure à 4 Go et que votre nombre d'utilisateurs soit inférieur à 200-500, vous pouvez certainement vivre avec SQL Express.

3. SQL Server Express utilise un peu moins d'espace mémoire ~ 200 Mo alors que l'édition Standard utilise ~ 1,5 Go, probablement parce que l'édition standard fera beaucoup de mise en cache. Vos requêtes seront plus lentes dans Express en quelques millisecondes par rapport à l'édition standard. Malheureusement, l'édition Express n'utilise pas de processeurs multi-cœurs (c'est une fonctionnalité limitée), donc cela ne sera pas d'une grande aide que vous ayez 2 cœurs ou 4 cœurs.

LuckyLindy - Je vous encourage à vous arrêter un instant et à vérifier que vous n'avez pas besoin de l'agent SQL. Tu as écrit:

Nous sommes sur le point de déployer une double application transactionnelle web / interne où chaque client dispose de sa propre base de données. Chaque base de données est très petite - moins de 50 Mo chacune, donc nous nous demandions s'il serait judicieux d'utiliser SQL Express 2008 au lieu de SQL Server complet.

Quel est votre plan pour les sauvegardes? Vous n'avez pas besoin d'utiliser l'Agent SQL, mais cela rend la vie d'un DBA plus facile. Vous pouvez écrire des scripts T-SQL / SMO / PowerShell / quels que soient vos sauvegardes, puis les exécuter via sqlcmd ou PowerShell à l'aide d'une tâche planifiée.

Quel est votre plan pour la maintenance de la base de données? Au fil du temps, ces bases de données devront être défragmentées et leur cohérence vérifiée. L'édition standard a toutes sortes de goodies pour rendre cela facile alors que, dans Express, vous devez travailler (encore une fois avec les scripts et les tâches planifiées).

Comment serez-vous informé des problèmes sur le serveur? L'agent aide ici avec les alertes pour vous avertir lorsqu'un journal est plein, un disque se remplit, etc.

Il s'agit de tâches critiques de type DBA SQL Server. C'est une chose que d'exécuter Express pour une application interne, mais une fois que vous commencez à nous dire que vous les hébergez pour des clients, je m'inquiète :)

La partie 2 de ceci vous demande combien de clients vous comptez soutenir à ce sujet - à la fois au lancement et après un an? Si vous dites "100 clients", alors 100 bases de données de 50 Mo ne suffiront pas sur Express - vous n'avez tout simplement pas assez de mémoire. Heck - selon le delta que vous avez, vous pourriez avoir un maximum de 15 DB, je ne sais pas.

Nous n'aurons jamais plus de ~ 200 utilisateurs simultanés, et la plupart des opérations seront plus transactionnelles (ce qui semble favoriser beaucoup de disques à haute vitesse par rapport à la RAM / CPU lourde, non?)

Les opérations transactionnelles telles que les INSERT sont toujours écrites en mémoire, ne vous attendez donc pas à moins de prise en charge de la mémoire. En fait, selon le nombre d'insertions que vous effectuez, vous pourriez avoir des besoins en mémoire plus importants que la plupart avec ce nombre d'utilisateurs. Si vous chargez beaucoup de données que les gens n'utiliseront pas vraiment, cela occupe toujours de la mémoire. Vous pouvez rencontrer des problèmes de contention entre «les données que les utilisateurs interrogent fréquemment» et «les données que les utilisateurs chargent et que personne n'interrogera pendant un certain temps». SQL nous protège en préservant les données que les personnes interrogent plus fréquemment en mémoire plus longtemps, mais vous aurez toujours des conflits.

À ce stade, je divague lol. Et 200 utilisateurs simultanés ne jibe pas avec moi non plus pour Express. Disons que 64k est la mémoire moyenne requise pour la connexion, combien de connexions vos applications feront-elles? Allez-vous utiliser le pool de connexions?

Dans l'ensemble, mon intuition à la lecture de votre description dit: "Non - l'édition Express n'est tout simplement pas assez puissante." Et je déteste l'édition Workgroup - je pense que c'est une mauvaise affaire - donc Standard me semble juste.

Avez-vous envisagé d'utiliser l'un des SGBD gratuits (MySQL, PostreSQL ...)? Cela atténuerait vos problèmes de licence?

Si ce n'est pas une option, SQL Server Express semble être une bonne solution.

Il peut certainement être utilisé pour des applications de production importantes. Nous l'avons utilisé dans plus de 1500 cliniques de soins de santé, toutes avec des instances SQL Server Express distinctes installées pour traiter des millions de transactions chaque jour. Vous pouvez facilement contourner l'inconvénient de l'Agent SQL Server en utilisant l'un des éléments suivants:

1. Produit tiers tel que SQLAutomate
2. Planificateur de tâches Windows
3. Une édition Standard ou Enterprise de SQL Server avec la capacité de serveur maître installée 1 et 2 est très peu coûteuse ou gratuite. 3 est cher à moins que vous ne l'ayez déjà dans votre environnement.

Voir l'excellente présentation de Michael Otey (google it) sur "Utilisation de SQL Server Express en production".