← На главную

В процессе работы с 1С на СУБД PostgreSQL, особенно после сбоев, таких как внезапное прерывание сеанса при обновлении конфигурации, можно столкнуться с критической ошибкой: Ошибка СУБД: error: invalid page in block NNN of relation base/NNNNN. Эта ошибка говорит о физическом повреждении данных в файлах базы на диске. Стандартные средства 1С, например, "Тестирование и исправление" (ТиИ), в таких случаях часто оказываются бессильны, так как они работают на логическом уровне, а проблема лежит глубже — на уровне самой СУБД.

Давайте разберем по шагам, как диагностировать и устранить эту проблему, начав с самых безопасных методов и переходя к более сложным.

Шаг 1. Точная диагностика: определяем поврежденный объект

Прежде чем что-то "лечить", нужно точно понять, что именно сломалось — таблица с данными или ее индекс. От этого зависит стратегия восстановления. Самый надежный инструмент для этого — технологический журнал (ТЖ) 1С. Для быстрого сопоставления физических таблиц СУБД с объектами метаданных 1С можно использовать отчет о структуре хранения базы данных.

1. Настроим технологический журнал. Нам нужно отследить события взаимодействия с СУБД. Для этого в файле конфигурации ТЖ (logcfg.xml) необходимо включить сбор событий DBPOSTGRS. В логах мы увидим полный текст SQL-запроса, который вызывает сбой.
2. Анализируем лог. В момент возникновения ошибки в логе ТЖ будет зафиксирован SQL-запрос к конкретной таблице PostgreSQL. Имя таблицы в 1С (например, "РегистрСведений.ЦеныНоменклатуры") и в PostgreSQL будет разным. В PostgreSQL оно будет выглядеть примерно как _inforg12345.
3. Ищем "улику". Внимательно посмотрим на имя таблицы из лога. Есть два варианта:
   • Имя вида _inforg20355: Это, скорее всего, сама таблица данных. Ситуация более сложная.
   • Имя вида _inforg20355_2: Наличие суффикса (_1, _2, и т.д.) с высокой вероятностью указывает на то, что поврежден индекс, а не сама таблица с данными. Это хорошая новость, так как исправить это гораздо проще.

После того как мы определили характер повреждения, можно выбирать метод восстановления.

Шаг 2. Методы восстановления базы данных

Рассмотрим несколько способов, от простого и безопасного к более сложному и рискованному.

Способ 1: "Перезаливка" базы через файловый вариант (наиболее безопасный)

Этот метод не требует глубоких знаний PostgreSQL и является самым надежным для специалиста 1С. Его суть в том, чтобы заставить платформу 1С логически прочитать все данные и заново создать физическую структуру базы.

Разберем по шагам:

1. Выгружаем информационную базу в файл .dt. Если этот процесс завершается успешно, без ошибок, — отлично, можно продолжать. Если выгрузка обрывается с ошибкой, этот метод не подходит, и нужно переходить к способам прямого восстановления СУБД.
2. Создаем на диске новую, абсолютно пустую файловую информационную базу.
3. Загружаем в эту пустую файловую базу наш .dt файл. После загрузки заходим в конфигуратор и в пользовательский режим, чтобы убедиться, что база работает корректно.
4. Из этой, уже работающей, файловой базы делаем новую выгрузку в .dt файл. Этот файл можно считать "очищенным" от физических ошибок структуры.
5. На сервере PostgreSQL полностью удаляем поврежденную базу данных. Внимание: убедитесь, что у вас есть резервная копия!
6. Создаем на сервере PostgreSQL новую пустую базу данных с теми же параметрами (имя, пользователь).
7. Загружаем в новую базу на PostgreSQL наш "очищенный" .dt файл из шага 4.

Почему это работает? При выгрузке в .dt платформа 1С читает данные логически, таблица за таблицей, не обращая внимания на физическую структуру хранения. При загрузке она создает все таблицы, индексы и связи с нуля, тем самым исправляя любые физические повреждения структуры.

Способ 2: Перестроение поврежденных индексов (если поврежден индекс)

Если на этапе диагностики мы выяснили, что проблема в индексе (например, в таблице _inforg20355_2), то самое правильное решение — перестроить его средствами PostgreSQL. Это быстро и не затрагивает сами данные.

