1c ошибка субд relation does not exist
Вы обновляете конфигурацию в базе данных или пытаетесь выгрузить ее в файл и «неожиданно» получаете «Ошибка СУБД: ERROR: relation…does not exist».
Откуда ноги
Причина данной ошибки в том, что таблицы, либо их отдельные поля, описанные в конфигурации 1с, не соответствуют таблицам в базе данных SQL. Например в новой, обновленной конфигурации 1с существует регистр, а среди таблиц SQL его нет.
Что делать?
Нужно привести таблицы(поля) SQL в соответствие с описанием конфигурации.
Т.е. все таблицы(поля), описанные в конфигурации, должны присутствовать в SQL.
. Внимание Если у вас появляется ошибка «schemastorage does not exist» попробуйте сначала провести ТИИ (тестирование и исправление информационной базы), а именно только «реструктуризация БД«. В большинстве случаев она помогает, возможно поможет и при отсутствии других таблиц.
Лечение
Необходимо, воспользовавшись утилитами, сравнить таблицы SQL с 1с. Описание ошибки сразу выводит на ту таблицу, которую нужно искать.
В приложенном файле показаны примеры исправления.
Размышления
1.Поиск в интернете показал, что наиболее страдают этой ошибкой базы, размещенные на Postgre.
Есть мнение, что одним из поводов для появления ошибки, является динамическое обновление конфигурации.
3. Данная ошибка не возникает, если в новой конфигурации, относительно старой, не изменяли реквизиты, таблицы. Т.е. при изменении только программного кода, форм конфигурации, такая ошибка не должна проявляться, т.к. не изменяется структура таблиц SQL.
На дорожку
При исправлении ошибки, сами работы с таблицами SQL, хотя и не являются сложными, но все же требуют определенной подготовки.
Поэтому — пару рекомендаций, чтобы не пришлось решать описанную проблему:
— Не хочу обижать Postgre, но если база данных небольшая, может использовать MSSQL? Бесплатная версия Express позволяет обслуживать базу размером до 10Гб.
— По возможности избегайте делать динамическое обновление. Хотя фирма 1с периодически сообщает, что ей удалось «победить» эту проблему, но «Пуганая ворона…».
Ну и конечно, прежде чем начать работать с базой данных «по живому», сделайте ее бэкап.
Предыстория такая: Позвонил бухгалтер, говорит, не могу поменять ФИО у ФизЛица. 1С пишет, мол "Критическая ошибка словаря. " дальше не помню.
Полез разбираться, и правда ошибка.
В Конфигураторе попытался сделать копию базы. 1С упала с ошибкой "ошибка субд error: relation does not exist"
Сделал копию средствами PostgreSQL, запустил Тестирование и исправление
Оно тоже на середине упала с такой же ошибкой, конфигуратор закрылся
При попытки открыть конфигуратор ошибка:
"При обновлении данных после последней реструктуризации произошла критическая ошибка".
Чуть погуглив, понял, что упала таблица с самой конфигурацией
Средствами SQL скопировал таблицу конфы и с точно такого же релиза, в упавшую базу, а именно:
copy config to 'D:/config_OK.txt' - из рабочей копии с таким же релизом
delete from config - в упавшей базе
copy config from 'D:/config_OK.txt' - в упавшей базе
В конфигуратор затем пустило, но при попытке открытия в Предприятий ошибка:
"Пользователь ИБ не идентифицирован"
Помогло вот это: (из просторов инета)
UPD ATE SchemaStorage SE T Status = 100
И в саму базу в итоге не заходит, ТИИ не делает, копию не делает.
Полез сравнить таблицы в SQL, а их кол-во в упавшей базе, СИЛЬНО МЕНЬШЕ, чем в рабочей копии.
см. скрины
Предложения восстановить из копии не реальны, т.к. ей более 2х месяцев. (((((
Базе конец, или есть какой-ньть скрипт, который может скопировать все таблицы из "копии" в "рабочую упавшую".
Руками не реально, более 5000 таблиц куда-то делось. Надежда на то, что данные в этих таблицах это не документы и справочники. Бух плачут.
(9)
вам нужно смотреть журнал раньше, а не после аварии
еще есть и журнал операционной системы и самой 1с
(9) что говорит pg_log на момент ТИИ пока не самое главное. главное что говорит pg_log на момент "Критическая ошибка словаря. " дальше не помню."
что говорит pg_log на момент ТИИ пока не самое главное. главное что говорит pg_log на момент "Критическая ошибка словаря. " дальше не помню."
Да ничего толкового, Весь день вот этим сыпет, и больше ничего:
< 2021-09-20 07:08:01.511 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.511 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.514 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.515 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.516 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.516 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:08:01.516 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:31:15.542 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
< 2021-09-20 07:31:15.543 MSK >LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
(36)"В конфигуратор затем пустило, но при попытке открытия в Предприятий ошибка:
"Пользователь ИБ не идентифицирован"" - в конфигураторе открыть конфигурацию , снять конфигурацию с поддержки сохранить ( не обновляя ИБ ) , и загрузить эту же конфигурацию из файла ( заменив существующую) , Сохранить и обновить ИБ. Проверить
P/S Все действия производить на копии!
(38) Это всё проделано конечно же, не помогло.
Я всё, что знал, с чем сталкивался ранее проделал, но в итоге решил написать сюда, вдруг кто что дельного предложит.
(38) Вы гляньте скриншоты. меня очень пугает разница в количестве таблиц в живой старой копии, но уже обновленной до релиза погибшей БД и кол-во таблиц в погибшей БД
В копии 7328 таблиц
В упавшей 2312 таблиц.
5000 таблиц разница, думаю это конец)
то что вы проделали подменив таблицу Config не есть "обновление" , нужно было смотреть таблицы ДО этих действий!
(8) Знаю, но я не написал выше, что изначально выгрузил базу средствами SQL, но в чистую беэкап загружаться тоже не хочет, ругается на индексы какие-то.
Спокойно начал искать причину, еще раз восстановил из копии
Ругается на то, что восстанавливается INDEX, а такой таблицы в базе нет
Константы и перечисления у вас там походу померли. Может что-то (кто-то) грохнул "пустые" таблицы? Оптимайз какой-нить.
Да, предварительно сохранил бы кластер куда-нить.
Вспоминается: админы делятся на тех, кто делает бэкап, и тех, кто его уже делает.
(2)
Предложения восстановить из копии не реальны, т.к. ей более 2х месяцев. (((((
не думаю, что там есть админ
--- Чуть погуглив, понял.
(2) Это всё ясно, но 5000 таблиц. Руками не реально сделать.
Как вариант подумываю о скрипте, который по сравнил бы все таблицы рухнувшей базы с древним бэкапом и создал не достающие, скопировав их из живой базы.
Но я совсем не спец в написании под SQL.
Если есть кто возьмётся написать такой скрипт, то заплачу за него)
а у кого права доступа уровня
а у кого права доступа уровня
У пользователей нет.
Админы там бузрукие. на вопрос почему нет копий. "А нам такую задачу не ставили". вот как-то так.
Былого у меня осталась копия базы с крайнего обновления.
это что за чудо файл ?
(4) Просто файл, в который предварительно выгружена таблица 'config' из живой базы, а затем из него загружена в таблицу 'config' упавшей базы.
(14)
смотрите журналы операционной системы на критические ошибки
недельной давности . если были ахтунги о железе - "админов" на коврик
На этом же сервере еще 8 баз, все в норме, одна только упала жестко
Журнал ОС - всё ок
Журнал 1С. сейчас расковыряю.
Обновляли конечно, но "бэкапную" базу тоже обновил до того же релиза, так что структура баз в SQL должна быть одинаковая.
до звонка от Бухов о проблемах - не было шаловливых ручек ?
или ни у кого кроме вас нет права обновить конфигурацию ?
Диск с базой мог начать сыпаться потихоньку. Посмотреть на наличие ошибок, smartmontools или утилитой к диску.
Желательно сделать новый кластер PostgreSQL(initdb) на заведомо исправном диске, там загрузить в новую, пустую базу "копию средствами PostgreSQL" и потом проводить эксперименты.
Диск с базой мог начать сыпаться потихоньку. Посмотреть на наличие ошибок, smartmontools или утилитой к диску.
Желательно сделать новый кластер PostgreSQL(initdb) на заведомо исправном диске, там загрузить в новую, пустую базу "копию средствами PostgreSQL" и потом проводить эксперименты.
С железом всё ОК
Нет, кроме меня никого по этим базам
(25) Это я сам хз как произошло. Возможно был отключен ранее. база передана в 2020г.
Да и журнал 1С думаю ничего бы нам не сказал, он же не пишет логи как SQL. а база окончательно упала после ТИИ.
(28) Нет, там ничего такого и нет.
Ксати! А средствами 1С можно как-то напрямую с таблица SQL работать? На 1С я быстрее напишу, чем на SQL)
В общем чую, что есть два варианта:
1. Поставить Бухов перед фактом, что вот база, но в ней нет 2.5 месяцев.
2. Скрипт средствами SQL, который перетащит не достающие таблицы из копии в рабочую базу. Скрипт пока не ясно как такой написать. Как руками перетаскивать таблицы - это без проблем, но их там адское количество. НО В ЭТО РЕШЕНИЕ, ЧТО ОНО ВОССТАНОВИТ БАЗУ Я ВЕРЮ НЕ БОЛЕЕ ЧЕМ НА 10%
вопрос , как понять причину аварии.
тем более , что другие базы работают
смотрите журналы операционной системы и все логи слона
7-14 дней " тому назад "
может что найдете - причину аварии на базе
ну и еще шанс
когда было :
В конфигуратор затем пустило, но при попытке открытия в Предприятий ошибка:
"Пользователь ИБ не идентифицирован"
да, я про это знал ранее, но это не помогло
Помог сброс конкретной переменной средствами SQL:
А полные логи оказывается отключены, кусок postgresql.conf:
Чую они отключены админом кто Postgree ставил, т.к. на старом сервере была нехватка места, отключали некоторые логи на самом деле. Но вот видимо конфиг со старого сервера на новый перетащили(
В общем для себя нашёл вот такое вот решение, которое из упавшей базы перекидывает таблицы в копию базы, с надеждой, что в перенесенных таблицах будут "свежие данные".
Написал обработку, в которой указываются параметры "упавшей" базы и параметры "старой копии" (всё указывается в коде).
Обработка перебирает все таблицы из "упавшей" БД, выгружается их в csv (можно в txt) файла, имя файла=имя_таблицы.
Затем загружает выгруженные таблицы в рабочую копию базы, заменяя одноименные таблицы.
Вот такая вот простая логика.
Обработка во вложении.
Код вот (писалось на очень скорую руку, было не до красоты коды, но всё в целом там понятно):
НО! Мне в итоге это не помогло , видимо оставшиеся таблицы тоже были порушены. База в итоге перестала открываться, просто повисает и всё. ТИИ не делает, тоже повисает. Реидексацию средствами PopstgreSQL не делает, ждал 2 часа.
Появилась обратная идея, т.е. выгрузить все таблицы из рабочей копии и загрузить в упавшую базу, то те, которых в ней не достаёт.
Но тут я столкнулся с тем, что не нашел рабочий способ как из папки с кучей файлов с "файлами-таблицами" создать таблицы в базе где их нет.
Выгрузку недостающих таблиц в файлы написал.
На загрузку нагуглил утилиту, которая якобы по указанному ей файлу создает таблицу в базе со структурой из указанного файла, но мне так и не удалось заставить её работать.
Написал скрипт *.bat, который перебирает все файлы в паке с таблицами и подсовывает утилитке, она всё отрабатывает, даже иногда задумывается на больших файлах, но таблицы не появляются в итоге в базе.
Утилита называется pgfutter
Причина данной ошибки в том, что таблицы, либо их отдельные поля, описанные в конфигурации 1с, не соответствуют таблицам в базе данных SQL. Например в новой, обновленной конфигурации 1с существует регистр, а среди таблиц SQL его нет.
Что делать?
Нужно привести таблицы(поля) SQL в соответствие с описанием конфигурации.
Т.е. все таблицы(поля), описанные в конфигурации, должны присутствовать в SQL.
Лечение
Необходимо, воспользовавшись утилитами, сравнить таблицы SQL с 1с. Описание ошибки сразу выводит на ту таблицу, которую нужно искать.
В приложенном файле показаны примеры исправления.
Размышления
1.Поиск в интернете показал, что наиболее страдают этой ошибкой базы, размещенные на Postgre.
Есть мнение, что одним из поводов для появления ошибки, является динамическое обновление конфигурации.
3. Данная ошибка не возникает, если в новой конфигурации, относительно старой, не изменяли реквизиты, таблицы. Т.е. при изменении только программного кода, форм конфигурации, такая ошибка не должна проявляться, т.к. не изменяется структура таблиц SQL.
На дорожку
При исправлении ошибки, сами работы с таблицами SQL, хотя и не являются сложными, но все же требуют определенной подготовки.
Поэтому — пару рекомендаций, чтобы не пришлось решать описанную проблему:
— Не хочу обижать Postgre, но если база данных небольшая, может использовать MSSQL? Бесплатная версия Express позволяет обслуживать базу размером до 10Гб.
— По возможности избегайте делать динамическое обновление. Хотя фирма 1с периодически сообщает, что ей удалось «победить» эту проблему, но «Пуганая ворона…».
Ну и конечно, прежде чем начать работать с базой данных «по живому», сделайте ее бэкап.
Для анализа конфигурации использовалась обработка Структура хранения таблиц базы данных
Причина данной ошибки в том, что таблицы, либо их отдельные поля, описанные в конфигурации 1с, не соответствуют таблицам в базе данных SQL. Например в новой, обновленной конфигурации 1с существует регистр, а среди таблиц SQL его нет.
Что делать?
Нужно привести таблицы(поля) SQL в соответствие с описанием конфигурации.
Т.е. все таблицы(поля), описанные в конфигурации, должны присутствовать в SQL.
Лечение
Необходимо, воспользовавшись утилитами, сравнить таблицы SQL с 1с. Описание ошибки сразу выводит на ту таблицу, которую нужно искать.
В приложенном файле показаны примеры исправления.
Размышления
1.Поиск в интернете показал, что наиболее страдают этой ошибкой базы, размещенные на Postgre.
Есть мнение, что одним из поводов для появления ошибки, является динамическое обновление конфигурации.
3. Данная ошибка не возникает, если в новой конфигурации, относительно старой, не изменяли реквизиты, таблицы. Т.е. при изменении только программного кода, форм конфигурации, такая ошибка не должна проявляться, т.к. не изменяется структура таблиц SQL.
На дорожку
При исправлении ошибки, сами работы с таблицами SQL, хотя и не являются сложными, но все же требуют определенной подготовки.
Поэтому - пару рекомендаций, чтобы не пришлось решать описанную проблему:
- Не хочу обижать Postgre, но если база данных небольшая, может использовать MSSQL? Бесплатная версия Express позволяет обслуживать базу размером до 10Гб.
- По возможности избегайте делать динамическое обновление. Хотя фирма 1с периодически сообщает, что ей удалось «победить» эту проблему, но «Пуганая ворона…».
Ну и конечно, прежде чем начать работать с базой данных «по живому», сделайте ее бэкап.
Для анализа конфигурации использовалась обработка Структура хранения таблиц базы данных
Причина данной ошибки в том, что таблицы, либо их отдельные поля, описанные в конфигурации 1с, не соответствуют таблицам в базе данных SQL. Например в новой, обновленной конфигурации 1с существует регистр, а среди таблиц SQL его нет.
Что делать?
Нужно привести таблицы(поля) SQL в соответствие с описанием конфигурации.
Т.е. все таблицы(поля), описанные в конфигурации, должны присутствовать в SQL.
Лечение
Необходимо, воспользовавшись утилитами, сравнить таблицы SQL с 1с. Описание ошибки сразу выводит на ту таблицу, которую нужно искать.
В приложенном файле показаны примеры исправления.
Размышления
1.Поиск в интернете показал, что наиболее страдают этой ошибкой базы, размещенные на Postgre.
Есть мнение, что одним из поводов для появления ошибки, является динамическое обновление конфигурации.
3. Данная ошибка не возникает, если в новой конфигурации, относительно старой, не изменяли реквизиты, таблицы. Т.е. при изменении только программного кода, форм конфигурации, такая ошибка не должна проявляться, т.к. не изменяется структура таблиц SQL.
На дорожку
При исправлении ошибки, сами работы с таблицами SQL, хотя и не являются сложными, но все же требуют определенной подготовки.
Поэтому - пару рекомендаций, чтобы не пришлось решать описанную проблему:
- Не хочу обижать Postgre, но если база данных небольшая, может использовать MSSQL? Бесплатная версия Express позволяет обслуживать базу размером до 10Гб.
- По возможности избегайте делать динамическое обновление. Хотя фирма 1с периодически сообщает, что ей удалось «победить» эту проблему, но «Пуганая ворона…».
Ну и конечно, прежде чем начать работать с базой данных «по живому», сделайте ее бэкап.
Для анализа конфигурации использовалась обработка Структура хранения таблиц базы данных
Читайте также: