| | Ошибка доступа к файлу после перерыва в работе [ Максим ] Пятница, 7 апреля 2006, 13:28
На одном из компьютеров возникает следующий "каскад" ошибок, перечисленный в едином сообщении:
"Код ошибки ГИС: 1 (Ошибка уровня управления БД), Код ошибки СУБД: 2511 (ошибка открытия файла БД), Ошибка ОС: 32 (процесс не может получить доступ к файлу, так как этот файл занят другим процессом)."
Данная ошибка возникает после перерыва в работе в несколько десятков минут. Через некоторое время после возобновления работы, при редактировании геометрий мышкой, экран неожиданно хаотично заполняется векторами (со слов пользователя). Фоновых задач нет, гасителей экрана - тоже, схема энергопотребления - "презентационная", то есть всё включено постоянно. Пользователь входит только в группу "Пользователи" со стандартными (неизменёнными после инсталляции) правами. Система win XP Pro SP2, в логах всё чисто (при возникновении ошибки было зафиксировано текущее время). Файлы были расположены, скорее всего, на сервере (samba), там тоже в самбовских логах (и в "общих", и в "помашинном") всё чисто.
В редактируемых файлах полностью отсутствуют таблицы, только графика и растры.
Ранее на этом же рабочем месте (тоже обычно после перерывов) возникала системная "ошибка отложенной записи" (немедленно сопровождавшаяся ошибкой OL), иногда приводившая к потере части введённой информации, но после сделанного в реестре увеличения max числа страниц виртуальной памяти до предельно возможного значения вроде "помогло".
Что следует "посмотреть" теперь ? |
|
| | [ ObjectLand Support ] Пятница, 7 апреля 2006, 14:03
В "период простоя" ObjectLand не делает ничего, т.е. его представление в виртуальной памяти неизменно. То, что на этой машине возникают системные ошибки, явно показывает, что проблема в ней самой.
Затрудняемся сказать что-то определенное, уверены, что ошибка не связана с ObjectLand вообще никак. |
|
| | [ ObjectLand Support ] Пятница, 7 апреля 2006, 15:51
|
| | [ Максим Юрьевич Трухачёв ] Пятница, 7 апреля 2006, 20:50
| Спасибо, буду разбираться с железом/ОС. |
|
| | [ Максим ] Пятница, 7 апреля 2006, 21:48
Я поторопился с ответом:)
Дело в том, что ошибку отложенной записи я давно и успешно ликвидировал (кстати, благодаря той же ссылке от MS, что вы здесь дали). Ссылка на sql.ru тоже посвящена этой же ошибке, которую я вообще упомянул здесь просто для полноты картины.
Обратите внимание, что "невозможность доступа к файлу" возникает не сразу после перерыва (во время которого образ процесса в памяти неизменен), а через некотрое время активной работы (в основном редактирования/рисования геометрий). Я сам не люблю "гадать на кофейной гуще", но, по-моему, предоставил достаточно информации для начала совместных "исследований" проблемы, в ходе которых я буду отвечать на все ваши вопросы и ставить эксперименты по вашим подсказкам. Ситуация осложняется тем, что ошибка "плавающая", воспроизвести её невозможно, дежурить возле пользователя я не могу, но зато могу проинструктировать его, что надо делать при очередной такой ошибке, если, конечно, сам получу такие "инструкции" от вас.
Я бы не донимал вас "исследованиями", если бы не один неприятный момент (мягко говоря), заложенный в вашу программу: она не умеет делать ни "Save", ни "Save As...", ни "Undo". Всё, что оператор делает в программе, мгновенно и "навечно" сохраняется в ГБД. Так же работает, например, FineReader. Но всё-таки ГИС - не распознавалка, и я хотел бы узнать, какие меры отказоустойчивости, доступные пользователю, в вашей программе реализованы. Я знаю только про создание "файла отката" при трансформации геометрий, при операциях с несколькими ГБД и, кажется, СУБД (не смотрел ещё). Какие меры ещё вы можете порекомендовать, как разработчики ?
В принципе, можно работать по очереди с двумя-тремя-и_более ГБД одного имени, но в разных каталогах, для подстраховки. Но пользователей это вгоняет в депрессию:), так как помимо основной работы им надо следить за актуальностью текущей копии ГБД и делать копирование каталогов в нужном порядке с принятой периодичностью. При любой ошибке (например, при приходе "нового" оператора) возникнет путаница и потеря наработанных изменений. Добавьте к этому многопользовательский режим редактирования базы, когда надо всех "выгонять", делать копии, а потом логинить снова... Можно, конечно, написать надстройку над OL (точнее, над его файлами) с целью автоматизировать весь процесс, но стОит "нетерпеливому начальнику" или непроинструктированному новичку поработать с какой-нибудь копией ГБД "в обход" надстройки, и путаница будет обеспечена "по определению". Не проще ли предусмотреть "защиту от сбоев" в концепции, например, по рассмотренной схеме поочерёдной смены "актуального" каталога из нескольких таковых (естественно, по "нажатию кнопки" пользователем, а не "по таймеру") ?
Хотя деваться мне особо некуда, буду со временем писать постепенно эту навороченную надстройку и "строить" пользователей, так как терять полгода работы из-за глюка не интересно... :( |
|
| | [ ObjectLand Support ] Понедельник, 10 апреля 2006, 13:50
В отношении сбоя, почему мы так уверены в том, что проблема в конкретном компьютере? У нашего самого крупного клиента, находящегося в пределах физического доступа, около полусотни человек ежедневно в течение многих лет вводят карты, таблицы, строят макеты в ObjectLand на самом разном железе (старом и новом) и в самых разных вариантах софта (разных OS, разнообразном другом софте,с расположением ГБД локально и на серверах). Т.е., конечно, и все возможные и невозможные варианты "простоя" случаются. И такая ошибка, если бы ее причиной был ObjectLand, уже давно бы вызвала бурные рекламации (проблемы немедленно доводятся до нас). Уже не говоря о нескольких тысячах инсталяций по России. Но о такого рода ошибке мы не слышали.
Из этих статистических соображений мы делаем вывод, что нужно разбираться с конкретной машиной. И безусловно случаются ситуации с плавающими ошибками, причину которых понять не удается (особенно в удаленном режиме), но это такая редкость и администраторы обычно сами признают, что это проблемная машина и помогает замена железа.
В данном конкретном случае, желательно бы на данной машине поработать для теста некоторое время с ГБД, размещенной локально (судя по ошибке OS).
*********
О защите данных в ГБД.
"Неприятный" момент о котором Вы пишите на самом деле не только не момент, а даже наоборот достоинство системы. Только десктоповские программы имеют возможность отказаться от всех изменений, т.к. изменения выполняет один человек. А кто сможет принять решение об отказе от всех изменений, если они вносятся несколькими равноправными людьми? Любая многопользовательская СУБД вносит данные в реальном времени. Что касается операторов, то они могут, например, выполнять Undo для всех операций редактирования графики, выполненных ими самими.
Все логически связанные операции в ObjectLand выполняются в транзакции. Если в транзакции встречается ошибка, то происходит отказ (rollback) от всех изменений в данной операции. Если ошибки нет, то выполняется commit(фиксация) измененных данных непосредственно в ГБД. Поэтому данные в ГБД всегда имеют логическую целостность (непротиворечивость).
**********
Возможность предварительной проверки введенных данных с возможностью отказа от них в случае многопользовательской работы в ObjectLand также существует. Для этого введен режим работы с использованием файла изменений. В этом файле будут накапливаться все изменения ГБД с момента, когда такой файл будет создан. При этом ГБД будет оставаться неизменной. пока администратор не решит, что данные хороши, и выполнит операцию консолидации ГБД. "Старое" состояние ГБД будет доступно другим пользователям, если открать ГБД в режиме "без файла изменений".
Режим использования файла изменений требует аккуратных действий от администратора, который не должен позволить какому-то пользователю открывать на модификацию ГБД без файла изменений, в то время, когда остальные пользователи используют файл изменений. Поэтому по умолчанию этот режим отключен и для его включения требуются некоторые осознанные действия.
Этот режим удобен, когда Вы вносите логически связанные изменения в ГБД, но не хотите, чтобы пользователи видели данные ГБД в прочессе ввода. Тогда все, кроме операторов, смогут видеть ГБД в прежнем состоянии.
Когда работа будет выполнена (например, введены все гаражи), то алминистратор консолидирует ГБД и файл изменений становится пустым.
*********** |
|
| | Ошибка при инсталляции [ александр ] Воскресенье, 30 декабря 2007, 03:19
| Здравствуйте! При любой инсталляции возникает ошибка. "Произошла ошибка при переименовании файла в папке назначения : MoveFile:сбой;код32. Процесс не может получить доступ к файлу, так как этот файл занят другим процессом." Что делать? |
|
| | [ Serg ] Воскресенье, 30 декабря 2007, 11:09
| Вы под администратором устанавливаете? |
|
| | Ошибка доступа к файлу после перерыва в работе [ ViFIZEG ] Суббота, 5 января 2008, 15:38
| либо при запущенном ол... |
|
ОтветитьЗнаком «*» отмечены обязательные для заполнения поля. |
