Сначала Oracle пытался засудить Google за JAVA API, теперь Apple патентует перелистывание, куда катится мир. Если так пойдет и дальше, кто-то запатентует нажатие кнопки и мы вернемся к консольным приложениям (Если никто не запатентует консоль...).
habrahabr.ru/post/155933/
Правда к этому еще добавилось пару плюшек, например за индексами я веду отдельную слежку, собирая инфо по ним дважды в сутки, и сами индексы дефрагментируются в зависимости от того, насколько интенсивно они используются и фрагментируются
Значит я не блеснул внимательностью, но по поводу применимости бэкапа логов готов спорить, опытным путем установлено что это необходимая мера, и к тому-же в 1С как правило важна сохраность данных, так что модель simple ИМХО не самый лучший вариант, неужели все так печально с быстродействием?
Отдельно хочу сказать про резервное копирование, зачем делать full backup каждый день? Конечно, если база весит 5-7 гигов, и бэкапы сжимать, то ладно, но что если база весит 100-300 Гб? Каждый день по 30 гигов бэкап, за месяц терабайт места только для резервных копий.
И еще момент, сколько данных вы готовы потерять? в вашем случае, в худшем варианте вы теряете данные за целый рабочий день. Я рекомендую делать так, раз в неделю full, каждый день differential, и каждый час (у меня каждые 30 минут, тут зависит от того сколько данных вы готовы потерять) бэкап логов, бэкап логов делается быстро, пользователи даже жаловаться не успевают :)
Из-за fill factor = 80 вы местами плотность данных не увеличиваете, а уменьшаете :). (это я занудствую, в общем-то, вы же писали зачем это делаете, но кто-то может удивиться, увидев, что после процедур, направленных на увеличение плотности данных, файл данных вырастает)
Я думаю, из этого можно раздуть холивар, но дефрагментацию делать надо, почему бы не следить за тем как она делается, и получать информацию о состоянии индексов :)
И это верно, но статистика обновится только по тем индексам, для которых был сделан REBUILD. Для индекса, «подвергшегося» дефрагментации (REORGANIZE), статистика не обновится. И также не обновится статистика, созданная SQL Server'ом автоматически.
Согласен. Но я не ставил перед собой цель описать весь план обслуживания БД, статья касается только индексов. А статистика у меня обновляется отдельным шагом.
Условие по proc_id поставил, спасибо за ценное замечание.
Что касается полезности этой процедуры, то даже с теоретической точки зрения она полезна (с практической же, ее полезность бывает разной, я согласен), ведь уменьшая фрагментацию, мы увеличиваем плотность данных на страницах, значит страниц надо будет прочесть меньше, меньше работа диска.
Про статистику я не забыл, msdn утверждает, что обновление статистики произойдет автоматически, если после rebuild мы явно не напишем STATISTICS_NORECOMPUTE = ON, я явно не писал.
Правда к этому еще добавилось пару плюшек, например за индексами я веду отдельную слежку, собирая инфо по ним дважды в сутки, и сами индексы дефрагментируются в зависимости от того, насколько интенсивно они используются и фрагментируются
И еще момент, сколько данных вы готовы потерять? в вашем случае, в худшем варианте вы теряете данные за целый рабочий день. Я рекомендую делать так, раз в неделю full, каждый день differential, и каждый час (у меня каждые 30 минут, тут зависит от того сколько данных вы готовы потерять) бэкап логов, бэкап логов делается быстро, пользователи даже жаловаться не успевают :)
Согласен. Но я не ставил перед собой цель описать весь план обслуживания БД, статья касается только индексов. А статистика у меня обновляется отдельным шагом.
Что касается полезности этой процедуры, то даже с теоретической точки зрения она полезна (с практической же, ее полезность бывает разной, я согласен), ведь уменьшая фрагментацию, мы увеличиваем плотность данных на страницах, значит страниц надо будет прочесть меньше, меньше работа диска.
Про статистику я не забыл, msdn утверждает, что обновление статистики произойдет автоматически, если после rebuild мы явно не напишем STATISTICS_NORECOMPUTE = ON, я явно не писал.