0. OLEG4120 143 28.08.13 10:42 Сейчас в теме

Ускорение реструктуризации таблиц

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. DERL 13.09.13 12:17 Сейчас в теме
Спасибо! Взято на заметку... Статья сохранена в справочном каталоге :)
2. OLEG4120 143 13.09.13 13:44 Сейчас в теме
3. vvr908 399 14.09.13 12:14 Сейчас в теме
Интересная статья, спасибо.
Но что было бы еще интереснее узнать, так это актуальна ли информация для MS SQL (понятно, в общих чертах, без деталей)? Как в реальности проходит та же реструктуризация на MS SQL?

И что будет, если меняется тип сложного поля, к примеру ссылочного (добавляется новый тип, скажем)?
4. OLEG4120 143 14.09.13 14:17 Сейчас в теме
(3) vvr908, На всех БД алгоритм одинако, при руструктуризации документа или другого объекта, состоящие, например, из 3 табличных частей, будет создано 4 таблицы с имена как у исходных таблиц и суффикса ng. Затем в эти новые таблици копируются данные по 1000 записей, после исходные таблици удаляются, а новые переименовываются. Т.е. изменив реквивит в одной из тч, будут копироваться все равно все 4 таблици. Вообще вся эта процедура упирается в производительность дисковой системы, процессор и память почти не задейтвованы. Отсюда такие низкие скорости
5. OLEG4120 143 14.09.13 14:25 Сейчас в теме
(3) vvr908, При ситуации из последнего, нужно рассматривать вторую часть статьи, она более универсальная, но скорость ниже
31. MariusUrsus 22.03.18 16:16 Сейчас в теме
(3) Для ссылочного поля механизм тот же самый. изменятся тип -
bytea
(уникальный идентификатор ссылки) и шаблон наименования поля - добавится
<sql_name>rref.

Вот с составным типом чуть сложнее, для него физически создается не одно поле, а кластер вида
<sql_name>_type|<sql_name>_n|<sql_name>_s|<sql_name>_l|<sql_name>_d|<sql_name>_rtref|<sql_name>_rrref,
т.е. идентификатор типа, поля примитивных типов, указатель (тип) ссылки, ссылка.

Подробнее и с картинками см. в книге "Профессиональная разработка в системе 1С:Предприятие 8. Издание 2. Том 2", приложение "Хранение данных".
Прикрепленные файлы:
6. wbazil 123 16.09.13 09:10 Сейчас в теме
спасибо, довольно простое и оригинальное решение
7. ADirks 181 16.09.13 09:49 Сейчас в теме
Что-то слишком долго 18 часов. Может, индексы снести перед копированием?
Чисто для интересу, на MS SQL закопировал табличку из ~5М строк, 21 колонка - 13 сек.
10. OLEG4120 143 16.09.13 11:10 Сейчас в теме
(7) при копировании, получается таблица вообще без индексов, если вы про "SELECT * INTO ..."
11. ADirks 181 16.09.13 12:25 Сейчас в теме
(10) нет, я имел в виду
INSERT INTO _document39_vt431(
_document39_idrref, _keyfield, _lineno432, _fld433rref)
select * from _document39_vt431_copy

На таблицах _document39_vt... полюбому же PK с контролем уникальности, да ещё и кластерный поди, соответственно вставка будет притормаживать.
Помнится, когда в журнал документов (семёрошный) что-то добавляли, приходилось индексы отключать, и потом создавать по новой, на готовой таблице.
14. OLEG4120 143 16.09.13 14:04 Сейчас в теме
(11) ADirks, Да, возможно Вы правы)
16. ADirks 181 17.09.13 19:54 Сейчас в теме
(14) А есть возможность попробовать (сортировку по PK при вставке)? Интересно же. Интерес конечно достаточно праздный, но всё же...
19. OLEG4120 143 18.09.13 14:47 Сейчас в теме
(16) ADirks, +100 к Вашему скилу :)
время загрузки 2 часа. С sort в селекте и индексами.
20. ADirks 181 18.09.13 16:38 Сейчас в теме
(19) Это -100 к разработчикам из 1С, за идиотские кластерные индексы. Мало того, что бессмысленные, так ещё и вредные.

Рекомендую читануть на досуге: http://www.gotdotnet.ru/blogs/bezzus/1178/
21. Evil Beaver 6403 02.12.13 11:17 Сейчас в теме
(20) ADirks, не думаете же вы, что разработчики платформы не знают что такое кластерный индекс и недостатки GUID полей?
Есть определенное архитектурное решение. Мне кажется, что есть определенные причины, почему было сделано так, а не иначе. Вот вы как думаете, зачем в платформе сделано именно так?
22. ADirks 181 02.12.13 17:25 Сейчас в теме
(21) Я думаю, что кластерные индексы они делают потому что существует мнение, что у всякой таблички обязательно д.б. кластерный индекс. Ну как бы и ладно, лепят и лепят. Собственно, кластерный индекс действительно весьма желателен. Но штука то в том, что GUID - случайное число, по определению. И кластерный индекс по такому полю приводит к неоправданному увеличению времени вставки, что самое печальное - чем больше табличка, тем больше времени уходит на вставку одной записи. Это конечно архитектурное решение, но именно что "определенное".
С другой стороны, понятно, что в общем случае кластерный индекс возможно слепить только по GUID. Ну так дайте возможность лепить свои индексы, по ситуации. Так нет же, развеж можно...
starik-2005; +1 Ответить
23. Evil Beaver 6403 02.12.13 18:20 Сейчас в теме
(22) ADirks, про собственные индексы согласен.
24. artbear 1165 18.06.15 18:04 Сейчас в теме
(20) Алексей, что за статья? ссылка http://www.gotdotnet.ru/blogs/bezzus/1178/ недоступна сейчас
8. juntatalor 61 16.09.13 10:31 Сейчас в теме
Плюсанул, но разберитесь с оформлением статьи - опечаток много.

