Здравствуйте, уважаемые коллеги!
Хочу попросить содействия в расследовании следующего странного случая с пропажей данных из базы.
В ЖР есть запись о добавлении объекта, документ был распечатан (сохранилась бумажная версия), транзакция добавления зафиксирована, но сейчас объект в базе отсутствует, при этом записей об удалении в ЖР нет... (см скрин)
Такие случаи замечены в получасовом промежутке с 11:27 до 12:07 примерно по паре видов документов и по паре видов справочников, как в толстом клиенте, так и в фоновых заданиях, всего около 30 случаев
База на MSSQL , dbcc checkdb сделал, ошибок не найдено
В кеше оптимизатора (в sys.dm_exec_sql_text и sys.dm_exec_query_plan) следов прямого удаления из СУБД через сутки после инцидента тоже не нашлось, впрочем кеш уже мог быть очищен...
Такое было замечено на одной базе дважды (как на скриншоте + еще раз повторилось).
В чём может быть причина и как избежать повторений?
Версия платформы 1С: 8.3.16.1148
Версия СУБД: Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)
Dec 28 2012 20:23:12
Copyright © Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
Хочу попросить содействия в расследовании следующего странного случая с пропажей данных из базы.
В ЖР есть запись о добавлении объекта, документ был распечатан (сохранилась бумажная версия), транзакция добавления зафиксирована, но сейчас объект в базе отсутствует, при этом записей об удалении в ЖР нет... (см скрин)
Такие случаи замечены в получасовом промежутке с 11:27 до 12:07 примерно по паре видов документов и по паре видов справочников, как в толстом клиенте, так и в фоновых заданиях, всего около 30 случаев
База на MSSQL , dbcc checkdb сделал, ошибок не найдено
В кеше оптимизатора (в sys.dm_exec_sql_text и sys.dm_exec_query_plan) следов прямого удаления из СУБД через сутки после инцидента тоже не нашлось, впрочем кеш уже мог быть очищен...
Такое было замечено на одной базе дважды (как на скриншоте + еще раз повторилось).
В чём может быть причина и как избежать повторений?
Версия платформы 1С: 8.3.16.1148
Версия СУБД: Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)
Dec 28 2012 20:23:12
Copyright © Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
Прикрепленные файлы:
По теме из базы знаний
- Подготовка отчетной формы статистики №11 (краткая) за 2013 год для государственных (муниципальных) учреждений
- Отчетная форма статистики №11 (краткая) за 2015 год с автозаполнением для БГУ 8
- Ошибки регламентированного отчета статистики «Форма №11 (краткая)» за 2017 год для БГУ 1.0 и их исправление
- Криптовалюты, а также иные взгляды на природу денег в терминах 1С
- Баг или фича? Неожиданное поведение платформы
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Да и сам ЖР можно почистить, к примеру:
сейчас объект в базе отсутствует, при этом записей об удалении в ЖР нет...
Точно не помню - программное (при помощи обработки) удаление объекта оставляет следы в журнале регистрации? По-моему, не оставляет.
Да и сам ЖР можно почистить, к примеру:
В чём может быть причина и как избежать повторений?
Причина, я думаю, в намеренных действиях кого-то из пользователей, а как избежать - проанализировать утраты и ответить на классический вопрос: "Cui prodest?"
(3)
"Cui prodest?"
Классная фраза, тоже об этом думал, но вроде никому это невыгодно... Но может плохо расследовал мотивы всех причастных... )
Да и сам ЖР можно почистить, к примеру:
По ссылке предлагает удаление записей из журнала формата SQLite , у нас же последовательный текстовый lgf
Точно не помню - программное (при помощи обработки) удаление объекта оставляет следы в журнале регистрации? По-моему, не оставляет.
Оставляет, в том то и дело
(1)
для начала посмотрите права пользователей на удаление помеченных на удаление объектов
отключите всем права на запуск внешних обработок
если они нужны - дайте одному (!!!) доверенному человеку
dbcc checkdb сделал, ошибок не найдено
не знаю, хороший ли это вариант - 1с сервер- еще тот фрукт
а журнал регистрации 1с посмотрите, на какие события настроен
еще есть журнал ОС и СУБД
может "вредина" оставил след
-------------------
так и в фоновых заданиях, всего около 30 случаев
подозреваю, что нужно узнать, что в последнее время "новенького" включили или "оптимизировали"
особенно по части "заказы и планирование"
документ был распечатан (сохранилась бумажная версия), транзакция добавления зафиксирована,
для начала посмотрите права пользователей на удаление помеченных на удаление объектов
отключите всем права на запуск внешних обработок
если они нужны - дайте одному (!!!) доверенному человеку
dbcc checkdb сделал, ошибок не найдено
не знаю, хороший ли это вариант - 1с сервер- еще тот фрукт
а журнал регистрации 1с посмотрите, на какие события настроен
еще есть журнал ОС и СУБД
может "вредина" оставил след
-------------------
так и в фоновых заданиях, всего около 30 случаев
подозреваю, что нужно узнать, что в последнее время "новенького" включили или "оптимизировали"
особенно по части "заказы и планирование"
(4)
Максимально полный сбор, да и это нет смысла смотреть, так как ЖР нет возможности настроить так, чтоб Добавление писалось, а Удаление - нет, т.е. если логируется одно, будет и второе
для начала посмотрите права пользователей на удаление помеченных на удаление объектов
отключите всем права на запуск внешних обработок
если они нужны - дайте одному (!!!) доверенному человеку
При удалении любым способом остаются записи в ЖР (кто, когда, вид клиента - дало бы дальнейшую пищу для размышлений), в нашем же случае их нет, в том и загадка
отключите всем права на запуск внешних обработок
если они нужны - дайте одному (!!!) доверенному человеку
а журнал регистрации 1с посмотрите, на какие события настроен
Максимально полный сбор, да и это нет смысла смотреть, так как ЖР нет возможности настроить так, чтоб Добавление писалось, а Удаление - нет, т.е. если логируется одно, будет и второе
подозреваю, что нужно узнать, что в последнее время "новенького" включили или "оптимизировали"
особенно по части "заказы и планирование"
Изменений не было, а если бы они были - всё равно: попробуйте удалить из базы любыми средствами 1С любой элемент справочника таким образом, чтоб это прошло мимо ЖР (при включенном логировании).
особенно по части "заказы и планирование"
(29)Лично я пока склоняюсь к тому, что базу "откатили" на бэкап средствами SQL - только в этом случае в ЖР не будет записи о удалении и объекта при этом реально может не быть в БД на момент проверки.
Сделать могли нечаянно.
Сделать могли нечаянно.
(1)
Документ что, только добавляли и все? Никаких изменений в нем не делали?
Запись с начала ноября, а вы только сейчас заметили? За это время уже много воды утекло.
Странно, но на вид, как будто транзакция, хоть и была зафиксирована, потом была отменена...
Как вариант, действительно, поискать в бэкапах момент, когда данные были и затем были удалены и попробовать отработать, регламентные задания для начала. Неизвестно, как у вас конфигурация поддерживается - есть ли доработки или только стандартный функционал. Также проверить настройки журнала регистрации
Документ что, только добавляли и все? Никаких изменений в нем не делали?
Запись с начала ноября, а вы только сейчас заметили? За это время уже много воды утекло.
Странно, но на вид, как будто транзакция, хоть и была зафиксирована, потом была отменена...
Как вариант, действительно, поискать в бэкапах момент, когда данные были и затем были удалены и попробовать отработать, регламентные задания для начала. Неизвестно, как у вас конфигурация поддерживается - есть ли доработки или только стандартный функционал. Также проверить настройки журнала регистрации
(17)
Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно
Документ что, только добавляли и все? Никаких изменений в нем не делали?
Всё верно, всё так. Только добавили, распечатали, через полчаса смотрят - уже нет
Запись с начала ноября, а вы только сейчас заметили? За это время уже много воды утекло.
Точно так... В ноябре был первый случай, в декабре второй, в других источниках ответ найти не удалось, вот решил здесь поинтересоваться, может кто-то сталкивался
Странно, но на вид, как будто транзакция, хоть и была зафиксирована, потом была отменена...
Вот именно... Но если написано Зафиксирована - значит зафиксирована, если Отменена - так и пишется ведь, значит всё же зафиксирована...
Как вариант, действительно, поискать в бэкапах момент...
К сожалению бекапов, где есть эти документы, не было создано изза модели восстановления SIMPLE (копия делается раз в сутки), скоро будем переводить на FULL, снизит возможный ущерб + возможно получим больше информации для расследования, если вдруг проблема повторится
Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно
Также проверить настройки журнала регистрации
Что именно проверить? Сейчас настроено так
я бы на последнее место поставил возможность исчезновения данных из MS SQL сервера. Кмк это лучшая поделка мелкософта.
Пожалуй, я бы начал с бэкапов. Восстановил бы на тот момент, когда объект в базе был, нашел бы его гуид в сиквеле, потом посмотрел бы, что сейчас с этим гуидом. Если его все же нет (в чем я очень сомневаюсь), попробовал бы поискать в промежуточных бэкапах момент исчезновения и вокруг этого момента рассмотрел бы журнал транзакций.
Пожалуй, я бы начал с бэкапов. Восстановил бы на тот момент, когда объект в базе был, нашел бы его гуид в сиквеле, потом посмотрел бы, что сейчас с этим гуидом. Если его все же нет (в чем я очень сомневаюсь), попробовал бы поискать в промежуточных бэкапах момент исчезновения и вокруг этого момента рассмотрел бы журнал транзакций.
Такие случаи замечены в получасовом промежутке с 11:27 до 12:07 примерно по паре видов документов и по паре видов справочников, как в толстом клиенте, так и в фоновых заданиях, всего около 30 случаев
по мне так это больше всего похоже на восстановление с бэкапа с потерей недавно созданных документов
(37)Если объект был создан и в ЖР есть информация об этом, то в случае, когда удалили объект и произошел рестарт сервиса 1С, информации об удалении объекта нет в ЖР - это, вроде как, возможно.
Чтобы подтвердить/опровергнуть данный факт, необходимо выполнить поиск в ЖР по представлению объекта. Запись о создании/изменении объекта должна быть в ЖР.
Чтобы подтвердить/опровергнуть данный факт, необходимо выполнить поиск в ЖР по представлению объекта. Запись о создании/изменении объекта должна быть в ЖР.
думаю все банально просто: "пользователь" "думая", что создал новый документ копированием отредактировал старый с полной заменой данных всех реквизитов. у самого такое на практике часто бывает, пришлось запустить историю по документам, после нескольких косяков "пользователь" уже не звонит с криками "куда вы дели мой документ".
p/s/ минус запуска истории документов БД начала пухнуть в разы
p/s/ минус запуска истории документов БД начала пухнуть в разы
М-да. Советов много, но кажется, что все они ушли в никуда - вслед за данными пропал и автор. Но не совсем бесследно - в ЖР Инфостарта запись о посещении осталась.
Причина? Возможно, нашел виновника пропажи данных... или виновник нашел его. ;-)
Пожелаем же ему удачи!
Причина? Возможно, нашел виновника пропажи данных... или виновник нашел его. ;-)
Пожелаем же ему удачи!
(27) Только дошли руки )
Виновник пока не найден, мысли следующие:
1. Такую картину в ЖР невозможно увидеть, удалив данные средствами 1С, поэтому версии про обмен и прочее не подходят...
2. Такую картину в ЖР можно увидеть, проделав действия напрямую в СУБД (например, развернуть архив, либо удалить данные скриптом сразу в SQL)
3. Есть вероятность, что в период сбоя был рестарт службы 1С, и если так: возможно это как-то повлияло на то, что данные таки были удалены средствами 1С, но из-за сбоя сервера запись об этом не дошла до ЖР.. Но не знаю, возможно ли это, воспроизвести такую ситуацию на тестовой базе мне не удалось
4. Из того, что планируем сделать:
а) обновить версию MSSQL на более свежую
б) перевести базу в режим восстановления FULL
Виновник пока не найден, мысли следующие:
1. Такую картину в ЖР невозможно увидеть, удалив данные средствами 1С, поэтому версии про обмен и прочее не подходят...
2. Такую картину в ЖР можно увидеть, проделав действия напрямую в СУБД (например, развернуть архив, либо удалить данные скриптом сразу в SQL)
3. Есть вероятность, что в период сбоя был рестарт службы 1С, и если так: возможно это как-то повлияло на то, что данные таки были удалены средствами 1С, но из-за сбоя сервера запись об этом не дошла до ЖР.. Но не знаю, возможно ли это, воспроизвести такую ситуацию на тестовой базе мне не удалось
4. Из того, что планируем сделать:
а) обновить версию MSSQL на более свежую
б) перевести базу в режим восстановления FULL
(44) Расскажу одну быль ... может наведет на мысль:
" В одном ресторане хозяйка стала обращать внимание что "выручка упала" ( чеки в то время как то не особо и били), а вот предчек в 1С оформляли по нему клиенты денег и отдавали официанту...Та вот ВСЕ просмотрели видно что был документ по ЖР, а нет его в системе ... ну нет и все... и так и сяк... пока запрос по документам не сделали ВСЕ а не за период с ... по ... !! и вышло что они предчеки делали дветысячидцатым годом ( дело лет 20 назад было еще на 77).." как то так
" В одном ресторане хозяйка стала обращать внимание что "выручка упала" ( чеки в то время как то не особо и били), а вот предчек в 1С оформляли по нему клиенты денег и отдавали официанту...Та вот ВСЕ просмотрели видно что был документ по ЖР, а нет его в системе ... ну нет и все... и так и сяк... пока запрос по документам не сделали ВСЕ а не за период с ... по ... !! и вышло что они предчеки делали дветысячидцатым годом ( дело лет 20 назад было еще на 77).." как то так
(1) ну, проверьте, остались ли от этого документа
1) данные в табличных частях
2)движения в регистрах накопления/бухгалтерии/регистра сведений
если остались, то запросто можно просто в табличке дока грохать рандомно записи и привет.
Проверить 1) в самом скуле 2)можно и в 1с-ине
1) данные в табличных частях
2)движения в регистрах накопления/бухгалтерии/регистра сведений
если остались, то запросто можно просто в табличке дока грохать рандомно записи и привет.
Проверить 1) в самом скуле 2)можно и в 1с-ине
(45)Нет такого определения, пока мы не увидим весь ЖР по этому номеру транзакции. Документ полтора часа редактировали, могло быть вообще все. Например пакетное формирование какое-то, которое создает документ и печатает его до завершения транзакции. Это может 8.2, а может и с 8.0 разрабатывают и чего там понаписали надо смотреть.
(61) Проверил, в этой транзакции запись только этого документа, ничего больше (99%, что пользователь просто интерактивно нажал на кнопку Записать в форме документа).
Короче, версию о том, что какая-то чехарда с НачатьТранзакцию() и ЗафиксироватьТранзакцию() можно смело отметать, была обычная интерактивная запись одного документа.
Спасибо за наводку, минус один подозреваемый!
Короче, версию о том, что какая-то чехарда с НачатьТранзакцию() и ЗафиксироватьТранзакцию() можно смело отметать, была обычная интерактивная запись одного документа.
Спасибо за наводку, минус один подозреваемый!
100% причина:
1. В 11:27 была открыта программная транзация (НачатьТранзакцию), которая не была закрыта (ЗафиксироватьТранзакцию или ОтменитьТранзакцию). Например, где-то в конфигурации что-то криво написали.
2. Пользователь продолжает честно работать: создает документы, распечатавает их и т.д.
3. В 12:07 программная транзация отменяется по таймауту. Всё, что делал пользователь - улетучивается, т.к. все его транзакции являются вложенными.
Ищете в конфигурации НачатьТранзакцию() без ЗафиксироватьТранзакцию()
1. В 11:27 была открыта программная транзация (НачатьТранзакцию), которая не была закрыта (ЗафиксироватьТранзакцию или ОтменитьТранзакцию). Например, где-то в конфигурации что-то криво написали.
2. Пользователь продолжает честно работать: создает документы, распечатавает их и т.д.
3. В 12:07 программная транзация отменяется по таймауту. Всё, что делал пользователь - улетучивается, т.к. все его транзакции являются вложенными.
Ищете в конфигурации НачатьТранзакцию() без ЗафиксироватьТранзакцию()
(50)
Был похожий случай в одной крупной IT-компании (называть не буду, всем она известна). Так вот, там пользователи жаловались: создают новые документы, проводят, распечатывают, видят эти документы в журналах. А через 20 минут эти документы из журналов исчезают, причем сразу и пачками. Бесследно. Как будто их никогда не существовало. У половины пользователей уже глаз дергался.
Оказалось, что какой-то горе-программист где-то в общем модуле написал код, который открывал транзакцию и не закрывал.
Был похожий случай в одной крупной IT-компании (называть не буду, всем она известна). Так вот, там пользователи жаловались: создают новые документы, проводят, распечатывают, видят эти документы в журналах. А через 20 минут эти документы из журналов исчезают, причем сразу и пачками. Бесследно. Как будто их никогда не существовало. У половины пользователей уже глаз дергался.
Оказалось, что какой-то горе-программист где-то в общем модуле написал код, который открывал транзакцию и не закрывал.
Попробую внести свои 5 копеек.
А что за конфигурация? По ходу обсуждения не нашел или упустил из вида. Есть ли в ней хитрые обработки типа Универсальный редактор реквизитов и им подобные? Есть такие - которые могут менять ГУИД дока, писать в обход ЖР. Но эти предположения на случай чьего-то злого умысла.
Во сколько рестарт сервера 1С происходил? - только ли 1С или MS SQL вместе с ним?
Были ли доработки базы перед тем, как доки начали пропадать?
А вообще, похоже на восстановление бекапа.
А что за конфигурация? По ходу обсуждения не нашел или упустил из вида. Есть ли в ней хитрые обработки типа Универсальный редактор реквизитов и им подобные? Есть такие - которые могут менять ГУИД дока, писать в обход ЖР. Но эти предположения на случай чьего-то злого умысла.
Во сколько рестарт сервера 1С происходил? - только ли 1С или MS SQL вместе с ним?
Были ли доработки базы перед тем, как доки начали пропадать?
А вообще, похоже на восстановление бекапа.
(53) УТ10.3
Хитрых обработок нет
Рестарт службы 1С во сколько происходил точно не скажу, но если был - то после 12:07
Доработок не было
Да, похоже на восстановление бекапа (либо другие работы напрямую в СУБД), но бекап точно не разворачивался (меня бы уже убили), ну и других следов не найдено
Хитрых обработок нет
Рестарт службы 1С во сколько происходил точно не скажу, но если был - то после 12:07
Доработок не было
Да, похоже на восстановление бекапа (либо другие работы напрямую в СУБД), но бекап точно не разворачивался (меня бы уже убили), ну и других следов не найдено
(56) достаточно (41) .. хоть запросом, хоть ручками удалить пару записей в самой табличке доков.
Но автор так и не проверил, есть ли данные этих удаленных доков в других объектах / табличных частях этого объекта.
Так будет сразу понятно - это удаление (данные есть )или oткaт транзакции/не зафиксированная транзакция(данных нема)
Но автор так и не проверил, есть ли данные этих удаленных доков в других объектах / табличных частях этого объекта.
Так будет сразу понятно - это удаление (данные есть )или oткaт транзакции/не зафиксированная транзакция(данных нема)
мы так базы чистим средствами SQL при переносе (переходе) - без следов
например: было 5 организаций - 4 удалить и все ссылки на них - остается 1
посмотрите, если какая то связь у ваших документов между собой: контрагент, ответственный..
например: было 5 организаций - 4 удалить и все ссылки на них - остается 1
посмотрите, если какая то связь у ваших документов между собой: контрагент, ответственный..
Во-первый, "Забытая транзакция" (50) объясняет всё:
А. Исчезли несколько элементов из разных справочников и несколько разных документов. Т.е. то, что пользователь успел создать. В следующий раз могут исчезнуть совсем другие справочники и документы.
Б. Автор пишет: "Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно". КАК РАЗ ВАЖНО. Напортачили с транзакциями.
В. В ЖР нужно искать следы от вызова НачатьТранзакцию() и момент отката этой транзакции.
Г. С SQL-сервером все в порядке. "Обновить версию MSSQL на более свежую" – не поможет.
Д. "Перевести базу в режим восстановления FULL" – не поможет в расследовании, т.к. учитываются только успешные транзакции (вложенные не в счет).
Е. "Рестарт службы 1С" – осталась бы запись в системном журнале.
Во-вторых, если у вас нет рациональной версии, то зачем раздувать тему заговора? Чтобы на словоблудии накрохоборить sm? Тогда ещё эти варианты не обсудили: происки конкурентов, русские хакеры, NSA, Петров и Боширов, инопланетяне, черная магия, потусторонние силы.
А. Исчезли несколько элементов из разных справочников и несколько разных документов. Т.е. то, что пользователь успел создать. В следующий раз могут исчезнуть совсем другие справочники и документы.
Б. Автор пишет: "Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно". КАК РАЗ ВАЖНО. Напортачили с транзакциями.
В. В ЖР нужно искать следы от вызова НачатьТранзакцию() и момент отката этой транзакции.
Г. С SQL-сервером все в порядке. "Обновить версию MSSQL на более свежую" – не поможет.
Д. "Перевести базу в режим восстановления FULL" – не поможет в расследовании, т.к. учитываются только успешные транзакции (вложенные не в счет).
Е. "Рестарт службы 1С" – осталась бы запись в системном журнале.
Во-вторых, если у вас нет рациональной версии, то зачем раздувать тему заговора? Чтобы на словоблудии накрохоборить sm? Тогда ещё эти варианты не обсудили: происки конкурентов, русские хакеры, NSA, Петров и Боширов, инопланетяне, черная магия, потусторонние силы.
(67) Спаси, Господи! Было желание получить адекватные комментарии, возможно у кого-то был похожий опыт
У Вас была такая ситуация? Без вмешательства на уровне СУБД можете смоделировать такой кейс, как на картинке? Если да - подскажете способ? Если нет - за что раздавать?
У Вас была такая ситуация? Без вмешательства на уровне СУБД можете смоделировать такой кейс, как на картинке? Если да - подскажете способ? Если нет - за что раздавать?
(73)
не нашлось подходящих...
смоделировать такой кейс ?
например,
такая же конфигурация 1с,
такие же кривые настройки,
так же установить журналы отслеживания, чтобы ничего не увидеть ?
и да, еще нужен человек с правами перезапуска служб, когда ему захотелось.
думаю у меня не получится.
но вы хоть для приличия раздайте старты,
а то ведь результат на лицо - все ничего не понимают так, как вы хотите :)
Было желание получить адекватные комментарии
не нашлось подходящих...
смоделировать такой кейс ?
например,
такая же конфигурация 1с,
такие же кривые настройки,
так же установить журналы отслеживания, чтобы ничего не увидеть ?
и да, еще нужен человек с правами перезапуска служб, когда ему захотелось.
думаю у меня не получится.
но вы хоть для приличия раздайте старты,
а то ведь результат на лицо - все ничего не понимают так, как вы хотите :)
Строим гипотезы ))
1) проверить жесткий диск, может он уже старый (что за тип дисков)
2) незавершенная транзакция откатилась (это именно 1с, модификация сразу нескольких объектов, т.к. в ms sql транзакции другие)
3) моргнул свет, электричество
4) на базу сверху записали другую версию базы т.е. копию
5) на ms sql можно записи удалять, можно модифицировать (менять значение поля) и ссылка будет уже битая
6) шринк лога ms sql
7) если не секретно, выложить сf-файл
8) если есть бэкапы базы, можно восстанавливать на разные моменты времени "назад" и смотреть в какой момент запись исчезает
т.е. с параметром STOPAT = N'11.09.2021 12:25:05'
9) посмотреть журнал регистрации1с
10) технологический журнал 1с был настроен? если нет, можно прямо сейчас настроить и ждать новых событий...
11) кто в организации имеет права доступа к серверам баз данных, серверу 1с ? политика безопасности windows
12) какие "странные" программы установлены на серверах?
Для расследования удобно взять конкретный документ и для него вести расследование.
1) проверить жесткий диск, может он уже старый (что за тип дисков)
2) незавершенная транзакция откатилась (это именно 1с, модификация сразу нескольких объектов, т.к. в ms sql транзакции другие)
3) моргнул свет, электричество
4) на базу сверху записали другую версию базы т.е. копию
5) на ms sql можно записи удалять, можно модифицировать (менять значение поля) и ссылка будет уже битая
6) шринк лога ms sql
7) если не секретно, выложить сf-файл
8) если есть бэкапы базы, можно восстанавливать на разные моменты времени "назад" и смотреть в какой момент запись исчезает
т.е. с параметром STOPAT = N'11.09.2021 12:25:05'
9) посмотреть журнал регистрации1с
10) технологический журнал 1с был настроен? если нет, можно прямо сейчас настроить и ждать новых событий...
11) кто в организации имеет права доступа к серверам баз данных, серверу 1с ? политика безопасности windows
12) какие "странные" программы установлены на серверах?
Для расследования удобно взять конкретный документ и для него вести расследование.
(62) Спасибо за комментарий
1. Думал об этом, но на нашем опыте, повреждения ЖД дают повреждения базы SQL, которые видно через checkdb
2. В этом случае будет статус транзакции Отменена
3. Сервер не выключался, но скорей всего был рестарт службы сервера 1С
4. Копию не раскрывали
5. Верно, но вроде не было такого, на 100% к сожалению сказать уже нельзя
6. Шринк журнала транзакций MSSQL? Разве это может повлечь потерю данных?
7. Боюсь, компания этого не одобрит, а что именно хотите проверить? В личке могу отправить наверное, но должен согласовать..
8. К сожалению, на тот момент база была в SIMPLE, уже перевели модель восстановления на FULL на случай если повторится
9. Журнал регистрации 1С на приложенном в топике фото... Или посмотреть на предмет чего?
10. К сожалению, нет. А на какие события настроить предлагаете?
11. Только те кто должен иметь такой доступ, вроде бы ни у кого мотивов химичить там нет
12. Никаких, насколько я знаю
1. Думал об этом, но на нашем опыте, повреждения ЖД дают повреждения базы SQL, которые видно через checkdb
2. В этом случае будет статус транзакции Отменена
3. Сервер не выключался, но скорей всего был рестарт службы сервера 1С
4. Копию не раскрывали
5. Верно, но вроде не было такого, на 100% к сожалению сказать уже нельзя
6. Шринк журнала транзакций MSSQL? Разве это может повлечь потерю данных?
7. Боюсь, компания этого не одобрит, а что именно хотите проверить? В личке могу отправить наверное, но должен согласовать..
8. К сожалению, на тот момент база была в SIMPLE, уже перевели модель восстановления на FULL на случай если повторится
9. Журнал регистрации 1С на приложенном в топике фото... Или посмотреть на предмет чего?
10. К сожалению, нет. А на какие события настроить предлагаете?
11. Только те кто должен иметь такой доступ, вроде бы ни у кого мотивов химичить там нет
12. Никаких, насколько я знаю
Было похожее. Клиенты переносили базу, для чего делали копию базы (как мне рассказывали их Ит-отдел) средствами скуля, но забыли отключить пользователей - те создавали документы. Потом пользаков отключили, старую базу удалили, создали новую, загрузили в нее данные. И получилось, что документов в базе нет (которые создавали пока копия делалась), а записи в журнале о них остались.
Была подобная ситуация, срочно потребовалась копия базы, сделали в рабочее время средствами MS SQL, без отключения пользователей. В результате были созданы и распечатаны документы. Спустя час после резервирования базы не смогли найти их в базе, записи в ЖР остались, что пользователь делал документы, но "объект не найден". Была сделана только полная копия, восстановление ее производилось в другую базу. Документы пропали в рабочей базе. В копии их тоже не было.
(77) Разумом и логикой допустить такое не могу. Но факт, остается фактом, делали полную копию именно в рабочее время, с порядка 30 пользователями в сети. И по итогу получили от бухгалтерии вот такой привет, пропал документ. Думаю что стечение обстоятельств и что-то еще, мы не стали углубляться в изучение проблемы и не анализировали журналы MS SQL.
Мне это видется следующим образом, для полного резервирования базы произошла "некая блокировка" базы (для обеспечения целостности данных в выгружаемую копию), все действия пользователей происходившие в этот момент, формировали некий набор транзакций, которые должны будут дополнить базу после ее "разблокировки", но что-то пошло не так и это не произошло (переполнение журнала\буфера\сбой) и транзакции были "сброшены".
В базе на тот момент половина пользователей это бухгалтерия с документами, вторая половина вносит изменения в существующие объекты. Т.е. только ~15 человек занимались документами, под удар попало два пользователя, создавшие в тот момент по документу. Именно этих двух документов и не досчитались.
Мне это видется следующим образом, для полного резервирования базы произошла "некая блокировка" базы (для обеспечения целостности данных в выгружаемую копию), все действия пользователей происходившие в этот момент, формировали некий набор транзакций, которые должны будут дополнить базу после ее "разблокировки", но что-то пошло не так и это не произошло (переполнение журнала\буфера\сбой) и транзакции были "сброшены".
В базе на тот момент половина пользователей это бухгалтерия с документами, вторая половина вносит изменения в существующие объекты. Т.е. только ~15 человек занимались документами, под удар попало два пользователя, создавшие в тот момент по документу. Именно этих двух документов и не досчитались.
(78) Полная копия (да и неполная тоже) делается на некоторый момент времени, все изменения вносимые пользователями, после этого момента в копию не попадут (но и в рабочей базе исчезнуть не должны).
(77) Не уверен, что транзакции SQL равны транзакциям в 1С, это больше к вопросу откатиться на любую секунду. Да и термин "откатиться" тут наводит на некоторые мысли. Зачем рабочую базу восстанавливать из бэкапа, если только она не разбита вследствие сбоя и не чинится. Накосячили бухи, пусть расхлебывают))
(77) Не уверен, что транзакции SQL равны транзакциям в 1С, это больше к вопросу откатиться на любую секунду. Да и термин "откатиться" тут наводит на некоторые мысли. Зачем рабочую базу восстанавливать из бэкапа, если только она не разбита вследствие сбоя и не чинится. Накосячили бухи, пусть расхлебывают))
(80) Я имел в виду, что транзакции формируемые в период "выгрузки базы" должны примениться к рабочей базе, после ее "разблокировки". То что копия не будет содержать эти данные, это и так я думаю всем ясно. Заковырка в том, почему эти данные не применились, а пропали.
Документ распечатать можно в любом месте и поэтому не является доказательством работы в базе. В этом случае все манипуляции с ЖР бессмысленны. Искать кошку в темной комнате, когда её там нет можно до бесконечности.
Если под этим номером другие данные, то самое очевидное только одно. Распечатали документ, изменили и провели. Ищи сколько хочешь. Это из личной практики.
Если под этим номером другие данные, то самое очевидное только одно. Распечатали документ, изменили и провели. Ищи сколько хочешь. Это из личной практики.
(88)
1. Битых ссылок в таблице ТЧ ЗаказПоставщику.Товары нет
2. Документ не проводился, а только был записан, движений и не было
Но версия о том, что кто-то на уровне СУБД удалил записи, в целом подходит под симптомы, собственно об этом предполагается в топике с пометкой, что следов прямого удаления не найдено...
1. Битых ссылок в таблице ТЧ ЗаказПоставщику.Товары нет
2. Документ не проводился, а только был записан, движений и не было
Но версия о том, что кто-то на уровне СУБД удалил записи, в целом подходит под симптомы, собственно об этом предполагается в топике с пометкой, что следов прямого удаления не найдено...
(90)
Не забывайте транзакции в 1с это не транзакции скуля. Есть вероятность коммита транзакции в 1С, но отсутствия транзакции в SQL, как пример из-за падения службы. Я думаю если бы удаляли в скуле, вы бы нашли следы в кеше SQL. При том возможно удалось напечатать, так как объект есть и оптимизатор 1С прочитал из текущего объекта, но из-за сбоя коммита в базе нет.
Если бы был включен тех. журнал, вы бы смогли отловить отсутствие коммита в SQL.
Не забывайте транзакции в 1с это не транзакции скуля. Есть вероятность коммита транзакции в 1С, но отсутствия транзакции в SQL, как пример из-за падения службы. Я думаю если бы удаляли в скуле, вы бы нашли следы в кеше SQL. При том возможно удалось напечатать, так как объект есть и оптимизатор 1С прочитал из текущего объекта, но из-за сбоя коммита в базе нет.
Если бы был включен тех. журнал, вы бы смогли отловить отсутствие коммита в SQL.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот