Поэтапное сжатие БД MS SQL Server / Microsoft SQL Server

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Поэтапное сжатие БД MS SQL Server

25 сообщений из 107, страница 4 из 5

все

Поэтапное сжатие БД MS SQL Server

#40114580

cad2206

Гость

SERG1257,

авторНе понял насчет тестового сервера.
не корректно выразился. На новом сервере, где установлен MS SQL Server 2019. База переедет со старого (на MS SQL Server 2012).

авторСжимаете таблицу (торопится не надо).
Помню, что нужно секционировать таблицы, но пока без этого. С каких таблиц лучше начать? Наиболее часто используемых? Больших?

...

Рейтинг:

0 / 0

24.11.2021, 16:24

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40114610

SERG1257

Участник

Сообщения: 2 932

Рейтинг: 0 / 0

Для больших таблиц прогоните sp_estimate_data_compression_savings
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-estimate-data-compression-savings-transact-sql?view=sql-server-ver15
Посмотрите на разные типы сжатия. Может ROW будет ненамного хуже (и точно дешевле)
У меня было пару случаев когда это имело смысл (большая таблицы с пустыми полями типа int и большая таблица с типом char(200))

Маленькие таблицы даже не рассматривайте - визгу много шерсти мало

...

Рейтинг:

0 / 0

24.11.2021, 17:14

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40114745

cad2206

Гость

SERG1257,
при размере файла БД 830 ГБт, какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings?

...

Рейтинг:

0 / 0

25.11.2021, 09:16

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40114746

cad2206

Гость

SERG1257,
авторСжимаете таблицу (торопится не надо).
Не делаете shrink.
Не делаете дефрагментацию. Я у себя отменил этот еженедельный джоб и никто не заметил разницы.
Я правильно понял, сжимать по несколько таблиц за ночь без shrink'а (это я уже понял, что shrink крайняя мера) и без дефрагментации. И смотреть на работу пользователей?

...

Рейтинг:

0 / 0

25.11.2021, 09:19

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40114818

selis76

Участник

Сообщения: 398

Рейтинг: 0 / 0

У меня нагруженная база 1С на 3 терабайта, по опыту пространство больше расходуется на фрагментацию поскольку кластерный (системный) код 1С много удаляет и вставляет заново особенно в итогах по регистрам.
Перестроение кластерных индексов и обычных индексов помогает гораздо эффективнее. Освобожденное место можно использовать для новых данных. Ну а вообще в решении должна быть заложена процедура обрезания старых данных и свертки остатков. База не должна расти бесконечно

...

Рейтинг:

0 / 0

25.11.2021, 12:40

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40114960

SERG1257

Участник

Сообщения: 2 932

Рейтинг: 0 / 0

cad2206какие таблицы считать большими для исследования их функцией sp_estimate_data_compression_savings?Исследовать можно хоть все (это просто посмотреть, это бесплатно)
Результаты (для PAGE и для ROW) в эксельку, сортируя по разнице между sample_size_with_current_compression_setting и sample_size_with_requested_compression_setting
Уверен, что кандидатов будет не больше десятка. А дальше нужно будет принимать решение кто достоин, а кто нет.

selis76, я человек простой, а вопрос сложный. Можешь пояснить свою мысль языком ЖЭКа. (или как говорят буржуи ELI5)
Правильно ли я понял, что ты хочешь сказать что для твоей базы перестроение индексов действительно высвобождает место.
Однако следом ты утверждаешь что плотно упакованный индекс, будет снова переразбит следующей операцией (особенно в итогах по регистрам.)
Так может и не трогать эти итоги по регистрам. Ну будут некоторые страницы наполовину пусты. Стоит ли овчинка выделки? И как это относится к сабжу топика (сжатие aka компрессия данных).
По поводу удаления старых данных это тоже оффтопик. Люди годами не могут почистить балкон (гараж, подвал), а тут данные удалить. А если понадобятся?

...

Рейтинг:

0 / 0

25.11.2021, 17:19

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40115005

selis76

Участник

Сообщения: 398

Рейтинг: 0 / 0

to SERG1257,
1C это генератор таблиц и запросов на основе финансовых метаданных . Поэтому большинство информации имеет период и итоги тоже периодичны (по умолчанию месяц) . Даже в регистрах накопления агрегаты тоже порождают много операций удаления и вставки
А это прямой путь к фрагментации. Конечно ребилд оптимизирует данные в прошлых периодах, но в новых периодах все начинается сначала. Играться с наполнением экстентов можно уже после того как все хорошо с фрагментацией.
Пример как 1С генерит SQL код можно увидеть тут https://infostart.ru/1c/articles/184361/
Структура таблиц и индексов 1С официально выложена https://its.1c.ru/db/metod8dev/content/1798/hdoc https://its.1c.ru/db/metod8dev/content/1590/hdoc

