Комментарии 13
Нужно забыть регламентных заданиях обновления статистики SQL это долго
мне кажется, что вы сгущаете краски.
у нас база полтора терабайта, еженощно работают скрипты от ola с агрессивными настройками переиндексации и обновления статистики.
EXECUTE [dbo].[IndexOptimize]
@Databases = 'xxx',
@MinNumberOfPages = 1,
@FragmentationLevel1 = 5,
@FragmentationMedium = 'INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_OFFLINE',
@SortInTempdb = 'Y',
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'N',
@StatisticsModificationLevel = 1,
@StatisticsSample = 100,
@LogToTable = 'Y';приведённый выше скрипт плюс полный бэкап на сетевой диск занимают 3 часа, ИМХО вполне приемлемо.
Нисколько не сгущаю. Выше я привел время на переиндексацию одного! индекса большой таблицы . Это гдето 2 часа это на ssd . Кроме того использование флага для снижения порога автопересчета статистики позволяет избежать ситуации:
"Пришло 5 миллионов изменений по шине Rabbit MQ, прогрузили . Запрос за последний день не увидев статистики поехал по неэффективному плану".
Флагом трассировки-Т2371 эта проблема решается фундаментально. Кстати это рекомендует даже 1С в своей статье Флаги трассировки для работы с MS SQL Server :: MS SQL Server :: Методическая поддержка для разработчиков и администраторов 1С:Предприятия 8 (1c.ru)
Поэтому лучше жить с ним чем без него.
Добавлю что у меня нагрузка создается горизонтальным маштабированием роботов, которые перепроводят Т-3 ежедневно, импортируют изменения. Поэтому без Т-2371 жить проблематично
Кроме того до 2022 года у меня рабочий кластер был 2 Терабайтами SSD RAID 1 и 4 терабайт HDD RAID 10 . Наиболее нагруженные по OLTP таблицы были на SSD остальные на HDD raid . В феврале нам поставили новый полностью на SSD , но принципы обслуживания остались те же
объем данных 5 Терабайт для базы 1С… Размер сжатого бэкапа 0.5 Терабайт
не экспериментировали со сжатием самой базы? я проверял на копиях, получалось примерно 1:4, негативного влияния на производительность не заметил, но на боевой базе не проверял.
У меня нагруженная с точки зрения OLTP база , поэтому сжатие я не рассматривал - поскольку бесплатным оно не бывает. Хотел включить сжатие только на буфере сообщений - он 3 терабайта за 2 месяца , последовательно наполняется, запросы на нем простые. SQL Compression Wizard для него выдал такие цифры
Это при том что там хранятся XML сообщения. Выигрыш был небольшой и закрыл эту тему.
Проще настроить fillfactor Fill factor / Хабр (habr.com)
под конкретную базу и выстроить оптимальную работу с экстентами
Pages and Extents Architecture Guide - SQL Server | Microsoft Docs
Ваш визард предлагает сжатие по строкам. А сжатие на уровне страниц пробовали? Ради эксперимента. Одинэсные базы отлично жмутся таким образом. Уж точно все тестовые базы можно жать для экономии места.
Имеется ввиду это Enable Compression on a Table or Index - SQL Server | Microsoft Docs с типом DATA_COMPRESSION = PAGE ? Я выложу тут результаты wizard для самой большой таблицы.
Что касается практического применения для тестовых баз, скорее всего освободится место в файловой группы, но файловую группу сжать уже будет проблематично (поскольку двигать экстенты медленно и вредно.). А тестовые базы делаются сейчас как копия продуктива, поэтому без сжатия файловой группы я ничего не сокращу по факту
Я выложу тут результаты wizard для самой большой таблицы.
выше уже писал, на моей базе размером в полтора терабайта получается 1:4
думаю, что у вас получатся похожие цифры
но файловую группу сжать уже будет проблематично (поскольку двигать экстенты медленно и вредно.)
с тем, что медленно, соглашусь. но чем особо вредно-то?
https://www.brentozar.com/archive/2017/12/whats-bad-shrinking-databases-dbcc-shrinkdatabase/
Про dbcc shrinkfile ниже high watermark аналогичный эффект
У меня нагруженная с точки зрения OLTP база , поэтому сжатие я не рассматривал - поскольку бесплатным оно не бывает.
На самом деле, если у вас дисковая полка - шпиндельная, или иопсы как-то лимитируются, или сервер в виртуальной среде - скорость обращения к данным даже вырастет после включения компрессии PAGE. Т.к. данных будет к диску и обратно будет путешествовать на 10-60% меньше.
Нагрузка на процессор при этом растет не сильно, на единицы процентов.
С тех пор, как у 2019 стандарт появилось постраничное сжатие - нет причины его не включить.
Если речь зашла о партиционировании, и в случае, если это партиционирование - правильно используется (т.е., например, запросы написаны так, что в них происходит partition eliminations) , то, очень часто, данные можно вообще не архивировать, а оставить в той же базе, или даже в той же таблице. Нужно просто преобразовать партицию в columnstore или columnstore archive.
Кстати, если у вас есть большие (больше нескольких миллионов записей) таблицы, которые по большей части всегда просматриваются целиком - смело преобразуйте их в clustered columnstore.
Это сжимает данные в 8-10 раз и ускоряет всяческое агрегирование в тысячи раз.
Обратная сторона медали - таблица или партиция всегда сканируется целиком, и плохо работает во всяческих join'ах
... хотя это, по большей части не про 1С
1С БодиПозитив