Может ли база данных SQL Server объемом 200 ГБ или больше загружаться в файл подкачки, если на сервере не хватает памяти?

Question

Вот что мы пытаемся сделать.

У нас будет база данных 200 ГБ + SQL Server, которую необходимо загрузить в память. Лучшей практикой Microsoft является наличие на сервере достаточной физической памяти, а затем загрузка всей базы данных. Это означает, что нам понадобится 256 ГБ памяти на каждом из наших SQL-серверов. Это приведет к быстрому доступу к базе данных, которая загружается в память, но для высокой стоимости памяти. BTW, мы запускаем SQL Server 2008 на Windows Server 2008.

В настоящее время наш сервер настроен только на 12 ГБ памяти. Только под 3 ГБ выделяется ОС, а остальные 9 ГБ используются для SQL Server. Возможно ли увеличить файл подкачки до 256 ГБ и настроить его на накопителе SSD? То, что мы хотим сделать, это загрузить базу данных в файл подкачки, расположенный на SSD. Мы надеемся, что производительность будет похожа на загрузку всей базы данных в память, так как она будет на SSD.

Будет ли это работать? Есть ли другая альтернатива, которую мы не замечаем? Мы хотим, чтобы затраты были снижены настолько, насколько мы можем, не жертвуя производительностью нашей среды. Любой совет будет принят во внимание.

Спасибо.

Answer 1

Если вы хотите, чтобы база данных хранилась в памяти, вам нужно купить больше памяти. Несмотря на то, что предлагает the other answer, память - это самый лучший и самый дешевый способ сделать базу данных лучше - SQL Server -, предназначенный для хорошо использовать память.

В то время как SQL Server будет использовать файл страницы, когда это необходимо, и при наличии файла на SSD будет немного быстрее, чем на старомодном механическом диске, это все еще I/O и свопинг, и там это много накладных расходов, независимо от типа диска под ним. В целом это может оказаться немного лучше, чем наличие одного и того же файла на диске (или вообще никакого файла с файлами), но я не думаю, что он будет находиться рядом с тем, реальной памяти или что она будет приближаться к вашим ожиданиям от «быстрого доступа».

Если вы не можете купить больше памяти, вы можете начать с этого файла на SSD, но я уверен, что вам нужно будет также сосредоточиться на других настройках - в основном, убедитесь, что у вас есть индексы, поддерживающие тип запросов, которые вы запускаете, избегая полного сканирования таблицы как можно больше. Для полных табличных агрегатов вы можете рассмотреть индексированные представления (см. here и here); для подмножеств вы можете рассмотреть filtered indexes.

И только для того, чтобы быть уверенным: вы храните фактические данные на накопителе SSD, правильно? Если нет, то я бы сказал, что вы должны использовать SSD для данных и/или журнала, а не для файла страницы. Файл страницы не принесет вам большой пользы, если он постоянно меняет данные, обмениваясь со спинниковым диском.

Answer 2

Нужно больше clairity по вопросу.

Вы управляете базой данных или это решение COTS, которое ограничивает вашу способность к оптимизации?

Вы группируете? Именно поэтому добавление 200 + Gb ОЗУ является проблемой (теперь более 400 ГБ, 200 на узел)?

Вы на голом металле или виртуализированы? Возможно, это проблема с RAM?

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

Пожалуйста, уточните свой вопрос ... :)