GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

SQL Server FAQ: ¿Qué diferencia hay entre Instancia y Base de Datos?

Volver a: [SQL Server FAQ :: Preguntas y Respuestas Frecuentes de SQL Server :: Manual SQL Server]


¿Qué diferencia hay entre Instancia y Base de Datos? Esta es una pregunta muy habitual, sobre todo, para aquellos que vienen de trabajar con otros motores de base de datos (ej: ORACLE) y también para aquellos que empiezan a trabajar con SQL Server (sin experienza). ¿Cuántas instancias de SQL Server me interesa mantener? ¿Cómo puedo organizarlas? ¿Qué motivos pueden implicar la utilización de una instancia dedicada? ¿utilizar múltiples instancias o múltiples bases de datos, cuando sólo disponemos de un único servidor?

Una Instancia de SQL Server es una instalación del motor de base de datos SQL Server, que se materializa en un Servicio de Windows que ejecuta un proceso sqlservr.exe con una configuración determinada, y sus propias bases de datos (las bases de datos del sistema, y la o las bases de datos de usuario). En un mismo equipo, pueden instalarse y ejecutarse varias Instancias (distintos procesos sqlservr.exe, cada uno con su configuración y bases de datos).

Cada Base de Datos mantiene sus propios ficheros de datos (dónde se almacenan las tablas, índices, vistas, procedimientos almacenados, y resto de objetos de base de datos), ficheros de LOG (dónde se almacenan las transacciones de dicha base de datos), configuración (Modo de Recuperación o Modo de Registro, intercalación, nivel de compatibilidad, etc.). Por el contrario, todas las bases de datos de una instancia particular, comparten la base de datos TEMPDB (dónde se almacenan los objetos temporales, resultados intermedios de consultas, etc.) y otros recursos de la Instancia, como la memoria, la afinidad de CPU, y la afinidad de entrada/salida (E/S).

En instalaciones sobre Microsoft Cluster (MSCS), es una buena práctica instalar una Instancia por nodo, debido a que la solución Cluster de SQL Server es una solución Activo/Pasivo. Así, en un Cluster de dos nodos, podemos tener una Instancia ejecutándose en cada uno de los nodos, y aprovechar así al máximo los recursos hardware que poseemos, en vez de dejar un nodo sin carga. En caso de fallo en un nodo, se producirá un balanceo, y podremos mantener el servicio ejecutándose sobre el nodo alternativo (quizas algo sobrecargado al disponer las dos instancias temporalmente) durante el tiempo necesario.

¿Cuántas instancias de SQL Server me interesa mantener? ¿Cómo puedo organizarlas? ¿Qué motivos pueden implicar la utilización de una instancia dedicada? Bajo mi punto de vista (ojo, que me puedo equivocar, y además cada cliente es un mundo), es interesante utilizar el menor número posible de Instancias de SQL Server. Del mismo modo, es interesante mantener una Instancia para cada entorno de ciclo de vida que estemos utilizando. Es decir, si sólo utilizamos un entorno de Desarrollo y un entorno de Producción, pues dos Instancias de SQL Server. Si utilizamos un entorno de Desarrollo, otro de Pruebas Integradas, otro de Calidad y Pre-Producción, y otro de Producción, pues entonces necesitaremos cuatro Instancias de SQL Server. También es recomendable instalar cada instancia en un servidor dedicado. Es decir, si necesitamos cuatro instancias, utilizar cuatro servidors. Es evidente que en muchos casos esto se deseará reducir por costes, y/o porque no sea necesario una infraestructura tan exquisita. En tal caso, se puede utilizar una Instancia de SQL Server para Producción y otra para el resto, etc. En caso de utilizar un Microsoft Cluster (MSCS) para la instalación de SQL Server, es interesante instalar una Instancia de SQL Server por cada Nodo del Cluster, de tal modo, que siempre tengamos los Nodos con carga, y no perdamos dinero con nuestra infraestructura (y por supuesto, mantengamos la Alta Disponibilidad).

