Installazione di SQL Server: è a 32 o 64 bit?

Recentemente stavo eseguendo un aggiornamento del sistema operativo su uno dei nostri server DB, passando da Server 2003 a Server 2008. Il DBMS è SQL Server 2005. Durante la reinstallazione di SQL sulla nuova installazione di Windows, sono andato su un altro dei nostri server DB per verificare un paio delle impostazioni.

Ora, ho sempre pensato che questo secondo server fosse Server 2003 x64 + SQL 2005 x64 (da quello che mi era stato detto), ma ora ho i miei dubbi su questo. Ora sospetto che in realtà sia solo un SQL a 32 bit, tuttavia vorrei verificarlo.

Ecco alcuni dettagli:

Il sistema operativo è decisamente a 64 bit.

xp_msvermostra PlatformcomeNT INTEL X86

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

Tuttavia sqlservr.exe non viene mostrato con '* 32' in taskmgr, qualcuno sa perché questo è il caso, se in realtà è a 32 bit come affermato? Nonostante ciò, sembra che si stia esaurendo la cartella dei file di programma x86.

Se eseguo gli stessi controlli su un'installazione confermata a 64 bit, restituisce le letture previste a 64 bit, il che può solo dimostrare che questo server in questione funziona solo a 32 bit.

In questo caso, sorge la domanda su quanta memoria può utilizzare questa installazione a '32 bit '. Task manager segnala l'utilizzo della memoria da 3,5 GB per sqlservr.exe (il server ha 16 GB fisici). Sospetto che AWE non sia stato affatto configurato, e quindi il server sarà significativamente sottoutilizzato (ricordando che il sistema operativo è a 64 bit) se SQL utilizza semplicemente uno spazio di indirizzi a 32 bit.

Questo assunto è corretto?

Ritengo che il server dovrebbe avere reinstallato SQL a 64 bit per utilizzare pienamente la piattaforma hardware, tuttavia è attualmente fortemente in produzione; questo non sarà un compito facile. Ho il sospetto che dovremmo semplicemente configurare AWE correttamente e lasciare che sia per il momento (A meno che questa non sia una cattiva idea?).

Mi scuso che questa domanda sia un po 'vaga / persa; Non sono un esperto di SQL, sto solo cercando di capire cosa sta succedendo qui.

Questo post elenca due diversi modi per verificare (il primo è la versione @@, che mostra che stai eseguendo una versione a 32 bit di SQL Server), ma per salvare facendo clic su,

select serverproperty('edition')

Il risultato sarà simile a:

32 bit: Enterprise Edition

64 bit: Developer Edition (64 bit)

Puoi anche usare

USE master
SELECT @@Version

Questo mostrerà qualcosa di simile -

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)

Nel tuo mezzo di installazione vedi una directory x64 o x86? Altrimenti credo che il tuo mezzo sarà solo a 32 bit.

Questo spiegherà perché hai solo una versione a 32 bit in esecuzione sul tuo sistema operativo a 64 bit.

Il disco è un acquisto in scatola o da un download MSDN o Technet?

Non commenterò se hai 64 bit o 32. Mi chiedi AWE, quindi risponderò a quella parte dato che ho una certa esperienza qui.

Ho usato AWE in situazioni simili e ha funzionato bene per noi temporaneamente.

Alla fine ci siamo ovviamente spostati su un sistema a 64 bit, ma AWE ci ha permesso di utilizzare più RAM. Guarda anche l'opzione / 3GB che va in boot.ini se ricordo. Se riesci a testare la tua installazione con AWE abilitato prima di scambiarlo sarebbe ovviamente utile. Abbiamo chiesto al nostro provider di hosting gestito di accenderlo e hanno avuto un lavoro DBA con noi che aveva avuto qualche esperienza con quello prima. Abbiamo programmato la modifica su una finestra di manutenzione mattutina, apportato le modifiche, riavviato e iniziato i test. In realtà ci ha comprato anche un sacco di prestazioni.

Da quanto ricordo, non è stato possibile vedere facilmente quanta memoria utilizzava SQL Server: taskmgr.exe non raccontava l'intera storia. Devi eseguire perfmon ed eseguire il drill-down sui contatori del server SQL per vedere a quanta RAM SQL sta effettivamente accedendo.

Ti suggerirei di leggere prima, ma è una buona strada da percorrere fino a quando non puoi risolvere la situazione in modo 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