Форум Администрирование Производительность и оптимизация (HighLoad)

Пропажа данных без следов

Платформа 1С v8.3 MS SQL

1. METAL 289 25.01.22 21:12 Сейчас в теме

Здравствуйте, уважаемые коллеги!

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

В ЖР есть запись о добавлении объекта, документ был распечатан (сохранилась бумажная версия), транзакция добавления зафиксирована, но сейчас объект в базе отсутствует, при этом записей об удалении в ЖР нет... (см скрин)

Такие случаи замечены в получасовом промежутке с 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)

Прикрепленные файлы:

По теме из базы знаний

Вознаграждение за ответ

Сумма: 4 $m

Добавили:
METAL (5.00 $m)

Получили:

gybson (1 $m)

Показать полностью

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

3. ishelper 25.01.22 21:37 Сейчас в теме

(1)

сейчас объект в базе отсутствует, при этом записей об удалении в ЖР нет...

Точно не помню - программное (при помощи обработки) удаление объекта оставляет следы в журнале регистрации? По-моему, не оставляет.

Да и сам ЖР можно почистить, к примеру: https://infostart.ru/public/1117959/

В чём может быть причина и как избежать повторений?

Причина, я думаю, в намеренных действиях кого-то из пользователей, а как избежать - проанализировать утраты и ответить на классический вопрос: "Cui prodest?"

28. METAL 289 26.01.22 23:03 Сейчас в теме

(3)

"Cui prodest?"

Классная фраза, тоже об этом думал, но вроде никому это невыгодно... Но может плохо расследовал мотивы всех причастных... )

Да и сам ЖР можно почистить, к примеру: https://infostart.ru/public/1117959/

По ссылке предлагает удаление записей из журнала формата SQLite , у нас же последовательный текстовый lgf

Точно не помню - программное (при помощи обработки) удаление объекта оставляет следы в журнале регистрации? По-моему, не оставляет.

Оставляет, в том то и дело

4. XAKEP 25.01.22 21:56 Сейчас в теме

(1)

документ был распечатан (сохранилась бумажная версия), транзакция добавления зафиксирована,

для начала посмотрите права пользователей на удаление помеченных на удаление объектов
отключите всем права на запуск внешних обработок
если они нужны - дайте одному (!!!) доверенному человеку

dbcc checkdb сделал, ошибок не найдено
не знаю, хороший ли это вариант - 1с сервер- еще тот фрукт

а журнал регистрации 1с посмотрите, на какие события настроен

еще есть журнал ОС и СУБД
может "вредина" оставил след

-------------------
так и в фоновых заданиях, всего около 30 случаев

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

29. METAL 289 26.01.22 23:14 Сейчас в теме

(4)

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

а журнал регистрации 1с посмотрите, на какие события настроен

Максимально полный сбор, да и это нет смысла смотреть, так как ЖР нет возможности настроить так, чтоб Добавление писалось, а Удаление - нет, т.е. если логируется одно, будет и второе

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

Изменений не было, а если бы они были - всё равно: попробуйте удалить из базы любыми средствами 1С любой элемент справочника таким образом, чтоб это прошло мимо ЖР (при включенном логировании).

30. nomad_irk 72 26.01.22 23:31 Сейчас в теме

(29)Лично я пока склоняюсь к тому, что базу "откатили" на бэкап средствами SQL - только в этом случае в ЖР не будет записи о удалении и объекта при этом реально может не быть в БД на момент проверки.
Сделать могли нечаянно.

Ответить

39. METAL 289 26.01.22 23:57 Сейчас в теме

(30) Технически, да, подходит, но см. (37)

17. qazaas 26.01.22 07:48 Сейчас в теме

(1)
Документ что, только добавляли и все? Никаких изменений в нем не делали?
Запись с начала ноября, а вы только сейчас заметили? За это время уже много воды утекло.
Странно, но на вид, как будто транзакция, хоть и была зафиксирована, потом была отменена...
Как вариант, действительно, поискать в бэкапах момент, когда данные были и затем были удалены и попробовать отработать, регламентные задания для начала. Неизвестно, как у вас конфигурация поддерживается - есть ли доработки или только стандартный функционал. Также проверить настройки журнала регистрации

