Recentemente eu estava executando uma atualização do sistema operacional em um de nossos servidores DB, passando do Server 2003 para o Server 2008. O DBMS é o SQL Server 2005. Ao reinstalar o SQL na nova instalação do Windows, fui para outro dos nossos servidores DB verifique algumas configurações.
Agora, sempre achei que esse segundo servidor fosse o Server 2003 x64 + SQL 2005 x64 (do que me disseram), mas agora tenho minhas dúvidas sobre isso. Eu agora suspeito que na verdade é apenas 32 bits SQL, no entanto eu gostaria de verificar isso.
Veja alguns detalhes:
O sistema operacional é definitivamente de 64 bits.
xp_msver mostra Platform como NT INTEL X86
SELECT @@VERSION mostra Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...
No entanto sqlservr.exe não é mostrado com '* 32' no taskmgr, alguém sabe por que este é o caso, se é de fato 32 bits como reivindicado? Apesar disso, parece estar ficando sem a pasta de arquivos de programa x86.
Se eu fizer as mesmas verificações em uma instalação confirmada de 64 bits, ele retornará as leituras de 64 bits esperadas, o que só pode provar que esse servidor em questão está sendo executado apenas em 32 bits.
Agora, sendo esse o caso, surge a questão sobre a quantidade de memória que essa instalação de '32 bits 'pode usar. Gerenciador de tarefas relata sobre o uso de memória de 3,5 GB para sqlservr.exe (o servidor tem 16 GB físico). Eu suspeito que o AWE não foi configurado de todo, e, portanto, o servidor será significativamente subutilizado (lembrando que o sistema operacional é de 64 bits) se o SQL está simplesmente usando um espaço de endereço de 32 bits.
Esta suposição é correta?
Eu sinto que o servidor deve ter o SQL reinstalado como 64 bits, a fim de utilizar plenamente a plataforma de hardware, no entanto, ele está atualmente muito em produção; isso não será tarefa fácil. Eu suspeito que nós podemos apenas ter que configurar o AWE corretamente e deixá-lo ser por enquanto (a menos que seja uma má idéia?).
Peço desculpas por essa questão ser um pouco vaga / perdida; Não sou especialista em SQL, apenas tentando entender o que está acontecendo aqui.
Esta postagem lista duas maneiras diferentes de verificar (a primeira é a @@ versão, que mostra que você está executando uma versão de 32 bits do SQL Server), mas para salvar clicando,
select serverproperty('edition')
O resultado será algo parecido com:
32 bits: Enterprise Edition
64 bits: Developer Edition (64 bits)
Você também pode usar
USE master
SELECT @@Version
Isso exibirá 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)
Na sua mídia de instalação, você vê um diretório x64 ou x86? Se não, acredito que seu meio será apenas de 32 bits.
Isso explicará por que você só tem uma versão de 32 bits em execução no seu sistema operacional de 64 bits.
O disco é uma compra em caixa ou de um download do MSDN ou Technet?
Não vou comentar se você tem 64 bits ou 32. Você pergunta sobre o AWE, então eu responderei a essa parte, já que tenho alguma experiência aqui.
Eu usei o AWE em situações semelhantes e ele funcionou bem para nós temporariamente.
No final, mudamos para um sistema totalmente de 64 bits, mas a AWE nos permitiu usar mais memória RAM. Veja também a opção / 3GB que vai em boot.ini, se bem me lembro. Se você pode testar sua instalação com o AWE ativado antes de trocar, isso obviamente seria benéfico. Pedimos ao nosso provedor de hospedagem gerenciada para ligá-lo, e eles tinham um DBA conosco que tinha alguma experiência com isso antes. Agendamos a mudança em uma janela de manutenção matutina, fizemos as alterações, reiniciamos e iniciamos o teste. Nos comprou bastante performance também.
Pelo que me lembro, você não podia ver facilmente quanta memória o SQL Server usou - o taskmgr.exe não contou a história toda. Você tem que executar o perfmon e, na verdade, fazer drill nos contadores do servidor SQL para ver a quantidade de RAM que o SQL está realmente obtendo acesso.
Sugiro que você leia primeiro, mas é um bom caminho até que você possa resolver a situação de forma mais permanente.
Tags 64-bit sql-server-2005 x86