Самый быстрый шринк на Диком Западе

Публикация № 1031815

Администрирование - Производительность и оптимизация (HighLoad)

SQLServer shrink шринк база данных

Шринк (shrink) базы данных. Наглядное объяснение что это, зачем, когда применять и как это можно ускорить.

Шринк? Что это и зачем?

Шринк (shrink) - это сжатие файлов данных для уменьшения занимаемого ими пространства на диске. Выполняется за счет перемещения страниц данных с конца файла в свободное пространство в начало файла. После этого страницы в конце файла становятся неиспользованными и это пространство может быть возвращено файловой системе.

 
 Не путать понятия!

В стародавние времена считалось нормальным выполнять шринк базы данных. Некоторые администраторы даже настраивали регламентные процедуры для "шринкования" вне рабочего времени. К счастью, такое уже редко где можно увидеть, но случаи еще есть.

Почему шринк не стоит делать регулярно на рабочем окружении? Вот основные причины:

  1. Сама по себе операция сжатия файла данных очень ресурсоемка и на больших базах может выполняться десятки часов, а то и больше. Также во время ее выполнения пользователи могут, и скорее всего будут, ощущать замедление работы системы.
  2. Значительное снижение эффективности работы индексов. Шринк переносит страницы в начало файла, так он может перенести и индекс. Причем часть его страниц может быть в самом начале файла, другая где-то по середине, а третья вообще разбросана где попало. В итоге фрагментация индекса будет под 99.9%, что значительно снижает производительность. Индексы попросту не могут быть использованы должным образом. Спасти может только перестроение или реорганизация (иногда), но это снова может увеличит размер файла данных. Есть отличная статья об этом от Brent Ozar.
  3. Появление дополнительных задержек при увеличении файла данных. После шринка база занимает минимальный размер, но если информационная система жива, то новые данные в нее будут поступать снова и снова. Новые данные = нужно больше места. Каждое увеличение файла данных потребует дополнительных ресурсов. Оптимизировать можно уменьшив количество таких операций за счет большего шага автоувеличения файла в настройках базы данных. О влиянии на производительность можно узнать вооооот здесь.

Постойте! Но статья же о быстром шринке! Если сам по себе он так плох, то неужели статью можно уже закончить?

Конечно, нет! Бывают ситуации, когда шринк для базы целесообразен. Замете, целесообразен, но не обязателен!

Вот несколько кейсов, когда его стоит использовать:

  1. В базе данных произошли серьезные изменения. Например, вы удалили какой-либо исторический регистр из базы 1С, который занимал 100 ГБ. И если эти 100 ГБ важны и их нужно освободить на диске, то от шринка не уйти.
  2. Вы применили сжатие страниц для таблиц и индексов, что уменьшило размер занимаемых данных на 70%! А файл базы данных на диске не изменился! Снова шринк! Но опять же, если место и правда нужно под что-то освободить, ведь рано или поздно данные в базе смогут занять его снова.
  3. Вы готовите тестовую базу и удаляете из нее данные, чтобы она не весила 1ТБ. Без шринка тоже никуда, но вопрос производительности может быть неактуальным. Ведь это тестовая среда.

Вообщем, смысл думаю уже понятен.

Классический путь

Стандартный способ выполнить шринк файлов базы данных - воспользоваться такими командами как "SHRINKDATABASE" или "SHRINKFILE". Вот примеры.

-- Первым параметром указываем имя базы данных. 
-- Вторым параметром указываем сколько процентов свободного пространства
-- данных мы хотим освободить
DBCC SHRINKDATABASE ('DatabaseName', 10);  

или

-- Первым параметром указываем логическое имя файла. 
-- Вторым параметром указываем целевой размер 
-- для сжатия файла в мегабайтах.
DBCC SHRINKFILE ('LogicalFileName', 100)

Разница между ними заключается лишь в том, что "SHRINKDATABASE" сжимает все файлы данных и журналы транзакций для указанной базы, а "SHRINKFILE" применяет изменения только для указанного файла.

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

Также для каждой операции могут быть указаны дополнительные параметры, о который вы можете узнать по ссылкам:"SHRINKDATABASE" или "SHRINKFILE".

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

Ах да, ни в коем случае не ставьте в настройках базы данных включенной опцию "Auto Shrink".

ALTER DATABASE [bsl] SET AUTO_SHRINK OFF WITH NO_WAIT