А постгресс у вас из коробки так работает (48ч на 25М записей)? Или есть какой-то "тюнинг"? Потому что это действительно ОЧЕНЬ долго.
9. OLEG4120 143 16.09.13 11:08 Сейчас в теме
(8) Это долго, Posgres настроен в соответствии с рекомендациями 1с, по-моему были такие на ИТС. В целом, скорость работы в предприятии, очень неплохо, 50 пользователей, 1000 документов день.

Почему так долго - из-за дисковой подсистемы сервера.
На Оракле, на нармальном сервере та же процедура несколько секунд, но Оракл - очень дорого, Майкрософт SQL - просто дорого.
13. Evgen.Ponomarenko 545 16.09.13 13:05 Сейчас в теме
(9)
На Оракле, на нармальном сервере та же процедура несколько секунд

Олег, Если на Оракле, операция занимает несколько секунд, а на PosgresSQL несколько часов - это явно ляп в настройках PosgresSQL, общие рекомендации это одно, а реальный тюнинг это другое. Смотрите на монитор производительности, ищите узкие места и устраняйте. Чаще всего нужно добавить возможность использовать больше памяти, и следите за свопом. Скульный сервер со свопом - куча дорогого металлолома.
uncle_Vasya; +1 Ответить
15. OLEG4120 143 17.09.13 08:06 Сейчас в теме
(13) Evgen.Ponomarenko, Скорее все Вы правы, но это не уменьшает значимости статьи, т.к. реструктуризация платформой - долгий процесс
12. ADirks 181 16.09.13 12:35 Сейчас в теме
Точняк, кластерный, да ещё и по GUID. Бедненький сервер :)

в принципе, можно попробовать так:
INSERT INTO _document39_vt431(
_document39_idrref, _keyfield, _lineno432, _fld433rref)
select * from _document39_vt431_copy 
order by _document39_idrref, _keyfield

возможно будет легче
17. ADirks 181 17.09.13 20:04 Сейчас в теме
И перед такой операцией наверное имеет смысл проиндексировать соотв. образом таблицу копии. Время на построение индекса приплюсовать к времени копирования.
OLEG4120; +1 Ответить
18. Al-X 18.09.13 11:34 Сейчас в теме
Спасибо ! Взял на заметку.
25. МихаилМ 18.06.15 19:10 Сейчас в теме
осталось самое чуть-чуть:

предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации

+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы), свои индексы, секционирование,
классическая репликация, файловые группы.
starik-2005; Sley; утюгчеловек; +3 Ответить
26. утюгчеловек 27.07.15 10:04 Сейчас в теме
осталось самое чуть-чуть:
предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации
+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы)


Это из собственного опыта? На эту тему хорошо бы отдельную статью сделать...
27. necropunk 6 06.07.16 09:24 Сейчас в теме
А при изменении иерархии справочника с элементов на группы как быть?
28. chukawata 10 15.03.17 05:50 Сейчас в теме
Реструктуризация - ресурсоёмкая процедура. Log-файл (в SQL-варианте) растёт на десятки гигабайт и может занять всё свободное место на диске с БД, что закончится ошибкой Runtime Errore.
Прилагаю иллюстрацию - диаграмму падения свободного места и батники для слежения за свободным местом и за объёмом файла.
Прикрепленные файлы:
diskfree.pdf
diskfree.bat
tempdb.bat
29. AvalonE2008 95 20.07.17 17:46 Сейчас в теме
30. Xershi 761 06.08.17 12:55 Сейчас в теме
По мотивам статьи сделал реструктуризацию на своей базе. Переименовал таблицу с 3 миллионами записей. По статистике обновление заняло бы 74 дня. После переименования оно заняло 15 минут. Считайте ускорение во сколько раз?) Это был переход с 8.3.6 на 8.3.8.
uncle_Vasya; +1 Ответить
32. sokir 22.10.18 13:04 Сейчас в теме
В 8.3.11.2867 это уже сделано и даже ещё намного более оптимизированнее.
https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/

Так что уже не актуально.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист/Cтарший программист 1С
Москва
зарплата от 100 000 руб. до 250 000 руб.
Полный день

Программист 1С
Калининград
зарплата от 60 000 руб. до 80 000 руб.
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Программист 1С
Новосибирск
зарплата от 80 000 руб. до 150 000 руб.
Полный день