Установка SQL Server: 32 или 64 бит?

Недавно я выполнял обновление ОС на одном из наших серверов БД, переходя с Server 2003 на Server 2008. СУБД - это SQL Server 2005. При переустановке SQL в новой установке Windows я отправился на другой из наших серверов БД, чтобы проверить пару настроек.

Теперь я всегда думал, что вторым сервером был Server 2003 x64 + SQL 2005 x64 (из того, что мне сказали), но теперь у меня есть сомнения по этому поводу. Теперь я подозреваю, что это на самом деле только 32-битный SQL, однако я бы хотел это проверить.

Вот некоторые детали:

ОС определенно 64-битная.

xp_msverпоказывает PlatformкакNT INTEL X86

SELECT @@VERSION шоу Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)...

Однако sqlservr.exe не отображается с '* 32' в taskmgr, кто-нибудь знает, почему это так, если он действительно 32-битный, как заявлено? Несмотря на это, похоже, что она заканчивается в папке с программными файлами x86.

Если я выполню те же проверки на подтвержденной 64-битной установке, то она выдаст ожидаемые 64-битные показания, что может только доказать, что данный сервер работает только в 32-битной версии.

Теперь, в этом случае, возникает вопрос о том, сколько памяти может использовать эта 32-битная установка. Диспетчер задач сообщает об использовании 3,5 ГБ памяти для sqlservr.exe (сервер имеет 16 ГБ физической памяти). Я подозреваю, что AWE не был настроен вообще, и, следовательно, сервер будет значительно недостаточно загружен (учитывая, что ОС является 64-битной), если SQL просто использует 32-битное адресное пространство.

Это предположение верно?

Я чувствую, что сервер должен переустанавливать SQL как 64-битный, чтобы полностью использовать аппаратную платформу, однако в настоящее время он активно используется; это будет нелегкой задачей. Я подозреваю, что нам, возможно, просто нужно правильно настроить AWE и оставить его на некоторое время (разве это плохая идея?).

Я извиняюсь, что этот вопрос немного расплывчатый / потерянный; Я не эксперт по SQL, просто пытаюсь понять, что здесь происходит.

В этом посте перечислены два различных способа проверки (первый - @@ 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-битной ОС работает только 32-битная версия.

Является ли этот диск покупкой в ​​штучной упаковке или с загрузкой MSDN или Technet?

Я не буду комментировать, есть ли у вас 64-битная или 32-битная версия. Вы спрашиваете об AWE, поэтому я отвечу на эту часть, поскольку у меня есть некоторый опыт здесь.

Я использовал AWE в подобных ситуациях, и он временно работал хорошо для нас.

В конце концов мы, конечно, перешли на полностью 64-битную систему, но AWE позволил нам использовать больше оперативной памяти. Также посмотрите на переключатель / 3GB, который идет в boot.ini, если я не забуду. Если вы можете проверить свою установку с включенным AWE перед тем, как поменять местами, это, очевидно, будет полезно Мы попросили нашего провайдера управляемого хостинга включить его, и у них был администратор базы данных, который уже имел опыт работы с этим. Мы запланировали изменения в течение раннего утреннего периода обслуживания, внесли изменения, перезагрузили и начали тестирование. Это тоже принесло нам много производительности.

Из того, что я помню, вы не могли легко увидеть, сколько памяти использовало SQL Server - файл taskmgr.exe не рассказывал всей истории. Вы должны запустить perfmon и фактически перейти к счетчикам SQL-сервера, чтобы увидеть, сколько оперативной памяти SQL получает на самом деле.

Я бы посоветовал вам сначала прочитать, но это хороший путь, пока вы не сможете разрешить ситуацию более навсегда.

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