31. METAL 289 26.01.22 23:33 Сейчас в теме

(17)

Документ что, только добавляли и все? Никаких изменений в нем не делали?

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

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

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

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

Вот именно... Но если написано Зафиксирована - значит зафиксирована, если Отменена - так и пишется ведь, значит всё же зафиксирована...

Как вариант, действительно, поискать в бэкапах момент...

К сожалению бекапов, где есть эти документы, не было создано изза модели восстановления SIMPLE (копия делается раз в сутки), скоро будем переводить на FULL, снизит возможный ущерб + возможно получим больше информации для расследования, если вдруг проблема повторится

Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно

Также проверить настройки журнала регистрации

Что именно проверить? Сейчас настроено так https://prnt.sc/26js4hx

2. a30v 25.01.22 21:30 Сейчас в теме

(1) В таблице документа в MS SQL не смотрели есть ли документ с таким номером и датой? Номер присвоен другому документу? Движения документа какие-то остались?

32. METAL 289 26.01.22 23:35 Сейчас в теме

(2) Документа с такими данными нет, в нумерации пропуск, движений не было (документ не проводили, только записали)

5. XAKEP 25.01.22 22:05 Сейчас в теме

и да, я проверил бы диски -- об этом забывают или думают, что они "долгоиграющие без поломки"

33. METAL 289 26.01.22 23:36 Сейчас в теме

(5) В случае проблем с дисками, checkdb как правило показывает ошибки... Был у нас инцидент (постоянно приходилось проверять/исправлять одну базу "with allow data loss", пока не поменяли железо)

6. starjevschik 25.01.22 22:10 Сейчас в теме

я бы на последнее место поставил возможность исчезновения данных из MS SQL сервера. Кмк это лучшая поделка мелкософта.
Пожалуй, я бы начал с бэкапов. Восстановил бы на тот момент, когда объект в базе был, нашел бы его гуид в сиквеле, потом посмотрел бы, что сейчас с этим гуидом. Если его все же нет (в чем я очень сомневаюсь), попробовал бы поискать в промежуточных бэкапах момент исчезновения и вокруг этого момента рассмотрел бы журнал транзакций.

34. METAL 289 26.01.22 23:38 Сейчас в теме

(6) К сожалению, подходящих бекапов не было, а на будущее - на этом варианте и остановились по большому счёту

7. Online-Ufa 25.01.22 22:53 Сейчас в теме

Человек, который надумал удалить документ из базы, возможно уже слышал про "Журнал регистраций" и ему могло хватить ума загуглить, как удалить соответствующие записи из ЖР.

14. nomad_irk 72 26.01.22 07:15 Сейчас в теме

(7)Это очень геморрно и требует определенных навыков и возможностей.

8. Akuji 22 25.01.22 23:11 Сейчас в теме

А обмен есть? если удалили в одной базе, то во второй базе будет такая история как в шапке...
Можно посмотреть ЖР в первой базе...

35. METAL 289 26.01.22 23:38 Сейчас в теме

(8) Обмена нет, и если удалено через обмен - будет запись в ЖР об удалении

9. muskul 26.01.22 01:33 Сейчас в теме