Важно: перед выполнением команд необходимо завершить все активные сеансы работы с базой данных 1С, кроме вашего собственного подключения для администрирования. Для автоматизации завершения сеансов и резервного копирования можно применить обработку для администрирования ИБ и управления сеансами.

Подключитесь к базе данных с помощью утилиты psql или через графический интерфейс (например, pgAdmin) и выполните одну из команд:

• Для перестроения конкретного индекса: REINDEX INDEX имя_поврежденного_индекса;
• Для перестроения всех индексов одной таблицы: REINDEX TABLE имя_таблицы;
• Для полного перестроения всех индексов в базе (надежно, но долго): REINDEX DATABASE имя_базы_данных;

После выполнения команды индексы будут созданы заново на основе существующих данных, и ошибка должна исчезнуть.

Способ 3: Обнуление поврежденных страниц (рискованный метод)

Этот способ следует применять в крайнем случае, когда повреждена сама таблица данных, а выгрузка в .dt невозможна. Метод заключается в том, чтобы разрешить PostgreSQL проигнорировать ошибку чтения, заполнив поврежденный блок данных нулями.

ВНИМАНИЕ: ЭТОТ МЕТОД ПРИВОДИТ К НЕИЗБЕЖНОЙ ПОТЕРЕ ЧАСТИ ДАННЫХ! Все строки, которые находились в поврежденном блоке, будут утеряны навсегда.

Разберем по шагам:

1. Остановите сервер PostgreSQL.
2. Найдите и откройте для редактирования конфигурационный файл postgresql.conf.
3. Установите в нем параметр: zero_damaged_pages = on.
4. Сохраните файл и запустите сервер PostgreSQL.
5. Теперь, при первом обращении к поврежденному блоку, сервер не выдаст ошибку, а просто запишет в него нули. Чтобы инициировать это обращение, можно, например, попытаться выгрузить базу в .dt или выполнить SQL-запрос вида SELECT count(*) FROM имя_проблемной_таблицы;.
6. Сразу же после того, как доступ к данным получен, сделайте полную выгрузку базы (в .dt или через pg_dump).
7. Снова остановите сервер и обязательно верните параметр в исходное состояние: zero_damaged_pages = off. Оставлять его включенным опасно, так как это будет маскировать будущие проблемы.
8. Разверните базу из полученной выгрузки в новую, чистую базу данных.

Шаг 3. Профилактика: ищем первопричину и предотвращаем повторение

Восстановить базу — это полдела. Важно понять, почему произошел сбой, чтобы избежать его в будущем. Для контроля корректности учетных данных после восстановления и завершения технических работ может применяться автоматическая сверка бухгалтерских и налоговых проводок между базами 1С.

• Проверка оборудования. Ошибка "invalid page" часто является следствием аппаратных проблем. Проверьте состояние диска (SMART), особенно если это SSD. Проведите тест оперативной памяти (memtest). Убедитесь в стабильности электропитания (наличие ИБП).
• Настройки PostgreSQL. Для повышения надежности, особенно при работе под Windows, убедитесь, что в файле postgresql.conf установлены безопасные параметры:
  • fsync = on — гарантирует, что данные физически записываются на диск, а не остаются в кэше ОС. Снижает производительность, но значительно повышает надежность.
  • full_page_writes = on — защитный механизм от частичной записи страниц на диск при сбоях. Должен быть включен.
• Резервное копирование. Это главный и самый надежный способ защиты. Люди делятся на тех, кто еще не делает бэкапы, и тех, кто уже делает.
  • Делайте резервные копии регулярно. При обслуживании множества информационных баз этот процесс удобно автоматизировать с помощью программы для пакетного архивирования и тестирования баз 1С.
  • Делайте бэкап перед любыми значимыми действиями, даже перед обновлением одного общего модуля.
  • Периодически проверяйте, что ваши бэкапы восстанавливаются и работоспособны.
  • Используйте разные методы: и выгрузку в .dt средствами 1С, и нативные средства PostgreSQL (pg_dump).

Следуя этим рекомендациям, вы сможете не только восстановить работоспособность базы данных после серьезного сбоя, но и значительно снизить риски его повторения в будущем.