1️⃣🔤 Мифы о DT

Достаточно часто в работе даже с КОРП-клиентами сталкиваемся с тем, что на выгрузку/загрузку DT возлагаются неоправданные надежды основанные на давних мифах…

Давайте разберём некоторые из них:

1. Выгрузка dt происходит в тот каталог куда мы указали.
В итоге – да, но сам процесс выгрузки выглядит иначе, а именно:
- конфигуратор выгружает базу в файл с расширением .n1 и выгрузка эта происходит в каталог временных файлов пользователя процесса rphost
- после окончания выгрузки файл переименовывается и перемещается в каталог, который мы указали при выгрузке
❗️Для успешной выгрузки базы необходимо обеспечить достаточно места не только в каталоге выгрузки, но и в каталоге временных файлов пользователя процесса rphost

2. Большую базу невозможно выгрузить в dt
Тут всё просто – точно возможно, если прочитать п.1 и обеспечить достаточно места.
А вот сколько места – это вопрос интересный, но в среднем dt занимает в 8 раз меньше чем объём базы данных.
Если у вас PostgreSQL, то dt будет занимать примерно столько же сколько резервная копия базы, созданная через pg_dump, так как dt как и pg_dump не содержит индексы.

3. Выгрузка/загрузка dt поможет убрать ошибки учёта или «красные» ошибки
Точно нет, тут даже обсуждать особо нечего…
А вот пересчёт итогов, причём даже в пользовательском режиме без необходимости монопольного доступа, как в случае пересчёта через ТИИ, действительно может починить ОСВ (почему итоги могут испортиться – это отдельная история)

4. Выгрузка/загрузка dt пересчитает итоги
И опять нет, такое было только в 1С 7.7

5. После выгрузки/загрузки dt база станет работать быстрее
Тут уже интереснее – база может начать работать быстрее по двум причинам:
- Поскольку таблицы создались заново, то их распухание и фрагментация стремятся к нулю
- Индексы так же создались заново

Но всё то же самое можно сделать средствами PostgreSQL выполнив неблокирующий reindex concurrently (вместо реиндексации в ТИИ или dt) или выполниd vacuum full (вместо реструктуризации в ТИИ или dt)

В MS SQL распухание таблиц редкое явление и практически не влияет на скорость работы, а неблокирующую реиндексацию можно сделать с галкой «в сети»

6. Имена таблиц на СУБД останутся такими же как у базы с которой был выгружен dt
Это не так, имена нумеруются согласно ИТС и никакой гарантии что они останутся такими же нет.
Например, в базе было 3 справочника с именами на СУБД _Reference1, _Reference2, _Reference3
Затем один справочник удалил (_Reference2) и добавили другой (_Reference4)/
В итоге у нас в базу на уровне СУБД 3 справочника - _Reference1, _Reference3, _Reference4
При загрузки dt, выгруженного с той базы имена справочников будут пронумерованы с начала и идти по порядку и мы получим в новой базу имена - _Reference1, _Reference2, _Reference3.

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

Для этого изначальная загрузка dt в базу должна была пройти не до конца и не создать все индексы, при этом загрузив все данные.
В этом случае всё будет работать, но медленно.
Реиндексация ни средствами ТИИ ни средствами СУБД не поможет, так как эти команды реиндексируют только уже существующие на СУБД индексы, и не формируют новые согласно Схеме базы данных 1С.
Такой сценарий нужно предварительно расследовать, чтобы понять что действительно состав индексов на СУБД не соответствует схеме бд 1С, например развернув чистую конфигурацию на тестовой базе получить состав таблиц и индексов и сравнить с рабочей базой хотя бы по количеству.

8. Ну и наверное самый старый миф – является ли dt резервной копией?
Тут есть много споров, а есть рекомендации 1С https://its.1c.ru/db/metod8dev/content/2922/hdoc

Где описаны некоторые недостатки резервного копирования с помощью dt, основными из которых по моему мнению является то, что необходимо обеспечить монопольный доступ к базе и однопоточность создания dt.

Но с другой стороны, только монопольный доступ гарантирует бизнес-целостность резервной копии, а копия снятая средствами СУБД – это консистентная только на уровне транзакций СУБД копия.