проведите эксперемент. создайте заказ, пометьте, удалите програмно/через рег задание/интерактивно (может там вообще непосредственное удаление включено

36. METAL 289 26.01.22 23:39 Сейчас в теме

(9) Даже если разрешено непосредственное удаление - будет запись в ЖР об удалении (как ни удаляй средствами 1С - запись есть в ЖР)

10. Oldsad 26.01.22 01:59 Сейчас в теме

Такие случаи замечены в получасовом промежутке с 11:27 до 12:07 примерно по паре видов документов и по паре видов справочников, как в толстом клиенте, так и в фоновых заданиях, всего около 30 случаев

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

37. METAL 289 26.01.22 23:43 Сейчас в теме

(10) Действительно, если развернуть бекап (или удалить на уровне 1С) - будет похожая картина, но середина дня, база 400ГБ, 120 пользователей, никаких восстановлений не было.. Но был рестарт службы 1С

40. nomad_irk 72 27.01.22 00:13 Сейчас в теме

(37)Если объект был создан и в ЖР есть информация об этом, то в случае, когда удалили объект и произошел рестарт сервиса 1С, информации об удалении объекта нет в ЖР - это, вроде как, возможно.

Чтобы подтвердить/опровергнуть данный факт, необходимо выполнить поиск в ЖР по представлению объекта. Запись о создании/изменении объекта должна быть в ЖР.

54. Vladimir-R 167 28.01.22 10:22 Сейчас в теме

(37) не полный бэкап, а бэкап транзакций по времени, как вариант

11. user1203706 13 26.01.22 02:12 Сейчас в теме

(1) обработкой можно грохнуть жешь или обменом.
База обменивается с кем-то ?

13. nomad_irk 72 26.01.22 07:14 Сейчас в теме

(11)что обработка, что обмен оставляют следы в ЖР.

12. Aitbay 26.01.22 06:13 Сейчас в теме

думаю все банально просто: "пользователь" "думая", что создал новый документ копированием отредактировал старый с полной заменой данных всех реквизитов. у самого такое на практике часто бывает, пришлось запустить историю по документам, после нескольких косяков "пользователь" уже не звонит с криками "куда вы дели мой документ".
p/s/ минус запуска истории документов БД начала пухнуть в разы

15. namazi74 4 26.01.22 07:18 Сейчас в теме

(12)

разве по ЖР это не видно? по объекту метаданных

16. Online-Ufa 26.01.22 07:40 Сейчас в теме

(15) В ЖР видно, что документ был изменен, но не видно, какие именно изменения при этом были сделаны пользователем.

18. ДмитрийС 26.01.22 07:55 Сейчас в теме

(16) Если изменена дата или номер документа, то будут отличия в ячейках Данные и Представление данных.

19. namazi74 4 26.01.22 08:22 Сейчас в теме

(16)

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

верно, но записи то остаются. у ТС вообще объекта нет

20. Andrekaa 26.01.22 08:46 Сейчас в теме

У кого то есть интерактивное удаление и чел просто не понимает что он документ не помечает в программе а просто грохает

21. nomad_irk 72 26.01.22 08:49 Сейчас в теме

(20)при этом есть отметка в ЖР об удалении объекта

22. user1203706 13 26.01.22 09:12 Сейчас в теме

(1) версионирование, или история данных включена для данного объекта ? Что там есть ? Кто хоть последний был..

23. Andrekaa 26.01.22 09:55 Сейчас в теме

а все таки
"а журнал регистрации 1с посмотрите, на какие события настроен"

24. glek 119 26.01.22 10:07 Сейчас в теме

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

25. metodeus 26.01.22 13:22 Сейчас в теме

Проверьте синхронизацию с другими базами/сайтами и прочими внешними ресурсами. При двухстороннем обмене такая ситуация вполне возможна. Если удалить / изменить документ в базе корреспонденте.

26. nomad_irk 72 26.01.22 18:08 Сейчас в теме

(25)при любом обмене запись о добавлении изменении/удалении объектов фиксируется в ЖР.

Чтобы очистить ЖР - нужны определенные навыки и возможности.

27. ishelper 26.01.22 18:39 Сейчас в теме

М-да. Советов много, но кажется, что все они ушли в никуда - вслед за данными пропал и автор. Но не совсем бесследно - в ЖР Инфостарта запись о посещении осталась.

Причина? Возможно, нашел виновника пропажи данных... или виновник нашел его. ;-)

Пожелаем же ему удачи!

38. METAL 289 26.01.22 23:54 Сейчас в теме

(27) Только дошли руки )

Виновник пока не найден, мысли следующие:
1. Такую картину в ЖР невозможно увидеть, удалив данные средствами 1С, поэтому версии про обмен и прочее не подходят...
2. Такую картину в ЖР можно увидеть, проделав действия напрямую в СУБД (например, развернуть архив, либо удалить данные скриптом сразу в SQL)
3. Есть вероятность, что в период сбоя был рестарт службы 1С, и если так: возможно это как-то повлияло на то, что данные таки были удалены средствами 1С, но из-за сбоя сервера запись об этом не дошла до ЖР.. Но не знаю, возможно ли это, воспроизвести такую ситуацию на тестовой базе мне не удалось
4. Из того, что планируем сделать:
а) обновить версию MSSQL на более свежую
б) перевести базу в режим восстановления FULL