Все еще сомневаетесь? Прочитайте перевод статьи от разработчика Microsoft, который имел прямое отношение к алгоритму сжатия файлов.

Быстрее, выше, сильнее

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

Речь идет о переносе данных из одной файловой группы в другую, при котором есть два пути:

  1. Старую файловую группу, из которой данные перемещены, после этого удаляют.
  2. Если исходную файловую группу удалить нельзя (например, если это группа "PRIMARY"), то ее можно обработать стандартной операцией шринка. В любом случае это будет быстрее, чем использовать стандартное сжатие на исходном файле.

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

На моем опыте использование этого подхода позволяло ускорить сжатие файла данных от 3 до 8 раз, да и последствий для производительности куда меньше.

Как это сделать для баз 1С?  Допустим, у нас есть некоторая база "bsl" на инстансе SQL Server и мы решили ее сжать через файловые группы. Т.к. файловая группа по умолчанию только одна, то нужно добавить еще одну дополнительную и файл данных для нее.

-- Добавляем файловую группу
ALTER DATABASE [bsl] 
	ADD FILEGROUP [FOR_SHRINK]
GO

-- После добавляем новый файл данных для новой файловой группы
ALTER DATABASE [bsl] 
	ADD FILE ( 
		NAME = N'AfterShrink', 
		FILENAME = N'F:\DBs\MSSQL14.MSSQLSERVER\MSSQL\DATA\AfterShrink.mdf' , 
		SIZE = 8192KB , 
		FILEGROWTH = 65536KB ) 
	TO FILEGROUP [FOR_SHRINK]
GO

Теперь с помощью этих скриптов мы можем переместить все таблицы, индексы и даже BLOB-данные в эту файловую группу вот так.

 EXEC dbo.sp_MoveTablesToFileGroup
    -- Фильтр по имени схемы (LIKE-оператор)
    @SchemaFilter = '%',
    -- Фильтр по имени таблицы (LIKE-оператор)
    @TableFilter  = '%',   
    @DataFileGroup = 'FOR_SHRINK', -- Имя файловой группы назначения (куда переносим)
    -- 1 означает "Перенести все кластерные индексы", то есть таблицы, где есть первичный ключ / кластерный индекс
    @ClusteredIndexes = 1,
    -- 1 означает "Переместить все дополнительные индексы"
    @SecondaryIndexes = 1,
    -- 1 означает "Перенести все кучи" - то есть таблицы без кластерного индекса.
    @Heaps = 1,
    -- 1 - значит только сгенерировать скрипт, ничего выполнять не нужно. 0 - сразу выполнить перемещение
    @ProduceScript = 0

Скрипт не универсальный, по крайней мере в текущей его версии, и не может перенести таблицы, в которых, например, только одно поле с BLOB-типом. Для баз 1С это таблица "DBSchema" с описанием структуры базы данных, которую автоматически в новую файловую группу переместить нельзя. Для этого нужно выполнить немного ручной работы:

BEGIN TRANSACTION
GO

CREATE TABLE dbo.Tmp_DBSchema
	(
	SerializedData varbinary(MAX) NOT NULL
	)  ON FOR_SHRINK
	 TEXTIMAGE_ON FOR_SHRINK
GO

ALTER TABLE dbo.Tmp_DBSchema SET (LOCK_ESCALATION = TABLE)
GO

