Ускорение реструктуризации таблиц
Иногда, может сложиться так, что на уже долгое время работающей базе нужно изменить типа реквизита, или добавить индексируемые поля, или просто добавить реквизит. Так вот после этого, нас ожидает долгий процесс (если база больших размеров)реструктуризации таблицы. В этой статье я рассмотрю алгоритм значительного сокращения времени реструктуризации.
Комментарии
Избранное
Подписка
Сортировка:
Древо
Интересная статья, спасибо.
Но что было бы еще интереснее узнать, так это актуальна ли информация для MS SQL (понятно, в общих чертах, без деталей)? Как в реальности проходит та же реструктуризация на MS SQL?
И что будет, если меняется тип сложного поля, к примеру ссылочного (добавляется новый тип, скажем)?
Но что было бы еще интереснее узнать, так это актуальна ли информация для MS SQL (понятно, в общих чертах, без деталей)? Как в реальности проходит та же реструктуризация на MS SQL?
И что будет, если меняется тип сложного поля, к примеру ссылочного (добавляется новый тип, скажем)?
(3) vvr908, На всех БД алгоритм одинако, при руструктуризации документа или другого объекта, состоящие, например, из 3 табличных частей, будет создано 4 таблицы с имена как у исходных таблиц и суффикса ng. Затем в эти новые таблици копируются данные по 1000 записей, после исходные таблици удаляются, а новые переименовываются. Т.е. изменив реквивит в одной из тч, будут копироваться все равно все 4 таблици. Вообще вся эта процедура упирается в производительность дисковой системы, процессор и память почти не задейтвованы. Отсюда такие низкие скорости
(3) Для ссылочного поля механизм тот же самый. изменятся тип - (уникальный идентификатор ссылки) и шаблон наименования поля - добавится
Вот с составным типом чуть сложнее, для него физически создается не одно поле, а кластер вида т.е. идентификатор типа, поля примитивных типов, указатель (тип) ссылки, ссылка.
Подробнее и с картинками см. в книге "Профессиональная разработка в системе 1С:Предприятие 8. Издание 2. Том 2", приложение "Хранение данных".
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", приложение "Хранение данных".
Прикрепленные файлы:
(10) нет, я имел в виду
INSERT INTO _document39_vt431(
_document39_idrref, _keyfield, _lineno432, _fld433rref)
select * from _document39_vt431_copy
На таблицах _document39_vt... полюбому же PK с контролем уникальности, да ещё и кластерный поди, соответственно вставка будет притормаживать.
Помнится, когда в журнал документов (семёрошный) что-то добавляли, приходилось индексы отключать, и потом создавать по новой, на готовой таблице.
INSERT INTO _document39_vt431(
_document39_idrref, _keyfield, _lineno432, _fld433rref)
select * from _document39_vt431_copy
На таблицах _document39_vt... полюбому же PK с контролем уникальности, да ещё и кластерный поди, соответственно вставка будет притормаживать.
Помнится, когда в журнал документов (семёрошный) что-то добавляли, приходилось индексы отключать, и потом создавать по новой, на готовой таблице.
(20) ADirks, не думаете же вы, что разработчики платформы не знают что такое кластерный индекс и недостатки GUID полей?
Есть определенное архитектурное решение. Мне кажется, что есть определенные причины, почему было сделано так, а не иначе. Вот вы как думаете, зачем в платформе сделано именно так?
Есть определенное архитектурное решение. Мне кажется, что есть определенные причины, почему было сделано так, а не иначе. Вот вы как думаете, зачем в платформе сделано именно так?
(21) Я думаю, что кластерные индексы они делают потому что существует мнение, что у всякой таблички обязательно д.б. кластерный индекс. Ну как бы и ладно, лепят и лепят. Собственно, кластерный индекс действительно весьма желателен. Но штука то в том, что GUID - случайное число, по определению. И кластерный индекс по такому полю приводит к неоправданному увеличению времени вставки, что самое печальное - чем больше табличка, тем больше времени уходит на вставку одной записи. Это конечно архитектурное решение, но именно что "определенное".
С другой стороны, понятно, что в общем случае кластерный индекс возможно слепить только по GUID. Ну так дайте возможность лепить свои индексы, по ситуации. Так нет же, развеж можно...
С другой стороны, понятно, что в общем случае кластерный индекс возможно слепить только по GUID. Ну так дайте возможность лепить свои индексы, по ситуации. Так нет же, развеж можно...
(8) Это долго, Posgres настроен в соответствии с рекомендациями 1с, по-моему были такие на ИТС. В целом, скорость работы в предприятии, очень неплохо, 50 пользователей, 1000 документов день.
Почему так долго - из-за дисковой подсистемы сервера.
На Оракле, на нармальном сервере та же процедура несколько секунд, но Оракл - очень дорого, Майкрософт SQL - просто дорого.
Почему так долго - из-за дисковой подсистемы сервера.
На Оракле, на нармальном сервере та же процедура несколько секунд, но Оракл - очень дорого, Майкрософт SQL - просто дорого.
(9)
Олег, Если на Оракле, операция занимает несколько секунд, а на PosgresSQL несколько часов - это явно ляп в настройках PosgresSQL, общие рекомендации это одно, а реальный тюнинг это другое. Смотрите на монитор производительности, ищите узкие места и устраняйте. Чаще всего нужно добавить возможность использовать больше памяти, и следите за свопом. Скульный сервер со свопом - куча дорогого металлолома.
На Оракле, на нармальном сервере та же процедура несколько секунд
Олег, Если на Оракле, операция занимает несколько секунд, а на PosgresSQL несколько часов - это явно ляп в настройках PosgresSQL, общие рекомендации это одно, а реальный тюнинг это другое. Смотрите на монитор производительности, ищите узкие места и устраняйте. Чаще всего нужно добавить возможность использовать больше памяти, и следите за свопом. Скульный сервер со свопом - куча дорогого металлолома.
Точняк, кластерный, да ещё и по GUID. Бедненький сервер :)
в принципе, можно попробовать так:
возможно будет легче
в принципе, можно попробовать так:
INSERT INTO _document39_vt431(
_document39_idrref, _keyfield, _lineno432, _fld433rref)
select * from _document39_vt431_copy
order by _document39_idrref, _keyfieldвозможно будет легче
осталось самое чуть-чуть:
предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации
+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы), свои индексы, секционирование,
классическая репликация, файловые группы.
предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации
+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы), свои индексы, секционирование,
классическая репликация, файловые группы.
осталось самое чуть-чуть:
предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации
+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы)
предложенный подход реализовать в виде ddl триггера(все субд поддерживают) и забыть о реструктуризации
+ появляются такие полюшки как: замена таблиц представлениями (например 1 кладр на все базы)
Это из собственного опыта? На эту тему хорошо бы отдельную статью сделать...
Реструктуризация - ресурсоёмкая процедура. Log-файл (в SQL-варианте) растёт на десятки гигабайт и может занять всё свободное место на диске с БД, что закончится ошибкой Runtime Errore.
Прилагаю иллюстрацию - диаграмму падения свободного места и батники для слежения за свободным местом и за объёмом файла.
Прилагаю иллюстрацию - диаграмму падения свободного места и батники для слежения за свободным местом и за объёмом файла.
Прикрепленные файлы:
diskfree.pdf
diskfree.bat
tempdb.bat
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|