...

Рейтинг:

0 / 0

25.11.2021, 20:08

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116381

cad2206

Гость

Добрый день, знатоки.
Продолжаю свои эксперименты, не ругайтесь, это лишь эксперименты на тестовых базах, для моего понимания.

Создал этапы в плане обслуживания:
1. Создание полной резервной копии в модели восстановления "Полная"
2. SHRINKDATABASE

Код: sql

DBCC SHRINKDATABASE(DBName)

3. Перевод базы в модель восстановления "Простая"

Код: sql

1.
2.

USE [master];  
ALTER DATABASE [DBName] SET RECOVERY SIMPLE;

4. Дефрагментация индексов
5. Перевод базы в модель восстановления "Полная"

Код: sql

1.
2.

USE [master];  
ALTER DATABASE [DBName] SET RECOVERY FULL;

6. Обновление статистики

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

Объясните пожалуйста, почему вырос лог?

...

Рейтинг:

0 / 0

01.12.2021, 09:42

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116389

msLex

Участник

Сообщения: 8 523

Рейтинг: 0 / 0

cad2206

Если я правильно понимаю, то в модели восстановления "Простая", лог журнала не растет.

Не правильно поняли.

В простой модели, лог автоматически усекается (освобождается место внутри файлов лога) по завершению транзакций.

cad2206

Перевод базы в модель восстановления "Полная"

Код: sql

1.
2.

USE [master];  
ALTER DATABASE [DBName] SET RECOVERY FULL;

Просто для понимания.
После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа.

...

Рейтинг:

0 / 0

01.12.2021, 10:14

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116393

felix_ff

Участник

Откуда: Moscow

Сообщения: 1 982

Рейтинг: 0 / 0

cad2206

Добрый день, знатоки.
2. SHRINKDATABASE

забудьте эту команду

...

Рейтинг:

0 / 0

01.12.2021, 10:19

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116404

cad2206

Гость

msLex,
Так отчего вырос лог (именно файл лога, очень сильно вырос )?

Понимаю, что при SHRINKDATABASE данные в БД фрагментируются полностью. Затем выполняю дефрагментацию для всех индексов.
Если завершенной транзакцией считать каждое выполнение:

Код: sql

ALTER INDEX [IndexName] ON [TableName] REBUILD

при дефрагментации, в модели восстановления "Простая", то лог будет усекаться внутри файла и сам файл расти не будет. А тут вырос сам файл лога.
Что в моем случае тогда считается завершенной транзакцией?

авторПросто для понимания.
После перевода базы в FULL, реальный переход на FULL модель восстановления произойдет только после 1-го полного бекапа.
Это я понимаю.

felix_ff,
авторзабудьте эту команду
забуду, как только разберусь во всем

...

Рейтинг:

0 / 0

01.12.2021, 11:22

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116410

cad2206

Гость

Код: sql

ALTER INDEX [IndexName] ON [TableName] REBUILD

...

Рейтинг:

0 / 0

01.12.2021, 11:44

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116421

felix_ff

Участник

Откуда: Moscow

Сообщения: 1 982

Рейтинг: 0 / 0

cad2206,

Код: sql

ALTER INDEX [IndexName] ON [TableName] REBUILD

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

...

Рейтинг:

0 / 0

01.12.2021, 13:34

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116427

cad2206

Гость

felix_ff,
спасибо, я понимаю что она журналируемая.
Но для большего понимания хочется усвоить:
1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции. Ок. Что считать подтвержденной транзакцией? Выполнение ALTER INDEX [IndexName] ON [TableName] REBUILD считается подтвержденной транзакцией? В моем случае таких вызовов на каждый индекс, при переиндексации, за 400.
2. В зависимости от понимания первого пункта, как предотвратить переполнение журнала (диска, выделенного под журнал)? Переиндексировать в модели восстановления "Полная" и бекапить журнал раз в 15 мин? Файл журнала вырос почти на 400ГБ, при размере БД в 220ГБ.

...

Рейтинг:

0 / 0

01.12.2021, 13:46

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116436

aleks222

Участник

Сообщения: 2 564

Рейтинг: 0 / 0

cad2206

1. @@trancount = 0
2. Так ты ничо и не понял. Увы. Даже донкихот не боролся с ростом журнала транзакций переключением мельниц на полные обороты.

...

Рейтинг:

0 / 0

01.12.2021, 14:16

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116438

aleks222

Участник

Сообщения: 2 564

Рейтинг: 0 / 0

Ах да, "как предотвратить?"

Завязывай с реиндексированием.
Надежно.
Просто.
Эффективно.

...

Рейтинг:

0 / 0

01.12.2021, 14:18

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116452

