Материал предоставлен сайтом www.learn1c.ru/
В предыдущей статье Вы узнали, что каждый регистр физически представлен парой файлов (для DBF-версии) или таблиц (для SQL-версии) (для простоты далее по тексту я буду использовать термин "таблица").
- Таблицы, начинающиеся с RA, хранят все движения, выполненные документами по регистрам.
- Таблицы, начинающиеся с RG, хранят промежуточные итоги с периодичностью, заданной на форме "Управление итогами" (пункт меню "Операции" -> Управление оперативными итогами), а также итоги на ТА.
В этой статье мы попытаемся разобраться, зачем понадобилось создавать таблицы RG и как периодичность сохранения остатков влияет на работу программы.
Зачем нужны таблицы RG
Давайте вспомним запрос из предыдущей статьи, который выполняется при временном расчете итогов на 18.03.06 (в тестовой базе период сохранения остатков 10 дней):
Алгоритм получения остатков: из таблицы RG берутся промежуточные итоги (1), к ним добавляются движения из таблицы RA, произведенные с момента сохранения промежуточных итогов до момента, на который рассчитываются остатки (2).
Представим, что таблицы RG нет. В этом случае остатки на 18.03.06 рассчитать тоже можно, однако, придется обрабатывать все записи из таблицы RA, начиная с самой первой. Запрос примет следующий вид (в тестовой базе учет начался с января 2004 г.):
Проанализируем выполнение того и другого запроса. Вместо формальных параметров @P1, @P2, @P3 и @P4 я подставил реальные значения. Запросы выполнялись в SQL Query Analyzer, показатели выполнения брались из SQL Profiler. Перед выполнением каждого запроса MS SQL Server перезапускался.
Запрос №1. Сгенерирован программой 1С, используются таблицы RA и RG:
Запрос №2. Написан вручную, используется только таблица RA:
Вы видите, что время определения остатков во втором запросе в 3 с лишним раза больше, чем в первом. При этом для второго запроса количество операций чтения с логического диска почти в 17 раз больше, а затраты процессорного времени в 14,5 раза больше, чем для первого.
По мере роста таблицы RA показатели выполнения запроса №2 будут стремительно ухудшаться, т.к. объем обрабатываемых строк будет становиться все больше и больше. Показатели выполнения запроса №1 тоже будут ухудшаться, но не так сильно: несмотря на то, что размер таблицы RA будет увеличиваться, количество обрабатываемых строк таблицы RA будет оставаться более-менее постоянным. И все это благодаря тому, что из таблицы RA будут браться только строки от момента сохранения промежуточных итогов до момента, на который рассчитываются остатки.
На рисунке, приведенном ниже, я схематично изобразил зависимость скорости расчета остатков от диапазона дат, за который хранятся движения в таблице RA. Предполагается, что количество записей по регистру в среднем одинаковое каждый день.
Рассмотрев приведенные примеры, можно сделать вывод, что использование таблиц RG позволяет снизить зависимость скорости работы программы от размеров таблиц RA:
- Запись в таблицы RG промежуточных итогов сужает диапазон поиска строк в таблицах RA, тем самым уменьшая время выполнения запросов;
- Запись в таблицы RG остатков на ТА вообще исключает таблицы RA из запросов, которые определяют остатки на ТА.
Как периодичность сохранения остатков влияет на работу программы
Периодичность сохранения остатков - это интервал времени, через который в таблицах RG фиксируются итоги по ресурсам регистра. Эти итоги называются промежуточными. В программе 1С существует возможность задавать следующую периодичность сохранения остатков:
| Периодичность сохранения остатков | Числа месяца, на которые сохраняются промежуточные итоги |
| Месяц | 1 число каждого месяца |
| Пятнадцать дней | 1 и 16 числа каждого месяца |
| Декада | 1, 11 и 21 числа каждого месяца |
| Пять дней | 1, 6, 11, 16, 21 и 26 числа каждого месяца |
А теперь давайте вновь вернемся к запросу, определяющему остатки на 18.03.06, только сейчас сконцентрируемся на условии, ограничивающем выбор строк из таблицы RA:
В моей тестовой базе периодичность сохранения остатков 10 дней. Поэтому из таблицы RG берутся промежуточные итоги на 11.03.06 (в запросе указано 20060301, это связано с особенностями хранения данных в таблицах RG), а из таблицы RA - движения за период с 11.03.06 по 17.03.06.
Если бы была установлена периодичность сохранения остатков "Месяц", то из таблицы RG брались бы промежуточные итоги на 01.03.06, а из таблицы RA - движения за период с 01.03.06 по 17.03.06.
Чем шире диапазон дат, за который обрабатываются строки из таблицы RA, тем медленнее работает запрос (при условии, что количество движений по регистру в среднем одинаковое каждый день).
Предвижу Ваше желание установить периодичность, равную 5 дням. Не спешите этого делать! Скорость расчета остатков, несомненно, важный показатель, но, отнюдь, не единственный, который влияет на производительность системы в целом.
Вспомним, где чаще всего для нас критична скорость работы? Правильно, при проведении документов, особенно, при большом количестве пользователей. Отчеты, конечно, тоже важны, но при их выполнении не возникают транзакции и блокировки, парализующие работу предприятия. Поэтому будем рассматривать влияние периодичности сохранения остатков именно на проведение документов.
В общем случае проведение документа можно представить следующим образом:
- отмена проведения:
- удаление движений по регистрам, если документ был проведен;
- проведение:
- выполнение алгоритма из процедуры "ОбработкаПроведения". Здесь очень часто рассчитываются остатки по регистрам;
- запись движений в регистры.
Рассмотрим, как влияет удаление и запись движений на скорость работы программы. В первую очередь следует уяснить, что записи в таблице RG являются производными от записей в таблице RA. Это означает, что любое изменение в таблице RA влечет за собой изменения в таблице RG.
Для примера возьмем две крайних периодичности сохранения остатков - "Месяц" и "5 дней". Предположим, что ТА находится на 28.03.2006 00:00:00. Вы перепроводите документ от 10.02.06. Последствия перепроведения приведены ниже:
| Периодичность сохранения остатков | Последствия перепроведения док-та задним числом |
| Месяц | Внесение изменений в таблицу RA Пересчет промежуточных итогов на 01.03.06 Пересчет остатков на ТА |
| Пять дней | Внесение изменений в таблицу RA Пересчет промежуточных итогов на:
|
Примечание: каждое действие выполняется дважды: при удалении движений по регистру и при записи новых движений.
В результате перепроведение документа вызывает пересчет промежуточных итогов:
- для периодичности "Месяц" - 2 раза,
- для периодичности "5 дней" - 20 раз.
Пересчет промежуточных итогов, так же как и расчет остатков, требует определенных затрат времени. К тому же эта операция связана с изменением данных на жестких дисках, что само по себе не быстро. Поэтому может выйти так, что при периодичности "Месяц" документ будет проводится быстрее, чем при периодичности "5 дней". Все зависит от того, насколько "старый" документ проводится.
С другой стороны, если документ находится в переделах одного периода сохранения остатков от ТА, то чем меньше этот период, тем быстрее будет проводиться документ, так как в этом случае скорость проведения будет определяться скоростью расчета остатков.
Например, дата документа 28.03.06. При периодичности "Месяц" в таблице RA будут обрабатываться движения за период с 01.03.06 по 28.03.06, а при периодичности "5 дней" - движения за период с 26.03.06 по 28.03.06. Во втором случае запрос, вероятнее всего, выполнится быстрее.
Подведем итоги:
- Периодичность сохранения остатков "Месяц". Подходит:
- для небольших баз, т.к. скорость работы программы не сильно зависит от периодичности сохранения остатков;
- для баз, в которых часто перепроводятся очень старые документы;
- для баз, в которых документы проводятся на ТА.
Период открывается 1 раз в месяц, рост базы данных из-за таблиц RG незначительный.
- Периодичность сохранения остатков "5 дней". Подходит:
- для больших баз, в которых документы если и проводятся задним числом, то редко и в основном в пределах 5 дней от ТА.
Период открывается 6 раз в месяц, рост базы из-за таблиц RG может быть значительным.
Это особенно актуально для DBF-версии программы, т.к. там существует ограничение на размер файлов (каждый файл не более 2 Гб). Кроме этого на больших DBF-базах период открывается заметно дольше, чем на такой же базе, но в формате SQL.
Мы рассмотрели две крайних периодичности сохранения остатков. Теперь Вы знаете, что можно ожидать от смены этого параметра программы. В любом случае перед сменой периодичности стоит изучить, как построена работа с программой именно на вашем предприятии, протестировать предполагаемый период сохранения остатков на тестовой базе и лишь потом изменять его на рабочей.
Примечание: в статье отражено мое мнение по поводу периодичности сохранения остатков. Оно может не совпадать с Вашим мнением и / или мнением других специалистов.
Начать дискуссию