v7: 1с 7.7 запись заблокирована #681436

Последнее время часто появляется ошибка "Запись заблокирована". И новый документ не проводится. Все встает колом. База 5 Гб, ДБФ, на копии ТИИ делал. Все зависает, ошибок много. Как то можно вылечить или пока не поздно переходить на 1с 8?

Последнее время часто появляется ошибка "Запись заблокирована". И новый документ не проводится. Все встает колом. База 5 Гб, ДБФ, на копии ТИИ делал. Все зависает, ошибок много. Как то можно вылечить или пока не поздно переходить на 1с 8?

Конфигурация ТиС, вся переписанная разными программистами.

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

Свертка стандартной обработкой вылетает с ошибкой "Недостаточно памяти".

5Г - небольшая база. Из этого только половина - данные, остаьлное индексы. какие самые большие таблицы? И в какой момент выскакивает сообщени о блокировке (и что чаще всего блокируется)?

за сколько лет данные в базе? сколько пользователей работает одновремено? какой размер самого большого dbf файла?

"и новый документ не проводится" - судя по всему при проведении.

Данные за 6 лет. Пользователей около 40, самый большой дбф ок 600Мб. Блокируются все новые документы. Старый перепроввести возможно. При этом у документа пропадает присвоенный номер и появляется сообшение типа "Запись заблокирована. Объект ЦБД...не найден".

если пригласить специалиста не вариант, возможно проще всего начать новую базу с переносом справочников и формированием остатков.

Это самый крайний вариант. Хочется понять куда рыть.

600 Мб это много. какой это файл? 40 одновременно работающих пользователей для dbf торговли это тоже очень много. чего там написано "разными программистами" неизвестно поэтому рецептов готовых я не вижу... возможно кратковременное решение в виде апгрейда железа. для перехода на 8ку если таковой делать все равно апгрейдиться придется.

Апгрейд железа планируется в виде установки SSD дисков. 600 Мб   это регистр СчетаФактурыВыданные. Можно его удалить, т.к. им никто не пользуется.

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

там поди взаиморасчеты по документам и регистры не закрываются.. ( в общем надо смотреть много чего. еще как вариант поищи нетиповые обработки по свертке базы - может одна из них подойдет.

если при ТИИ все зависает и много ошибок, при условии размера базы 5Гб и самый большой файл - 600Мб - то 1) вы уверены что при ТАКОМ размере базы самый большой файл весит только 600Мб? я что-то сомневаюсь! 2) с какого момента появилась проблема, особенно - много ошибок при ТИИ? - если недавно - то воспользоваться архивом - судя по всему - базе кранты! 3) ТИИ - делалось только тестирование - или исправление? хотя после исправления тоже наверняка базе - кранты! 4) проверь железо - может диск посыпался?

Да, это регистр не закрывается. Это знаю. Его совсем можно удалить и проведение по нему закомментировать.

1) да 2) давно 3) Только тестирование. Запускал тестирование и исправление на копии, завершалось с ошибками.

и как вариант - отладчик в помощь! в нем найдешь узкое место.

Про отладчик думал. Искать, что вешает базу и исправлять этот код?

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

и 600 - немного, и 40 человек для файловой - вполне приемлемо (она по скорости в стандарте - выше). Судя по всему - проблема с индексами. И, мое мнение (я его обосновывать не хочу, но чувствую) - с сетью (ну, может, еще на сервере вклчено журналирование дисков)

а "пока не поздно" - лучше перевести на сиквел.

При тестировании физической целостности БД пишет "Неисправимая ошибка таблиц". Сейчас запускал тестирование на копии.

Логическая целостность - есть некоторые ошибки.

ну и ладно, нефик баловаться подменой мд.

значит, диски сервера.

поищите копию в которой проходит ТИИ без проблем

Подмену МД не делал, может до меня кто-то.

За время своей работы с этой базой я такой копии не видел)

полный синтаксис контроль в пофигураторе проходит хоть ?

Никогда не запускал ранее. Сейчас запустил - 4 ошибки есть.

Значит, мд целый хотя бы.. Ну тогда, правь таблички.. занимайся.

все-таки какк верен закон "подобное притягивается подобным"

