Кто-нибудь с опытом использования SQL 2008, но все в ОЗУ? Пытаюсь сделать некоторые вещи быстрее, и, возможно, добьемся этого, спасибо
Это зависит от того, что вы подразумеваете под «все в ОЗУ».
Если вы хотите запустить свою базу данных с RAM-диска, вы обнаружите, что это маловероятно (если у вас нет какой-либо карты RAM-диска, которая выглядит для ОС как обычный диск, т.е. представляет интерфейс SATA или PATA) как SQL Server откажется. Он предполагает, что любые записываемые данные достаточно важны, чтобы их можно было сохранить, и не рискует ими, записывая их на энергозависимый носитель. Возможно, вы сможете обмануть его, запустив его на виртуальной машине и запустив эту виртуальную машину с RAM-диска, но я бы не рекомендовал пробовать оба варианта по той же причине (вы теряете все данные в случае потери питания или перезагрузки) и из-за того, что возникнет набор других проблем с производительностью от решения виртуализации, о которых нужно беспокоиться.
Если ваша проблема заключается в медленной активности чтения (то есть при большом количестве операций, которые приводят к чтению с диска, то просто увеличьте объем ОЗУ на машине, чтобы он был больше обычного рабочего набора или, что еще лучше, больше, чем вся база данных. Таким образом, если у вас нет выпуска SQL Server, который налагает искусственные ограничения ОЗУ (IIRC Express Edition не будет использовать более 1 ГБ), он будет использовать изобилие памяти для хранения всего, что он читает, кэшированным в ОЗУ, где его можно будет быстро прочитать в следующий раз Если вы хотите предварительно загрузить данные в ОЗУ в любое время после их очистки (то есть после перезагрузки из-за установки обновлений), вы можете написать сценарий, который заставляет все страницы индекса и данных сканироваться и считывать их в память. .
Если проблема связана с большим количеством операций записи, то может помочь оптимизация структуры диска. Не зная больше о вашей базе данных, мы не можем дать конкретные советы, но стандартные практические правила (например, попробуйте хранить файлы данных, журналы транзакций и tempdb на отдельных физических дисках) могут помочь.
По умолчанию SQL Server будет использовать всю доступную оперативную память на сервере. Лучшая практика - настроить SQL Server, чтобы у него было на 2-4 гигабайта меньше доступной оперативной памяти, чем у сервера на самом деле (в зависимости от того, что еще установлено, сколько SQL CLR вы используете и т. Д.). SQL Server будет использовать память на сервере в качестве буферного кеша, поэтому данные должны считываться с диска как можно реже. Чем больше оперативной памяти SQL Server доступен для него, тем больше данных SQL Server может загрузить в память. При идеальной работе SQL Server почти никогда не будет читать с диска (кроме как при запуске, поскольку данные должны считываться с диска в какой-то момент), так что единственный требуемый ввод-вывод диска - это ввод-вывод записи.
Запуск SQL Server на RAM-диске аналогичен настройке файла подкачки машины для размещения в RAM: это нарушит ожидания системы.
SQL Server на самом деле очень похож на операционную систему, у него есть собственная версия процессов, потоков, собственный диспетчер памяти и многое другое. Так что же произойдет, если мы запустим SQL Server на RAM-диске?
Первое - самое важное. SQL Server на RAM-диске больше не будет иметь согласованности транзакций в случае сбоя. Ничто другое не должно иметь для вас значения, но я могу с уверенностью сказать, что нет никаких технических преимуществ при запуске базы данных SQL Server или файлов журнала на RAM-диске, которые могли бы перевесить риски.