IF EXISTS(SELECT * FROM dbo.DBSchema)
	 EXEC('INSERT INTO dbo.Tmp_DBSchema (SerializedData)
		SELECT SerializedData FROM dbo.DBSchema WITH (HOLDLOCK TABLOCKX)')
GO

DROP TABLE dbo.DBSchema
GO

EXECUTE sp_rename N'dbo.Tmp_DBSchema', N'DBSchema', 'OBJECT' 
GO

COMMIT

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

-- Сжимаем файл основной файловой группы 'PRIMARY'
DBCC SHRINKFILE('bsl', 0)

В итоге все данные перемещены в новую файловую группу, что можно проверить с помощью этого скрипта.

По ссылке выше в своей статье Paul S. Randal этот способ рекомендовал использовать вместо стандартного сжатия данных. Так почему бы не прислушаться? Если бы исходную файловую группу можно было бы удалить (если это не "PRIMARY"), то можно было бы сделать следующее.

-- Удаляем все данные из файла перенося их в другие файловые группы
-- Подробнее о параметре смотреть здесь:
-- https://docs.microsoft.com/ru-ru/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017
DBCC SHRINKFILE ('AfterShrink', EMPTYFILE);
GO

-- Удаляем пустой файл
ALTER DATABASE [bsl]  REMOVE FILE [AfterShrink]
GO

-- Удаляем файловую группу
ALTER DATABASE [bsl] REMOVE FILEGROUP [FOR_SHRINK]
GO

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

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

База в базу

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

  1. Использовать Bulk-операции, как, например, описано здесь.
  2. Штатный мастер импорта и экспорта данных
  3. Использовать утилиту "sqlpackage.exe", входящую в состав SQL Server Data Tools.
  4. Сгенерировать скрипт с помощью SQL Server Managment Studio
  5. Использовать операцию "INSERT INTO".

Подробнее на этом способе останавливаться не будем. За более подробной информацией и развернутыми примерами Вы можете обратиться к отличной статье о шести различных способах передачи данных между базами для SQL Server.

Вы все еще шринкуете?

На этом все. Думаю, в публикации не открыл особо ничего нового для сообщества, но может хотя бы скрипты пригодятся. Главное помнить - шринку нет места в продакшене! Хватит шринковать! :)

Другие ссылки

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Hekeus 17.04.19 09:33 Сейчас в теме
Поставил плюс. Вот только мой шринк быстрее и эффектнее: drop database!
Lelic24RUS; succub1_5; YPermitin; +3 Ответить
2. YPermitin 7382 17.04.19 09:34 Сейчас в теме
3. asved.ru 35 17.04.19 09:50 Сейчас в теме
(1) Для внедрений, хранящих БД на механике, существуют устройства, реализующие аппаратный шринк. Вот например.
4. bykrash 17.04.19 09:55 Сейчас в теме
По ссылке описание и скрипт поэтапного сжатия файла бд https://www.sqlshack.com/shrinking-your-database-using-dbcc-shrinkfile/. Немного доработал, так как попытки сжатия идут даже после отсутствия свободного пространства.
5. bykrash 17.04.19 10:00 Сейчас в теме
Код и описание скрипта пошагового сжатия файла БД https://www.sqlshack.com/shrinking-your-database-using-dbcc-shrinkfile/. Немного доработал, так как попытки сжатия не прекращаются при отсутствии свободного места.
USE [DBname]
DECLARE @FileName sysname = N'LogicalFileName';
DECLARE @TargetSize INT = (SEL ECT 1 + size*8./1024 FR OM sys.database_files WHERE name = @FileName);
DECLARE @Factor FLOAT = .99;
DECLARE @ActualSize INT = 0;
 
WHILE @TargetSize > @ActualSize
BEGIN
    SET @TargetSize *= @Factor;
    DBCC SHRINKFILE(@FileName, @TargetSize);
	SET @ActualSize = (SELECT 1 + size*8./1024 FR OM sys.database_files  Wh ere name = @FileName) * 0.99; 
    DECLARE @msg VARCHAR(200) = CONCAT('Shrink file completed. Target Size: ', 
         @TargetSize, ' MB. Actual size: ', @ActualSize, 'MB. Timestamp: ', CURRENT_TIMESTAMP);
    RAISERROR(@msg, 1, 1) WITH NOWAIT;
     WAITFOR DELAY '00:00:01';
END;
Показать
artichoke; YPermitin; +2 Ответить
6. YPermitin 7382 17.04.19 10:02 Сейчас в теме
(5) шринкуете на постоянной основе? :)
7. bykrash 17.04.19 10:06 Сейчас в теме
(6) Да, сжатие как этап при переносе с прода на тест.
YPermitin; +1 Ответить
13. user-z99999 22 17.04.19 10:28 Сейчас в теме
(7)
Сжатие - это архивирование т.е. базе будет нужно каждый раз, при обращении к данных, распаковывать данные.
Будет тратится время ...