Подскажите как/чем их править и какие ошибки в них искать?

- это типа нет нормального архива?! да уж....

Нормального архива нет.

ну выложи в архиве все *.dbf и мд куда-нить на поглядеть.

Ок

Вот таблички.

справочники пожадничал ? Книжки покупок/продаж в этой базе ведёте ? Они нужны вам ?

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

ну как бэ, тиИ проходит,опосля выкидывания мусора в виде спец символов из полей.

А как образом подчищали таблички?

А нестремно разрешать непосредственное удаление?

руками, дбф редактором

эдак тебе такого наудаляють...........

у него распределенка.. видать, много мусора бывает.. так и чистют :)

ну дык и че у мене тож распределенка.

Можете мне скинуть таблицы после чистки на ealll@yandex.ru

Как все-таки поступить? База пока работает, но в любом случае решать проблему нужно.

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

1. Оптимизировать работу. Понятно, код причешу. 2. Выкинуть лишнее. Что имеется ввиду? 3. Установить другой период хранения останков. Это что такое?

лишние регистры и движения по ним. + лишние не используемые измерения.

51.3 это 5 дней.

А таблицы нужно чистить ДБФ редактором или так оставить?

желательно поправить, хотя это и не критичные ошибки

Спасибо. На тестовой поэкспериментирую.

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

Для DBF может быть и большая. Поищи узкие места в операциях записи ...

Ну, зачем же сразу удалять ... сделай оборотным для начала :-)

а чем сие лечить ? а то у меня периферийки, хотелось бы знать (

совсем не факт не. приличная, но не большая. большая - это уже около 18-20, там уже что-нибудь начинает к гигу приближаться...

Эта база раньше была распределенной, сейчас все по терминалу работают в одной базе.

Где-то в книге знаний видел алгоритм по переводу на SQL, не могу найти. Может кто даст ссылку?

:) Мало тормозов, хочешь добавить еще ? Удачи :))

выгрузить и загрузить

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

SQL добавит тормозов?

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

для типовой - да

как ее деинициализировать?

за что в яндексе забанили?

Нет)

Я запускал отладчик. 45% (0.8 сек) - тратится на функцию РассчитатьРегистрыПо, как то можно оптимизировать этот момент?

нужно.

Ну это ж системная функция. Вижу варианты: 1. пытаться обойтись без нее. 2. разобраться почему тормозит. Предполагаю, что из-за того что база с 2006 г. и ни разу не сворачивалась.. Подскажите как оптимизировать?

У меня похожая проблема. Когда запускаю нештатную обработку восстановления границы проведения документов, на каком-нибудь документе она останавливается, так как провести документ нельзя. И после этого документ блокируется! Как этого избежать?

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

Ну вот, пока не написал на форум, мучался три года. А как написал - нашел косяк в обработке. Отлично, просто отлично...

мучился*

сам блокировку накладывал шо ле ?

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

жестоко

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

Не все регистры закрываются нормально. Тут тоже есть вопросы: 1. Что делать с неиспользуемыми измерениями? Удалять/не удалять из конфигурации (движения по ним есть). Или оставить, но убрать код, который делает по ним движения? 2. Что делать с незакрытым хламом за прошлые периоды?

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

Очистить напрямую. Поясните, пожалуйста, этот момент?

прямым запросом. Или дбф-редактором. или любой программкой работы с дбф. или даже обработкой из другой конфигурации 1с.

Ок, спасибо.

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

у тебя при проведении заявки пишется/читается периодика?

ПриЗаписи читается. При проведении - нет.

ну вот тебе и ответ..

В других документах пишется Периодика. Документ Изменения цен - их немного, может штук 20 в день.

В принципе эту периодику можно перенести в ПриЗаписи..

Еще вопросец. Когда подключаю formex.dll, при открытии меню Сервис->Параметры 1с вылетает с ошибкой "DAX error class Timage...". Как-то лечится? Если формекс не подключать - ошибки нет.

Это бывает следствие того, что у вас Плохо работает Сетевое оборудование. :) Поздравляю вас... и ваших Админов :)

Версия последняя?

Врядли, что последняя. Формекс.длл - дата изменения от 2007 года.