42. Torin 744 27.01.22 22:56 Сейчас в теме

(38) ЖР легко удаляется если :) если удалить кэш сервера 1С :) в папке reg_1541

44. METAL 289 27.01.22 23:43 Сейчас в теме

(42) Совершенно верно, но как это поможет в решении проблемы? В нашем случае ЖР на месте, из каталога службы сервера его никто не удалял

47. Torin 744 27.01.22 23:52 Сейчас в теме

(44) Расскажу одну быль ... может наведет на мысль:
" В одном ресторане хозяйка стала обращать внимание что "выручка упала" ( чеки в то время как то не особо и били), а вот предчек в 1С оформляли по нему клиенты денег и отдавали официанту...Та вот ВСЕ просмотрели видно что был документ по ЖР, а нет его в системе ... ну нет и все... и так и сяк... пока запрос по документам не сделали ВСЕ а не за период с ... по ... !! и вышло что они предчеки делали дветысячидцатым годом ( дело лет 20 назад было еще на 77).." как то так

94. minarenko 17.02.22 14:31 Сейчас в теме

(44) у вас журнал не делится по дням, месяцам? Может файл журнала с периодом когда удаляли объект удалили?

95. METAL 289 02.10.23 17:28 Сейчас в теме

(94) Файлы разделяются по дням, и файлы на месте... Но кстати проблема ушла... Не знаю в какой момент, но давно жалоб не было

41. user1203706 13 27.01.22 20:53 Сейчас в теме

(1) ну, проверьте, остались ли от этого документа
1) данные в табличных частях
2)движения в регистрах накопления/бухгалтерии/регистра сведений

если остались, то запросто можно просто в табличке дока грохать рандомно записи и привет.
Проверить 1) в самом скуле 2)можно и в 1с-ине

43. gybson 27.01.22 23:40 Сейчас в теме

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

45. METAL 289 27.01.22 23:45 Сейчас в теме

(43) Транзакция добавления зафиксирована = запись объекта произошла. По определению

46. gybson 27.01.22 23:49 Сейчас в теме

(45)Нет такого определения, пока мы не увидим весь ЖР по этому номеру транзакции. Документ полтора часа редактировали, могло быть вообще все. Например пакетное формирование какое-то, которое создает документ и печатает его до завершения транзакции. Это может 8.2, а может и с 8.0 разрабатывают и чего там понаписали надо смотреть.

48. METAL 289 28.01.22 00:27 Сейчас в теме

(46) Забудьте про бумажку, важно что в ЖР есть запись. Если "зафиксирована" - значит зафиксирована вся, и неважно один там документ, или 1000. Если зафиксирована - значит документ в базу был добавлен.

61. gybson 30.01.22 17:48 Сейчас в теме +1 $m

(48)главный посыл в том, чтобы посмотреть всё, что происходило в этой транзакции

84. METAL 289 05.02.22 04:09 Сейчас в теме

(61) Проверил, в этой транзакции запись только этого документа, ничего больше (99%, что пользователь просто интерактивно нажал на кнопку Записать в форме документа).

Короче, версию о том, что какая-то чехарда с НачатьТранзакцию() и ЗафиксироватьТранзакцию() можно смело отметать, была обычная интерактивная запись одного документа.

Спасибо за наводку, минус один подозреваемый!

86. ishelper 05.02.22 11:10 Сейчас в теме

(84)

минус один подозреваемый!

Осталось еще 4? ;-)

87. METAL 289 12.02.22 21:26 Сейчас в теме

(86) Которые?

89. ishelper 12.02.22 21:34 Сейчас в теме

(87)

Которые?

Откуда мне знать? Я просто считаю стартмани - 1 выдан, 4 осталось. :-)

49. muskul 28.01.22 04:03 Сейчас в теме

Это фигня. Мы тут динамически добавили для одной из ролей право на самописный документ и он вообще пропал

50. sivin-alexey 507 28.01.22 09:10 Сейчас в теме

100% причина:

1. В 11:27 была открыта программная транзация (НачатьТранзакцию), которая не была закрыта (ЗафиксироватьТранзакцию или ОтменитьТранзакцию). Например, где-то в конфигурации что-то криво написали.

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

