SQL Server-Installation: Ist es 32 oder 64 Bit?

Kürzlich führte ich ein Betriebssystem-Upgrade auf einem unserer DB-Server durch und wechselte von Server 2003 zu Server 2008. Das DBMS ist SQL Server 2005. Während der Neuinstallation von SQL in der neuen Windows-Installation ging ich zu einem anderen unserer DB-Server, um einige zu überprüfen von Einstellungen.

Ich dachte immer, dieser zweite Server sei Server 2003 x64 + SQL 2005 x64 (nach dem, was mir gesagt wurde), aber jetzt habe ich meine Zweifel. Ich vermute jetzt, dass es sich tatsächlich nur um 32-Bit-SQL handelt, möchte dies jedoch überprüfen.

Hier sind einige Details:

Das Betriebssystem ist definitiv 64 Bit.

xp_msverzeigt PlatformalsNT INTEL X86

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

Allerdings wird sqlservr.exe in taskmgr nicht mit '* 32' angezeigt. Weiß jemand, warum dies der Fall ist, wenn es tatsächlich 32-Bit ist, wie behauptet? Trotzdem scheint der Ordner mit den x86-Programmdateien nicht mehr zu funktionieren.

Wenn ich bei einer bestätigten 64-Bit-Installation die gleichen Überprüfungen durchführe, werden die erwarteten 64-Bit-Messwerte zurückgegeben, was nur beweisen kann, dass dieser betreffende Server nur in 32-Bit ausgeführt wird.

In diesem Fall stellt sich die Frage, wie viel Speicher diese 32-Bit-Installation verwenden kann. Der Task-Manager meldet eine Speicherauslastung von 3,5 GB für sqlservr.exe (der Server verfügt über physische 16 GB). Ich vermute, dass AWE überhaupt nicht konfiguriert wurde und daher der Server erheblich unterlastet ist (wenn man bedenkt, dass das Betriebssystem 64-Bit ist), wenn SQL einfach einen 32-Bit-Adressraum verwendet.

Ist diese Annahme richtig?

Ich bin der Meinung, dass auf dem Server SQL als 64-Bit neu installiert werden sollte, um die Hardwareplattform vollständig nutzen zu können. Derzeit wird jedoch viel produziert. Dies wird keine leichte Aufgabe sein. Ich vermute, wir müssen AWE möglicherweise nur richtig konfigurieren und es vorerst zulassen (es sei denn, dies ist eine schlechte Idee?).

Ich entschuldige mich, dass diese Frage etwas vage / verloren ist; Ich bin kein SQL-Experte und versuche nur, einen Überblick darüber zu bekommen, was hier vor sich geht.

In diesem Beitrag werden zwei verschiedene Möglichkeiten zum Überprüfen aufgeführt (die erste ist die @@ -Version, die zeigt, dass Sie eine 32-Bit-Version von SQL Server ausführen).

select serverproperty('edition')

Das Ergebnis sieht ungefähr so ​​aus:

32-Bit: Enterprise Edition

64-Bit: Developer Edition (64-Bit)

Sie können auch verwenden

USE master
SELECT @@Version

Das zeigt so etwas wie -

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)

Sehen Sie in Ihrem Installationsmedium ein x64- oder ein x86-Verzeichnis? Wenn nicht, glaube ich, wird Ihr Medium nur 32-Bit sein.

Dies erklärt, warum auf Ihrem 64-Bit-Betriebssystem nur eine 32-Bit-Version ausgeführt wird.

Handelt es sich bei der Festplatte um einen Box-Kauf oder um einen MSDN- oder Technet-Download?

Ich werde nicht kommentieren, ob Sie 64bit oder 32 haben oder nicht. Sie fragen nach AWE, also werde ich diesen Teil beantworten, da ich hier einige Erfahrungen habe.

Ich habe AWE in ähnlichen Situationen verwendet und es hat vorübergehend gut für uns funktioniert.

Am Ende sind wir natürlich auf ein 64-Bit-System umgestiegen, aber AWE hat uns erlaubt, mehr RAM zu verwenden. Schauen Sie sich auch den / 3GB-Schalter an, der sich in der boot.ini befindet, wenn ich mich recht erinnere. Wenn Sie Ihre Installation mit aktiviertem AWE testen können, bevor Sie tauschen, wäre dies natürlich von Vorteil. Wir haben unseren Managed Hosting-Anbieter gebeten, es einzuschalten, und sie hatten eine DBA-Arbeit mit uns, die zuvor einige Erfahrungen damit gemacht hatte. Wir haben die Änderung über ein Wartungsfenster am frühen Morgen geplant, die Änderungen vorgenommen, neu gestartet und mit dem Testen begonnen. Es hat uns auch ziemlich viel Leistung gebracht.

Soweit ich mich erinnere, konnte man nicht leicht erkennen, wie viel Speicher SQL Server verwendet - die taskmgr.exe hat nicht die ganze Geschichte erzählt. Sie müssen perfmon ausführen und tatsächlich einen Drilldown zu den SQL Server-Zählern durchführen, um zu sehen, auf wie viel RAM SQL tatsächlich Zugriff erhält.

Ich würde vorschlagen, dass Sie zuerst nachlesen, aber es ist ein guter Weg, bis Sie die Situation dauerhafter lösen können.

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