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


14

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?

Réponses:


17

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.


+1 ne peut rien ajouter d'autre à cette réponse
Nick Kavadias

Je ne pense pas que la licence de groupe de travail et d'édition Web puisse être utilisée pour des applications d'entreprise hébergées externes.
Akash Kava

1
Les licences CPU sont disponibles pour toutes les éditions (sauf Express qui n'a pas besoin de licence CPU) ce qui signifie que vous pouvez l'utiliser pour un site Web public. Voici le lien vers la licence de processeur de groupe de travail bit.ly/KDLDR . Je ne pouvais pas trouver facilement l'édition Web, mais n'importe quel VAR devrait être en mesure de le fournir sans beaucoup regarder autour.
mrdenny

Je suggère également de commencer par quelque chose au-dessus d'Express, et passer de l'express à toute autre édition peut parfois être difficile.
DanBig

3
SQL Express est exactement le même moteur que les autres éditions, juste avec des limites de taille en place. Passer d'Express à une autre édition consiste simplement à détacher la base de données de l'édition Express et à la rattacher à une autre instance qui exécute une autre édition.
mrdenny

15

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

Sauvegardes planifiées

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?

2
  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.


Je pensais que SSE 2008 utilisait plusieurs cœurs (jusqu'à 4)?
Bip bip

@LuckyLindy Standard utilisera jusqu'à 4 sockets, avec autant de cœurs par socket que vous en avez.
mrdenny

"mais jusqu'à ce que la taille de votre base de données dépasse 4 Go" 4 Go est la restriction par instance. Je ne me souviens pas qu'il y ait une restriction sur le nombre d'instances utilisées
Gennady Vanin Геннадий Ванин

2

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.


2
Scott - Excellente réponse. À votre point ... SQL Server Express n'a en fait aucune limite de taille de stockage entre les bases de données, vous ne pouvez tout simplement pas avoir une seule base de données avec plus de 4 Go de données. Comme test, j'ai créé 10 000 bases de données de 100 Mo (1 To) sur un seul serveur et SQL Server Express s'est bien déroulé. De plus, la mémoire liée à chaque connexion n'est pas prise en compte dans le total de 1 Go. Je suis d'accord que la gestion de toutes ces bases de données pourrait être un peu pénible ... mais comme nous aurons en fait des milliers de bases de données, nous aurions probablement besoin de scripts de toute façon (il n'y a aucun moyen que je veuille toucher manuellement une base de données à moins qu'elle ne devienne corrompu).
Bip bip

+1, je suis d'accord pour dire que c'était une réponse gr8 mais j'ai aussi voté pour
Gennady Vanin Геннадий Ванин

1

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.


2
Nous avons en fait effectué des tests de performances contre toutes les principales bases de données l'année dernière - MySQL, PostgreSQL, Firebird, DB2, Oracle, SQL Server, SQL Server Express et SQL Desktop. Nous avons constaté que DB2, Oracle et SQL Server (et Express, mais pas Desktop) ont fait exploser MySQL et PostgreSQL sur Windows pour nos opérations transactionnelles - par un facteur de 2 1/2, la performance signifie le double du nombre de serveurs. Hébergés sur Linux, MySQL et PostgreSQL ont fait un peu mieux, mais toujours pas à la hauteur.
Bip bip

1

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".


C'était un post de 7 ans en fait :)
BaronSamedi1958
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.