(1) crabzzy, Сделайте выгрузку базы средствами 1С, затем средствами 1С администрирование (Администрирование серверов 1С) очистите данные не удаляя саму БД на СУБД. После у вас будет чистая БД на СУБД, на сервере та же БД, заходите в 1С и загружаете из последней выгрузки. Если такое будет повторяться, то надо разбираться с настройками СУБД.
Здравствуйте. У нас своя конфигурация для ServiceDesk на базе Итилиум. Неделю назад, после обновления платформы для нужд обновленной ERP (1С 8.3.7.1759) и параллельного запуска на том же сервере второй подобной базы с конфигурацией Итилиум, тоже столкнулись с Ошибкой СУБД:
Microsoft OLE DB Provider for SQL Server: There is already an object named '#tt4' in the database.
HRESULT=80040E14, SQLSrvr: SQLSTATE=42S01, state=6, Severity=10, native=2714, line=1.
При чем ошибка может выдаться в любой момент - при входе в базу, при открытии документа, или при сохранении. Еще заметили, что в Журнале регистрации обеих баз пересекаются записи сеансов из двух разных баз - это вообще нонсенс. Теперь не знаем, на что грешить - на обновление сервера или на вторую базу с той же конфигурацией, или на то и другое вместе.
(1) crabzzy, подскажите, удалось ли Вам выяснить причину ошибки? Нашли ли решение?
Попробуйте настроить перестроение индексов. Да и вообще емешало настроить регламентные задания на сервере.
Еще как вариант запустить тестирование и исправление, средствами смого 1С, только перед этим занятием сделайте резервную копию.
по ошибке видно что с базой что-то не так! Возможно нарушена где то ссылочная целостность.
Спасибо за ответы!
У нас база большая и работает без остановки, сложно будет такое предложить без четких оснований, что это поможет.
Я думаю, что тут с временными таблицами (оптимизация 8.3) что-то не то.
(10)(сложно будет такое предложить без четких оснований)
Интересно руководству просто надо список вариантов действий или решение проблемы.
Вообще как минимум надо иметь отдельный тестовый сервер с копией базы. И если тут что-то вам сказали, то немедленно пробовать.
-Ошибка появляется именно при выполнении отчета "Анализ субконто"?
Возможен вариант, что в тестовой базе всё будет работать без ошибки: пересоздайте рабочую.
Если конкретно проблема в отчете: переписывайте отчет.
Если дело ни в отчете, ни в базе: Пробуйте с другим релизом платформы
Возможно надо будет сделать откат на более старый релиз.
Ждать, что вам кто-то сейчас скажет секретный секрет, который решит все ваши проблемы не стоит.
А уж тем более ожидать, что на пресловутом "партнерском форуме" "супер мозги" придумают экстраординарный шаг конём.
Вообще, то что вы используете SQL 2008 SP4 хорошо.
Если база большая, то я предполагаю, что начала она наполняться до 2008 года?
Достаточно давно, мы перешли с SQL 2005 на SQL 2008 и столкнулись с проблемами.
Естественно ни один из франчей, включая саму фирму 1С не смогли дать ни каких рекомендаций.
Пришлось самими исследовать и тестировать проблемы. База тоже достаточно большая.
Проблемы были связаны с регистрами расчетов. Если интересно, то могу показать результаты исследований.
Но самый главный результат - вернулись к SQL 2005 и больше не гонимся за новинками SQL
Надежная работа важнее.
Проблема с неудалением временных таблиц, обсуждалась на партнерском форуме. Вероятно, кривая работа пула временных таблиц. Пока нормального решения нет.
(14) CaptainMorgan, да, спасибо! Попробуем с другим релизом платформы, но чуть позже
(15) KillHunter, база круглосуточно работает, не хотели лишний раз грузить туда-сюда
(16) rar_xxx, да, вероятно действительно нам стоит это проверить - наличие конструкций УДАЛИТЬ
не только в этом отчете, бухгалтера говорили любой не работает
отправили запрос в 1С, посмотрим. что ответят, но и себе заметка хорошая - наличие конструкций УДАЛИТЬ проверить, спасибо большое!!
Посмотрим запросы.
(17) crabzzy, Как временное решение попробуйте при возникновении ошибки в tempdb найти эту таблицу и снести ее. Не гарантирую что я думаю правильно и что сервак не придется ребутить, но я бы попробовал ) Если будете пробовать отпишитесь плз по результату).
(18) rar_xxx, ага, думал надо бы скрипт какой, чтобы все временные из tempdb чистить
а то мы тоже сервак перегружаем для очистки tempdb - думаю накладно
. Это происходит только в отчете который на скрине? Если да я бы проверил запрос сначала в конструкторе, если не ругнется, тогда удалял бы временные таблицы сразу как они станут ненужны. По идее, давно где то читал, правильно временные таблицы всегда удалять, после того как они стали ненужны, но копая типовые бух. 2.0, зуп 2.5, бух 3.0, УТ11, и КОРП и ПРОФ очень редко вижу удаление временных таблиц.
select name fr om tempdb.sys.objects
where name like '#tt%'
надо бы обход как-то сделать,
FOR ... in (select ..) loop end loop - так не вышло,
в инете какие-то сложные вещи с удалением(drop) набора таблиц
как бы обойти набор и drop всем сделать?
тоже имена длинные оказались, типо таких:
#tt4________________________________________________________________________________________________________________000000000755
(20) crabzzy, ну я бы все тблицы не сносил ), в этот момент могут выполнятся запросы(а нынче все через запросы), ты убьешь временные таблицы запросы не выполнятся, куча недовольных юзеров ) дропни для начала одну с именем в ошибке
Боюсь, конструкция УДАЛИТЬ здесь не поможет: экспериментально проверяли наличие ВТ в tempdb после выполнения УДАЛИТЬ.
До некоторых пор деструктор временной таблицы выполнялся (при его отсутствии в коде запроса 1С) по факту деструкции запроса без менеджера временных таблиц или по факту деструкции менеджера временных таблиц при его наличии.
Пул временных таблиц, по словам некоторых товарищей, был введен как механизм понижения влияния многочисленных созданий/уничтожений временных таблиц на качество работы СУБД.
Такая же проблема, обновили платформу до 8.3.7.1776. Добавили несколько таких же конфигураций (Торговля 10.3). Получили аналогичную ошибку и логи всех входов-выходов пользователей этих баз.
Понизили платформу до 8.3.6.2421. Результата не дало.
Пришли к выводу, что это глобальная проблема платформы, нужно разносить подобные конфигурации по разным серверам или переводить часть их в файловый режим. Планируем пока второй вариант потестировать.
Разработчикам, конечно, отдельный привет надо передать.
Добрый вечер! Уважаемые коллеги, как раз недавно на партнерском форуме увидел, что проблема из-за работы в режиме совместимости с 8.1, если отойти от неё, хотя бы на 8.2, то проблема должна уйти. У нас ушла проблема.
crabzzy, спасибо за информацию!
Только в партнерский форум не у всех есть доступ. Было бы неплохо почитать, о чем там пишут. Нельзя ли опубликовать?
Оставили одну базу из набора проблемных, перевели режим совместимости с 8.1 на 8.2. День прошел без ошибок. Дальше будем по одной добавлять подобные базы обратно и смотреть.
У нас была "совместимость с 8.1". Поэкспериментировали с разными видами совместимости, кое-где кое-что поправили в конфигурации, в итоге выставили вариант "Не использовать". В обеих базах... За сегодня ошибок не было. Но перекрестные записи в журнал по-прежнему есть. Размер логов растёт... В понедельник продолжим анализ и дальнейшие опыты.
АПДЕЙТ: Прошла неделя в режиме совместимости "Не использовать". Ошибка СУБД больше не появлялась. А вот логи по-прежнему растут... Будем "расселять" базы на разные сервера.
Нет, при нахождении нескольких баз на одном сервере (не важно - 1С:Предприятие и 1С:Предприятие, или 1С:Предприятие и ERP) повышением/отключением режима совместимости удается только избавиться от SQL-ошибок "There is already an object named ##ttNN in the database...". Проблема же с перекрестными записями в логах и соответствующее увеличение размера логов (каждой из баз) в десятки-сотни раз - остается.
Окончательное решение - разнести каждую базу на отдельный сервер/сервис.
Мы на одном сервере подняли параллельные сервисы на разных портах - по ним и разнесли базы. На производительности сервера (ввиду того, что несколько процессов крутятся на одном сервере) это вроде бы почти не сказалось. Зато от проблемы с логами наконец-то полностью избавились.
Подводя итог, хочется сказать, что обсуждаемая проблема с перекрестными запросами и записями из разных баз - это явный косяк сервера 1С.
Такой же "нежданчик" поймал,
Subject: Периодическое падение клиента с ошибкой СУБД
Добрый день!
1. Регистрационный номер программы : ...
2. Название организации: .....
3. Версия программного продукта, название конфигурации:
1С:Предприятие 8.3 (8.3.6.2421) 64х,
Управление производственным предприятием, редакция 1.1 (1.1.14.39), Режим совместимости интерфейса «Версия 8.2», Режим совместимости «Версия 8.1»
После перевода конфигурации на 8.3 в режиме совместимости, в процессе эксплуатации возникают ошибки клиента вида
Descr='src\ServerJobExecutor.cpp(792):dc31263e-ecbf-41bd-9b3a-7b55897d5fd6: Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: В базе данных уже существует объект с именем "#tt2".
HRESULT=80040E14, SQLSrvr: SQLSTATE=42S01, state=6, Severity=10, native=2714, line=1'
При чем ошибка может выдаться в любой момент - при входе в базу, при открытии документа, или при сохранении.
Настроил технологичный журнал, в результате получил логи, но я не могу понять причину (логи ТЖ во вложении)
Помогите разобраться в причине. (Снятие режима совместимости не желательно)
Дополнительная информация:
БД на Microsoft SQL Server Enterprise (64-bit) , 11.0.2100.60, уровень совместимости SQL Server 2005 (90), ОС Win Server 2012 R2
На Сервере 1С одновременно с проблемной базой находятся еще три:
Бухгалтерия предприятия КОРП, редакция 3.0 БИТ.ФИНАНС 3.0 3.0.37.25/3.1.17.5, Режим совместимости интерфейса «Версия 8.2», Режим совместимости «Версия 8.3.5»
Бухгалтерия предприятия, редакция 3.0 (3.0.42.85), Режим совместимости интерфейса «Такси. Разрешить Версия 8.2», Режим совместимости «Не использовать»
1С:ERP Управление предприятием 2.0 2.0.9.47 , Режим совместимости интерфейса «Версия 8.2. Разрешить Такси», Режим совместимости «Версия 8.3.4»
---------------
после долгих переписок и сборов логов, официальный ответ
Здравствуйте!
Ваше обращение зарегистрировано под номером SW999027 / 3.
Пожалуйста, в тексте следующих обращений на эту же тему ссылайтесь на этот номер.
Ответ от разработчиков:
Ошибка зарегистрирована (10156333) и будет исправлена в одной из ближайших версий.
8.3.8.1747 Вышеуказанная ошибка осталась....
Мы с этой ошибкой боримся следующим образом:
Есть 3 процедуры SQL
1) Обновление статистик
2) Дефрагментация индексов
3) Реиндексация индексов
Вот только после выполнения третьей процедуры (Реиндексация индексов) ошибка пропадает на некоторое время. Бывает несколько дней, бывает несколько недель.
Если процедуру делать каждую ночь, то у меня пропадает эта ошибка.