Локальные файлы SQL Server или NAS или SAN?
Вершина имеет поле, названное "iowait". Если Ваша система видит многое из этого, Вы знаете, что что-то произошло. Существует также iotop!
Package: iotop:
Description: simple top-like I/O monitor
iotop does for I/O usage what top(1) does for CPU usage. It watches I/O
usage information output by the Linux kernel (requires 2.6.20 or later)
and displays a table of current I/O usage by processes on the system.
Handy for answering the question "Why is my disk churning so much?".
Homepage: http://guichaz.free.fr/iotop/
NAS
Определенно не NAS для SQL Server. SMB/CIFS не имеет соответствующей поддержки захвата файла для поддержки DBMS (по крайней мере, это не сделало несколько лет назад, приблизительно 2002-2003). Обратите внимание, что NFS делает и можно на самом деле сделать это с Oracle на сервере NFS. Однако SQL Server на доле CIFS не надежен из-за ограничений протокола. Это даже не может позволить, Вы поместить файлы на CIFS смонтировали доли.
SAN
Это хорошо для транзакционных приложений, поскольку кэш на RAID-контроллерах может поглотить довольно большие рабочие наборы. RAID-контроллеры SAN будут обычно поддерживать больше кэша, чем основанные на хосте RAID-контроллеры, особенно на высокопроизводительном наборе, где RAID-контроллер мог бы быть многопроцессорным полем, это так же мощно как сервер.
SAN с двойными контроллерами также имеют архитектуру без единой точки отказа и предлагают много опций для горячего резервного копирования. Это делает их победой из перспективы надежности и управляемости. Однако они являются дорогими и ограниченными для потоковой передачи объемов данных, хотя последний вряд ли будет проблемой о системе обработки транзакций.
Для операционных систем SAN являются почти всегда лучшим выбором при наличии. Они могут также быть совместно использованы несколькими серверами рабочая низкая середина систем объема. Однако они идут с ценой, которая помещает вполне существенную нижнюю границу на самую маленькую систему, с которой может использоваться технология.
Прямое присоединение
В некоторых случаях прямое устройство хранения данных присоединения является лучшим. Одна возможность является пропускной способностью, ограниченной, передавая приложения потоком, где ограниченное количество соединений Fibre Channel ограничит доступную пропускную способность к меньше, чем, могло бы быть возможным с высокопроизводительным контроллером SAS. Однако они, вероятно, будут довольно специализированными приложениями, такими как очень большие хранилища данных, где общее - ничто архитектура может обеспечить лучшую пропускную способность.
На самом деле, прямое устройство хранения данных присоединения часто лучше, чем SAN для систем хранилища данных по ряду причин:
Хранилища данных помещают большие переходные скачки загрузки на дисковые подсистемы. Это делает их довольно антиобщественными на SAN, поскольку они могут влиять на производительность других систем на SAN.
Вышеупомянутое узкое место потоковой передачи.
Прямое устройство хранения данных присоединения является довольно много более дешевым, чем устройство хранения данных SAN.
Другой рынок для устройства хранения данных прямого присоединения - когда Вы продаете рынку, который не заплатит достаточно денег за SAN. Это часто верно для приложений, проданных клиентам SMB. Для системы кассовых терминалов или системы управления практики, которая будет иметь шесть пользователей, SAN является, вероятно, излишеством. В этом типе ситуации маленький автономный сервер башни с некоторыми внутренними дисками является намного более соответствующим решением.
Локальный или SAN единственный способ поддержать производительность. В некоторых случаях SAN может быть быстрее, чем локальный диск из-за большего кэша записи и параллельным дисковой конфигурации пропускной способности.
Постарайтесь не делать любой высокопроизводительный файловый ввод-вывод по долям окон. Существует большая сумма протокола наверху, который замедлит пропускную способность существенно. Например, несколько лет назад я имел размеры, большая передача файлов по WAN на ~50% быстрее использовала FTP по долям Windows.
-
1I' d избегают SAN, если он не выделен SQL, который isn' t обычно случай. SAN' s хороши и быстры для SQL, пока у Вас нет некоторого другого приложения hogging кэш записи. – SqlACID 30 April 2009 в 19:43
Не используйте NAS.
Любое локальное использование (хорошо в течение среднесрочного периода с хорошим RAID-контроллером), но если бюджет позволяет, пойдите для достойного SAN. С удачей можно начать "совместно использовать" SAN с другими системами и исправлять большую часть начальных издержек.
4 ГБ RAM хорошо для большинства систем, пока это - специализированный SQL Server (и это должно всегда быть). Если Вы уже не рассмотрели это, используйте ОС на 64 бита и SQL-сервер, таким образом, можно легко добавить больше RAM, не слоняясь без дела с материалом PAE/AWE.
Также думайте о виртуализации. Вы испытываете необходимость в тестовом сервере? dev сервер? Протестировать установку SP1? (Бесстыдный плюс для более раннего сообщения: sql-server-in-vmware)
С размером базы данных 2 ГБ нет никакой причины даже рассмотреть SAN. NAS не будет работать, необходимо только думать об использовании NAS для резервных копий, таким образом, Вы не храните резервные копии на той же машине как Вы данные, и легко сделать копии с NAS для удаленного устройства хранения данных.
С маленькой базой данных просто используйте локальные диски в RAID 1 или RAID 10. Если Ваша база данных помещается в RAM, Вы не должны быть вполне так взволнованы по поводу производительности IO. Используйте 64-разрядные окна и поместите 8 Концертов там. Это оставит много для ОС и даст Вам комнату для роста.
Я работаю с системами, которые используют оба локальных диска RAID, а также волокно соединяют SAN. SAN, кажется, работает лучше даже с бывшим являющимся более новой и более быстрой машиной. Я думаю, что значимый фактор - то, что расположение локального диска является единственным диском, таким образом, SQL совместно использует диск ввод-вывод с ОС и файлом подкачки. Это, вероятно, способствует в большой степени перетаскиванию.
Как @spoulson упомянутый, SAN может обеспечить намного лучшую производительность диска. Мало того, что это - отдельный диск, но и это вероятно на намного более быстрых дисковых аппаратных средствах.
В нашем случае мы используем SAN, потому что он обеспечивает область централизованного хранения для автоматической обработки отказа сервисные группы SQL Server VERITAS. Когда основная машина перестала работать, диски окон, смонтированные на SAN, повторно смонтированы к машине горячего резервного копирования, и сервер возвращается довольно быстро. Конечно, это требует системы, подобной VERITAS для сервисного управления группы, которое могло бы быть вне Вашего объема.
Один протест, с которым мы боролись, состоит в том, что присвоение дискового пространства SAN обрабатывается консервативно. Поскольку это дорого, они не подают его на прихоти. С SAN EMC мы используем, Вы не можете освободить присвоенное пространство, не выводя весь LUN. Таким образом, если мы находим, что выделенное место является больше, чем нам нужно, и мы хотим использовать часть того пространства для другого LUN, мы не можем только уменьшить увеличенного размера. Мы должны отбросить его и повторно присвоиться. Это не работает так хорошо в продуктивной среде.
Как другие предположили, избегайте NAS. Вы могли бы также поместить свои файлы данных на внешний жесткий диск USB.
-
1Если Ваш SAN EMC является CX4, позже в этом году EMC выпускает обновление ОС, которая будет поддерживать LUN уменьшения для движения с Windows 2008' s способность уменьшить диск. – mrdenny 20 May 2009 в 18:10
Для маленькой базы данных 2GB SAN был бы излишеством.
Вообще говоря, Вы не хотите, чтобы Ваши диски SQL были совместно использованы с любым другим приложением. Аналогично, чем больше шпинделей (диски) можно распространить файлы через, тем лучше. Снова, с маленькой базой данных как Вы описывают, Вы сможете соответствовать всему, в чем Вы нуждаетесь в RAM, таким образом, производительность диска будет меньшим количеством фактора.
Тем не менее не идите и создавайте единственный объем RAID-10 и помещайте ВСЕ свои файлы базы данных на нем. Вы могли запустить с чего-то простого как: Данные - 2x 73 ГБ 15K об/мин, Журналы RAID1 - 2x 73 ГБ 15K об/мин, Резервные копии RAID1 - единственные большие 7 200 об/мин или пара в RAID1
Если у Вас есть бюджет для обновления, добавьте другой отдельный объем для TempDB (если Вы делаете какое-либо создание отчетов комплекса / аналитические запросы), или дайте объему Журнала больше дисков и настройте его как RAID10, если Вы - система, больше транзакции w/большой объем обновлений.
SAN, вероятно, стоил бы 3-4x так же как непосредственно подключаемая система хранения данных для эквивалентного количества дисков. SAN действительно обеспечивают много усовершенствованных возможностей резервного копирования/создания снимков, кластеризируя поддержку и миграцию LUN и расширение. Если они важны для Вас, это может стоить добавленного расхода.
Disclaimer: There are many serious issues with storing SQL Server database files on a NAS. All other options being equal, it is correct to choose the SAN option. A detailed discussion of the relevant issues is in MS KB304261. Yet this thread has become a catch all for other questions regarding SQL Server on a network share, I'd rather post references to the state of NAS support in SQL Server versions.
Quite a few people now experiment with using NAS with MS SQL.
This used to be prohibited by default, however one could lift the restriction in MS SQL 2008 and MS SQL 2005. Since MS SQL 2008 R2 there is no such restriction.
In MS SQL 2005 and 2008 the key is the trace flag that prohibits the use of network shares. One can issue
DBCC TRACEON(1807, -1)
CREATE DATABASE [test] ON PRIMARY
( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )
More details in the September 2010 post in the MSDN blog of Varun Dhawan.
At least technically running SQL Server on a NAS is possible. The choice depends on many factors and it is not hard to imagine a situation where storage for a database is readily available on a NAS.