Безопасность дефрагментации диска на SQL серве? #142159

Имеется ввиду дисковый массив, содержащий ИБ от V8, при активной работе юзеров. С тормозами все ясно - вопрос о целостности данных? Не могу найти на эту тему вразумительного ответа. Кто-то что может подсказать? SQL в работе постоянно - свободного времени нет.

елси работает лучше ничегго не трогай. - золотое правило. ФС какая?

ФС лучше не трогай при работе + бэкап всегда должен быть

NTFS понятно... w2k3. Рискнул только что... defrag файлы БД не тронул, которые в работе. Видать, СКЛ не отпустил.

работает, но медленно. База огромная - за 40 гигов.

ДУмаешь дефрагментация поможет, очень сомневаюсь.

+5 да.. не поможет. да и не нужна. Кодд наверное в гробу перевернулся. 40 гиг -это что?

Ну, я исхожу из предположения, что скорострельность есть совокупность многих факторов. Упорядоченная файловая система - один из них.

NTFS это не надо. 40 гиг это что?

У тебя что на этом разделе еще чего-нибуль есть кроме базы? Т.е. файлы интенсивно создаюся/удаляются? Но даже при этом эффект будет стремиться к нулю. PS. Больще зависит от настроек SQL-сервера, быстродействия дисковой подсистемы, объема оперативки и наконец самое важное, от структуры данных и оптимальности кода.

40 гигов,это круто! свертка не канает?

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

Это mdf. За 4 месяца. А на скл.ру есть статьи, говорящие об эффетивности дефрага для больших баз.

акуеть. а что будет за год. а за два. Что за инфа за 4 месяца 40 гигов?

Документооборот огромный... что будет через год, я стараюсь не думать :)

Оптимальность кода, конечно, заставляет желать лучшего... УПП, знаете ли.

а раздербанить базу по нескольким физ. дискам? Ну и обслуживание индексов при таких размерах,оч. актуально,мнимум 15% прибавишь по быстродействию

40 гигов это только база за 4 месяца?! Это без лога транзакций?

а вот тут подробней, пжалста... я не в курсе, как один mdf на разные диски разогнать.

если точнее, то 44 гига.

по обслуживанию индексов,глянь здесь: а вот насчет разделения файлов БД,то при создании этой самой БД,есть возможность указать пути,где будут располагаться mdf и ldf файлы, потом закачаешь в нее данные (в БД) и юзай,я так для семерки делал,да и щас у меня лог файл на отдельном физ. диске валяется

+20 ну как ты понимаешь,что все это делается в Ent. manager

Спасибо, ШтушаКутуша, про это я в курсе. Правда, все на одном диске за неимением (по бедности) второго массива.

а насчет дефрагментации индексов,если забуксуешь,то скину исходники на дельфях,пишешь на дельфи? ну а если не пишешь,то по крайней разберешься и наваяешь в 1С,используя ADO... ...а массив то,не raid-5 случаем?

На делфях так и не научился - я с Сей начинал когда-то ;) Я этот момент мэйтененс планом разрулил. Массив 10-й. СКЛ по настройкам вылизал, на мой взгляд, в самый потолок (как доехало до 10 гиг, он по стандартным настройкам вообще шевелиться перестал).

тада поюзай счетчики производительности,это в журнале быстродействия, это поможет найти узкое место

Юзаю... узкое место - дисковая система. А причина этого места - бардак с партиями. Но это отдельная песня.

ну тады, ой! пусть босяки не скупятся на апгрейд

При работе многозадачных систем дефрагментация помогает незначительно. Некая фрагментация данных наоборот ускоряет процесс (10-30 %), нежели его усугубляет - бул такой тест ;)

у нас файлавая БД 10 гиги выдерживала

у меня максимум-29 гигов

Хах! Так я теперь никого не боюсь! :) Ща плнируется трохи пригрузить базу доп.инфой... и мои 12 гектар в месяц превратятся в 15-17!

тормоза жуткие (при документообороте в 4000 доков с нефиговой табличной частью и 4-5 запросами).

обрезание сделали. 1-3 гига в месяц :)

а еще индексы можнл в снеондари шмальнуть,ежели у таблицы их больше 5

можнл в снеондари=можно в секондари