Разместить *.mdf и *.ldf файлы на виртуальном диске? #457651

Как у пытливого ума, возникла идея, для общего развития :), разместить *.mdf и *.ldf файлы на виртуальном диске. Будет ли производительность выше, или mssql достаточно эффективно кеширует и никаких преимуществ это не даст? 1. селект`ы будут быстрее? 2. апдейты, инсерты будут быстрее? 3. есть ли драйвера виртуального диска для х64?

а tempdb на флешку :)

..зачем Хаус сбрил усы?(с) ))

Намного эффективнее будет разместить на виртуальном диске папки пользователей.

есть ssd - чуток умнее все-таки...

- бесполезная затея. Или вы ставите базу в full-режим и у вас быстренько кончается место на виртуальном диске, или вы ставите базу в simple-режим и теряете в скорости столько, что все плюсы виртуального диска обесцениваются.

>>есть ssd - чуток умнее все-таки... ога, если еще и в страйп их запрячь )))...  тока небюджетно

чем "симпл" медленнее?

- чем full :-) Я не теоретик, обосновать не смогу. Но я практик, так что могу с уверенностью сказать - базы в simple ощутимо медленнее на добавлении данных. Microsoft однозначно рекомендует держать базы в full и чикать логи при регламентных операциях. Причем не только из соображений надежности, но и для максимального быстродействия.

ага.. а чикать базы всюду рекомендуют так 1. переведите базу в симпл режим 2. выполните шринковку :)

1) быстрее 2) быстрее 3) есть зато потеряется важное свойство СУБД - надежность.

>> зато потеряется важное свойство СУБД - надежность. это конечно так...

когда лдф до размера виртуального диска вырастет - что делать будешь?

>> базы в simple ощутимо медленнее на добавлении данных. А мужики-то не знают...

а зачем ему давать расти?

- не знают - пусть учатся. Это не позорно в любом возрасте.

возьмет и вырастет... а ты и не успеешь почикать

только кошки сами родяца! )))...

мне бы ссылочку, почитать.. где написано, что симпл медленнее чем фулл

виртуальный - это имеется в виду такой, который в оперативной памяти?

+ если ответ утвердительный, то сабж - интеллектуальный онанизм

ага )))..

ищешь братьев по разуму? :)))))))))

брат пацак, ну что ты не по теме? ))).. желательно обсудить не "кошерность - некошерность" "гадов", а как "гадов" готовить

что должна быть за база, чтоб ради производительности жертвовать данными? база кладр чтоли? :)

>>что должна быть за база, чтоб ради производительности жертвовать данными? база кладр чтоли? :) типа того)).. бывают ситуации когда надо разовые операции над данными провести, но как можно быстрее

Если ты о "программном" - толку в "расределенном" режиме (многопользовательский режим) не будет, там софт ресурсы процессора отжирает капитально из того что я тестил. А вот апаратный рам-диск - вешч. При правильном подходе - система летает.

а что за такое "аппаратный"?.. ниразу на глаза не попадалось!)).. поди дорогой, аглицкой работы?..

вот те, аппаратный: :)

контроллер такой. :) втыкаеца в PCI. в него втыкается память. в него же втыкается батарейка, для вящей суръезности.

эта дятел айбиэмовский)))..  кстате хорошие были диски

>>контроллер такой. :) втыкаеца в PCI. писиай это несерьезно...

Не, ну можешь воткнуть куда считаешь серьезно. Я не возражаю.

..ейная пропускная способность уже категорически устарела и любой софтварный виртуальный диск ныне будет быстрее... я так думаю )

Ты не о том подумал. Первое, что гуглится сходу по твоему вопросу:

+ повторюсь. софт-рам-диски из того что можно погонять бесплатно - ерунда. или мне не тупо не везло. ;) Поиграться можно только для рабочей станции и для специфических задач. Для "разгона" СУБД - только железячные контроллеры. При нужной доле настойчивости можно вытворять шикарные вещи и грабить корованы. ;)

>>и грабить корованы. ...эхх (мечтательно прикрыл глаза)  )))

..оне вроде версию "i-RAM 2" выпустили.. вот где бы прикупить?..

за 215-250 usd в забугорном интернет магазине.

ага..дятлосерия была очень удачная... гарантированно сыпалась :)

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

неее. дятлосерия была особенной... там целую партию пришедшую в нерезиновск меняли вообще без вопросов - тупо по желанию.

Изучайте. Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. Журнал транзакций автоматически не обрезается. Этот режим обеспечивает максимальные возможности восстановления (за счет снижения производительности). Только в этом режиме вы можете использовать зеркальное отображение баз данных и автоматическую доставку журналов (log shipping). Именно этот режим выбирается по умолчанию для пользовательских баз данных, поскольку он настроен для базы данных model. Если изменить режим восстановления для базы данных model, то для создаваемых баз данных по умолчанию будет выбираться новый режим. Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций. Но в этом режиме использовать журнал транзакций для восстановления уже удасться. Вы не сможем даже выполнить резервное копирование журнала транзакций: команда BACKUP LOG в этом режиме сразу вернет ошибку. Какой же режим восстановления выбрать? Microsoft (в своих учебных курсах) рекомендует для рабочих баз данных выбирать только режим Full. Однако из опыта проведения автором этих самых учебных курсов и общения со слушателями можно сказать, что очень многие опытные администраторы сознательно настраивают для своих баз данных режим восстановления Simple. Значительное повышение производительности при операциях массовой вставки и при работе с большими двоичными данными вполне оправдывает некоторое снижение возможностей резервного копирования и восстановления. Что важнее для вашей задачи — дополнительные возможности восстановления или максимальная производительность, решать вам.

с чего вдруг что-то должно быть быстрее? или под виртуальным диском имеется в виду рам-диск?

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

ну ты хочешь высокую производительность и даром? :) к тому же, об отказоустойчивости тоже не забывай

Отдайте SQL Server'у максимум памяти. Он то, что ему надо сам закэширует.

да, неудачно я выразился.. под вирт. диском я конечно имел рам-диск!

Именно. Нафиг надо.. Прирост есть разве только в синтетических тестах, в реальной работе незаметно.