| 0
- 10.08.2012 - 13:24
|
Всем привет. Обновили в марте базу ЗИК на 322 релиз, после этого ничего не обновляли, все хорошо работало, периоды меняли до июля, вылетов не было. В июле начались проблемы. Проводим документ начисления зарплаты, запускаем расчет, вылетает программа. Делаем лечение исправление, делаем расчет по отдельности по каждому сотруднику, вылетает на ком-то, делаем тестирование исправление опять, опять выдает ошибки такого плана: Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Линкевич Маргарита Николаевна(90104) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Лаптева Елена Александровна(90170) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Кузнецова Ольга Николаевна(89788) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Климович Ирина Александровна(5307) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Климкина Елена Эдуардовна(90000) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Кашмирова Ирина Викторовна(5316) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Истомин Владимир Вячеславович(5202) Проверка уникальности внутреннего идентификатора в журнале расчетов. Зарплата. ПроизвольноеУдержание01 01.07.12<=>31.07.12 Исмаилова Елена Владимировна(89929) Опять тестирование исправление, продолжаем расчет по людям на ком был сбой, расчет проходит, сбой теперь уже на другом ком нибудь. *.DD файлы создавали по новой, подскажите что можно сделать с этим?     | |
| 361
- 13.12.2012 - 22:03
|
(352) > при снятии с проведения начисления ЗП, херятся у автора все записи в ЖР.. - ??? немножко не так... херятся они при перепроведении документа начисление ЗП, в котором отрабатывает штатный оператор ОчиститьДвижения() - а вот почему он прибивает весь ЖР при этом перед проведением начисления ЗП - снимаетм с проведения выплату ЗП) - хз... | |
| 362
- 13.12.2012 - 22:04
| РЕЗЮМЕ: проблема осталась нерешенной. | |
| 363
- 13.12.2012 - 22:44
|
362-Чучундер > Как решается, так и получается. Со среды надо смотреть. И бэкапы использовать. | |
| 364
- 13.12.2012 - 22:46
| 359-Ирли Бёрд > Свинтуса ты в зеркале видишь ежедневно, неблагодарного. А Ёпрсту респект, 3 дня ковырялся, время свое тратил, жаль что не получилось. | |
| 365
- 13.12.2012 - 22:47
| 363-VZ > Бэкапы разные поднимали, сильно старые времени уже нету поднимать. С момента перехода на ноябрь все перепробовали, везде рушится в итоге. | |
| 366
- 13.12.2012 - 22:53
| (363) это понятно. кроме того что восстановить работоспособную базу - еще бы хорошо хотя понять ГДЕ косяк..? пока - это непонятно... | |
| 367
- 13.12.2012 - 22:55
| Вот именно... "Рушится". Ага. Берет, и рушится. Сама. Ага. | |
| 368
- 13.12.2012 - 22:59
| (367) ну хз.. сама или не сама.. есть база (как проверить ее нет ли вней бяк - хз). есть последовательность действий, которая приводит к бяке... пока все... дальше - непонятно... | |
| 369
- 13.12.2012 - 23:12
|
368-Чучундер > Чо непонятно? Причины разрушения дбф-[*****] баз известны, в основном. Это размещение не в подходящей файловой среде (надо ntfs), это слишком разросшиеся таблицы (для 1С - это гиг, касается и индексов), это рассыпающийся диск, наконец, обиженный админ, хорошо знающий структуру... Самая популярная причина - это прокладка. С энтузиазмом, и кривыми конечностями. Чей девиз "Бэкапы делают чайники". | |
| 370
- 13.12.2012 - 23:17
| 369-VZ > НТФС есть, таблицы маленькие, винт целый, за админа не могу сказать, там их куча менялась. Бэкапы делались, но какой от них толк, если при ТИИ все они как один ровные, а проблема вылезает после? | |
| 371
- 13.12.2012 - 23:18
| Толк конечно в плане того что не знаешь который нужно взять... Так то бэкапы это святое, никто не спорит. | |
| 372
- 13.12.2012 - 23:34
|
371-Fold > И стабилизатор питания есть? Должна быть внешняя причина. Чудес не бывает. Движок 27 устойчивый, работает ровно до 2008 и севена, проверено. Еще сеть может быть виновата. Если таблицы рвутся регулярно, рекомендую базу разместить локально, на комп расчетчицы. Бэкап наладить на сервер. Имена бэкапов должны включать дату: *20121214*.zip Хранить не менее 10 дней. Поместили базу локально, и не мучая расчетчицу, ищем причину сбоев. | |
| 373
- 13.12.2012 - 23:42
| 372-VZ > Там помимо расчетчицы еще 3 кадровика. База на сервере, они все по RDP конектятся. Если локально к расчетчице поставить базу то по сетке устанут они туда сюда гонять ее, тем более сеть сбоит бывает. Бэкапы делает расчетчица вручную после сбоя в июле регулярно, хранятся за последние пол года уже, места мало занимают на 7-ке, не критично. | |
| 374
- 13.12.2012 - 23:43
| Стабилизатор сказал купить. Админ бычит что это ниче не даст, но вроде как купить хотят. | |
| 375
- 13.12.2012 - 23:46
| "Поздно, Вася, пить боржом, когда почки отвалились!" | |
| 376
- 13.12.2012 - 23:48
| 374-Fold > Сеть пусть протестирует. Не умеет - пусть ищет сетевика. Бычит он. | |
| 377
- 13.12.2012 - 23:55
|
373-Fold > Бэкапы надо делать не руками, а автоматом. Минус админу, а тебе - два жирных. Три кадровика - это круто. Это, кстати, серьезная опасность саботажа, ибо для маленькой базы кадровик вообще не нужен, а три - это три бездельницы, обеспокоенные тем, что кто-то может удивиться: "А зачем, собственно, мы их кормим?" У меня одна расчетчица (без кадровика) ведет базу с 600-ми сотрудниками, и не чирикает. Другая - базы поменьше (в среднем на 40 юзеров), но четыре. Она же и кадровик. Тоже не чирикает. | |
| 378
- 13.12.2012 - 23:57
|
(376) Так ведь терминал же! Физически база не покидает сервер, да и при локальной работе вылазят косяки, см. (4). Мне, что ли, тоже попросить базу глянуть? Есть одна мыслишка... хотя нет, не надо: энтузизисты еще не кончились и ценник не озвучен. Да и переход на новую базу всяко дешевле будет. | |
| 379
- 14.12.2012 - 00:13
|
378-Ткачик > Терминал я как-то пропустил :) Да, тогда сеть непричем. Хм. А переход на новую базу - теперь только через месяц. Не раньше. И все таки, ИМХО, скорее причина внешняя. | |
| 380
- 14.12.2012 - 08:05
| (379) А, может быть, и внутренняя... Помнится несколько лет назад на этом самом форуме некая Юля06 привела пример "штатного" дублирования внутренних идентификаторов. Народ тогда проверил, убедился и постановил считать это не глюком, а фичей. :) | |
| 381
- 14.12.2012 - 08:10
|
Не причина в этом , я её нашел. Ща поправлю - кину на проверку. | |
| 382
- 14.12.2012 - 08:12
|
возникновение проблемы не коррелирует с ТИИ? библиотеки в bin все родные, патченных нет? сталкивалась с тем, что при подмене какой-то длл для "усовершенствования" работы (не помню какой, но вроде для обеспечения возможности прямых запросов к базе в монопольном режиме), именно после ТИИ начинались "чудеса". После возвращения родной длл проблемы исчезли. | |
| 383
- 14.12.2012 - 08:17
|
(382) не.. у автора косяк только в ЖР. первичный документ Ввод расчета по списку сотрудников за 01.01.2010 имеет родительские документы за 10,11,12 года :) и таких документов много. | |
| 384
- 14.12.2012 - 09:33
| 377-VZ > Я сам в шоке, 1 расчетчик, 3 кадровика. :) А бэкапы я специально сделал чтобы ручками, мало ли что. | |
| 385
- 14.12.2012 - 09:34
| 382-Синегурочка > Белая полностью 27я платформа стоит, ТИИ не находит ничего. | |
| 386
- 14.12.2012 - 10:14
|
380+ у меня оно и в Бух 7.7 на SQL дубли появлялись. когда во второй раз появился дубль, я согласился на 8ку, благо до НГ недалеко оставалось. | |
| 387
- 14.12.2012 - 10:27
|
383-Ёпрст > "первичный документ Ввод расчета по списку сотрудников за 01.01.2010 имеет родительские документы за 10,11,12 года" - а вот теперь сузим раскрывшиеся глаза, и начинаем думать, не привлекая нечистую силу в качестве объяснений (бритва Окамы). Каким образом в 2010 году появились документы 2012 года? Ведь чтобы были ссылки, надо чтобы были документы, не так ли? Поле IDDOC, являющийся основой для формирования ссылки, объявлено в индексе уникальным, и платформа следит за соблюдением уникальности. Так что же произошло? Первый вариант: активная работа при разрушенных индексах. Юзеры презирают сообщение, что был несанкционированный вылет, и не переиндексируют базу. Здесь нужна а) воспитательная работа б) организационная работа (запрет запуска в монопольном режиме + скрипт восстановления индексов. Последний доступен интерактивному запуску, а так же автоматически выполняется автоматом каждые сутки до начала работы. Прмечание: переиндексации предшествует снос файлов cdx). Второй вариант: Документы 2010 года были удалены без контроля ссылочной целостности ("Оне мне не нужны"). Как известно, платформа без специального режима "сжатие БД") записи не удаляет, а ставит специальный бит (флажок) удаления. После чего запись становится невидимой в 1С. И при создании новых записей платформа первым делом ищет такие псевдоудаленные записи, и размещает их в тех позициях. Чтоб не делать дефрагментезацию таблиц. Кстати, именно Расчет ну ооочень активно использует этот механизм для ЖР. Борьба с этой бедой традиционна: полный запрет на удаление без контроля ссылочной целостностью. И для себя, любимого, тоже. Другие варианты требуют отложить бритву Окамы ;) и рассматривать тонкую диверсию. | |
| 388
- 14.12.2012 - 11:23
|
(387) лень качать приведи здесь значения IdDoc из документов - есть одно подозрение | |
| 389
- 14.12.2012 - 11:23
|
(387) не, всё гораздо банальнее - тупое игнорирование о переиндексации базы, когда она того просит Автор, посмотри это (я там даже твои "пустые" даты не трогал) http://rusfolder.com/34105043 | |
| 390
- 14.12.2012 - 11:25
|
(387) заставить переиндексироваться гораздо проще ночью стартует задание, которое 1. делает регламентную копию 2. сносит индексы при отсутствии индексов фиг они войдут в базу | |
| 391
- 14.12.2012 - 11:27
| на самом деле вывод уже есть - база на сервере в терминале. Значит, либо аппаратный косяк на сервере, либо ..... | |
| 392
- 14.12.2012 - 11:30
|
у автора, вот такая картина в ЖР: и записи на род документ начинаются с 2010 года | |
| 393
- 14.12.2012 - 11:30
| ну и таких документов.. дофига. | |
| 394
- 14.12.2012 - 11:31
|
а при отмене проведения.. там тупой алгоритм - удаляет все записи ЖР, вот она ему и прибивает его весь целиком :)) | |
| 395
- 14.12.2012 - 11:39
|
389-Ёпрст > "всё гораздо банальнее" - см.вариант 1 (387) - про то и речь. 390-Helen1986 > Угу. Только это означает, что каждое утро оне начинают работу со входа в монопольный режим. Ну зачем их так мучать? Надо быть гуманее к юзерам :) После удаления индексов просто запускаем на исполнение в пакетном режиме, заставляя конфу переиндексироваться, и выйти. Тут не надо ничего изобретать, достаточно команд пакетного запуска. | |
| 396
- 14.12.2012 - 11:49
| (395) можно и так | |
| 397
- 14.12.2012 - 12:55
|
Всем физкульт-привет! Автоматическую переиндексацию реализовал у себя не только по ночам, но и в случае, если она требуется во время работы, в разделённом режиме. Причём пользователь не может отказаться от неё, так как она происходит автоматически при попытке входа даже в разделённом режиме. Подробности здесь: http://pl1c.org/publ/1-1-0-14 (читать сообщения с 19 по 26) | |
| 398
- 14.12.2012 - 13:15
|
397-volk13 > А зачем проверять "бит завершения"? Ведь время-то для переиндексации выделено? Нет? Тогда зачем проверять? Беспокоишься, что сервер вспотеет зря? :) Да, еще. Обоснование FAT для диска со свопом: в FAT таблица заголовков файлов целиком загружается в память. Поэтому поиск нужных фрагментов осуществляется быстрее. Вот и все. | |
| 399
- 14.12.2012 - 14:01
| 389-Ёпрст > Алгоритмом которым ронял до этого не роняется база. | |
| 400
- 14.12.2012 - 14:06
| 393-Ёпрст > Ты таким докам самого себя в родителя воткнул? | |
