Ir al contenido principal

Que arquitectura de procesador elegir para SQL SERVER

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/oSQL 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.).

Comentarios

Entradas populares de este blog

¿En qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?

Una buena práctica inmediatamente después de instalar SQL Server 2005 es cambiar el Puerto TCP de escucha, por múltiples motivos: Seguridad, Configuración de reglas de acceso de Firewall, Aplicaciones cliente que requieren un puerto TCP estático para SQL Server, etc. En este Artículo se explica cómo averiguar en qué puerto TCP escucha SQL Server 2005, cómo cambiar el puerto TCP de escucha de SQL Server 2005, etc. Resulta de gran interés ser capaz de responder a la pregunta  ¿En qué puerto TCP escucha SQL Server?  Por defecto, una  Instancia por Defecto de SQL Server 2005  queda configurada durante la instalación para escuchar en el  puerto TCP-1433 , sin embargo,  las Instancias con Nombre  quedan configuradas durante el proceso de instalación para escuchar en  puertos TCP dinámicos , por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho d

¿Qué es el nivel de aislamiento (Isolation Level) de una Transacción? ¿Qué niveles de aislamiento ofrece SQL Server?

Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level)  define el grado en que se aísla una transacción de las modificaciones de recursos o datos rea

Aumentar y Reducir la TempDB en SQL Server?

Una buena práctica después de instalar SQL Server (y que interesa revisar periódicamente) es tener bien dimensionada la base de datos TEMPDB, es decir que el  tamaño inicial de TEMPDB  sea suficiente, y en consecuencia no sea necesario que TEMPDB crezca ni tampoco reducir TEMPDB (SHRINK). Esta artículo explica brevemente  para qué sirve TEMPDB , explica camo cambiar el tamaño inicial de TEMPDB (aumentar o reducir),  cómo reducir TEMPDB , cuántos ficheros son recomendables para TEMPDB, etc. ¿Para qué sirve TEMPDB?  La base de datos TEMPDB es un elemento de gran importancia en una Instancia de SQL Server, ya que  TEMPDB es la encargada de almacenar tanto los objetos temporales  (tablas temporales, procedimientos almacenados temporales, etc.),  como los resultados intermedios  que pueda necesitar crear el motor de base de datos, por ejemplo durante la ejecución de consultas que utilizan las cláusulas GROUP BY, ORDER BY, DISTINCT, etc. (es decir, las tablas temporales o WorkTables que