Целесообразно ли разносить базу и логи на разные диски в SQLServer если физически дис #507153

Есть виртуальный машина, на нем SQLServer 2005, физический диск один, на вирутальку выделено мето и разбито на 2 диска. Вопрос : Целесообразно ли разность файл базы данный и логов на разные диски или все равно ?

смысла нет

имеет смысл их разносить физически, а не логически :-)

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

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

ага, и байты соскальзывают из-за центробежной силы

Т.е. ты считаешь, что луше объединить диски С и D и писать базу и логи в на этот логический диск ? Кто бы спорил, нет возможности Пока не растет, но хочу попросить,чтобы прописали чтоб росло.

Так если нет возможности, то тогда расслабься.. Чудес на свете не бывает :-)

Головке пофик откуда считывать.. ближе или дальше от центра. Но вот лишнее позицинирование головки - это безусловно замедление операций считывания/записи

видел графики скорости чтения с разных дорожек ?

это не "график чтения с разных дорожек" это "график чтения с учётом позиционирования"... Безусловно время позиционирования "чем дольше, тем больше", но само по себе физическое чтение от номера дорожки не зависит

с центральных дорожек медленнее чтение, ведь линейная скорость поверхности диска относительно головки заметно меньше, а ЖД начинается с внешних дорожек, в отличие от CD

а теперь попробуй объяснить: 1) почему позиционирование на внутренних дорожках существенно медленней, да так, что скорость чтения аж в 2 раза меньше 2) откуда берется позиционирование при последовательном доступе

Тебе уже сказали что на виртуалке смысла выпендриваться нет.

это когда физически они смежны идёт "последовательное чтение".. а когда ты выёживаешься на логическом, то два последовательных логических блока физически могут располагаться как угодно и твоё последовательное чтение на виртуале - для физического чтения плошное смыканье позиционирования

во-первых: "два последовательных логических блока физически могут располагаться как угодно" только в одном случае - произошел ремапинг сбойного блока из таблицы замещения и тогда, действительно, происходит чтение из резервной зоны, что требует долгого позиционирования. именно этот эффект используется для качественного визуального определения сбойных секторов по графику последовательного чтения. во-вторых, все-таки хотелось бы услышать ответ на вопрос "почему позиционирование на внутренних дорожках существенно медленней, да так, что скорость чтения аж в 2 раза меньше ?"

"только в одном случае - произошел ремапинг сбойного блока из таблицы замещения" сказочник :-).. сейчас физичекая конфигурация (количество головок, цилиндров, секторов) ничего не имеет даже близко схожести с логической конфигурацией. Особенно сейчас, когда приходится постоянно реализовывать на "старых  BIOS" современные уже терабайтные ёмкости. а замещение сбойных секторов "резервными" - это совсем иной механизм

бредятина

Спешиал для 1Сников в кавычках: Резервные секторы Для увеличения срока службы диска на каждой дорожке могут присутствовать дополнительные резервные секторы. Если в каком либо секторе возникает неисправимая ошибка, то этот сектор может быть подменён резервным (англ. remapping). Данные, хранившиеся в нём, при этом могут быть потеряны или восстановлены при помощи ECC, а ёмкость диска останется прежней. Существует две таблицы переназначения: одна заполняется на заводе, другая — в процессе эксплуатации. Границы зон, количество секторов на дорожку для каждой зоны и таблицы переназначения секторов хранятся в ЗУ блока электроники. Логическая геометрия По мере роста емкости выпускаемых жёстких дисков их физическая геометрия перестала вписываться в ограничения, накладываемые программными и аппаратными интерфейсами (см.: Барьеры размеров жёстких дисков). Кроме того, дорожки с различным количеством секторов несовместимы со способом адресации CHS. В результате контроллеры дисков стали сообщать не реальную, а фиктивную, логическую геометрию, вписывающуюся в ограничения интерфейсов, но не соответствующую реальности. Так, максимальные номера секторов и головок для большинства моделей берутся 63 и 255 (максимально возможные значения в функциях прерывания BIOS INT 13h), а число цилиндров подбирается соответственно ёмкости диска. Сама же физическая геометрия диска не может быть получена в штатном режиме работы и другим частям системы неизвестна.

и где же здесь написано, что _порядок_ следования физических секторов не совпадает с логическим при использовании LBA ?

читать совсем не умеешь??? "В результате контроллеры дисков стали сообщать не реальную, а фиктивную, логическую геометрию, вписывающуюся в ограничения интерфейсов, но не соответствующую реальности. " твоя "кажущая последовательная" последовательность является ФИКЦИЕЙ, потому что реальная физическая реализация скрыта самим котроллером (которые тебе выдаёт "удобные для интерфеса" данные, но которые ничего общего не имеют сеалиями)

воспринимать написанную информацию можешь ? контроллеры сообщают фиктивную информацию о _геометрии_, то есть номера цилиндров и головок. НО нигде не сказано, что _последовательность_ логической нумерации секторов отличается от физической ! да, мы не знаем реальный номер цилиндра или трека, но за сектором 739 идет сектор 740.

"за сектором 739 идет сектор 740." именно.. для логической нумерации всё именно так, но ты НЕ ЗНАЕШЬ, как это реализованно физически.. будет ли при таком переходе менятся (физически) номер головки и номер цилиндра).