En ocasiones surge la duda de si utilizar múltiples instancias o múltiples bases de datos, cuando sólo disponemos de un único servidor. Esta problemática tiene dos puntos de vistas: Es más interesante una única instancia que sobrecargar la máquina con múltiples instancias que puedan pelear por los recursos (Memoria, Procesador y acceso a disco), y además simplificar la administración (copias de seguridad, Service Packs, mantenimiento de los Jobs, etc.). Sin embargo, si tenemos una única instancia de SQL Server, y deseamos utilizarla para cubrir varios entornos de ciclo de vida, tenemos el problema de que los nombres de las bases de datos son únicos... es decir, si la base de datos de nuestra Intranet en el entorno de desarrollo y en el entorno de producción se llama IntraBD, para el entorno de pruebas tendremos que darle otro nombre ! Esto en ocasiones puede resultar algo problemático, en función de qué aplicación se trate. Por ejemplo, en ocasiones es posible encontrar en el código Transact-SQL referencias a objetos de base de datos cualificados con el nombre de la base de datos, por lo tanto, esos detalles habrá que tenerlos en cuenta a la hora de promocionar dichos objetos entre entornos (si los nombres de las bases de datos varía, claro).

Volver a: [SQL Server FAQ :: Preguntas y Respuestas Frecuentes de SQL Server :: Manual SQL Server]



Comentarios

jbsoft - 05/10/2011 (UTC)
Buenas Guille,

Tengo una consulta con respecto al manejo de usuario en instancias distintas

EL usuario SA puede tener diferentes contrasenas en las diferentes instancias en un SQL?


GuilleSQL - 05/10/2011 (UTC)
Si, no hay ningún problema. La contraseña de SA se guarda en las tablas del sistema de cada instancia, por lo que, efectivamente puedes tener distintas contraseñas en distintas instancias.

Saludos,
Guille


fifth column - 05/11/2011 (UTC)
Hola Guille,
mira mi escenario a implementar es el siguiente:

1 servidor SQL 2008 r2 con diferentes instancias para correr SAP business One y en cada instancia, generar las BD para SAP segun se requiera.

has tenido alguna experiencia en este tipo de escenarios?

los usuarios al hacer login en su cliente SAP, podran ver que existen otras BD de otras empresas?

gracias!

M


GuilleSQL - 05/11/2011 (UTC)
Hola,

Lamento no poder ayudarte... Trabajé hace bastante tiempo con Business Objects (XI y XI R2, justo antes de que Business Objects fuese comprada por SAP) y colaboré en una implementación de SAP sobre SQL Server, pero no tengo más experiencia en entornos SAP... No puedo responderte...

Saludos,
Guille


NadiaV - 23/02/2012 (UTC)
Buenos días, requiero de su ayuda.
Que inconvenientes existen al realizar una consulta con un JOIN entre tablas que se encuentran en diferentes instancias?

De antemano, gracias por sus respuestas.


GuilleSQL - 23/02/2012 (UTC)

Hola Nadia,

Por un lado están las pegas propias de realizar un JOIN, lo cual, nos puede provocar eventos de tipo Hash Join y los correspondientes problemas de rendimiento asociados. Para más info: https://guillesql.es/Articulos/Hash_Warning_Sort_Warnings.html

Por otro lado, en función de como accedas a la base de datos remota y de la propia consulta, te puedes encontrar que la instancia origen necesite "traerse" la tabla remota completa, en lugar de sólo las filas necesarias, lo cual será mucho más pesado. Por ejemplo, se puede utilizar un OPENROWSET o un OPENQUERY especificando una consulta SQL con una WHERE lo más restrictiva posible para traernos un número de filas lo más reducido posible, y sobre las mismas, realizar el JOIN.

Al final, cada caso hay que estudiar por separado. Es decir, aunque OPENROWSET u OPENQUERY nos puedan servir en unos casos, en otros, quizás sea más apropiado realizar un Paquete DTSX.

Saludos,
Guille



Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2019 (1)
Octubre de 2018 (1)
Julio de 2018 (1)
Junio de 2018 (4)
Mayo de 2018 (5)
Abril de 2018 (3)
Marzo de 2018 (2)
Febrero de 2018 (7)
Enero de 2018 (1)
Diciembre de 2017 (15)
Noviembre de 2017 (7)
Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.