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

SQL Server FAQ: ¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium?

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


¿Qué arquitectura de procesador (CPU) elegir para SQL Server? ¿32-bit o 64-bit? ¿x86, x64 ó IA64 Intel Itanium? SQL Server está disponible en distintas arquitecturas de procesador (CPU). Sin embargo, la elección de una arquitectura de procesador para SQL Server implica también su elección para el hardware y para el sistema operativo, con el correpondienten impacto en costes. Además, la elección de una arquitectura de procesador, puede implicar ciertas limitaciones de utilización del producto (direccionamiento de memoria, disponibilidad de drivers de Sistema Operativo, Conectividades - ODBC, OLEDB, .Net Providers, etc. -, disponibilidad de iFilters, disponibilidad de software, etc.). Entonces ¿Qué arquitectura de procesador me interesa para mi SQL Server?

Antes de instalar SQL Server, podemos elegir la arquitectura sobre la que construir nuestra infraestructura de base de datos. En el caso de SQL Server 2000 podemos elegir entre x86 e Itanium (IA64 - 64 bits), ya que no es posible montarlo sobre arquitectura de 64-bit de x64. En el caso de SQL Server 2005, podemos elegir entre arquitecturas de procesador CPU x86 (32 bits), x64 (64 bits) e IA64 (64 bits).

Lo primero que debemos elegir es el Sistema Operativo. La mejor manera de sacar el mejor provecho a SQL Server es elegir una arquitectura de Sistema Operativo congruente con nuestra elección de motor de base de datos (ej: Windows Server 2003 x64 y SQL Server 2005 x64) y arquitectura de procesador CPU (es decir, el "hierro"... en éste ejemplo, x64 de Intel o de AMD ;-).

Es posible montar sobre una arquitectura de procesador CPU x64 (64 bit), una edición de Windows x86 (32 bit), algo de hecho muy habitual, por costes (la pela es la pela.... jeje ;-). La arquitectura x64 es la única excepción (al tratarse de la evolución de x86, ya que Itanium IA64 es una arquitectura totalmente distinta), pues habitualmente, cada arquitectura de procesador requiere de una compilación acorde (en Itanium IA64 sólo podremos montar software para Itanium, y en x86 sólo podremos montar software para x86). Esto es un caso especial, pues en una máquina (es decir, el "hierro") x64 podemos montar Windows x86 (32 bit) y software x86 de 32 bits, o bien podemos montar Windows x64 (64 bits) y software x64 o software x86 (este último se ejecutará emulando 32 bits, en lo que se llama WoW - Windows on Windows). Un detalle... en x64 tenemos dos administradores de ODBC... el de 64 bits y el de 32 bits !!

Realizada esta pequeña introducción, ahora queda lo más importate ¿qué factores determinan la elección de una arquitectura de procesador (CPU) u otra? Alla vamos...

  • Direccionamiento de memoria. En arquitecturas x86 de 32 bit, la memoria que un proceso de Windows puede direccionar está limitada a 2GB. Para poder direccionar más memoria en SQL Server, es necesario utilizar AWE, un API que permite realizar una "paginación" entre zonas de memoria visibles por el proceso de SQL Server (los 2GB que háblabamos) y zonas de memoria no visibles (por encima de los 2GB de memoria). Esto en su día estaba muy bien, pero a fecha de hoy, poco sentido tiene, además de que dicha paginación aunque rápida (es en memoria) existe, y evitarla con un direccionamiento de memoria lineal siempre será una mejora. Por ello, si deseamos o necesitamos direccionar grandes cantidades de memoria, es interesante utilizar versiones de Windows y de SQL Server de 64 bits (x64 ó Itanium IA64).
  • Drivers del Sistema Operativo. Si elegimos un hardware y Sistema Operativo de 64 bits (ej: x64 o Itanium IA64) es importante que dispongamos de todos los drivers para dicha arquitectura para sacar el mayor provecho (drivers de VGA, de tarjetas de fiber channel para el Almacenamiento SAN, de red, etc.).
  • Disponibilidad de conectividades (ODBC, OLEDB, .Net Providers, etc.). Si desde una edición de SQL Server (ej: x64) deseamos utilizar conectividades con otros motores, será necesario disponer de los correspondientes drivers para dicha arquitectura. Si esto es requisito, por existencia de alguna aplicación de nuestra empresa, es interesante considerarlo a priori (mejor que a posteriori, verdá !! ;-)
  • Disponibilidad de iFilters. No hay duda de que la Búsqueda de Texto Completo (Full Text Search) es una funcionalidad muy interesante de SQL Server (bien aprovechada por Sharepoint, por cierto). Sin embargo, cuando deseamos poder indexar documentos fuera de lo habitual, necesitamos de los correspondientes iFilters (para PDF, para AutoCad, etc.). Bien, pues también es interesante de que nos preocupemos de que tenemos disponibilidad de los iFilters que necesitamos para la arquitectura que deseamos utilizar (y a priori... que a posteriori lo hace cualquiera ;-)
  • Disponibilidad de software adicional. En toda empresa que se precie (incluso en las que no), se suele utilizar una serie de aplicaciones corportivas que puede ser requisito que montemos (antivirus corporativo, software de monitorización, cliente de backup, etc.). Es importante comprobar que tenemos disponibilidad de dicho software para el sistema que deseamos instalar, para lo cual, es importante verificar las versiones (quizás sea necesario subir la versión del software de Backup, y ésto a su vez implique un trabajo considerable en función del parking de máquinas de la empresa.... en fin... nuestro día a día... jeje ;-) Como siempre, vamos a comprobarlo a priori... que a posteriori lo hace cualquiera !!

Otro tema, es la edición particular de SQL Server y de Windows, en función de la necesidad de determinadas funcionalidades (ej: clustering MSCS requiere Windows Server 2003 Enterprise) y aprovechamiento de hardware (límites de procesadores y memoria, principalmente).

Para entornos de desarrollo, por favor, comprobar el precio de SQL Server 2000 Developer y/o SQL Server 2005 Developer, en vuestro proveedor de software adicional o en Amazon o dónde sea !! La edición Developer es igual en funcionalidad que la Enterprise, pero cuesta sólo 40 euros y se puede conseguir incluso en Amazon. Si no tuviera mi suscripción MSDN, ya me la habría comprado para casa !!! Si comparáis el precio de SQL Server Developer con un Enterprise... en fin... la idea al final es facilitar a la creación de entornos de desarrollo (ej: empresas fabricantes de software), puesto que el objetivo de todo software que se desarrolla es que se pase a producción (y es en ese punto dónde Microsoft si exige el coste de licencia... ). Más que razonable, ¿o no?.

En cualquier caso, el precio junto con el contrato particular que se tenga establecido con Microsoft, puede ser un factor relevante. También se paga el hecho de "ser el primero".... es decir, resulta más fácil sentirse confortable con una edición x86 o x64 que con Itanium, puesto que existen muchas más instalaciones en el mundo x86 ó x64 que Itanium, y esto repercute en un producto mucho más probado (tanto Windows como SQL Server). Por contra, los servidores más grandes son arquitecturas Itanium, máquinas en las que podemos encontrar ediciones Windows DataCenter, certificadas por Microsoft y pre-instaladas por el fabricante de hardware (HP, Unisys, etc.).

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




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.