最近、私はDBサーバーの1つでOSアップグレードを実行し、サーバー2003からサーバー2008に移行しました。DBMSはSQL Server 2005です。新しいWindowsインストールにSQLを再インストールしている間に、別のDBサーバーに移動していくつかのことを確認しました設定の。
さて、この2台目のサーバーはServer 2003 x64 + SQL 2005 x64(言われたことから)だといつも思っていましたが、今は疑問があります。私は今、それが実際には32ビットSQLのみであると疑っていますが、これを確認したいと思います。
詳細は次のとおりです。
OSは間違いなく64ビットです。
_xp_msver
_はPlatform
を_NT INTEL X86
_として表示します
_SELECT @@VERSION
_はMicrosoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...
を示します
ただし、sqlservr.exeがtaskmgrで「* 32」と表示されていない場合、実際に32ビットであると主張されている場合、これが当てはまる理由を誰かが知っていますか?それにもかかわらず、x86プログラムファイルフォルダーが不足しているようです。
確認済みの64ビットインストールで同じチェックを行うと、予想される64ビットの読み取り値が返されます。これは、問題のこのサーバーが32ビットでのみ実行されていることを証明するだけです。
さて、そういうわけで、この「32ビット」のインストールが使用できるメモリの量についての疑問が生じます。タスクマネージャは、sqlservr.exeの3.5GBのメモリ使用量を報告します(サーバーには16GBの物理容量があります)。 AWEがまったく構成されていないため、SQLが単に32ビットのアドレス空間を使用している場合、サーバーの使用率は大幅に低下します(OSは64ビットであることを思い出してください)。
この仮定は正しいですか?
ハードウェアプラットフォームを完全に利用するためには、サーバーでSQLを64ビットとして再インストールする必要があると思いますが、現在は本番環境に集中しています。これは簡単な作業ではありません。私はAWEを正しく設定し、当分の間それを可能にする必要があるだけかもしれないと思います(これが悪い考えでない限り)。
この質問は少し漠然としています/失われています。私はSQLの専門家ではありません。ここで何が起こっているのかを理解しようとしています。
この投稿 は、2つの異なる方法を確認します(最初の方法は@@ versionで、32ビットバージョンのSQL Serverを実行していることを示します)が、クリックスルーを保存します。
select serverproperty('edition')
結果は次のようになります。
32ビット:Enterprise Edition
64ビット:Developer Edition(64ビット)
あなたも使うことができます
USE master
SELECT @@Version
それは次のように表示されます-
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)
インストールメディアにx64またはx86ディレクトリがありますか?そうでない場合は、メディアは32ビットのみになると思います。
これは、64ビットOSで32ビットバージョンしか実行していない理由を説明しています。
ディスクは箱入りの購入ですか、それともMSDNまたはTechnetのダウンロードからですか?
64ビットまたは32ビットであるかどうかについてはコメントしません。AWEについて質問したので、ここでいくつかの経験があるので、その部分についてお答えします。
私は同様の状況でAWEを使用しましたが、一時的にそれはうまく機能しました。
最終的には、もちろん完全に64ビットシステムに移行しましたが、AWEにより多くのRAMを使用できるようになりました。また、覚えている場合は、boot.iniにある/ 3GBスイッチも確認してください。スワップする前にAWEを有効にしてインストールをテストできれば、明らかに有益です。私たちはマネージドホスティングプロバイダーにそれをオンにするように頼みました、そして彼らは以前にそれでいくつかの経験を持っている私たちとのDBAの仕事を持っていました。変更を早朝のメンテナンスウィンドウにスケジュールし、変更を加え、再起動して、テストを開始しました。実際、私たちにもかなりのパフォーマンスを提供してくれました。
私が覚えていることから、SQL Serverが使用したメモリの量を簡単に確認することはできませんでした-taskmgr.exeはすべての話をしませんでした。 perfmonを実行し、SQLサーバーカウンターに実際にドリルインして、RAM SQLが実際にアクセスしている量を確認する必要があります。
最初にお読みになることをお勧めしますが、状況をより永続的に解決できるようになるまでは、この方法をお勧めします。
http://blogs.msdn.com/chadboyd/archive/2007/03/24/pae-and-3gb-and-awe-oh-my.aspxhttp:// msdn.Microsoft.com/en-us/library/ms190673.aspx