Либо на тесте - использовать полную копию рабочей базы (не нужно сжимать),
либо - обрезать таблицы за предыдущие года, оставлять последний год (месяц).
15. bykrash 17.04.19 10:45 Сейчас в теме
(13) В данном случае архивирование - это то, что нужно, т.к. процессорных мощностей в избытке, а вот дисковое пространство нет (тестовая среда работает на ssd). Полная копия рабочей базы (одной из) занимает ~600 гб и пока от предыдущих данных избавиться нельзя.
8. triviumfan 14 17.04.19 10:08 Сейчас в теме
SQL 2014
В плане обслуживания присутствует "Сжатие БД".
Никакого "Значительного снижения эффективности работы индексов" не замечено.
Проверим статистику индексов самых популярных таблиц.
Прикрепленные файлы:
maksa2005; YPermitin; +2 Ответить
9. YPermitin 7382 17.04.19 10:10 Сейчас в теме
(8) утверждаете, что все что в стать "от лукавого"?
10. triviumfan 14 17.04.19 10:13 Сейчас в теме
(9) У меня нет глубоких знаний и опыта администрирования БД. Просто факт. Но похоже, что "Сатана тут точно замешан".
YPermitin; +1 Ответить
11. YPermitin 7382 17.04.19 10:17 Сейчас в теме
(10) тут на самом деле два варианта:
1. вам повезло и при шринке данные индексов не были перемещены.
2. Вы делали шринк без перемещения данных, который только освобождает место в конце файла. При этом пустое место внутри файла не затрагивается.

Подробнее посмотрите статью Brent Ozar по ссылке в публикации. Она хоть и на английском, но все хорошо показано о влиянии на индексы.
14. triviumfan 14 17.04.19 10:43 Сейчас в теме
(11)
Brent Ozar

Натыкался я на него однажды, ютуб канал ведёт. Непутёвый он.
(12) После. В понедельник выполнялся, 2 дня прошло. Этот план выполняется только по понедельникам.
Прикрепленные файлы:
maksa2005; YPermitin; +2 Ответить
16. YPermitin 7382 17.04.19 10:57 Сейчас в теме
36. Дмитрий74Чел 183 18.04.19 17:48 Сейчас в теме
(11) да у него база 51Мб, плюс в базе оставляет 10% места. И статистику проверил лишь по 3м объектам.
Я читал товарища Брантозавра. И тест выполнил на рабочей базе размером более 200Гб. После этого пришел к админам и смог на цифрах подтвердить - почему я и раньше был против регулярного шринка базы.
12. bykrash 17.04.19 10:26 Сейчас в теме
(10) Статистика собрана после выполнения плана в котором отработало сжатие? Если план ежедневный, на следующий день после сжатия у вас произойдет обсуживание индексов и статитика по идексам будет в норме. Кстати, возможно вы забыли в плане обновление статистики и очистку кэша?
18. nicxxx 236 17.04.19 12:35 Сейчас в теме
(8) Сколько строк в таблицах?
22. triviumfan 14 17.04.19 15:37 Сейчас в теме
(18) достаточно: документов 100к и цен 10кк. Базе более 10 лет.
17. ids79 5046 17.04.19 11:50 Сейчас в теме
Спасибо, хорошая статья.
YPermitin; +1 Ответить
19. YPermitin 7382 17.04.19 14:12 Сейчас в теме
20. nvv1970 17.04.19 14:19 Сейчас в теме
Прочитал по диагонали в надежде уловить, какую задачу вы решаете?
Чем база со свободным местом "хуже", чем без него?

Предполагая, что база наполняется данными, а не пребывает в RO состоянии, что реиндексация способна генерировать большое расширение пространства базы, делаю вывод, что шринк файла данных не нужен чаще, чем "никогда".
А превентивное выделение пространства? А fillfactor? А 24/7 и отсутствие "техокон"? А.......

В чем тогда смысл шринка? Давайте холиварить )))
Лишние (свободные) 50 Гб заполнятся гораздо быстрее, чем DBA потратит время на борьбу за экономию места

PS: а статья да... хорошая ))

PPS_UPD: все нашел строки про "смысл" )))) согласен
YPermitin; +1 Ответить
21. YPermitin 7382 17.04.19 14:22 Сейчас в теме
(20) холивар можно быстро закончить.

Вот удалили Вы из базы файлы размером 300 ГБ, и чтобы место на серверном SSD освободить под некоторую другую задачу. - нужно сделать шринк за минимальное время.

Никогда не говори никогда! =D
23. 3vs 17.04.19 16:57 Сейчас в теме
"Главное помнить - шринку нет места в продакшене! Хватит шринковать! :)"
Да, вот товарищ тоже с этим согласен:
"Почему вы не должны сжимать ваши файлы данных"
habr.com/ru/post/330492/

