Instalación de SQL Server: ¿es de 32 o 64 bits?

Recientemente estaba realizando una actualización del sistema operativo en uno de nuestros servidores de base de datos, pasando del servidor 2003 al servidor 2008. El DBMS es SQL Server 2005. Al reinstalar SQL en la nueva instalación de Windows, fui a otro de nuestros servidores de base de datos para verificar un par de ajustes.

Ahora, siempre pensé que este segundo servidor era Server 2003 x64 + SQL 2005 x64 (por lo que me habían dicho), pero ahora tengo mis dudas al respecto. Ahora sospecho que en realidad es solo SQL de 32 bits, sin embargo, me gustaría verificar esto.

Aquí hay algunos detalles:

El sistema operativo es definitivamente de 64 bits.

xp_msvermuestra PlatformcomoNT INTEL X86

SELECT @@VERSION muestra Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...

Sin embargo, sqlservr.exe no se muestra con '* 32' en taskmgr, ¿alguien sabe por qué este es el caso, si de hecho es de 32 bits como se afirma? A pesar de esto, parece que se está quedando sin la carpeta de archivos de programa x86.

Si hago las mismas verificaciones en una instalación confirmada de 64 bits, devuelve las lecturas esperadas de 64 bits, lo que solo puede probar que este servidor en cuestión solo se ejecuta en 32 bits.

Ahora, siendo ese el caso, surge la pregunta sobre cuánta memoria puede usar esta instalación de '32 bits '. El administrador de tareas informa sobre el uso de memoria de 3,5 GB para sqlservr.exe (el servidor tiene 16 GB físicos). Sospecho que AWE no se ha configurado en absoluto y, por lo tanto, el servidor se subutilizará significativamente (recordando que el sistema operativo es de 64 bits) si SQL simplemente usa un espacio de direcciones de 32 bits.

¿Es correcta esta suposición?

Siento que el servidor debería tener SQL reinstalado como 64 bits para utilizar completamente la plataforma de hardware, sin embargo, actualmente está en producción; Esta no será una tarea fácil. Sospecho que es posible que solo tengamos que configurar AWE correctamente y dejar que sea por el momento (¿A menos que sea una mala idea?).

Pido disculpas porque esta pregunta es un poco vaga / perdida; No soy un experto en SQL, solo trato de entender lo que está sucediendo aquí.

Esta publicación enumera dos formas diferentes de verificar (la primera es la versión @@, que muestra que está ejecutando una versión de SQL Server de 32 bits), pero para guardar haciendo clic,

select serverproperty('edition')

El resultado se verá más o menos así:

32 bits: Edición Enterprise

64 bits: Edición para desarrolladores (64 bits)

También puedes usar

USE master
SELECT @@Version

Eso mostrará algo como:

Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 
Feb 10 2012 19:39:15 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

En su medio de instalación, ¿ve un directorio x64 o x86? Si no, creo que su medio será solo de 32 bits.

Esto explicará por qué solo tiene una versión de 32 bits ejecutándose en su sistema operativo de 64 bits.

¿Es el disco una compra en caja o de una descarga de MSDN o Technet?

No comentaré si tienes o no 64 bits o 32. Preguntas sobre AWE, así que responderé esa parte ya que tengo algo de experiencia aquí.

He usado AWE en situaciones similares y nos ha funcionado bien temporalmente.

Al final, nos mudamos a un sistema de 64 bits, por supuesto, pero AWE nos permitió usar más RAM. También recuerdo el modificador / 3GB que va en boot.ini si recuerdo. Si puede probar su instalación con AWE habilitado antes de cambiar, obviamente sería beneficioso. Le pedimos a nuestro proveedor de hosting administrado que lo activara, y tenían un DBA que trabajaba con nosotros y que tenía alguna experiencia con eso antes. Programamos el cambio en una ventana de mantenimiento temprano en la mañana, realizamos los cambios, reiniciamos y comenzamos a probar. En realidad, también nos compró bastante rendimiento.

Por lo que recuerdo, no se podía ver fácilmente cuánta memoria usaba SQL Server: el taskmgr.exe no contaba toda la historia. Debe ejecutar perfmon y, de hecho, acceder a los contadores del servidor SQL para ver a qué RAM RAM está realmente accediendo.

Te sugiero que leas primero, pero es un buen camino a seguir hasta que puedas resolver la situación de manera más permanente.

http://blogs.msdn.com/chadboyd/archive/2007/03/24/pae-and-3gb-and-awe-oh-my.aspx http://msdn.microsoft.com/en-us/library /ms190673.aspx