Ostatnio przeprowadzałem aktualizację systemu operacyjnego na jednym z naszych serwerów DB, przenosząc się z Server 2003 na Server 2008. DBMS to SQL Server 2005. Podczas ponownej instalacji SQL przy nowej instalacji Windows, poszedłem na inny z naszych serwerów DB, aby zweryfikować kilka ustawień.
Teraz zawsze myślałem, że ten drugi serwer to Server 2003 x64 + SQL 2005 x64 (z tego, co mi powiedziano), ale teraz mam co do tego wątpliwości. Podejrzewam teraz, że w rzeczywistości jest to tylko 32-bitowy SQL, ale chciałbym to sprawdzić.
Oto kilka szczegółów:
System operacyjny jest zdecydowanie 64-bitowy.
xp_msverpokazuje PlatformjakoNT INTEL X86
SELECT @@VERSION przedstawia Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...
Jednak narzędzie sqlservr.exe nie jest oznaczone słowem „* 32” w taskmgr. Czy ktoś wie, dlaczego tak jest, jeśli w rzeczywistości jest 32-bitowy? Mimo to wydaje się, że kończy się folder plików programu x86.
Jeśli wykonam te same kontrole w potwierdzonej instalacji 64-bitowej, zwróci oczekiwane 64-bitowe odczyty, co może jedynie udowodnić, że ten serwer działa tylko w wersji 32-bitowej.
W tej sytuacji pojawia się pytanie, ile pamięci może użyć ta „32-bitowa” instalacja. Menedżer zadań zgłasza zużycie pamięci 3,5 GB dla narzędzia sqlservr.exe (serwer ma 16 GB pamięci fizycznej). Podejrzewam, że AWE w ogóle nie zostało skonfigurowane, a zatem serwer będzie znacznie słabo wykorzystywany (pamiętając, że system operacyjny jest 64-bitowy), jeśli SQL po prostu używa 32-bitowej przestrzeni adresowej.
Czy to założenie jest prawidłowe?
Wydaje mi się, że serwer powinien ponownie zainstalować SQL w wersji 64-bitowej, aby w pełni wykorzystać platformę sprzętową, jednak obecnie jest mocno produkowany; to nie będzie łatwe zadanie. Podejrzewam, że możemy po prostu poprawnie skonfigurować AWE i pozwolić na to na razie (chyba że to zły pomysł?).
Przepraszam, że to pytanie jest trochę niejasne / zagubione; Nie jestem ekspertem od SQL, po prostu próbuję zrozumieć, co się tutaj dzieje.
źródło
Odpowiedzi:
W tym poście wymieniono dwa różne sposoby sprawdzania (pierwszy to wersja @@, która pokazuje, że używasz 32-bitowej wersji programu SQL Server), ale aby zapisać, klikając,
Wynik będzie wyglądał mniej więcej tak:
32-bit: edycja Enterprise
64-bit: Developer Edition (64-bit)
źródło
Możesz także użyć
To wyświetli coś w stylu -
źródło
Czy na twoim nośniku instalacyjnym widzisz katalog x64 lub x86? Jeśli nie, uważam, że twoje medium będzie tylko 32-bitowe.
To wyjaśni, dlaczego masz tylko wersję 32-bitową działającą w 64-bitowym systemie operacyjnym.
Czy dysk jest zakupem w pudełku, czy można go pobrać z witryny MSDN lub Technet?
źródło
Nie będę komentować, czy masz 64-bitowy czy 32-ty. Pytasz o AWE, więc odpowiem na to pytanie, ponieważ mam tutaj pewne doświadczenie.
Korzystałem z AWE w podobnych sytuacjach i działało to dla nas tymczasowo.
Ostatecznie przeszliśmy na system w pełni 64-bitowy, ale AWE pozwoliło nam na użycie większej ilości pamięci RAM. Spójrz także na przełącznik / 3GB, który wchodzi w boot.ini, jeśli pamiętam. Jeśli możesz przetestować swoją instalację z włączoną AWE przed zamianą, byłoby to oczywiście korzystne. Poprosiliśmy naszego zarządzanego dostawcę usług hostingowych, aby go włączyć, a oni mieli z nami DBA, która wcześniej miała z tym pewne doświadczenie. Zaplanowaliśmy zmianę w oknie wczesnego porannego przeglądu, dokonaliśmy zmian, uruchomiliśmy ponownie i rozpoczęliśmy testy. Kupił nam całkiem sporo wydajności.
Z tego, co pamiętam, nie było łatwo zobaczyć, ile pamięci używał SQL Server - taskmgr.exe nie opowiedział całej historii. Musisz uruchomić perfmon i przejść do liczników serwera SQL, aby zobaczyć, do jakiej ilości RAM SQL ma dostęp.
Proponuję najpierw przeczytać, ale jest to dobra droga, dopóki nie rozwiążesz sytuacji na stałe.
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
źródło