3. В 12:07 программная транзация отменяется по таймауту. Всё, что делал пользователь - улетучивается, т.к. все его транзакции являются вложенными.

Ищете в конфигурации НачатьТранзакцию() без ЗафиксироватьТранзакцию()

51. sivin-alexey 507 28.01.22 09:46 Сейчас в теме

(50)
Был похожий случай в одной крупной IT-компании (называть не буду, всем она известна). Так вот, там пользователи жаловались: создают новые документы, проводят, распечатывают, видят эти документы в журналах. А через 20 минут эти документы из журналов исчезают, причем сразу и пачками. Бесследно. Как будто их никогда не существовало. У половины пользователей уже глаз дергался.

Оказалось, что какой-то горе-программист где-то в общем модуле написал код, который открывал транзакцию и не закрывал.

63. пользователь 31.01.22 16:43

Сообщение было скрыто модератором.

...

66. пользователь 02.02.22 16:22

Сообщение было скрыто модератором.

...

69. METAL 289 03.02.22 19:31 Сейчас в теме

(50) Дык в ЖР тогда будет статус транзакции - Отменена!

52. VmvLer 28.01.22 10:02 Сейчас в теме

(51) как правило, в подобных темах, с 50-го сообщения, наконец, очевидное становиться вероятным.

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

53. TormDV 28.01.22 10:03 Сейчас в теме

Попробую внести свои 5 копеек.
А что за конфигурация? По ходу обсуждения не нашел или упустил из вида. Есть ли в ней хитрые обработки типа Универсальный редактор реквизитов и им подобные? Есть такие - которые могут менять ГУИД дока, писать в обход ЖР. Но эти предположения на случай чьего-то злого умысла.
Во сколько рестарт сервера 1С происходил? - только ли 1С или MS SQL вместе с ним?
Были ли доработки базы перед тем, как доки начали пропадать?
А вообще, похоже на восстановление бекапа.

55. sivin-alexey 507 28.01.22 10:30 Сейчас в теме

(53) Мы в детстве тоже пугали друг друга "красной" пленкой. И сами в это верили. А вы сами верите, что "есть такие - которые могут менять ГУИД дока, писать в обход ЖР"?

56. nomad_irk 72 28.01.22 10:43 Сейчас в теме

(55)Прямыми запросами - вполне.

70. METAL 289 03.02.22 19:35 Сейчас в теме

(53) УТ10.3
Хитрых обработок нет
Рестарт службы 1С во сколько происходил точно не скажу, но если был - то после 12:07
Доработок не было
Да, похоже на восстановление бекапа (либо другие работы напрямую в СУБД), но бекап точно не разворачивался (меня бы уже убили), ну и других следов не найдено

57. user1203706 13 28.01.22 11:02 Сейчас в теме

(56) достаточно (41) .. хоть запросом, хоть ручками удалить пару записей в самой табличке доков.

Но автор так и не проверил, есть ли данные этих удаленных доков в других объектах / табличных частях этого объекта.

Так будет сразу понятно - это удаление (данные есть )или oткaт транзакции/не зафиксированная транзакция(данных нема)

58. WasiliyMay 8 28.01.22 14:34 Сейчас в теме

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

71. METAL 289 03.02.22 19:36 Сейчас в теме

(58) Распечатать можно и непроведённый документ

83. WasiliyMay 8 04.02.22 11:08 Сейчас в теме

(71)Распечатать то можно, но формирование печатной формы по непроведенному документу очень редкий случай, по этому предположил, что документ был проведен.

59. Silent64 28.01.22 21:23 Сейчас в теме

мы так базы чистим средствами SQL при переносе (переходе) - без следов
например: было 5 организаций - 4 удалить и все ссылки на них - остается 1

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

60. sivin-alexey 507 30.01.22 06:15 Сейчас в теме

Во-первый, "Забытая транзакция" (50) объясняет всё:

А. Исчезли несколько элементов из разных справочников и несколько разных документов. Т.е. то, что пользователь успел создать. В следующий раз могут исчезнуть совсем другие справочники и документы.