По сути шринк, получается, та же дефрагментация диска.
Лишний напряг железа - износ механики и нагрева электроники жёстких дисков, что снижает
надёжность.
Один штатовский товарищ считает по тому же поводу, что любой RAID кроме RAID0 - зло
в плане долгожительства жёстких дисков.

Кстати, сегодня была новость, что импортные медики выявили закономерность внезапной смерти человека от его пульса, человек, у которого пульс в покое 55 ударов в минуту, даже если пьёт и курит и т.п. имеет шансов дожить до глубокой старости больше, чем тот, у кого в покое пульс 75 ударов в минуту.
Сердечко, видимо, тоже имеет свой ресурс по количеству сокращений...

Юрий, а нет более радикального решения избавления от фрагментации - иметь, к примеру,
два идентичных дисковых массива, один рабочий а другой пустой, на который периодически
сливаются данные с первого массива, но так, чтобы при записи на пустой массив происходила уже дефрагментация, после чего в работу запускается бывший пустым массив с дефрагментированными данными, а первый, рабочий массив, очищается и ждёт своей очереди по включению в работу?
Да, затратно, но в плане долговечности дисков, возможно выигрыш.
YPermitin; +1 Ответить
24. TODD22 18 17.04.19 17:03 Сейчас в теме
(23)
Да, затратно, но в плане долговечности дисков, возможно выигрыш.

Диски в серверах уже давно расходный материал.
YPermitin; +1 Ответить
25. 3vs 17.04.19 17:04 Сейчас в теме
(24)Это у кого как, к сожалению...
YPermitin; +1 Ответить
26. TODD22 18 17.04.19 17:09 Сейчас в теме
(25)
Это у кого как, к сожалению...

У тех у кого объёмы данных диски до дыр затирают, остальным смысла нет беспокоится.

У меня серверные диски выходили из строя на сервере на котором 4 буха иногда считали ЗП и вели бух учёт примерно два раза в неделю. И база была что то под 500Мб. Однако пара серверных дисков за пару лет вышли из строя.
YPermitin; +1 Ответить
27. 3vs 17.04.19 17:26 Сейчас в теме
"Однако пара серверных дисков за пару лет вышли из строя."
От брака никто на застрахован!
Мы вот тоже наскребли немного денег на два серверных SSD,
так вот один был в плёнке в упаковке, другой без плёнки.
Который был в плёнке, работает третий год.
Который был без плёнки, был неисправен, когда даёшь нагрузку, он вообще пропадал
из системы и биоса, выключаешь сервер, отключаешь питание, снова появляется...
Заменили, правда прошло пара месяцев и на другой тип, так как замены уже не было.
Хотя в фирме, где диски покупали, сказали, что тестировали диск несколько часов, ничего не отваливалось.
По моему настоянию диск, таки отправили на завод, откуда сообщили, что да, брак...
YPermitin; +1 Ответить
28. YPermitin 7382 17.04.19 20:01 Сейчас в теме
(23)
Юрий, а нет более радикального решения избавления от фрагментации - иметь, к примеру,
два идентичных дисковых массива, один рабочий а другой пустой, на который периодически
сливаются данные с первого массива, но так, чтобы при записи на пустой массив происходила уже дефрагментация, после чего в работу запускается бывший пустым массив с дефрагментированными данными, а первый, рабочий массив, очищается и ждёт своей очереди по включению в работу?
Да, затратно, но в плане долговечности дисков, возможно выигрыш.


На мой взгляд это сильно зависит от назначения этой базы, интенсивности изменения в ней данных, особенностей планов обслуживания.

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

Но возможно и есть какое-то решение по Вашей схеме, надо думать и экспериментировать :)
29. 3vs 17.04.19 20:12 Сейчас в теме
"Но возможно и есть какое-то решение по Вашей схеме, надо думать и экспериментировать :)"
Надо экспериментировать! :-)
Я в Вас верю, всё получится! :-)

Давайте беречь жёсткие и твердотельные диски! :-)
В принципе, есть и дополнительный стимул - пока данные на грязном
дисковом массиве не грохнули, он вам будет копией базы, разумеется без
новых данных, но всё таки...
YPermitin; +1 Ответить
30. YPermitin 7382 17.04.19 20:16 Сейчас в теме
(29)
массиве не грохнули, он вам будет копией базы, разумеется без
новых данных, но всё таки...


