Пропали и вернулись сами собой документы 1С 8.2 SQL. Почему?
Добрый день.
У нас на MS-SQL сервере работают 2 базы 1С 8.2. Однажды в обеих базах 1С в формах списка документов пропали документы за последние полдня. Через 1-2 часа - они самопроизвольно восстановились (появились в 1С). Начальник требует от меня, чтобы я предоставил документально подтверждённую причину этого явления. Проблема проявилась одновременно в двух разных 1С базах.
Я смотрел журнал регистрации в одной из баз. На момент пропажи там были записи "Объект не найден" с его уникальным идентификатором. Залез и в т.н. технологический журнал - есть такой в 1С - показывает все события на уровне клиент-серверного взаимодействия. Но технологический журнал оказался пуст - он был не настроен, и, видимо, настройка по-умолчанию автоматически стирала записи там через несколько часов.
На SQL у меня доступа нет - админ не пускает. Начальник смотрел логи SQL-сервера, и сказал, что "со стороны SQL всё в порядке - а значит, виноваты программисты 1С".
Вопрос в следующем: как можно документально обосновать сбой, если не по логам? Но 1С-овские логи пусты. Сохранился, правда, дамп за тот день - его уже отправили вендору 1С - для разбора.
Короче, начальник хочет видеть документально подтверждённую причину сбоя - что можно ему предоставить?
Я пытаюсь рассуждать логически. Если проблема проявилась одновременно в двух разных базах 1С - значит, сбой был явно не на уровне баз 1С - а, по меньшей мере, на уровне сервера 1С - или ещё ниже - на уровне SQL-сервера - логично? Будь сбой на уровне баз 1С - значит, проблема проявилась бы только в одной из двух баз данных 1С - не так ли? И тем более, будь виновна тут какая-то из 1С баз - то данные оттуда просто пропали бы - но уж никак бы сами собой не сумели бы восстановиться, верно? На такие чудеса, очевидно, способен только MS-SQL в моём представлении. Или я не прав?
Прошу совета и подсказки. Где и какие логи следует смотреть в данном случае?
У нас на MS-SQL сервере работают 2 базы 1С 8.2. Однажды в обеих базах 1С в формах списка документов пропали документы за последние полдня. Через 1-2 часа - они самопроизвольно восстановились (появились в 1С). Начальник требует от меня, чтобы я предоставил документально подтверждённую причину этого явления. Проблема проявилась одновременно в двух разных 1С базах.
Я смотрел журнал регистрации в одной из баз. На момент пропажи там были записи "Объект не найден" с его уникальным идентификатором. Залез и в т.н. технологический журнал - есть такой в 1С - показывает все события на уровне клиент-серверного взаимодействия. Но технологический журнал оказался пуст - он был не настроен, и, видимо, настройка по-умолчанию автоматически стирала записи там через несколько часов.
На SQL у меня доступа нет - админ не пускает. Начальник смотрел логи SQL-сервера, и сказал, что "со стороны SQL всё в порядке - а значит, виноваты программисты 1С".
Вопрос в следующем: как можно документально обосновать сбой, если не по логам? Но 1С-овские логи пусты. Сохранился, правда, дамп за тот день - его уже отправили вендору 1С - для разбора.
Короче, начальник хочет видеть документально подтверждённую причину сбоя - что можно ему предоставить?
Я пытаюсь рассуждать логически. Если проблема проявилась одновременно в двух разных базах 1С - значит, сбой был явно не на уровне баз 1С - а, по меньшей мере, на уровне сервера 1С - или ещё ниже - на уровне SQL-сервера - логично? Будь сбой на уровне баз 1С - значит, проблема проявилась бы только в одной из двух баз данных 1С - не так ли? И тем более, будь виновна тут какая-то из 1С баз - то данные оттуда просто пропали бы - но уж никак бы сами собой не сумели бы восстановиться, верно? На такие чудеса, очевидно, способен только MS-SQL в моём представлении. Или я не прав?
Прошу совета и подсказки. Где и какие логи следует смотреть в данном случае?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) prodines, 1.Удаляем документы за период (несколько часов) какой нибудь обработкой, например
2.Получаем Объект не найден в ЖР. В журнале документов они отображаться не будут вообще.
3.Берем копию базы, или узел РИБ, в котором эти документы еще не удалены, и переносим через выгрузку_загрузку_XML или РИБ.
Т.е. такая ситуация со стороны 1с моделируема, и легко воспроизводима.
А чтобы такой эффект, давали сбои сервера БД, практически не сталкивался.
И если документы,кстати, таким образом восстанавливались, в ЖР будут следы, документы будут изменены примерно в одно и то же время.
2.Получаем Объект не найден в ЖР. В журнале документов они отображаться не будут вообще.
3.Берем копию базы, или узел РИБ, в котором эти документы еще не удалены, и переносим через выгрузку_загрузку_XML или РИБ.
Т.е. такая ситуация со стороны 1с моделируема, и легко воспроизводима.
А чтобы такой эффект, давали сбои сервера БД, практически не сталкивался.
И если документы,кстати, таким образом восстанавливались, в ЖР будут следы, документы будут изменены примерно в одно и то же время.
(3) Caspersky, В этом случае не было бы "Объект не найден".
Вопрос автору - РИБ в базах есть ? Хотя такой вариант, что одновременно произошел сбой в обеих базах практически равен нулю даже при использовании РИБ. Теоретически обработкой удалить и потом из копии выгрузкой-загрузкой такое сделать можно, но опять-таки - кто это будет делать и кому это надо ? На уровне сервера 1С такое тоже практически нереально. Так что 99% SQL, тут надо информацию о том, делаются ли бекапы средствами SQL и какой план используется.
Вопрос автору - РИБ в базах есть ? Хотя такой вариант, что одновременно произошел сбой в обеих базах практически равен нулю даже при использовании РИБ. Теоретически обработкой удалить и потом из копии выгрузкой-загрузкой такое сделать можно, но опять-таки - кто это будет делать и кому это надо ? На уровне сервера 1С такое тоже практически нереально. Так что 99% SQL, тут надо информацию о том, делаются ли бекапы средствами SQL и какой план используется.
(1) prodines, 0. Перестать кивать в сторону админов, а админам в сторону программистов: объединить усилия и разобраться)))
1.Прежде всего выяснить выполнялись ли какие-нибудь операции по времени предшествующие сбою:
1.1. С ИБ 1С: настройка прав доступа, выгрузки, загрузки, изменение конфигурации, запуск обработок модиф. данные ИБ...
1.2. С сервером 1С: изменени конфигурации сервера...
1.3. С сервером БД: Изменение конфиурации сервера БД, может настроены какие-нибудь регл.операции, выполняющиеся в течение дня, или были запущены вручную.
Собрать максимум информации, проанализировать... дальше по обстоятельствам ...
1.Прежде всего выяснить выполнялись ли какие-нибудь операции по времени предшествующие сбою:
1.1. С ИБ 1С: настройка прав доступа, выгрузки, загрузки, изменение конфигурации, запуск обработок модиф. данные ИБ...
1.2. С сервером 1С: изменени конфигурации сервера...
1.3. С сервером БД: Изменение конфиурации сервера БД, может настроены какие-нибудь регл.операции, выполняющиеся в течение дня, или были запущены вручную.
Собрать максимум информации, проанализировать... дальше по обстоятельствам ...
Базы - стандартные, т.е. из числа тех, которые выпускаются самой фирмой 1С. Какие именно - не могу назвать, запрещено мне разглашать. Обмен в базах не используется - никакой вообще. SQL делает автоматические бэкапы - полные еженедельные и разностные дневные. У меня нет доступа к SQL-серверу - только админ туда вхож. Что-то узнать у админа насчёт SQL?
(12) prodines, тогда на какой ответ вы рассчитываете? Вы пишете: "у меня всё то же самое, что и у других" - в этом случае у вас и набор проблем должен быть, как у других, а того, что вы описали, у других нет и единственный ответ, который можно дать, основываясь раскрытых вами данных: "вы всё выдумали".
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот