Ожидание блокировки таблицы "Журналы", хотя никто ничего не делает ??!!
Часто возникает такая ситуация, в базе возникает ошибка: Ожидание блокировки таблицы "Журналы", хотя никто ничего не делает, и никто ничего не может сделать из-за ошибки. И пока все юзеры не выйдут, ошибка не исчезает. Подскажите, пожалуйста, можно-ли решить эту проблему без выхода пользователей? И может кто знает из-за чего это может происходить?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3)
Да вообще все пользователи замирают и ничего не делают, в диспетчере задач, загрузка ЦП 1cv7.exe у всех на 0%. К базе все подключатся через RDP (удаленный рабочий стол)
Даже если никто ничего и не делает, процессоры у всех ли клиентов простаивают?
Да вообще все пользователи замирают и ничего не делают, в диспетчере задач, загрузка ЦП 1cv7.exe у всех на 0%. К базе все подключатся через RDP (удаленный рабочий стол)
(9) где проверить? И у кого?
Если я так понял, имеете ввиду права пользователей, которые подключились к удаленному рабочему столу, и причем здесь могут быть эти права, если люди работают какое-то время, а потом бац и ожидание транзакции у всех, никто ничего не может сделать.
Если я так понял, имеете ввиду права пользователей, которые подключились к удаленному рабочему столу, и причем здесь могут быть эти права, если люди работают какое-то время, а потом бац и ожидание транзакции у всех, никто ничего не может сделать.
При каких действиях возникает ошибка? Это как то отражается на работоспособности? Что в этот момент Вы не можете делать, какое идет ограничение?
(16) насколько я помню в распределенной БД обмен идет через конфигуратор и в монопольном режиме, пользователи в этот момент работать не могут????
предлагаю попробовать тестирование и исправление БД+сжатие, если не поможет, то попробовать создать новую базу и загрузить в нее данные из старой
предлагаю попробовать тестирование и исправление БД+сжатие, если не поможет, то попробовать создать новую базу и загрузить в нее данные из старой
На моей прошлой работе такая ошибка возникала в случае переполнения таблицы журнала. Уже не помню, как конкретно файл назывался, но один из тех, которые начинаются с 1s. Причина простая - таблица DBF имеет ограничение по размеру файла и по количеству записей (. При попытке записать сверх этого количества 1Ска у текущего пользователя подвисает с такой ошибкой, а у остальных просто висит в ожидании захвата таблицы. Не ваш случай?
1. Проверить размер файлов в базе. Не должно быть ни одного dbf/cdx больше гига. Исключение, пункт 2
2. Проверить не используется ли какой-то нестандартный "движок". Типа
3. Какой-нибудь неспешный отчёт может давать блокировку общего журнала.
4. Возможна зависшая блокировка после аварийного завершения у кого-то 1Ски.
2. Проверить не используется ли какой-то нестандартный "движок". Типа
3. Какой-нибудь неспешный отчёт может давать блокировку общего журнала.
4. Возможна зависшая блокировка после аварийного завершения у кого-то 1Ски.
(26)
Неправильный ответ. Невозможно корректно работать на типовой 1С с DBF большими гига. Движок не способен. Больше гига начинаются проблемы, притом, на сколько помнится, именно на блокировках. Больше двух гигов и 1С ничего с этим файлом сделать не может. Может просто не запуститься.
А обрезать базу всегда возможно. Даже если очень-очень не хотят все. От высшего руководства до последнего кодера. Или перейти на SQL. И почти навечно забыть о ограничении размеров.
файлы больше 1 гига есть, сделать их меньше гига невозможно.
Неправильный ответ. Невозможно корректно работать на типовой 1С с DBF большими гига. Движок не способен. Больше гига начинаются проблемы, притом, на сколько помнится, именно на блокировках. Больше двух гигов и 1С ничего с этим файлом сделать не может. Может просто не запуститься.
А обрезать базу всегда возможно. Даже если очень-очень не хотят все. От высшего руководства до последнего кодера. Или перейти на SQL. И почти навечно забыть о ограничении размеров.
(29) Меньше 1 гига сделать невозможно регистр Покупатели, я подрезку делаю каждые полгода, оставляю итоги только 1 последний год, и это уже 1,4 ГБ, причем это без ввода начальных остатков, подрезку делаю сторонней программой (просто тупо обрезаю полгода, если еще ввод начальный остатков сделать тогда база превысит 2 ГБ). Пробывали перейти на SQL - запустили обработку, которая переводит файловую в SQL - ждали 2 месяца, не дождались когда закончиться, в итоге бросили эту затею.
(33) Перевод на SQL тоже делают частями, потому что полная выгрузка базы, которую можно заливать как правило превышает ограничения файловой системы.
Выпочковывают распределенку с миграцией только справочники, база только получатель, заливают в SQL, заменяют мд-шник на полную миграцию и доливают данные по периодам(месяц, неделя,день, минимальный чтоб не тормозило), перезапись документов всех без перепроведения. Когда данные в периферийной SQL будут полностью синхронизированы, можно будет прописать пути у пользователей на новую базу за минуту. В периферийной базе работать нельзя до полной синхронизации, движения должны быть из данных ЦБ.
Выпочковывают распределенку с миграцией только справочники, база только получатель, заливают в SQL, заменяют мд-шник на полную миграцию и доливают данные по периодам(месяц, неделя,день, минимальный чтоб не тормозило), перезапись документов всех без перепроведения. Когда данные в периферийной SQL будут полностью синхронизированы, можно будет прописать пути у пользователей на новую базу за минуту. В периферийной базе работать нельзя до полной синхронизации, движения должны быть из данных ЦБ.
(33)
За подробностями - к уважаемому hogik, или сразу сюда, чтобы не искать:
На всякий случай - там даны ссылки на другие варианты решения (от того же автора):
Меньше 1 гига сделать невозможно регистр Покупатели
Тогда без решения этой проблемы бесполезно что-то еще предпринимать: при совместном (многопользовательском) режиме работы 1С 7.7 на файлах больше 1 Гб ведет себя непредсказуемо.
За подробностями - к уважаемому hogik, или сразу сюда, чтобы не искать:
На всякий случай - там даны ссылки на другие варианты решения (от того же автора):
Пробывали перейти на SQL - запустили обработку, которая переводит файловую в SQL - ждали 2 месяца, не дождались
А переходили, наверное, "с наскока", не обращая внимания на размер базы? Возможно, что и тут вся проблема в нем, можно попробовать:
Никак. Более того, даже если вы найдете причину .блокировки и снимете процесс, блокировка останется.
...антивирус? Уверены, что у всех пользователей однотипные настройки относительно "проверки" файлов 1С?
Одна из особенностей антивируса - проверка "на лету", так вот, эта проверка прекращается, когда к файлу перестали обращаться. Даже защитник Windows может пакостить.
если dbf то файлы до 2 гиг. Смотри диспетчер терминалов. у меня на серваке остаётся незакрытая сессия. Просто сбрось. Мож поможет.
В дбф файлах 1с есть ограничение на размер юид и количество строк в некоторых файлах. Но при превышении этого лимита 1с не блокируется, а перестает сохранять новые данные.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот