Estamos a punto de lanzar una aplicación transaccional dual web / interna donde cada cliente tiene su propia base de datos. Cada base de datos es muy pequeña, menos de 50 MB cada una, por lo que nos preguntamos si tendría sentido usar SQL Express 2008 en lugar del SQL Server completo.
Esto parece tener las ventajas de distribuir E / S de disco a través de servidores mientras se ahorra mucho dinero (ya que las unidades pequeñas de 15K y los servidores de doble núcleo usados son económicos). Si en algún momento necesitamos demasiados servidores, podemos actualizar a SQL Server ... pero con docenas de usuarios internos, esto parece demasiado costoso en este momento (especialmente porque necesitaríamos un cuadro de conmutación por error).
La memoria de 1GB y el uso de 4 núcleos en un solo procesador no suena demasiado restrictivo dados nuestros pequeños tamaños de bases de datos. Nunca tendremos más de ~ 200 usuarios simultáneos, y la mayoría de las operaciones serán más transaccionales (lo que parece favorecer muchos discos de alta velocidad sobre RAM / CPU pesados, ¿verdad?)
¿Me estoy perdiendo alguna ventaja de SQL Server Standard que podría justificar la inversión adicional de $ 5-20K inicialmente?
Algunos problemas de producción y soluciones que he tenido con la edición Express:
Copias de seguridad programadas
SSIS
¿Puedo ejecutar paquetes SSIS con SQL Server 2008 Express / Web o Workgroup
SSIS con Sql Server 2005 express
Perfilado
fuente
Si lee la Licencia de SQL Server, no necesita comprar una licencia adicional para el servidor pasivo si solo se usa para la conmutación por error y no atiende consultas hasta que su primer servidor falla.
Hemos usado SQL Server Express durante bastante tiempo, y es bueno y mucho mejor que el MSDE anterior, tenemos más de 200 conexiones simuladas, pero solo tenemos una base de datos de tamaño 2GB, y todo es fluido. Nunca tuvimos ningún problema siempre que evitemos uniones costosas y hagamos una buena indexación. Ahora estamos utilizando SQL Standard, pero hasta que el tamaño de su base de datos sea superior a 4 GB y su número de usuarios sea inferior a 200-500, ciertamente puede vivir con SQL Express.
SQL Server Express usa poco menos espacio de memoria ~ 200 MB, donde la edición estándar usa ~ 1.5 GB, probablemente porque la edición estándar hará mucho almacenamiento en caché. Sus consultas serán más lentas en Express en unos pocos milisegundos en comparación con la edición estándar. Desafortunadamente, la edición Express no utiliza cpus multi-core (esa es una función limitada), por lo que no será de gran ayuda si tiene 2 core o 4 core.
fuente
LuckyLindy: te animo a que te detengas por un segundo y verifiques que no necesitas el Agente SQL. Tu escribiste:
¿Cuál es su plan para las copias de seguridad? No tiene que usar el Agente SQL, pero seguro le facilita la vida a un DBA. Puede escribir T-SQL / SMO / PowerShell / cualquier script que haga sus copias de seguridad y luego ejecutarlo a través de sqlcmd o PowerShell usando una tarea programada.
¿Cuál es su plan para el mantenimiento de la base de datos? Con el tiempo, esas bases de datos deberán desfragmentarse y comprobarse para mantener su coherencia. Standard Edition tiene todo tipo de beneficios para facilitar esto, mientras que en Express, tienes que trabajar (nuevamente con las secuencias de comandos y las tareas programadas).
¿Cómo se le notificarán los problemas en el servidor? El Agente lo ayuda aquí con Alertas para notificarle cuando un registro se está llenando, un disco se está llenando, etc.
Estas son tareas críticas del tipo DBA de SQL Server. Una cosa es ejecutar Express para una aplicación interna, pero una vez que comienza a decirnos que está alojando estos para clientes, me preocupa :)
La parte 2 de esto es preguntarle a cuántos clientes planea apoyar esto, tanto en el lanzamiento como después de un año. Si dice "100 clientes", entonces 100 bases de datos de 50 MB no serán suficientes en Express, simplemente no tiene suficiente memoria. Diablos: dependiendo de cuánto delta tengas, podrías alcanzar un máximo de 15 DB, no lo sé.
Las operaciones transaccionales como INSERTs todavía se escriben en la memoria, por lo que no espere que necesite menos soporte de memoria. De hecho, dependiendo de cuántos INSERTs hagas, es posible que tengas mayores necesidades de memoria que la mayoría con esa cantidad de usuarios. Si está cargando muchos datos que la gente realmente no usará, entonces todavía ocupa memoria. Puede encontrar problemas de contención entre "datos que los usuarios consultan con frecuencia" y "datos que los usuarios están cargando y que nadie consultará por un tiempo". SQL nos protege al preservar los datos que las personas consultan con mayor frecuencia en la memoria durante más tiempo, pero aún tendrá contención.
En este punto, estoy divagando jajaja. Y 200 usuarios concurrentes tampoco están de acuerdo conmigo para Express. Digamos que 64k es un requisito promedio de memoria de conexión, ¿cuántas conexiones harán sus aplicaciones? ¿Utilizará la agrupación de conexiones?
En general, mi instinto al leer su descripción dice: "No - Express Edition simplemente no es lo suficientemente potente". Y odio la Workgroup Edition, creo que es un mal negocio, por lo que Standard me parece correcto.
fuente
¿Ha considerado usar uno de los DBMS gratuitos (MySQL, PostreSQL ...)? ¿Eso aliviaría sus preocupaciones de licencia?
Si esa no es una opción, SQL Server Express parece una buena solución.
fuente
Ciertamente se puede usar para aplicaciones de producción importantes. Lo hemos usado en más de 1500 clínicas de atención médica, todas con instancias separadas de SQL Server Express instaladas para procesar millones de transacciones cada día. Puede evitar fácilmente la desventaja del Agente SQL Server utilizando uno de los siguientes:
Vea la excelente presentación de Michael Otey (google it) sobre "Uso de SQL Server Express en producción".
fuente