sn1251На raw лучше не размещать, потому что она системой не кэшируется.

Так это же хорошо - СУБД -то кеширует данные, зачем два раза их кэшировать ? Только память лишнюю тратить.

Я уж не знаю , на чем там на Linux лучше, но на всех *NIX достоточно стандартный подход - создавать ВСЕ девайсы на raw partitions.

Их есть у меняsn1251, то есть, к примеру (RedHat возьмем) - для tempdb
разумнее было бы сделать раздел с ext2, к примеру, а не транзакционные etx3
или ReiserFS, ведь тразакционность уж точно замедлит работу tempdb?
Чем тупее файловая система ОС, тем лучше это для СУБД. Уж тем более не нужна какая-то транзакционность файловой системы - СУБД это и так обеспечивает.

RomaleСкорее всего Ваши тесты покажут примерно одинаковые результаты. О общем случая однозначно лучше размещать на raw. ИМЕННО, чтобы уйти от файлового кэша. Сейчас многие даже на NT уходят от файлового хранения девайсов, хотя там это не есть raw в чистом виде.


Как раз наоборот, сейчас, когда на всех уже почти *NIX-ах появилась возможность делать dsync=off, причина делать raw device ушла, и Sybase уже рекомендует не делать raw (или не рекомендует делать RAW - ранее на многих *NIX, в частности, SUN OS, это было просто жестким требованием).

sn1251
Память действительно тратится, но не зазря - записи журнала транзакций ведь регулярно скидываются на диск, и если ОС их сможет буферизировать - возможно будет некоторый прирост в скорости, по крайней мере при очень большой активности в tempdb.


Именно зря. Какие страницы будет кэшировать ОС ? Которые читались ? Тогда память будет тратиться зря, поскольку те же страницы будет кэшировать и СУБД. Которые еще НЕ читались (типа read-ahead)? Ну тогда и подавно кэш ОС зря тратиться будет, поскольку не знает ОС, что в файле лежит, какие страницы НУЖНО читать, а какие - НЕ НУЖНО.

СУБД - это всегда маленькая операционная система, и чем меньше реальная операционная система будет дублировать функции СУБД, тем легде СУБД будет работать.

Romale
... возникала ситуация, когда на ASE нарушалась внутренняя целостность базы. При этом database device`ы располагались на NTFS. Его версия: После аппаратного сбоя (возможно после пергрузки) ОС производит check filesystem,
далее, check успешно выполнен, с точки зрения NTFS, но ASE считает по-другому. В результате - битая база.

Насколько я знаю, в WIN32 API исходно была возможность сказать операционке, чтобы она для данного файла не использовала бы кэш или чтобы кэш работал в режиме write-through. И поэтому ASE на NT не требовала использования raw device. На Solaris такое требование до недавнего времени было. Что же касается краха БД - NTFS наверное может "лечить" не все случаи порчи данных, а типичной причиной порчи данных при аппаратных сбоях является использование контроллеров дисков без отдельного питания на внутренние буфера обмена. Ну сценарий там простой - база пишет в файл, диск говорит, что УЖЕ записал, но на самом деле ЕЩЕ только положил во внутренний буфер, а на диск еще не записал, потом, например, выключается питание, машина перегружается - на диске старые данные, непонятно какие.