Installation SQL Server: est-il 32 ou 64 bits?
Récemment, je jouais une mise à niveau du système d'exploitation sur l'un de nos serveurs de base de données, passant du serveur 2003 au serveur 2008. Le SGMS est SQL Server 2005. Lors de la réinstallation de SQL sur la nouvelle installation Windows, je suis allé à un autre de nos serveurs de base de données pour vérifier un couple des paramètres.
Maintenant, j'ai toujours pensé que ce second serveur était serveur 2003 x64 + SQL 2005 x64 (à partir de ce que j'avais été informé), mais j'ai maintenant mes doutes à ce sujet. Je soupçonne maintenant que ce n'est en fait que 32 bits SQL, mais j'aimerais vérifier cela.
Voici quelques détails:
Le système d'exploitation est définitivement 64 bits.
xp_msver Affiche Platform comme NT INTEL X86
SELECT @@VERSION Affiche Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...
Cependant, SQLServr.exe n'est pas affiché avec '* 32' dans TaskMgr, est-ce que quelqu'un sait pourquoi c'est le cas, s'il est en fait 32 bit comme revendiqué? Malgré cela, il semble s'épuiser sur le dossier X86 Dossier de programme.
Si je fais les mêmes chèques sur une installation de 64 bits confirmée, il redonne les lectures attendues 64 bits, ce qui ne peut prouver que ce serveur en question ne fonctionne qu'en 32 bits.
Maintenant, cela étant le cas, la question se pose sur la quantité de mémoire que cet installation '32 bit 'peut utiliser. Rapports de la tâche Rapports sur l'utilisation de la mémoire de 3,5 Go pour SQLServr.exe (le serveur a 16 Go physique). Je soupçonne que la crainte n'a pas été configurée du tout, et le serveur sera donc significativement sous-utilisé (rappelant que le système d'exploitation est 64 bits) si SQL utilise simplement un espace d'adressage 32 bits.
Cette hypothèse est-elle correcte?
Je pense que le serveur doit avoir SQL réinstallé sous 64 bits afin d'utiliser complètement la plate-forme matérielle, mais elle est actuellement fortement en production; Ce ne sera pas une tâche facile. Je soupçonne que nous pourrons simplement avoir à configurer une crainte correctement et que ce soit pour le moment (à moins que ce ne soit une mauvaise idée?).
Je présente des excuses que cette question est un peu vague/perdue; Je ne suis pas un expert SQL, essayant simplement d'avoir une poignée sur ce qui se passe ici.
ce post répertorie deux façons différentes de vérifier (la première est la version @@ la version, qui indique que vous exécutez une version 32 bits de SQL Server), mais pour enregistrer en cliquant sur,
select serverproperty('edition')
Le résultat ressemblera à quelque chose comme:
32 bits: Edition Enterprise
64 bits: édition de développeur (64 bits)
Vous pouvez aussi utiliser
USE master
SELECT @@Version
Cela affichera quelque chose comme -
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)
Dans votre support d'installation, consultez-vous un répertoire X64 ou X86? Sinon, je pense que votre support sera 32 bits seulement.
Cela expliquera pourquoi vous n'avez qu'une version 32 bits en cours d'exécution sur votre système d'exploitation 64 bits.
Le disque est-il un achat en boîte ou à partir d'un téléchargement MSDN ou TechNet?
Je ne dirigerai pas si vous avez ou non 64 bits ou 32. Vous posez des questions sur la crainte, alors je vais répondre à cette partie car j'ai une certaine expérience ici.
J'ai utilisé une crainte dans des situations similaires et cela a bien fonctionné pour nous temporairement.
En fin de compte, nous avons progressé dans un système entièrement de 64 bits bien sûr, mais il nous a permis d'utiliser plus de RAM. Regardez également le commutateur/3 Go qui passe à Boot.ini si je me rappelle. Si vous pouvez tester votre installation avec crainte activée avant d'échanger ce qui serait évidemment bénéfique. Nous avons demandé à notre fournisseur d'hébergement géré de l'activer et ils ont eu un travail de DBA avec nous qui possédait une certaine expérience avec cela auparavant. Nous avons programmé la modification sur une fenêtre de maintenance tôt le matin, a formulé les modifications, redémarré et commencé à tester. Cela nous a acheté beaucoup de performances aussi.
De ce que je me souviens, vous ne pouvez pas facilement voir combien de mémoire SQL Server a utilisé - le TaskMgr.exe n'a pas raconté toute l'histoire. Vous devez exécuter Perfmon et réellement percer aux compteurs SQL Server pour voir combien RAM SQL est en réalité accès à.
Je vous suggérerais de lire d'abord, mais c'est un bon itinéraire pour aller jusqu'à ce que vous puissiez résoudre la situation plus en permanence.
http://blogs.msdn.com/chadboyd/archive/2007/03/24/pae-and-3gb-and-awe-oh-my.aspxhttp: // msdn.microsoft.com/en-us/library/ms190673.cox