cad2206

Гость

aleks222,
авторТак ты ничо и не понял
Ну объясни доступно. Где что я не понимаю? На каких этапах что происходит?

Уважаемые знатоки, мне придется один раз сделать шринк, кто бы что не говорил, но придется. ОДИН РАЗ! На рабочей базе, когда пойму все особенности и отлажу на тестовых базах. А после шринка придется сделать дефрагментацию, как минимум один раз (т.к. после шринка все данные фрагментированы очень сильно). Поэтому и прошу помощи разобраться.

...

Рейтинг:

0 / 0

01.12.2021, 15:01

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116471

felix_ff

Участник

Откуда: Moscow

Сообщения: 1 982

Рейтинг: 0 / 0

cad2206,

вы с какой проблемой пытаетесь бороться?

shrink файлов базы данных (замечу не файлов лога) нужен только в одном случае: когда у вас к примеру файл базы данных заполнил весь объем свободного дискового пространства и дальше файлы бд в том числе файлы лога расти не могут, а руководство жопится и денег на новые диски не дает.
вы берете чистите (delete/truncate) какой то большой объем архивных данных за N-лет который уже никогда никому не понадобится, у вас высвобождается место которое можно вернуть операционной системе, тем самым позволив файлу лога расти что бы не стопорить бд, вот только в этом случае шринк файлов данных оправдан.

в других ситуациях:
а) файл бд должен быть всегда 300ГБ и ни капельки больше,
б) о мой бог наш файл разово разросся нужно его ужать сейчас же
с) прочая хрень

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

Но для большего понимания хочется усвоить:
1. В модели восстановления "Простая", журнал усекается внутри файла журнала при подтверждении транзакции.

не верно, в простой модели восстановления усечение происходит после достижения контрольной точки

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

ознакомьтесь:
https://docs.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver15#FactorsThatDelayTruncation

...

Рейтинг:

0 / 0

01.12.2021, 16:02

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116472

cad2206

Гость

felix_ff,
авторshrink файлов базы данных (замечу не файлов лога) нужен только в одном случае: когда у вас к примеру файл базы данных заполнил весь объем свободного дискового пространства и дальше файлы бд в том числе файлы лога расти не могут, а руководство жопится и денег на новые диски не дает
именно!

...

Рейтинг:

0 / 0

01.12.2021, 16:08

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116475

cad2206

Гость

felix_ff,

авторвы с какой проблемой пытаетесь бороться?

сейчас уже не проблема, а желание понять. Например, почему вырос файл журнала, при дефрагментации в модели восстановления "Простая".

...

Рейтинг:

0 / 0

01.12.2021, 16:19

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116476

L_argo

Участник

Сообщения: 1 497

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

01.12.2021, 16:22

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116482

cad2206

Гость

L_argo,
авторФайл журнала будет размером с самую большую транзацию
Что мне понимать под транзакцией в моем случае?

авторЕсли у вас есть хотя бы одна большая таблица, то файл будет огромным вне зависимости от модели
на тестовой базе самая большая таблица занимает 24ГБт.

...

Рейтинг:

0 / 0

01.12.2021, 16:39

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116489

cad2206

Гость

felix_ff,
авторне верно, в простой модели восстановления усечение происходит после достижения контрольной точки

Из документации https://docs.microsoft.com/ru-ru/sql/relational-databases/logs/database-checkpoints-sql-server?view=sql-server-ver15:
в простой модели восстановления автоматическая контрольная точка становится в очередь, если журнал заполняется на 70 процентов.

Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала?

...

Рейтинг:

0 / 0

01.12.2021, 17:22

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116497

aleks222

Участник

Сообщения: 2 564

Рейтинг: 0 / 0

cad2206

Верный ли от сюда вывод, что журнал будет усекаться при достижении его размера в 70% от размера самого файла журнала?

Кто на ком стоял?

ЗЫ. Прирожденный управдом. Этот тредстартер.

...

Рейтинг:

0 / 0

01.12.2021, 17:58

| Ответить | Цитировать | Написать

Поэтапное сжатие БД MS SQL Server

#40116503

cad2206

Гость

aleks222,
Ох, хочется услышать от тебя что то полезное, а каждый пост все о одном...

...

Рейтинг:

0 / 0

01.12.2021, 18:18

| Ответить | Цитировать | Написать

25 сообщений из 107, страница 4 из 5

все

Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Поэтапное сжатие БД MS SQL Server

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=46&msg=40116421&tid=1684055]:	0ms
get settings:	11ms
get forum list:	14ms
check forum access:	4ms
check topic access:	4ms
track hit:	333ms
get topic data:	12ms
get forum data:	3ms
get page messages:	67ms
get tp. blocked users:	2ms
others:	12ms

total:	462ms