Ну вот, весь энтузиазм убили :D
31. 3vs 17.04.19 20:20 Сейчас в теме
(30)Не, это побочный эффект! :-)

Можно, даже, для экономии электроэнергии пустой массив отключать!
Хотя, некоторые говорят, что лучше не выключать - установившийся режим лучшее для жёстких дисков, а старт/стоп могут приводить к неисправностям.
Был давно у нас такой случай, сервер работа себе и работал, решили пропылесосить, всё, жёсткий диск больше не включился...
32. genayo 18.04.19 06:22 Сейчас в теме
Что плохого в том, чтобы делать шринк например раз в месяц в технологическое окно? SSD не резиновые так-то :))
33. nicxxx 236 18.04.19 07:32 Сейчас в теме
(32) Написано же, фрагментация 99.9%. Если с highload-ом не сталкивались, то это не очень страшно. А вот когда к диску пойдет 10000 запросов в секунду, а строк в таблицах будет по миллиарду.....
34. genayo 18.04.19 08:59 Сейчас в теме
(33) Ну то есть это не про 1С :))
35. nicxxx 236 18.04.19 09:01 Сейчас в теме
(34) Про 1С, но таких компаний немного. Спроси у брокеров, если есть знакомые, например, БКС или Открытие, как они свои базы 1С обслуживают.
37. YPermitin 7382 18.04.19 20:54 Сейчас в теме
(35) есть еще на просторах родины Highload в 1С =)
38. DonAlPatino 137 23.04.19 16:03 Сейчас в теме
А можно вопросик почти в тему? Что shrink (обрезание) файла для фрагментации индексов очень плохо - это понятно. А как повлияет backup transaction log при full модели восстановления на фрагментацию? Ведь по логике тоже самое происходит... Может кто-нибудь ткнуть носом в хорошую статью по этой теме.
YPermitin; +1 Ответить
39. YPermitin 7382 23.04.19 20:16 Сейчас в теме
(38) нет, шринк лога транзакций не влияет на фрагментацию в файле данных, также не практически не влияет на фрагментацию в самом файле журнала. Но есть нюансы.

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

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/a538cb11-634d-4f5b-91d6-b2257d903783/shrinking-the-log-file-and-fragmentation?forum=sqltools

Но шринк лога транзакций не должен быть регулярной операцией. Зачем? Если это полная модель восстановления, то достаточно делать бэкап лога, тогда данные в нем будут перезаписываться, если так можно выразиться.
40. DonAlPatino 137 23.04.19 20:40 Сейчас в теме
(39) Дык я и не говорил про шринк лога транзакций. Я спрашивал про backup transaction log и его влияние на фрагментацию индексов.
Скажем в лоб - делаем rebuld index, а потом backup transaction log. Соответственно все данные из transaction log переносятся в файл с данными. И что происходит с индексами в этот момент?
YPermitin; +1 Ответить
41. YPermitin 7382 23.04.19 23:18 Сейчас в теме
(40) понял.

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

На производительность это может влиять и есть рекомендации по этому поводу.

Тут дальше можно отдельную статью написать :)
Пару лет назад смотрел вот это: https://www.youtube.com/watch?v=WnLupnOoPXw

Там где-то в видео было подробное описание про влияние бэкапирования на лог транзакций и как с этим бороться. Рекомендую посмотреть.
42. DonAlPatino 137 24.04.19 11:36 Сейчас в теме
(41) Провел тест с утра... Выгрузил базу в бэкап, отребилдил индексы скриптом с https://gallery.technet.microsoft.com/scriptcenter/Script-for-rebuilding-all-8d079754, посмотрел степень фрагментации, сделал backup transaction log, посмотрел степень фрагментации ... один в один до backup. В общем похоже backup transaction log на фрагментацию индексов никак не влияет.
Вот что интересно.. в процессе обнаружил, что ребилд скриптом работает значительно лучше чем rebuild index task из Maintance Plan... ибо на обработанной rebuild index task базе снизил фрагментацию раза в два.
43. YPermitin 7382 24.04.19 12:51 Сейчас в теме
(42) мы говорим на разных языках похоже.

Я говорю про фрагменьацию в файле логов.

В файле данных на фрагментацию не влияет, это я еще в прошлом комментарии написал.

