Ошибка разделенного доступа к информационной базе.... #584273

При выгрузке ИБ пишет "Ошибка разделенного доступа к информационной базе...." И в качестве активного сеанса пишет мой же сеанс.... Сервис перезапускал.. в консоли никаких соединений больше не показывает.....че за хрень такая?... Перегружать сервер пока нет возможности (это поможет?)...

посомтреть в консоли сервера 1с блокировки ИБ (клиент-серверная база ?)

попробуйте остановить сервис, прослдедить чтобы все процессы выгрузились из памяти (prhost,ragent,rmngr) и только потом запустить

код ошибки 10054 ?

в блокировках только блокировки от конфигуратора....... такое просто было уже давно....непомню как разрешилось...может сервер перегружал.....

shuhard, да нет никакого кода не пошет.... просто Ошибка разделенного доступа к информационной базе Активные сеансы: и тут пишет мой же сеанс.....

не верю

блин и перезагрузка сервера не помогла......черт.....ну ладно сделаю бэкап базы на sqlserverе.....непонятно че с этим делать?.....

подниму опять темку......так и не решил..... в чем может быть проблема.... даже перегружаю сервер, делаю новую базу, восстанавливаю из бэкапа......делаю выгрузить в конфигураторе и бац ошибка разделенного доступа к ИБ.....

ошибка на мисте описана сотни раз и не представляет ни какого интереса

ошибка тривиальная, когда кто-то сидит в базе или выполняется регламентное задание......но когда ты перегружаешь сервер, создаешь новую базу (сразу же выключаешь регламентные задания), восстанавливаешь базу из бэкапа, Потом из конфигуратора начинаешь выгружать базу....он повисит и потом говорит, что уже есть сеанс и говорит про твой же сеанс начатый конфигуратором (хотя 2 раза конфигуратор даже запустить нельзя).... именно такие случаю сотни раз разорбраны?....

воспользоваться поиском что-то не позволяет ?

пользовался......в основном либо сеансы есть, либо люди не блокируют регламентные задания....у меня то какаято другая фигня....

сказки

вот нашел описание такого же случая... то что там прочитал, так это "если создать базу средствами SQL, а не создать и залить типовыми методами 1С, то в дальнейшем происходит ошибка/проблема – база типовым методами 1С не выгружается" я ее именно так и создал, а не загружал.... неужели теперь никогда не выгрузить?!?...

лезь в консоль скуля и ищи зависшую блокировку

да нету в консорле никаких соединений.....было б все так просто я б не писал .....

в консоль СКУЛЯ а не 1с

не поможет это ошибка не хватки памяти сервера 1С и лечиться либо кастрацией конфигурации(обычно УПП) либо расширением памяти разными способами

ну память можно расширить увеличив файл подкачки

не а, не помогает либо /3Gb либо 64х

операционка 32 разрядная, на сервере 4 ГБ с расширением физических адресов.....но процесс больше 3 гб не захапает.....хотя в настоящий момент занято всего 1ГБ ....бэкап базы в районе 2 ГБ....

это ошибка не хватки памяти сервера 1С и лечиться либо кастрацией конфигурации(обычно УПП) либо расширением памяти разными способами либо /3Gb либо 64х

3G щас сделаю..... интересно какого фига на SQLСервере 2 соединения.....запускаешь конфигуратор......в консоли сервера 1с одно подключение, а на скуле - 2 соединения....закрываешь конфигуратор....закрываются оба.....

, "нехватки" пишется слитно! :-)

shuhard, да все спасибо помогло либо /3GB либо то, что почистил временные файлы.....свободного места на диске C на сервере 1с было мало.....интересно сколько ему надо свободного места на диске (размером с базу)....потому как занятой памяти сейчас всего 500 МБ....

а теперь пуcт поиск по форуиу на "/3GB" и убедись, что проблема поднималась сто раз и что через месяц /3GB уже не поможет и придётся конц кастрировать или увеличить RAM

или опять удалять лишние файлы с системного раздела, чтоб своп поместился :-)

не в кассу

сервера все равно виртуальные под Hiper-V-Serverom..... стояла статическая память 4 ГБ... я сделал динамическую с 4 до 8 ГБ.....но говорю же занято памяти немного.....похоже просто места на диске мало было для каких-то служеных файлов.....херово конечно если он ее вначале на диске сохраняет всю....

бред топик закрыт

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

ну что за дебилизм ставить на виртуалки клиент серверные базы? нельзя так делать!!! по любому будут всплывать трудно обьяснимые тормоза и блокировки...

к данной ошибке виртуалка отношения не имеет

имеет, данная ошибка возникла из-за полного не понимания как работает SQL. А факт непонимания - отражается попыткой запустить скуль под виртуалкой

к сиквелу ошибка отношения не имеет, ни какого, это ошибка сервера приложения

vde69, если руки не кривые то никаких тормозов не будет..... зато нет привязки к железу..организован отказоустойчивый кластер пока из 3-х узлов....при отказе даже 2-х узлов....все будет работать.....а перебрасывать виртуалку с узла на узел можно даже при работающих пользователях.... но как сказано это не имеет отношения к теме..... проблема в неправильной диагностике ошибки самой 1с....

Почему нельзя?

1. по тому что сервер SQL не понимает где действительно физическая память а где виртуальная память железа (фидимая как физическая) 2. сервера приложений (а к ним относятся и 1с) не могут оптимизировать дисковые операции, по сколько идет конкуренция между виртуалками. в результате частенько кеш запросов помещается в медленую дисковую очередь.... может знаете чем вызвано так и не докапался пока

угу, всё так, виртуалки не идеальны и могут создавать ошибки, не воспроизводимые в иных условиях но к ошибке ТС это не относиться, она воспроизводиться, например на УПП, легко и не принуждённо без виртуалок

vde69, может просто для решения 1 и 2 проблемы достаточно сделать так чтоб физической памяти было достаточно для всех....и не будет конкуренции за память и проблема в использовании виртуальной памяти....

чтоб вся виртуалка, вместе с ОС и скулем, поместилась в ОЗУ? а нафига эта виртуализация? почему нормальную ОСь не поставить, если ресурсы позволяют?

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

"некоторые программы даже не заметят этого..... " но некоторые пользователи заметят, если вместо запросов к ОЗУ скуль будет вращаться в свопе...

1с на 100% отвалится, по сколько трафик между клиен сервером шифруется сеансовыми ключами. По этому ты в любом случае не имеешь отказоустойчивый кластер!!! При чем данная опция НЕ НАСТРАИВАЕМА и ее нельзя отключить, вроде как RSA там... (я разбирал попакетно трафик между клиент и сервером). Тот-же кластер 1с - тоже сделан только для маштабируемости а не для отказоустойчивости...

vde69, не соглашусь..... Зависит от того, что делает пользователь 1с в это время... Если ничего не делает, то сеанс не отвалится.....Если что-то делает, то программа предложит перезапустить и продолжит работу.... Для самой 1с по сути.....всего лишь пару секунд был недоступен сервер и все... Но пару секунд отсутствие сервера это все равно не сравнимо с несколькими часами в лучшем случае (а то и полдня) в случае отказа железяки на обычной машине....

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

ты меня пугаешь. я именно в виртуалке и держу centos с базой postgre и терминалку под 2008. Пока полет нормальный.

2 он же не говорит про Постгресс...и про ДБ2 ничего не говорит, которая у меня тоже в виртуалке