Ошибка при выполнении запроса post к ресурсу e1cib misc

Добрый день.

В базу были перенесены данные. Потом часть документов «Перенос данных» была помечена на удаление и удалена (документы с периодом Январь 2016).

При этом при непосредственном удалении документов не были удалены 3 документа (удаление в ERP выполняется в фоновом задании и происходили зависания фоновых заданий).

Сейчас при попытке снять пометку удаления с этих документов, либо попытке очистить их табличные части и записать документ программа зависает после чего (период времени от 30 мин до 1,5 дней) появляется сообщение об ошибке

«Ошибка при выполнении запроса POST к ресурсу /e1cib/misc:»

Сервер 1С и SQL неоднократно перегружались.

При тестировании и исправлении базы средствами 1С (из конфигуратора) на каком то этапе возникла ошибка доступа к базе)

Такое чувство, что документы каким-то образом заблокированы.

Есть какие-нибудь идеи как побороть?

Информация для технической поддержки:

Платформа: 1С:Предприятие 8.3 (8.3.7.1917)

Конфигурация: 1С:ERP Управление предприятием 2 (2.1.3.100) (http://v8.1c.ru/erp/)

Copyright © ООО «1C», 2004-2016. Все права защищены

(http://www.1c.ru)

Режим: Серверный (сжатие: усиленное)

Приложение: Толстый клиент

Локализация: Информационная база: русский (Россия), Сеанс: русский (Россия)

Вариант интерфейса: Такси

Ошибки:

———————————————————————————

25.03.2016 4:42:54

Ошибка выполнения запроса

Ошибка при выполнении запроса POST к ресурсу /e1cib/misc:

Содержание:

1.       Почему появляется эта ошибка 1с 8?

2.       Исправление ошибку POST  

1.    Почему появляется эта ошибка 1с 8?

В процессе работы с 1С порой появляется сообщение «Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm». Данное сообщение достаточно нередко связано с кодом 1С 8.3 в новых релизах 1С.

Рассмотрим, в чем же заключается «неправильность» выполнения запроса POST к ресурсу 1С, каковы первопричины ее образования и как с ней бороться.

В тексте сообщения обычно содержится растолкование источника появления проблемы – это ошибка 1С 8 либо на сервере, либо СУБД, либо какая-то другая.

«Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm» появляется неожиданно и чаще всего не обладает какой-либо логичностью.  

2.    Исправление ошибку POST

Чтобы исправить ошибку POST к ресурсу /e1cib/logForm можно попробовать сделать следующее:

· Провести типовое Тестирование и Исправлении базы 1С 8 (в конфигураторе в пункте меню «Администрирование» выберите Тестирование и исправление). Предварительно обязательно подготовьте архивную копию базы 1С 8!

· Установить последние актуальные обновления к базе 1С 8.

· Откатить программу 1С до предыдущей версии/релиза (восстановить копию базы 1С, сделанную до выполнения обновления).

· Работая с Windows, можно очистить сеансовые данные. Для этого потребуется остановить службу сервера базы 1С, после чего в папке C:Program Files1cv8srvinforeg_1541snccntx + *уникальный идентификатор* удалить все за исключением файлов, которые имеют расширение *.1, а затем обратно запустить «Сервер 1С».

· Перезапустить сам сервер 1С Предприятие.

· Обратиться на линию консультаций в официальную поддержку фирмы «1С». Кстати, Вы также можете обратиться и к нам по этому или любому другому вопросу. Мы всегда на связи и с радостью поможем решить Вашу проблему.

Специалист компании «Кодерлайн»

Иванова Ольга

Тема: Ошибки после перехода на новую платформу

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

Текущая платформа 1С 8.3.13.1690, все остальные технические параметры остались прежними и ничего не менялось.

(экспериментировать с другими версиями платформы не стал, так как на этой версии сидим давно и вроде бы все работало же….)

Конфигурация до недавнего времени находилась как было описано выше в режиме совместимости 8.3.10, благодаря чему реструктуризация из под конфигуратора проходила штатно и не превносила сюрпризов, казалось бы жили да жили так дальше без новых возможностей…

Месяц назад, после очередной такой реструктуризации которая прошла штатно поломалась часть объектов (при чем уже более значительная, открытие которых в режиме 1С приводило к SDBL разного рода), час икс настал благо это случилось в выходной день. Откат базы к бэкапу недельной давности, наращивание логами транзакции до момента поломки. Выгрузка в DT которая кстати проходит штатно как и выгрузка CF как и загрузка того и другого обратно.

Поднял тестовую базу и начал экспериментировать (на боевой запретил все регламенты по реструктуризации и пересчетам итогов по выходным), в итоге пришлось полностью убить все имеющиеся планы обмена (выгрузка CF удаление всех планов обмена, сравнением объединение с CF чтобы планы обмена вернулись обратно и до настройка их в 1С), так как оказалось в них откуда то взялись данные зарегистрированные для узла ЭтотУзел (подозреваем это привнесла одна из платформ так как там находилась часть данных а не все что могло бы туда попасть за прошлые года). Пришлось лишиться записей в регистре сведений «История изменений» — самопальный механизм которые регистрировал любые настроенные изменения любых настроенных объектов (изменения реквизитов или табличных частей) — в этом регистре были сотни миллионов записей, штатно очистить не представлялось возможным из за недостатка времени, поэтому TRUNCATE TABLE на SQL решил проблему моментально.

После долгих мучений в итоге (спасибо предыдущему посту про обновление на сервере) конфигурация была снята с режима совместимости 8.3.10 и обновлена на сервере (не через штатную кнопку обновления — через штатную крашилось при реструктуризации), что прошло в принципе достаточно быстро, далее открытие режима 1С предприятия, проверка всех объектов — все работает (чудо не иначе). Возвращаемся в конфигуратор, реструктуризация через ТиИ — все проходит.

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

Всем удачи я поделился исключительно своим опытом и своими «колдобинами» при мучении с базой объемом под 300 гб, и не настаиваю что всем это поможет, но в друг кому то пригодится .

Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:

Выглядит данная ошибка вот так:

Сначала напишем список предположительных причин данной ошибки, которые Вы можете найти в интернете и которые являются ОШИБОЧНЫМИ:

• Ошибка в релизе 1С
• Ошибка в платформе 1С
• Повреждение базы данных (требующее лечения с помощью «Тестирования и исправления»)
• Ошибка кэша
• Ошибка сервера 1С (предлагается перезапуск службы сервера 1С)

Нет, все перечисленное не имеет отношения к действительности. Иногда проделанные выше действия, кажется, что помогают с исправлением ошибки. Но просто совпадение с решением одновременно реальной причины.

Сложность разбора реальной причины данной проблемы заключается в том, что воспроизводится она непредсказуемым образом.

Замечено, что ошибка воспроизводится практически только при клиент-серверном режиме работы. И обычно при выполнении длительных операций.

«Ошибка при выполнении запроса POST» — есть информация, что ошибка возникает при выполнении длительных, нагруженных операций над базой данных в ситуациях, когда у процесса rphost заканчивается разрешенная оперативная память на процесс.

Нашей рекомендацией является – снять ограничение на количество оперативной памяти на рабочий процесс сервера 1С.

Также может помочь переход с х86 сервера 1С на х64.

Либо иногда может помочь обновление платформы 1С на актуальный релиз и/или перезапуск сервера 1С. Перезапуск понятно, почему помогает. При этом освобождаются ресурсы.

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

Для снятия ограничений на потребление памяти нужно в консоли сервера 1С зайти в свойства рабочего сервера, как показано на скриншоте:

Если для настроек указать значения «-1», как на скриншоте, то данные ограничения для сеансов использоваться не будут. То есть не будет выполняться завершение сеансов, которые потребляют много оперативной памяти.

Используйте эту настройку под свою ответственность. Нужно понимать, что в большинство случаев при параллельной работе большого количества пользователей вы получите стабильную работу сервера 1С все-таки если не будете отключать данную настройку.

Мы рекомендуем устанавливать значения «-1» только на время выполнения задачи переноса данных 1С, либо другой нужной Вам ресурсоемкой задачи.