Instancia de SQL Server: ¿Debería utilizar varias instancias o bases de datos?

Instancia de SQL Server: ¿Debería utilizar varias instancias o bases de datos?

Tengo un servidor razonable conectado a una SAN que ejecutará servidores SQL para múltiples aplicaciones de la misma aplicación. No hay problemas de seguridad si una aplicación puede leer la base de datos de otra.

Desafortunadamente, también estamos en Windows de 32 bits.

Soy de la opinión de que sería mejor usar una instancia en el servidor, habilitar AWE para que la instancia del servidor pueda usar casi toda la RAM que tenemos y luego ejecutar cada una de las bases de datos en una instancia.

Sin embargo, los dioses del departamento de TI me han anulado en este caso, así que tengo mucha curiosidad por escuchar tu opinión al respecto. Desde el punto de vista del rendimiento, ¿me equivoco al decir que una instancia de SQL es mejor que dos?

Sé que podríamos hacer algunas cosas de conmutación por error, pero hacerlo en una sola hoja me parece excesivo.

Respuesta1

SQL Server 2000 y 2005 Workgroup y Standard (32 bits, no estoy seguro acerca de 64 bits) solo usarán un máximo de 2 GB de memoria, por lo que tener dos instancias le permitiría usar los 4 GB completos. Esto sería cierto incluso si está ejecutando SQL Standard de 32 bits en Windows x64, más aún si desea una instancia por cada 2 GB de memoria.

En principio, usar una sola instancia con dos bases de datos es más rápido que dos instancias con una base de datos cada una, aunque no estoy convencido de que sea una gran diferencia. Tener instancias separadas puede resultar útil para la gestión. Por ejemplo, si utiliza inicios de sesión SQL y hay diferentes conjuntos de inicios de sesión para diferentes bases de datos, el uso de instancias separadas puede facilitar el seguimiento de los inicios de sesión.

Entonces la respuesta a tu pregunta es "Depende" :-)

J.R.

Con respecto al comentario de Spence: SQL Server Standard en Windows de 32 bits puede usar un máximo de 2 GB de memoria. SQL Server Enterprise puede usar 3 GB si usa el modificador /3GB. En Windows 2003 Enterprise con AWE se pueden utilizar hasta al menos 16 GB de memoria (posiblemente más) para que pueda obtener un mejor valor de su memoria ejecutando más de una instancia de SQL Server.

Me temo que la respuesta sigue siendo "depende". Si tiene mucha memoria, es decir, 8 GB o 16 GB, entonces querrá colocar las bases de datos más grandes en instancias separadas para que puedan tener 2 GB (o 3 GB con /3 GB) cada una. Si solo tiene 4 GB, probablemente usaría una sola instancia y el modificador /3 GB, ya que la pequeña cantidad de memoria adicional utilizada al tener dos instancias no valdría la pena.

Como otros han comentado a continuación, puede haber otras consideraciones. Si hace referencia a dos bases de datos al mismo tiempo, por ejemplo, en una consulta de selección o si inserta desde una base de datos en otra, entonces las querrá en la misma instancia para mayor velocidad.

Respuesta2

32 bits es un callejón sin salida.

En SQL2K5, el consumo de memoria para cosas como la compilación del plan, el tamaño del plan en sí y, por lo tanto, el caché de proceso, han aumentado significativamente en más de 2k. Además, otros componentes, como la caché del token de permiso, tienden a crecer si tiene muchos usuarios (es decir, organizaciones grandes y suplantaciones de nivel medio). Dado que todo esto no puede beneficiarse de AWE, le resultará difícil adaptar un sistema ocupado a un espacio de memoria de 32 bits. Si tiene consultas y planes complejos, agregar las instancias puede resultar en el robo de un porcentaje muy alto del grupo de búfer para que estos cachés dejen un pequeño grupo de búfer para los datos, lo que resulta en un desalojo constante del caché de los planes compilados y una expectativa de vida útil de la página baja.

Por otro lado, varias instancias de SQL en el mismo cuadro tienden a pisarse unas a otras, provocando presión de memoria entre sí. Dado que los administradores de memoria de las instancias no se comunican entre sí, es mucho más difícil encontrar un equilibrio en comparación con una sola instancia. Además, la programación del procesador de múltiples instancias puede sufrir problemas similares, ya que el sistema operativo se adelantará a los programadores SQL entre las instancias, lo que provocará la destrucción de la memoria caché de la CPU.

Respuesta3

En mi humilde opinión, diría que ustedes, dioses de TI, están equivocados en este caso. Siempre que no haya ningún problema de seguridad que abordar al tener varias bases de datos ejecutándose en la misma instancia, ese es el camino a seguir. Las instancias múltiples siempre introducen cierta sobrecarga, lo que efectivamente le dará a su servidor un rendimiento subóptimo. Desde el punto de vista administrativo, también es mejor ceñirse a una instancia.

Respuesta4

Como siempre, depende:¿Alguna vez las bases de datos necesitarán "comunicarse" entre sí?

Si es para la misma aplicación, a menudo encontrará ocasiones en las que desee que una base de datos lea o escriba en la otra. Si ese es el caso, es preferible tener dos bases de datos en una sola instancia. (Aquí no hay servidores vinculados, inicios de sesión compartidos, tempdb compartido).

Sin embargo, si las dos bases de datos están completamente aisladas y nunca se comunicarán entre sí y, de hecho, no tienen nada que ver remotamente entre sí (es decir, SharePoint y SAP), entonces pueden ser preferibles dos instancias. (La capacidad de ejecutarse en diferentes niveles de Service Pack o limitar la memoria utilizada por una instancia son dos ventajas que se me ocurren).

información relacionada