Большой размер базы Acronis Storage Node DML Database (asn_dml_objects.db3)
Здравствуйте.
Я обратил внимание, что при переходе на версию Acronis Backup 12.5 значительно выросла база данных Acronis Storage Node DML Database (asn_dml_objects.db3). За последнюю неделю база выросла с 16 до 50 Гб. Может ли это как-то быть связано с некорректной работой заданий репликации резервных копий, т.к. по моему наблюдению репликация не всегда начинается или выполняется частично? Согласно статье в базе знаний эта база содержит записи о выполненных действиях и принятых оповещениях. В связи с этим хотелось бы узнать о том какую ценность представляет эта база данных для работы Acronis Backup 12.5, можно ли её удалить (пересоздать) и/или ограничить рост?
Я решил проанализировать содержимое базы данных Acronis Storage Node DML Database (asn_dml_objects.db3), чтобы выяснить какие таблицы и записи вызывают значительный рост. На текущий момент в сутки у меня база растёт на 4 Гб. Для анализа был взят файл asn_dml_objects.db3 размером 11,4 Гб.
Количество записей в таблицах:
- BuiltinIndexedPredicate - 41
- BuiltinPredicate - 41
- IndexedPredicate - 55
- Info - 3
- NormTuple - 857081
- NumericTuple - 70234
- OrderedPredicate - 0
- Predicate - 1454
- StringTuple - 0
- Subject - 3684
Из всех таблиц подозрение вызывает только NormTuple, т.к. таблицы NumericTuple и Subject содержат данные одной и той же длины, в то время как в NormTuple есть поле Value.
Дальнейший анализ таблицы NormTuple показал, что размер занимаемых данных в ней можно выделить по полю ValueType (ValueType > байт (записей)):
- 0 > 0 (54 541)
- 1 > 103 581 (103 581)
- 2 > 734 (734)
- 6 > 149 610 (106 478)
- 7 > 174 (86)
- 8 > 239 168 (90 239)
- 9 > 251 939 (27 417)
- 10 > 5 180 (1412)
- 11 > 402 324 (1445)
- 12 > 1 587 060 (44 085)
- 13 > 8 054 217 (382 476)
- 14 > 31 191 (3 457)
- 15 > 12 195 197 467 (39 859)
- 16 > 0 (1 269)
- 31 > 2 (2)
Теперь видно, что наибольший объём в таблице занимают записи с ValueType = 15, а это 99,6 % размера всей базы!
Дальнейший анализ записей с ValueType = 15 был проведён по полю Predicate.
| Predicate | Кол-во | Размер данных, байт |
| 1328 | 721 | 3 967 775 993 |
| 715 | 721 | 3 757 619 359 |
| 1182 | 721 | 3 757 619 359 |
| 1187 | 721 | 690 356 641 |
| 1340 | 1446 | 15 106 778 |
| 1338 | 1440 | 3 299 676 |
| 1041 | 721 | 2 154 905 |
| ... | ... | ... |
Как видно 99,8 % от размера записей по полю Value занимают записи со значением поля Predicate равным 715, 1182, 1187 и 1328.
Из таблицы Predicate узнаём, что:
- 715 .Result.Description.Slices
- 1182 .Details.Argument.SourceStageInfo.StageDescription.Slices
- 1187 .Details.Argument.TargetNewSlicesUri
- 1328 .Details.Argument.TargetStageInfo.StageDescription.Slices
В моём случае некоторые объёмные записи содержат данные в поле Value размером до 9 Мб!
Теперь осталось понять зачем весь этот объём хранится в базе и как его можно ограничить.
Если у кого-то наблюдается похожая проблема с ростом файла asn_dml_objects.db3, то можно поступить согласно статье. Единственный нюанс в том, что после таких манипуляций узел хранения, для которого был удалён этот файл, на сервере управления может перейти в оффлайн режим. Для решения этой проблемы достаточно повторно зарегистрировать узел хранения следующей командой (выполняется на узле хранения):
"C:\Program Files\Acronis\RegisterAgentTool\register_agent.exe" -a management_server_name -o register -s asn
Юрий,
Мы попробовали воспроизвести подобные симптомы у себя, но к сожалению добиться таких результатов не получилось. У вас будет возможность сохранить диагностическую информацию с Acronis Management Server (лучше целиком, а не только проблемные базы), чтобы выслать её нам на исследование? Если да, то используйте FTP адрес по ссылке, которую я пошлю в личном сообщении. Анализ, проведённый вами впечатляет, но для полноты картины (чтобы понять корневые причины) нам всё-таки понадобится диагностическая информация.
Спасибо.
Продолжаю разбираться в проблеме, и кое-что проясняется.
Рост базы asn_dml_objects.db3, а также потребление оперативной памяти процессом StorageServer.exe в значительной степени зависит от количества резервных копий в хранилищах и количества выполненных заданий репликации резервных копий за время работы службы Acronis Storage Node Service.
Как я ранее писал, база данных asn_dml_objects.db3 во время репликации резервных копий забивается записями типа:
.Result.Description.Slices
.Details.Argument.SourceStageInfo.StageDescription.Slices
.Details.Argument.TargetNewSlicesUri
.Details.Argument.TargetStageInfo.StageDescription.Slices
При этом мне удалось определить простую формулу, по которой можно вычислить рост базы данных:
| Прирост 1 (d1), байт | 2756 | .Details.Argument.SourceStageInfo.StageDescription.Slices |
| Прирост 2 (d2), байт | 475 | .Details.Argument.TargetNewSlicesUri |
| Прирост 3 (d3), байт | 2852 | .Details.Argument.TargetStageInfo.StageDescription.Slices |
| Прирост 4 (d4), байт | 2756 | .Result.Description.Slices |
| Репликаций на задание, r | ||
| Заданий, t |
Прирост = t*(d1 + d2 + d3 + d4)*(r + 1)*r/2 (байт)
Например, если будет выполняться 8 заданий, для каждого из которых будет реплицировано 1000 резервных копий, то прирост базы данных составит: 8*(2756 + 475 + 2852 + 2756)*(1000 + 1)*1000/2 = 35 391 356 000 байт (33 Гб)!
Если же удалить базу данных asn_dml_objects.db3 и продолжить выполнение заданий, то лучше не станет.
Если за суммарное количество ранее сделанных репликаций на задание принять переменную ro, то формула прироста будет следующей:
Прирост после очистки = (2*(d1 + d2 + d3 + d4)*ro*t + (d1 + d2 + d3 + d4)*r)*r/2
Например, если до очистки было выполнено 1000 репликаций на каждое из 8-ми заданий и будет выполнено столько же, то прирост базы данных составит: (2*(2756 + 475 + 2852 + 2756)*1000*8 + (2756 + 475 + 2852 + 2756)*1000)*1000/2 = 75 131 500 000 байт (70 Гб)!
Таким образом каждое новое задание репликации резервной копии одного архива увеличивает значение поля Value записей в таблице NormTuple в арифметической прогрессии. Одна задача репликации в среднем увеличивает новые значения Value на сумму предыдущих и 8839 байт (d1 + d2 + d3 + d4). При этом некоторые из значений прироста (d2 и d3) с ростом базы также могут увеличиться. Получается, что, например, через 1000 репликаций, очередное задание репликации добавит в базу 1000*8839 = 8 839 000 байт (8,42 Мб) данных! При этом новые значения в базе незначительно отличаются от предыдущих по содержимому.
Можно подвести итог, что использование относительно большого количества резервных копий и заданий репликации из-за неоптимизированных алгоритмов, может привести к значительному росту базы данных asn_dml_objects.db3 и потреблению оперативной памяти процессом StorageServer.exe.
Чуть позже предоставлю архив полученной базы данных asn_dml_objects.db3. Например, за сутки с нуля одним заданием резервного копирования с репликацией в 4 хранилища можно раздуть базу до 4 Гб!
Юрий, спасибо за дополнительные детали - базу с ФТП я скачал и отправил разработчикам на исследование.
Здравствуйте, Василий.
Планируются ли какие-либо изменения в Acronis Backup по проблеме, описанной в данной теме?
Здравствуйте, Юрий
Проблема с размером базы - инфраструктурная и связана с количеством объектов перечисляемых в сервисных активностях (не связанных непосредственно с операциями резервного копирования) от сервиса Acronis Storage Node. В следующей версии Acronis Backup мы планируем начать переход от Acronis Storage Node на отдельные сервисы, чтобы не смешивать функциональность по управлению дедупликацией и ленточными накопителями, что в частности и приводит к подобным проблемам связанным исключительно с особенностями Acronis Storage Node.
Это произойдёт еще не скоро и для решения текущей проблемы стоит в первую очередь попробовать обновиться на недавно вышедший Update 3, изменения в котором могут помочь. Если же это не поможет то стоит обратиться в нашу команду поддержки для корректного отслеживания статуса решения.
Спасибо.