Комментарии
Шринки бывают разные, но все они не являются регулярными операциями. По видам:
Единственное корректное применение шринка (и данных и ЖТ) - это после масштабных преобразований БД: разворачивание из dt, после свёртки, после реструктуризации основного регистра бухгалтерии. А такие операции происходят нечасто, планово и можно в план воткнуть еще пару пунктов (шринки с последующим обслуживанием индексов).
- shrink для журнала транзакций - не нужен, если корректно настроено резервное копирование и обслуживание индексов. Про роль резервного копирования я писал . А обслуживание индексов, если делать его как в этой статье не приводит к большому росту журналов (если делать штатными средствами, то журналы транзакций будут примерно чуть больше размера базы, но тоже достаточно определённого размера).
- shrink для файла данных - не нужен, так как увеличивает фрагментацию индексов.
Единственное корректное применение шринка (и данных и ЖТ) - это после масштабных преобразований БД: разворачивание из dt, после свёртки, после реструктуризации основного регистра бухгалтерии. А такие операции происходят нечасто, планово и можно в план воткнуть еще пару пунктов (шринки с последующим обслуживанием индексов).
(37) наверно следует рассказать про бэкапы журналов транзакций, после которых СУБД перезаписывает закомитченные данные. Лог условно не растет. Шринк тут вообще не к месту, только показатель отсутствия знаний и обслуживания.
А если говорить про реальную необходимость шринка после масштабных операций, то он должен быть не до нуля, а до некоего стабильного значения размера журнала от бэкапа до бэкапа журнала.
ПС: отдельный привет передам тем слабоумным, кто переключает для усечения журнала базу в сипмл. Вас так много ((((
А если говорить про реальную необходимость шринка после масштабных операций, то он должен быть не до нуля, а до некоего стабильного значения размера журнала от бэкапа до бэкапа журнала.
ПС: отдельный привет передам тем слабоумным, кто переключает для усечения журнала базу в сипмл. Вас так много ((((
(3)
1. Почти нигде нет органичений по длительности и суммарному размеру обработки.
2. Почти нигде нет тестового режима.
3. Часто в скриптах есть странные вещи (то филлфактор не 100, то статистика не пересчитывается при ребилде индекса)
4. Часто в скрипте нет анализа размера таблиц (постоянно переиндексируются мелкие) и заполненности страниц.
5. Часто перестроение индекса отделено от пересчета статистик.
ps: Блин. Заметил, что движок сайта скрипт опять переколбасил (хотя я специально lg и gt ставил). Прикреплю сейчас файликом.
1. Почти нигде нет органичений по длительности и суммарному размеру обработки.
2. Почти нигде нет тестового режима.
3. Часто в скриптах есть странные вещи (то филлфактор не 100, то статистика не пересчитывается при ребилде индекса)
4. Часто в скрипте нет анализа размера таблиц (постоянно переиндексируются мелкие) и заполненности страниц.
5. Часто перестроение индекса отделено от пересчета статистик.
ps: Блин. Заметил, что движок сайта скрипт опять переколбасил (хотя я специально lg и gt ставил). Прикреплю сейчас файликом.
(4) Ясно. По п.1., наверное соглашусь. Я так полагаю, это все имеет место быть когда объемы баз подходят к космическим масштабам? :) П.2 - п.5 я так полагаю, появились из-за п.1.?
Мне чем стандартный план обслуживания нравится: нарисовал все стрелками. Каждую операцию пометил на неудачу по уведомлениям. Если не произошло то- туда, если это - сюда. И забыл про все это дело как страшный сон :) Полагаю, у вас в скриптах тоже все это можно настроить.
Мне чем стандартный план обслуживания нравится: нарисовал все стрелками. Каждую операцию пометил на неудачу по уведомлениям. Если не произошло то- туда, если это - сюда. И забыл про все это дело как страшный сон :) Полагаю, у вас в скриптах тоже все это можно настроить.
скрипт скопировал, но он не до конца получился? не могу проверить в sql 2005
а в 2005 sql надо будет немного переделать декларацию переменных, т.е.
БЫЛО: declare @database_names as nvarchar(max) = N'Analyzerworkstm';
СТАЛО: declare @database_names as nvarchar(max);
set @database_names = N'Analyzerworkstm';
а в 2005 sql надо будет немного переделать декларацию переменных, т.е.
БЫЛО: declare @database_names as nvarchar(max) = N'Analyzerworkstm';
СТАЛО: declare @database_names as nvarchar(max);
set @database_names = N'Analyzerworkstm';
(5) Да, движок сайта сожрал половину. Если не получается скачать, то могу выложить/выслать.
(6) Время становится важным даже если суммарный объём баз на сервере 200-300 ГБ. А этот скрипт применялся и для баз 1-2 ТБ (точнее - почти этот, именно этот скрипт написан заново, потому что я там уже не работаю и не стал воровать). Но и дисковое пространство тоже внезапно расходуется при стандартном скрипте:
Неприятно прийти утром на работу и внезапно узнать, что из-за переиндексации базы упало всё из-за пересечения с загрузкой данных или съедено 200-500 ГБ на серверах.
Собственно, скрипт сейчас написал именно из-за того, что каждые выходные у наших админов журналы транзакций вырастали до двух размеров баз.
Про запуск из планов обслуживания я написал:
(6) Время становится важным даже если суммарный объём баз на сервере 200-300 ГБ. А этот скрипт применялся и для баз 1-2 ТБ (точнее - почти этот, именно этот скрипт написан заново, потому что я там уже не работаю и не стал воровать). Но и дисковое пространство тоже внезапно расходуется при стандартном скрипте:
- Файлы данных могут вырасти на размер самой большой таблицы
- Файлы журналов при полной модели могут вырасти на 1-2 объёма файлов данных
- Файлы журналов при простой модели могут вырасти на размер самого большого индекса в некоторых условиях (но построение индекса - обычно является операцией с минимальным протоколированием, поэтому обычно всё же ЖТ не сильно растёт)
- Не забываем про бэкапы журналов и разностные бэкапы - они тоже станут большими после переиндексации
Неприятно прийти утром на работу и внезапно узнать, что из-за переиндексации базы упало всё из-за пересечения с загрузкой данных или съедено 200-500 ГБ на серверах.
Собственно, скрипт сейчас написал именно из-за того, что каждые выходные у наших админов журналы транзакций вырастали до двух размеров баз.
Про запуск из планов обслуживания я написал:
Такой скрипт можно запускать из задания (job) MS SQL Server Agent или из "кирпичика" Execute T-SQL Statement Task в планах обслуживания (кому как удобнее)
(15) При ребилде индекса, если не указать "STATISTICS_NORECOMPUTE" статистика по данному индексу пересчитывается сама, и причем "бесплатно": при ребилде всё равно весь индекс считывается. Но если таблица достаточно большая, а изменения в ней не приводят к фатальной фрагментации, то если мы не выполняем полного перестроения индекса (например, обходимся reorganize), то статистика может устареть.
Теоретически можно их вообще не пересчитывать, MS SQL сам их будет пересчитывать (если ему не запретить явно), но делать он это будет во время пользовательской транзакции, когда каждый тик-так на счету. Ну и для больших таблиц (100+ ГБ) с массовыми изменениями замечено, что лучше статистику пересчитывать в режиме full scan (иначе она бывает неактуальна), но это очень медленно.
Можно, конечно, пересчитать статистику отдельно от обслуживания индексов, но при обслуживании индексов как раз "протухает" много планов запросов, они потребуют перекомпиляции, поэтому достаточно разумно сразу после ребилдов/реорганайзов выполнить и sp_updatestats, чтобы "волн" рекомпиляций была одна, а не две.
sp_updatestats обновляет не все статистики, а только устаревшие, так что её вызов сразу после перестроения индексов не приводит к повторному просмотру только что перестроенных индексов, так что тут нет лишних затрат.
Теоретически можно их вообще не пересчитывать, MS SQL сам их будет пересчитывать (если ему не запретить явно), но делать он это будет во время пользовательской транзакции, когда каждый тик-так на счету. Ну и для больших таблиц (100+ ГБ) с массовыми изменениями замечено, что лучше статистику пересчитывать в режиме full scan (иначе она бывает неактуальна), но это очень медленно.
Можно, конечно, пересчитать статистику отдельно от обслуживания индексов, но при обслуживании индексов как раз "протухает" много планов запросов, они потребуют перекомпиляции, поэтому достаточно разумно сразу после ребилдов/реорганайзов выполнить и sp_updatestats, чтобы "волн" рекомпиляций была одна, а не две.
sp_updatestats обновляет не все статистики, а только устаревшие, так что её вызов сразу после перестроения индексов не приводит к повторному просмотру только что перестроенных индексов, так что тут нет лишних затрат.
(16)
Мне не понятно 2 момента:
1.
Как статистика может устареть от дефрагментации? Ведь статистика это распределение данных в таблице. Грубо говоря если имеем таблицу на 1000 записей, то статистика это информация о том, что в этой таблице 100 записей со значением "Стул", 50 со значением "Стол" и 850 со значением "Кресло".
Если мы сделали дефрагментацию, то данные никуда не делись и их распределение никак не поменялось, количество столов и стульев не изменилось, следовательно статистика осталась актуальной. Может я что-то неправильно понимаю?
2.
По какой именно причине обслуживание индексов вызывает перекомпиляцию плана запроса?
Мне не понятно 2 момента:
1.
если мы не выполняем полного перестроения индекса (например, обходимся reorganize), то статистика может устареть.
Как статистика может устареть от дефрагментации? Ведь статистика это распределение данных в таблице. Грубо говоря если имеем таблицу на 1000 записей, то статистика это информация о том, что в этой таблице 100 записей со значением "Стул", 50 со значением "Стол" и 850 со значением "Кресло".
Если мы сделали дефрагментацию, то данные никуда не делись и их распределение никак не поменялось, количество столов и стульев не изменилось, следовательно статистика осталась актуальной. Может я что-то неправильно понимаю?
2.
при обслуживании индексов как раз "протухает" много планов запросов, они потребуют перекомпиляции
По какой именно причине обслуживание индексов вызывает перекомпиляцию плана запроса?
(24) Andreynikus,
1. Статистика устаревает не от дефрагментации, а от того, что не обновляется. Просто перестроение индекса статистику обновляет, а дефрагментация не трогает. У автоматического обновления есть своя специфика: оно срабатывает, если я правильно помню на 20% обновления таблицы (что очень немало) и может произойти в "неудобный" для системы момент, затормозив работу текущего запроса.
2. . При обновлении статистики (т.е. при перестроении индекса, в частности) запросы потребуют перекомпиляции.
1. Статистика устаревает не от дефрагментации, а от того, что не обновляется. Просто перестроение индекса статистику обновляет, а дефрагментация не трогает. У автоматического обновления есть своя специфика: оно срабатывает, если я правильно помню на 20% обновления таблицы (что очень немало) и может произойти в "неудобный" для системы момент, затормозив работу текущего запроса.
2. . При обновлении статистики (т.е. при перестроении индекса, в частности) запросы потребуют перекомпиляции.
(17) в (2) еще описал же вроде. Откуда им взяться в регулярном обслуживании?
(18) Фишка в том, что планы обслуживания, как описано в той статье выполняются в разы или десятки раз дольше, чем предлагаемый скрипт. И журналы транзакций на перестроении индексов будут расти до размера базы (если полная модель используется).
(18) Фишка в том, что планы обслуживания, как описано в той статье выполняются в разы или десятки раз дольше, чем предлагаемый скрипт. И журналы транзакций на перестроении индексов будут расти до размера базы (если полная модель используется).
(29)
Спасибо за то что поделились опытом, в отличии от технических статей статьи с опытом получаются наиболее концентрированными.
Есть пара вопросов:
Как вы боретесь с этим? Насколько сильная фрагментация получается?
Судя по
У вас подобный скрипт выполняется раз в неделю?
Спасибо за то что поделились опытом, в отличии от технических статей статьи с опытом получаются наиболее концентрированными.
Есть пара вопросов:
Если у вас есть таблицы 100-200 ГБ и больше, то при распараллеливании построения индекса, после перестроения он формально снова может оказаться фрагментированным.
Как вы боретесь с этим? Насколько сильная фрагментация получается?
Судя по
При полной модели восстановления я бы поставил полное резервное копирование после обслуживания индексов.
У вас подобный скрипт выполняется раз в неделю?
(31)
Не сильная, не боремся
Нет, хоть каждый день. Тут скорее "я бы не ставил полное и разностное резервное копирование прямо перед индексированием, а поставил бы сразу после, чтобы при сбое иметь копию сразу после обслуживания, а не трахаться с последующим восстановлением больших журналов транзакций"
(32)
Возможно, дисковая посистема такая, возможно статистик много нагенерировано. Тут надо предметно смотреть.
Как вы боретесь с этим? Насколько сильная фрагментация получается?
Не сильная, не боремся
У вас подобный скрипт выполняется раз в неделю?
Нет, хоть каждый день. Тут скорее "я бы не ставил полное и разностное резервное копирование прямо перед индексированием, а поставил бы сразу после, чтобы при сбое иметь копию сразу после обслуживания, а не трахаться с последующим восстановлением больших журналов транзакций"
(32)
Возможно, дисковая посистема такая, возможно статистик много нагенерировано. Тут надо предметно смотреть.
(38) Eduard66,
Тут нужно умение оценить текущее состояние базы в SQL, оценить степень проблемы, и применить нужное средство в нужное время.
Например, в данной статье рассматривается проблема большой/дефрагментированной таблицы индексов, и смежная проблема статистики. А статистика может быть неактуальна и в маленькой базе.
Другое дело, что чем меньше данных обрабатывается - тем меньше влияние неактуальной статистики, и поэтому её обновлением пренебрегают в таком случае.
А что нужно дорабатывать при больших базах?
То же, что и "при маленьких".
Тут нужно умение оценить текущее состояние базы в SQL, оценить степень проблемы, и применить нужное средство в нужное время.
Например, в данной статье рассматривается проблема большой/дефрагментированной таблицы индексов, и смежная проблема статистики. А статистика может быть неактуальна и в маленькой базе.
Другое дело, что чем меньше данных обрабатывается - тем меньше влияние неактуальной статистики, и поэтому её обновлением пренебрегают в таком случае.
(39) AlexO, я имел в виду что автор указывает на доработку скрипта при работе с большими базами.
Вопрос собственно про это
Он подходит без изменений для большинства баз данных 1С до примерно 0,5-0,7 ТБ (дальше его уже лучше немного доработать, если кому-то интересно/актуально могу пояснить в комментариях).
Вопрос собственно про это
Перестроение — полное построение индекса. При этом обычно станицы становятся максимально плотно забиты данными, а статистика обязательно обновляется (всё равно все данные читать). Обычно данные индексированные данные полностью недоступны при перестроении индекса.
Rebuild index у меня проходит за час, сбор статистики за два. Возникают два вопроса, почему перестройка индекса идет быстрее сбора статистики и можно ли вообще отказаться от сбора статистики и делать по ночам только ребилд индекс?
Спасибо за статью, и за подробные комментарии к вопросам.
Для меня остался невыясненным один вопрос:
Надо ли делать обновление статистики после перестроения индекса? Ведь обновление и так происходит автоматически при ребилде. И если все же надо, то почему?
Для меня остался невыясненным один вопрос:
Надо ли делать обновление статистики после перестроения индекса? Ведь обновление и так происходит автоматически при ребилде. И если все же надо, то почему?
Мир этому дому!
С большим удовольствием прочитал статью и обсуждения - информация полезная особенно для тех, для кого MS SQL - черный ящик. Автору спасибо.
На курсах по оптимизации внимание на индексы и статистику обращали в первую очередь.
С большим удовольствием прочитал статью и обсуждения - информация полезная особенно для тех, для кого MS SQL - черный ящик. Автору спасибо.
На курсах по оптимизации внимание на индексы и статистику обращали в первую очередь.
Подскажите, пожалуйста, есть ЗУП КОРП 2,5 база стала сииильно пухнуть, каждый день выполняется переиндексация, обновление статистики. Нашел таблицу в ней всего 2 индекса, но они занимают 45Гб, это как-то не нормально. Что делать то?
(53) Под SQL 2000 не работает: там нет нужных DMV и приходилось подобное делать через кучу приседаний (см. DBCC SHOWCONTIG)
Я бы настоятельно рекомендовал уже уйти с 2000 - слишком много накопилось исправленных проблем. Если речь про 7.7, то это немного сложнее, но эти сложности того стоят. Если речь про 1С8, то безусловно переходить.
Я бы настоятельно рекомендовал уже уйти с 2000 - слишком много накопилось исправленных проблем. Если речь про 7.7, то это немного сложнее, но эти сложности того стоят. Если речь про 1С8, то безусловно переходить.
(57) подскажите, я сделал свертку базы sql 2008 1c 7.7. Удалял данные прямо из таблиц sql, удалилось несколько миллионов строк из проводок и регистров,но размер базы не изменился. Для сжатия базы запустил отдельно регламентную процедуру на ночь, но размер базы не уменьшился, ужался только лог. Модель базы данных "простая".
Попробовал вашу скрипт. На небольших базах до 100Гб, работает замечательно время обслуживания раза в три уменьшилось. А вот на большой базе 300Гб проблема. Перестроение индексов делается достаточно быстро, а вот обновление статистики занимает часов 15. Опять же скрипт не прекращает работу по таймауту. Не могли бы подсказать куда копать, где может быть проблема?
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.