Б. Автор пишет: "Конфигурация доработанная, но, на мой взгляд, в данном контексте это неважно". КАК РАЗ ВАЖНО. Напортачили с транзакциями.

В. В ЖР нужно искать следы от вызова НачатьТранзакцию() и момент отката этой транзакции.

Г. С SQL-сервером все в порядке. "Обновить версию MSSQL на более свежую" – не поможет.

Д. "Перевести базу в режим восстановления FULL" – не поможет в расследовании, т.к. учитываются только успешные транзакции (вложенные не в счет).

Е. "Рестарт службы 1С" – осталась бы запись в системном журнале.

Во-вторых, если у вас нет рациональной версии, то зачем раздувать тему заговора? Чтобы на словоблудии накрохоборить sm? Тогда ещё эти варианты не обсудили: происки конкурентов, русские хакеры, NSA, Петров и Боширов, инопланетяне, черная магия, потусторонние силы.

Ответить

67. XAKEP 02.02.22 17:42 Сейчас в теме

(60)

магия

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

73. METAL 289 03.02.22 19:46 Сейчас в теме

(67) Спаси, Господи! Было желание получить адекватные комментарии, возможно у кого-то был похожий опыт
У Вас была такая ситуация? Без вмешательства на уровне СУБД можете смоделировать такой кейс, как на картинке? Если да - подскажете способ? Если нет - за что раздавать?

79. XAKEP 04.02.22 08:20 Сейчас в теме

(73)

Было желание получить адекватные комментарии

не нашлось подходящих...

смоделировать такой кейс ?
например,
такая же конфигурация 1с,
такие же кривые настройки,
так же установить журналы отслеживания, чтобы ничего не увидеть ?

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

думаю у меня не получится.

но вы хоть для приличия раздайте старты,
а то ведь результат на лицо - все ничего не понимают так, как вы хотите :)

72. METAL 289 03.02.22 19:38 Сейчас в теме

(60) Всё бы хорошо, только отменённая транзакция добавления будет иметь в ЖР статус "Отменена" ¯\_(ツ)_/¯

62. user-z99999 67 31.01.22 11:31 Сейчас в теме

Строим гипотезы ))
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) какие "странные" программы установлены на серверах?
Для расследования удобно взять конкретный документ и для него вести расследование.

74. METAL 289 03.02.22 19:58 Сейчас в теме

(62) Спасибо за комментарий
1. Думал об этом, но на нашем опыте, повреждения ЖД дают повреждения базы SQL, которые видно через checkdb
2. В этом случае будет статус транзакции Отменена
3. Сервер не выключался, но скорей всего был рестарт службы сервера 1С
4. Копию не раскрывали
5. Верно, но вроде не было такого, на 100% к сожалению сказать уже нельзя
6. Шринк журнала транзакций MSSQL? Разве это может повлечь потерю данных?
7. Боюсь, компания этого не одобрит, а что именно хотите проверить? В личке могу отправить наверное, но должен согласовать..
8. К сожалению, на тот момент база была в SIMPLE, уже перевели модель восстановления на FULL на случай если повторится
9. Журнал регистрации 1С на приложенном в топике фото... Или посмотреть на предмет чего?
10. К сожалению, нет. А на какие события настроить предлагаете?
11. Только те кто должен иметь такой доступ, вроде бы ни у кого мотивов химичить там нет
12. Никаких, насколько я знаю

64. user824140 01.02.22 17:29 Сейчас в теме

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

75. METAL 289 03.02.22 19:59 Сейчас в теме

(64) Вероятный сценарий, согласен, но копию не разворачивали...

65. user1472622 01.02.22 19:32 Сейчас в теме

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

76. METAL 289 03.02.22 20:00 Сейчас в теме

(65) Да, уже сделали... На любую секунду можно будет откатиться

68. alex25ru 03.02.22 04:50 Сейчас в теме

Была подобная ситуация, срочно потребовалась копия базы, сделали в рабочее время средствами MS SQL, без отключения пользователей. В результате были созданы и распечатаны документы. Спустя час после резервирования базы не смогли найти их в базе, записи в ЖР остались, что пользователь делал документы, но "объект не найден". Была сделана только полная копия, восстановление ее производилось в другую базу. Документы пропали в рабочей базе. В копии их тоже не было.

