Что такое реиндексация таблиц в 1с
Тестирование и исправление базы 1С 8. Ставим флажки осознанно
В статье рассматривается системная утилита «Тестирование и исправление информационной базы» — в каких случаях может помочь, какие имеет настройки для чего нужны.
Содержание
Бывает так, что из-за программного или аппаратного сбоя, аварийного прерывания работы или еще по ряду причин, в базе 1С начинают накапливаться ошибки. До поры они могут быть незаметными, но со временем симптомы проявляются все отчетливее. Вот лишь некоторые из них:
на самом деле, проблем и ошибок много, и для разных баз они могут быть совершенно разными, вплоть до того, что 1С в принципе отказывается запускаться или вылетает. В большинстве случаев причина — физическое повреждение базы данных или рассогласование логической целостности (например, платформа должна была удалить данные из двух таблиц синхронно, но по какой-то причине удалила только из одной, и т.п.).
Все болит, ничего не помогает!
Если мы словили ошибку времени выполнения — отладчик в руки и вперед! А что делать, если причина ошибки не локализуется и от нас не зависит? Верно! Воспользоваться средствами диагностики! Вообще, средств диагностики и исправления ошибок, связанных именно с платформой и БД, не так много.
Тестирование и исправление ИБ средствами встроенной утилиты
Запускается данная утилита из конфигуратора, через меню Администрирование, в котором следует выбрать пункт «Тестирование и исправление». Откроется окно утилиты:
Какие же флажки следует ставить и для чего?
Первое и главное — сделать резервную копию базы. Так как если вы будете не просто запускать не просто тестирование, а еще и исправление выявленных ошибок, данная операция будет необратима, и если что-то пойдет не так, все может стать еще хуже 🙂
Реиндексация таблиц информационной базы
Данная галочка отвечает за перестроение индексов у таблиц базы данных. Вообще, индексы — это предмет отдельного обсуждения, и здесь я упомяну лишь, что часть индексов создается платформой, а другая часть — нашими умелыми ручками разработчиков 1С. Индексы нужны для ускорения поиска данных и повышения производительности 1С при работе с данными. И вот этот флажок «Реиндексация таблиц» отвечает за то, что утилита заново физически пересчитает все индексы, чтобы они не расходились с индексируемыми исходными таблицами. Также, полное перестроение индексов может привести к значительной оптимизации их работы и ускорению всей системы в целом.
Небольшое дополнение — этот флажок больше подходит для файловых баз, так как для клиент-серверных 1С рекомендует реиндексацию делать средствами самой СУБД (MS SQL Server, PostgreSQL и т.д.) Например, можно почитать тут: https://its.1c.ru/db/metod8dev#content:5837:hdoc:p4
Проверка логической целостности информационной базы
Ошибки, связанные с нарушением логической целостности, чаще всего возникают в результате некорректного обновления конфигурации, или в момент аварийного завершения работы при записи объекта. Это происходит потому, что редактирование объекта в базе означает редактирование записей в соответствующих таблицах СУБД. А при аварийном завершении в одних таблицах записи уже внесены, а в других — система не успела, что и приводит к логической рассинхронизации.
Тестирование и исправление с установленным флажком «Проверка логической целостности информационной базы» решает эти проблемы, восстанавливая логические связи между записями в таблицах.
Проверка ссылочной целостности информационной базы
Это подпункт проверки логической целостности, и отдельно его указать нельзя — если проставить его, то и предыдущий устанавливается автоматически.
Данный флажок отвечает за проверку и исправление т.н. «битых» ссылок на несуществующие объекты. Чаще всего «битые» ссылки появляются из-за некорректных действий разработчика. Неверно настроенные правила обмена или непосредственное удаление объектов могут приводить к появлению «битых» ссылок.
Пересчет итогов
Итоги — это отдельные таблицы в ИБ, которые хранят рассчитанные на основе движений итоги по регистрам бухгалтерии, накопления и периодических регистров сведений. Простейший пример — мы начали учет в январе; за январь у нас 100 движений приход и 100 движений расход. Когда мы хотим сформировать отчет, к примеру, по остаткам на 15 февраля, платформа получает уже рассчитанные итоги за январь, досчитывает по таблице движений остатки до 15 февраля, и возвращает эти остатки. Если бы итогов не было, нам бы каждый раз пришлось анализировать все движения с начала времен, что сильно замедлило бы работу.
Но в процессе работы, в таблицах итогов накапливаются нулевые значения, которые замедляют обработку данных для соответствующих регистров. Кроме того, в результате сбоев, выключения электричества и т.п., таблица итогов может не соответствовать движениям, которые эти итоги сформировали. Например, два движения в приход 10 шт, но в итогах не 20шт, как ожидается, а 10.
Для того, чтобы привести в соответствие итоги и движения, а также для оптимизации таблиц итогов, и используется утилита со включенным флажком «Пересчет итогов».
Сжатие таблиц информационной базы
Данный флажок доступен только для файлового варианта, так как при использовании сервера 1С, за управление физическими таблицами и выделение места на диске под них отвечает СУБД. При удалении данных из базы 1С, платформа для экономии ресурсов и времени не удаляет физически данные из СУБД. Они остаются в таблицах, но со специальной пометкой, чтобы платформа 1С их не использовала. В результате объем файла БД со временем увеличивается за счет этих скрытых объектов. Сжатие таблиц ИБ физически удаляет такие объекты.
Реструктуризация таблиц информационной базы
Если включена данная опция, то утилита для каждой таблицы в СУБД создаст копию с такой же структурой, и переместит данные из старой таблицы в новую. Аналогичная процедура реструктуризации происходит при изменении структуры конфигурации.
Пересоздание автономной конфигурации
Этот флажок предназначен для создания автономной конфигурации для мобильного клиента с автономным режимом. Эта возможность появилась в платформе начиная с версии 8.3.16. Если вкратце, часть критичного функционала, который должен быть доступен оффлайн, можно вынести в автономную конфигурацию, которая будет использоваться мобильным клиентом, если основной сервер не доступен. Подробнее можно почитать здесь:
https://wonderland.v8.1c.ru/blog/mobilnyy-klient-s-avtonomnym-rezhimom/
Нюансы
Следует учитывать, что тестирование и исправление ИБ — процедура длительная, необратимая, и монопольная. Отсюда рекомендации — делайте перед запуском резервную копию, убедитесь что предоставлен монопольный доступ — кроме конфигуратора не должно быть ни других сеансов, ни фоновых заданий. И планируйте запуск утилиты в нерабочее время. Соответственно, чем больше размер базы и больше отмечено флажков, тем длительнее будет работа утилиты.
На этом статья подходит к концу! Спасибо что дочитали, и удачи!
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Существуют вещи настолько привычные, что кажется все про них знают, но это весьма обманчивое впечатление. Да, о них почти все знают, почти все используют, но мало кто представляет происходящие при этом процессы, скрытые за привычной внешней формой инструмента. При этом те, кто знает не спешат делиться, ведь это «общеизвестно», а те, кто не знает стесняются спросить по той же самой причине. Но мы не будем стесняться, а подробно расскажем о том, что делает каждая опция данного инструмента, заглянув каждый раз немного глубже простого описания.
Описание этой таблички можно найти много где, но в большинстве случаем там будут стандартные абзацы вроде:
Проверка логической целостности информационной базы проверяет и исправляет логические ошибки в структурах таблиц
Поэтому давайте разбираться, мы специально упростили многие вопросы, постаравшись сделать их понятными даже тем, кто имеет смутное представление о структуре и принципах работы баз данных.
Реиндексация таблиц информационной базы
Допустим у нас есть некая таблица и мы хотим получить из нее все данные, связанные с фамилией Иванов. Для этого программе нужно последовательно считать все страницы, принадлежащие данной таблице и найти в них записи, соответствующие запросу.
По мере работы с программой эффективность индексов снижается, особенно если вы активно удаляли или добавляли данные. Также индексы могут подвергаться фрагментации. Если снова сравнить с библиотекой, то за день работы посетители перепутали несколько ящиков, а работники библиотеки карточки новых книг поставили в конец и забыли убрать отсутствующие. Но все равно поиск по такому каталогу окажется быстрее, чем обход всех стеллажей в зале. А что нужно сделать, чтобы вернуть поиску прежнюю эффективность? Правильно, навести порядок в каталоге. Именно этим и занимается реиндексация, которая заново формирует индексы таблиц базы данных и устраняет их фрагментацию, что важно, если вы используете обычные жесткие диски или недорогие SSD.
Проверка логической целостности информационной базы
Но на уровне информационной базы 1С существует совсем иной набор объектов: Справочники, Документы, Регистры сведений и накопления и т.д. и т.п. При этом они связаны определенной внутренней логикой. Так элементы справочника могут иметь иерархическую структуру, являться подчиненными для другого справочника, а документы быть основанием для других документов, формировать проводки, записи регистров и т.д. и т.п. В процессе работы данная логика может быть нарушена, как по причине ошибок в программе, так и в результате некоторых действий пользователя.
Давайте рассмотрим следующую схему, отражающую некоторый набор бизнес-логики. У нас есть два документа: Реализация и Оплата, которые делают движения по некоторым регистрам. Так при реализации мы списываем нужное количество товара со склада и вносим в регистр взаиморасчетов задолженность покупателя. В момент оплаты мы вносим полученную сумму в регистр денежных средств и закрываем задолженность покупателя по отгрузке полностью или частично. Но как мы определим, какую именно задолженность погасил клиент? А для этого мы введем в документе оплата обязательное поле Основание, в котором будем указывать нужную реализацию.
При этом документ Оплата будет являться подчиненным к документу Реализация и в случае его отмены также должен быть отменен, так как перестает существовать основание для оплаты. Теперь представим, что в результате какой-то нештатной ситуации или некорректных действий пользователя у нас в документе Оплата пропала ссылка на документ основание, т.е. нарушилась структура подчиненности. Найти такую ошибку будет не так-то просто. Потому что все записи в базе данных останутся, и каждая из них по отдельности будет верная. Так правильным останется количество товаров на складах и суммы денежных средств предприятия, а вот взаиморасчеты враз станут неверны.
Внешне это может проявляться так: отчеты по реализациям и оплатам от контрагента совпадают, а вот отчет по взаиморасчетам или акт сверки формируется неправильно. При этом вы можете раз за разом пересчитывать суммы руками, все будет сходиться, но отчет снова и снова будет давать неверный результат.
Поэтому во всех подобных случаях, когда отчеты показывают неверные результаты или не сходятся друг с другом, следует запускать проверку логической целостности. Но не следует ожидать от нее какого-либо чуда, потому что она способна исправить только некоторые, самые очевидные ошибки (проводка без регистратора, неверный родитель элемента справочника и т.д.), в остальных случаях потребуется анализ ситуации и ручное исправление обнаруженных проблем. При этом нарушение логической целостности очень часто бывает связано с нарушением ссылочной целостности, о которой мы поговорим ниже.
Проверка ссылочной целостности информационной базы
Контроль ссылочной целостности является подмножеством контроля логической целостности и осуществляется на уровне конфигурации. С ним сталкивался каждый, кто пытался удалить какой-либо объект их базы, а в ответ получал сообщение, что это невозможно, так как данный объект используется и приводился список мест использования.
Но что будет, если используемый объект все-таки удалить? Возникнет битая ссылка. Внешне она выглядит как запись со ссылкой на уникальный идентификатор отсутствующего объекта:
Если подходить с чисто теоретических позиций, то битых ссылок в информационной базе быть не должно. Но не все так просто, если в базе используется РИБ, либо иные технологии обмена с другими базами и внешними источниками, то ряд второстепенных реквизитов может не передаваться. Например, сведения о подключаемом оборудовании.
В данном случае это нормально (Конфигурация Розница 2.3), так как конкретный экземпляр оборудования подключен именно к конкретному рабочему месту и передавать эти данные куда-то еще лишено особого смысла.
А вот после, установив сам факт их наличия следует думать. В ряде случаев, если выявленные ссылки являются второстепенными объектами подчиненных баз не нужно делать ничего. Наоборот, любая попытка «исправления» может привести к нарушению нормальной работы информационной базы. А вот в других надо предпринимать какие-либо действия.
Давайте посмотрим какие варианты у нас есть. Начнём со ссылок на несуществующие объекты. Здесь все довольно просто, мы можем или очистить ссылку, или создать новый объект нужного типа. Допустим, если запись справочника Номенклатура оказалась повреждена, но мы точно знаем по бумажным документам, что именно реализовывали, то ставим Создавать объекты, после чего переходим к ним и заполняем нужные реквизиты. Если же это какой-то второстепенный реквизит, то можем просто очистить ссылки. Второй вариант довольно часто применяется в тех случаях, когда надо быстро почистить базу и ряд объектов удаляется без контроля ссылочной целостности.
Теперь о частичной потере данных объектов. К ним могут относиться элемент подчиненного справочника без владельца или движение без регистратора. Мы можем либо удалить такие объекты, либо создать связанные с ними. Чаще всего такие объекты имеет смысл удалять, особенно если это движения, хотя если это элемент справочника, владелец которого потерян, то в ряде случаев имеет смысл создать владельца.
Внимание! Перед любыми исправлениями ссылочной целостности в базе обязательно создайте резервную копию. Помните, что данная операция необратима и может привести к полной или частичной потере данных!
Когда следует запускать эту проверку? В тех случаях, когда в базе не обнаружены битые ссылки или когда проверка логической целостности выявляет ошибки. Но в любом случае первый запуск следует производить с действиями Не изменять, а последующие решения принимать на основании глубокого анализа ситуации.
Пересчет итогов
Немного сложнее с регистрами накопления, записи в них содержат только сведения о движениях, скажем, такого-то числа в такое-то время на склад пришло 10 позиций некоторой номенклатуры, затем тем же днем продали 1 шт, потом 3 шт, за ней снова 5 шт и после еще 1 шт. При этом ряд вопросов, которые могут нас интересовать гораздо шире. Нас могут интересовать остатки на произвольный момент времени, либо обороты за некоторый период.
Чтобы не делать глубоких выборок по регистрам накоплений в них предусмотрены виртуальные таблицы Остатки, Обороты, Остатки и обороты. Каждая из них содержит актуальные данные за определенный период, в нашем случае день. И если таблица остатков в особом пояснении не нуждается, то таблица оборотов на нашей схеме может вызвать вопросы, так как ее содержимое полностью совпадает со значениями регистра. На самом деле редко когда регистр содержит единственную запись за день, чаще всего там множество записей движения: утром привезли на склад товар, потом его активно продавали, затем довезли еще немного и продолжили торговлю. При этом таблица обороты отобразит общий оборот за период.
Собственно, как и индексы, итоги предназначены для ускорения получения данных из информационной базы, теперь вам не нужно считывать весь или почти весь регистр, чтобы получить данные на определенный момент времени, достаточно обратиться к одной из виртуальных таблиц. Но со временем итоги тоже начинают терять эффективность: в них могут накапливаться мусорные записи, они могут фрагментироваться. Пересчет итогов решает эту проблему, заново создавая нужные виртуальные таблицы.
Пересчет итогов, как и реиндексация, простой и эффективный способ поддержания производительности информационной базы. Следует выполнять его регулярно в рамках обслуживания, а также каждый раз после исправления ошибок логической или ссылочной целостности.
Сжатие таблиц информационной базы
По мере работы информационной базы объем добавляемых в нее данных растет, вместе с ним растет и объем файла (файлов) базы данных. Но если мы удалим из базы часть информации, то объем файла базы данных не уменьшится, просто некоторые страницы будут помечены как пустые и снова доступные для записи. Если мы хотим уменьшить физически занимаемый объем, то следует произвести операцию сжатия таблиц информационной базы. В этом случае база переместит текущие данные на место освободившихся страниц, а затем уменьшит файл базы данных на объем освободившегося пространства.
Когда следует выполнять данное действие? Только если вы удалили из базы значительный объем данных, ну или если размер файла базы для вас критичен.
Реструктуризация таблиц информационной базы
Если реиндексация только перестраивала индексы, то реструктуризация полностью перестраивает содержимое базы данных, для каждой таблицы создается копия и записывается в отдельное место на диске, затем вся база данных полностью замещается копией. В чем смысл этого действия? Фактически мы произвели дефрагментацию базы данных, если ранее данные таблицы могли быть разбросаны по диску, то теперь они будут расположены последовательно.
И как раз-таки после реструктуризации будет уместно выполнить сжатие. Так как данные перемещать уже не надо, а пустое пространство уже сосредоточено в одном месте.
Как часто следует запускать? По необходимости, в том случае если вы изменили набор метаданных.
Пересоздание автономной конфигурации
Достаточно специфическая функция и относится к мобильному клиенту с возможностью автономной работы. Потеряв связь с основной базой данных такой клиент переключается в автономный режим и начинает использовать автономную конфигурацию. Если в данном режиме автономный клиент ведет себя неадекватно, то автономную конфигурацию следует пересоздать.
Проверка логической целостности расширений конфигурации
Данная проверка аналогична проверке логической целостности, только с учетом подключенных расширений, которых может быть и не одно. Если вы используете расширения, то обязательно включайте данную проверку вместе с проверкой логической целостности.
Заключение
По умолчанию фирма 1С предлагает достаточно сбалансированный набор действий: реиндексация и пересчет итогов благотворно влияют на производительность, а проверка логической целостности позволяет на ранних этапах выявить возможные проблемы. Если вы используете расширения, то добавьте туда проверку логической целостности расширений.
Остальные проверки и действия следует выполнять только при наличии необходимости. Так обнаружив ошибки в логической целостности следует выполнить проверку ссылочной целостности, а существенно изменив структуру базы данных имеет смысл выполнить реструктуризацию.
Надеемся, что данный материал окажется вам полезен, а также поможет по-новому взглянуть и глубже понять привычные действия.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Заметки из Зазеркалья
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Мы разработали новый механизм реструктуризации базы данных, который позволяет ускорить обновление конфигурации в среднем в 3-4 раза, а в отдельных случаях на порядки. Ускорение достигается за счёт минимизации манипуляций над данными и максимального их переноса на уровень системы управления базой данных (СУБД).
Что такое реструктуризация?
Реструктуризация это изменение структуры и состава таблиц базы данных, и перенос имеющихся данных в изменённые таблицы. Обычно реструктуризация выполняется в тот момент, когда вы нажимаете Обновить конфигурацию базы данных в Конфигураторе. Но выполняется она не каждый раз.
Реструктуризация выполняется тогда, когда изменения конфигурации требуют появления новых колонок или таблиц в базе, или когда меняется тип существующей колонки. Например, вы добавили реквизит к справочнику, добавили документ, или изменили тип имеющегося реквизита с Число на Строка. В этих случаях потребуется реструктуризация.
Если рассматривать реструктуризацию с точки зрения манипулирования данными, то существует база данных и схема данных, которая соответствует конфигурации базы данных. После того, как вы обновляете конфигурацию базы данных, создаются новые структуры данных, в которые переносятся старые данные.
«Традиционная» реструктуризация
В процессе реструктуризации последовательно анализируются все объекты конфигурации. Не углубляясь в подробности можно сказать, что для каждого объекта выполняется:
Из этих трёх шагов перенос данных занимает наибольшее количество времени. При этом сами операции переноса данных могут быть простыми и сложными.
Например, к простым и быстрым операциям относятся те, которые вызваны добавлением или удалением столбцов таблицы. В этом случае отдельным запросом создаётся новая таблица (с изменённой структурой) и данные переносятся в неё.
Все остальные операции являются сложными, могут занимать длительное время, и для их выполнения требуется участие Конфигуратора (или серверной части платформы, если обновление выполняется на сервере). Потому что процесс переноса данных может сопровождаться различными вспомогательными действиями, обусловленными спецификой 1С:Предприятия.
Например, может потребоваться удаление ссылок на несуществующие объекты, изменение предопределённых данных, предварительная фильтрация данных (для удаления движений, соответствующих удаляемым регистраторам), проверка уникальности номеров и кодов, проверка количества уровней вложенности справочника и корректности его иерархии, и другие.
Новый механизм реструктуризации
Главное изменение заключается в том, что оптимизация реструктуризации достигнута не за счёт локальных изменений «традиционного» механизма, а за счёт создания полностью нового механизма реструктуризации.
Это непростая и трудоёмкая задача, потому что механизм реструктуризации должен обеспечивать транзакционность изменений, то есть надежность и целостность базы данных во всех случаях. Механизм должен быть готов к тому, что процесс реструктуризации может прерваться в любой момент (в результате сбоя, например), и при этом система должна остаться в консистентном состоянии. То есть либо в виде старой версии, либо в виде новой версии. Старый механизм для этого создавал новые версии изменённых таблиц, и заполнял их. А потом подменял все старые версии на новые.
Новый механизм тоже обеспечивает транзакционность, но более сложным способом.
Кроме этого новый механизм основан на ряде идей, которые позволили получить значительное ускорение:
На основе этих идей мы достигли максимальной оптимизации на тех изменениях конфигурации, которые приводят к следующим операциям с данными:
В других операциях перенос данных требуется как и раньше, но практически всегда (в большей части операций) он осуществляется на уровне СУБД. Данные переносятся единым запросом. Это может быть INSERT для новых таблиц, или UPDATE существующих таблиц.
Конечно, существуют такие изменения, которые всё равно проходят обработку на сервере с выгрузкой данных построчно. Например, преобразование строки в число, или в дату. Такие операции нецелесообразно делать на уровне СУБД, к тому же они довольно редко встречаются. Но наиболее частые изменения проводятся всё же на уровне СУБД, одним запросом на одну таблицу.
В среднем ускорение достигает 4 раз. Это, конечно, зависит от конкретной конфигурации, от конкретных изменений, и даже конкретных данных. В отдельных случаях ускорение может быть до 20 раз. Такое возможно, например, при удалении реквизита в большой таблице, или если изменения затрагивают маленькие таблицы, но сам объект при этом является довольно большим.
Помимо ускорения есть и другой положительный момент. Во многих случаях не перестраиваются индексы. Это позволяет сохранить их актуальность, сохранить статистику, сократить место, требуемое для реструктуризации.
Мы провели несколько сравнительных экспериментов на реальных информационных базах, и получили следующие результаты:
Особенности текущей реализации
Новый механизм реструктуризации мы планируем включить в версию 8.3.11 в статусе бета. Он реализован только на сервере, причём на сервере должна быть установлена Java 8.
Чтобы использовать новый механизм реструктуризации, вы можете запустить Конфигуратор в пакетном режиме. Кроме этого в файле conf.cfg вы также можете указать необходимость использования нового механизма. Тогда новая реструктуризация будет выполняться при нажатии Конфигурация – Конфигурация базы данных – Обновить конфигурацию базы данных на сервере. Если никаких специальных действий не предпринимать (просто установить новую платформу), то стандартно будет использоваться старый механизм.
Пока поддерживаются только две СУБД: MS SQL Server и PostgreSQL.
На текущий момент мы оптимизировали реструктуризацию не всех объектов конфигурации, а только основных:
Для перечисленных объектов (кроме регистров) оптимизированы любые их изменения. Для регистров мы оптимизировали реструктуризацию движений и реструктуризацию таблиц регистрации изменений. Операции пересчёта итогов и пересчёта срезов для регистра сведений мы пока не оптимизировали. Однако, несмотря на это, использование нового механизма уже даёт существенное ускорение всего обновления регистров в целом.
Мы рассматриваем возможность увеличения охвата операций и расширения состава объектов конфигурации, реструктуризация которых оптимизирована в новом механизме.