Посмотрите видео, там ответы на все ваши вопросы.
44. СергейК 51 24.04.19 23:01 Сейчас в теме
Спасибо за статью.
Натолкнуло на интересную идею:
Для создания тестовой базы минимально возможного размера использовать метод копирования из рабочей в тестовую базу, предварительно в тестовой создав таблицы и применив к ним сжатие, а только потом заливка данными.
Идеально если применительно к своей конфигурации можно было бы исключать некоторые таблицы от копирования, а некоторые ограничить фильтром, например по дате.

Если у кого есть (полу)готовые наработки, поделитесь плз.

p.s. В виду того что тестовая база на другом SQL сервере и соединение между ними 1ГБит, требует проверки скорость такого копирования для базы 400ГБайт...
Оставьте свое сообщение

См. также

Простое обнаружение проблем производительности в PostgreSQL

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    1150    w.r.    4       

Голосование за доклады на INFOSTART MEETUP Kazan - до 25 февраля. Промо

Выбирайте и голосуйте за самые интересные доклады! Лучшие из лучших попадут в окончательную программу казанского митапа. Оставить свой голос можно до 25 февраля 2020 года.

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    3681    Evil Beaver    13       

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    4105    a.doroshkevich    15       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Оптимизатор запросов. Вторая часть

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    3395    darkdan77    59       

Улучшаем производительность 1С. Рекомендации

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    4662    Kaval88    26       

1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо

Данный онлайн-курс предусматривает углубленное изучение языка запросов и возможностей системы компоновки данных, которые понадобятся при разработке отчетов, работающих на платформе “1С:Предприятие” в рамках различных прикладных решений. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей различных прикладных решений, которые используют в своей работе отчеты разного назначения.

6500 рублей

Атака сервера кнопонажималкой

Статья Программист Нет файла Бесплатно (free) Нагрузочное тестирование

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    2912    nixel    16       

Активный 2019 год на Инфостарт

Статья no Нет файла Бесплатно (free) О сообществе О жизни

О прошедшем 2019 годе в 100 и 500 словах.

26.12.2019    2261    YPermitin    24       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Мониторим производительность с помощью 1С RAS

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Инструментарий разработчика Производительность и оптимизация (HighLoad)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    5585    ivanov660    12       

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    3945    EugeneSemyonov    11       

​​​​​​​CorelDRAW Graphics Suite 2019 Промо

CorelDRAW – пакет профессиональных инструментов для редактирования фотографий, разработки дизайна, создания макетов страниц и векторных иллюстраций

Набор скриптов для знакомства с SQL Server

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    15524    YPermitin    14       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Мониторинг высоконагруженной системы

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    5944    Repich    5       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    11378    Sloth    11       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Руководство по SQL: Как лучше писать запросы (Часть 2)

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    5196    w.r.    1       

1C:Предприятие для программистов: Расчетные задачи (зарплата). Онлайн-интенсив с 01 по 17 июня 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, которые предназначены для автоматизации периодических расчетов, а именно - для расчета зарплаты. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей прикладного решения “1С:Зарплата и управление персоналом” и прочих прикладных решений, в которых реализован функционал расчета зарплаты.

4900 рублей

Анализ производительности APDEX

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    6017    144    YPermitin    7       

Руководство по SQL: Как лучше писать запросы (Часть 1)

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    6434    w.r.    0       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Использование Union вместо OR

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    2545    w.r.    35       

Тюнинг производительности запросов в PostgreSQL

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    4895    w.r.    5       

Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо

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

16450 рублей

Неочевидные проблемы производительности: важность системного подхода при анализе

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    6269    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С"

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    6202    fhqhelp    0       

Управление ИТ-проектами. Модуль 2: продвинутый онлайн-курс по классическим методам управления проектами. Вебинары проходят с 12 марта по 11 июня 2020 года. Промо

Продвинутый онлайн-курс по классическому управлению ИТ-проектами позволит слушателям освоить инструменты из PMBoK® и 1С:Технологии корпоративного внедрения и научиться их применять для проектов любого масштаба. Курс включает в себя 12 вебинаров и 12 видеолекции, разбор кейсов и рекомендации экспертов по проектам слушателей. Ведущая курса - Мария Темчина.

от 13000 рублей

Настройка параметров PostgreSQL для оптимизации производительности

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    4908    w.r.    13       

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    3063    w.r.    6       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Настройка параметров ядра Linux для оптимизации PostgreSQL

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    3722    w.r.    1       

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    8128    igordynets    119