77. METAL 289 03.02.22 20:01 Сейчас в теме

(68) Хотите сказать, что архивация(резервирование, backup) базы в рабочее время средствами MSSQL может повлечь удаление данных из архивируемой базы?

78. alex25ru 04.02.22 03:17 Сейчас в теме

(77) Разумом и логикой допустить такое не могу. Но факт, остается фактом, делали полную копию именно в рабочее время, с порядка 30 пользователями в сети. И по итогу получили от бухгалтерии вот такой привет, пропал документ. Думаю что стечение обстоятельств и что-то еще, мы не стали углубляться в изучение проблемы и не анализировали журналы MS SQL.

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

В базе на тот момент половина пользователей это бухгалтерия с документами, вторая половина вносит изменения в существующие объекты. Т.е. только ~15 человек занимались документами, под удар попало два пользователя, создавшие в тот момент по документу. Именно этих двух документов и не досчитались.

80. TormDV 04.02.22 08:30 Сейчас в теме

(78) Полная копия (да и неполная тоже) делается на некоторый момент времени, все изменения вносимые пользователями, после этого момента в копию не попадут (но и в рабочей базе исчезнуть не должны).
(77) Не уверен, что транзакции SQL равны транзакциям в 1С, это больше к вопросу откатиться на любую секунду. Да и термин "откатиться" тут наводит на некоторые мысли. Зачем рабочую базу восстанавливать из бэкапа, если только она не разбита вследствие сбоя и не чинится. Накосячили бухи, пусть расхлебывают))

81. alex25ru 04.02.22 08:53 Сейчас в теме

(80) Я имел в виду, что транзакции формируемые в период "выгрузки базы" должны примениться к рабочей базе, после ее "разблокировки". То что копия не будет содержать эти данные, это и так я думаю всем ясно. Заковырка в том, почему эти данные не применились, а пропали.

82. redfred 04.02.22 10:02 Сейчас в теме

(81) Транзакции во время выполнения бэкапа фиксируются в штатном режиме, нет никакой особой блокировки базы на этот период. А для обеспечения целостности в файл полного бэкапа входит еще и бэкап логов на время выполнения бэкапа

85. МимохожийОднако 141 05.02.22 10:04 Сейчас в теме

Документ распечатать можно в любом месте и поэтому не является доказательством работы в базе. В этом случае все манипуляции с ЖР бессмысленны. Искать кошку в темной комнате, когда её там нет можно до бесконечности.
Если под этим номером другие данные, то самое очевидное только одно. Распечатали документ, изменили и провели. Ищи сколько хочешь. Это из личной практики.

88. user1203706 13 12.02.22 21:32 Сейчас в теме

(87) что на счет (41) ?

90. METAL 289 14.02.22 22:59 Сейчас в теме

(88)
1. Битых ссылок в таблице ТЧ ЗаказПоставщику.Товары нет
2. Документ не проводился, а только был записан, движений и не было

Но версия о том, что кто-то на уровне СУБД удалил записи, в целом подходит под симптомы, собственно об этом предполагается в топике с пометкой, что следов прямого удаления не найдено...

93. dshershen86 17.02.22 13:42 Сейчас в теме

(90)
Не забывайте транзакции в 1с это не транзакции скуля. Есть вероятность коммита транзакции в 1С, но отсутствия транзакции в SQL, как пример из-за падения службы. Я думаю если бы удаляли в скуле, вы бы нашли следы в кеше SQL. При том возможно удалось напечатать, так как объект есть и оптимизатор 1С прочитал из текущего объекта, но из-за сбоя коммита в базе нет.
Если бы был включен тех. журнал, вы бы смогли отловить отсутствие коммита в SQL.

91. user1203706 13 15.02.22 09:54 Сейчас в теме

(90) Гы.. если вы печатаете НЕ проведенный документ, то вполне вероятно, что ОН не был записан вообще никогда.
Тогда пазл сходится - создали новый док, распечатали, закрыли не сохраняя, усё.

92. user726666 15.02.22 11:11 Сейчас в теме

(91) Есть прикрепленный файл. Зафиксирована транзакция Добавление. Документ был записан

Оставьте свое сообщение

E-mail: