Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
26.02.2018, 23:36
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
Всем доброго времени суток! Случилось страшное - посреди рабочего дня упала база 1С. Упала странно - очистилась полностью. не осталось ни одного пользовательского объекта. Как будто из базы удалили их все. При этом удаления собственно базы не было - она жила на тех же файлах .mdf и .ldf Ладно, были нормально настроены бэкапы, развернул на тестовой машине, отыскал примерно момент падения и базу восстановил в состояние за пару минут до падения. Восстанавливал просто откатом к нужному моменту времени. Но все ж хочется выявить причину такого падения. Найти тот запрос, который сумел завалить базу, к которой было немало активных соединений. Руками такой финт провернуть не удалось. Есть полный бэкап, есть копия лога транзакций. известен с точностью до пары минут момент краха. Вопрос. Какими средствами/методами можно выявить собственно причину этого краха? В идеале бы пошагово (как в отладчике) пройти все запросы, которые на базе исполнялись до падения --------------------- Я всегда лгу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 00:25
|
|||
|---|---|---|---|
|
|||
Странная самоликвидация базы |
|||
|
#18+
Contrast, самый быстрый вариант - откатить виртуальную машину к снепшоту, когда база была пустой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 01:14
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
Contrast, В дефолтном трейсе точно нет DROP TABLE? У вас остались сломанные .mdf и .ldf ? Что говорит DBCC CHECKDB? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 06:22
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
В принципе Mind уже написал что вам надо посмотреть. Включен ли Default Trace - вот тут кратко что это Если остался лог (если вы на полной модели конечно), посмотрите fn_dblog, если этот момент уже попал в Backup, то fn_dump_log. Пример здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 10:41
|
|||
|---|---|---|---|
|
|||
Странная самоликвидация базы |
|||
|
#18+
ContrastВсем доброго времени суток! Случилось страшное - посреди рабочего дня упала база 1С. Упала странно - очистилась полностью. не осталось ни одного пользовательского объекта. Как будто из базы удалили их все. При этом удаления собственно базы не было - она жила на тех же файлах .mdf и .ldf Ладно, были нормально настроены бэкапы, развернул на тестовой машине, отыскал примерно момент падения и базу восстановил в состояние за пару минут до падения. Восстанавливал просто откатом к нужному моменту времени. Но все ж хочется выявить причину такого падения. Найти тот запрос, который сумел завалить базу, к которой было немало активных соединений. Руками такой финт провернуть не удалось. Есть полный бэкап, есть копия лога транзакций. известен с точностью до пары минут момент краха. Вопрос. Какими средствами/методами можно выявить собственно причину этого краха? В идеале бы пошагово (как в отладчике) пройти все запросы, которые на базе исполнялись до падения --------------------- Я всегда лгу . угу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 10:44
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
Contrast, прсто так удалить все объекты устанет рука, разве что убить все констрейны, а потом дропать... Так что да, DEFAULT TRACE вам всё расскажет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 14:22
|
|||
|---|---|---|---|
|
|||
Странная самоликвидация базы |
|||
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 15:02
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
кто-то грохнул базу, а потом создал пустую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 16:51
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
Критиккто-то грохнул базу, а потом создал пустую пишет же: авторПри этом удаления собственно базы не было - она жила на тех же файлах .mdf и .ldf я лично понимаю "на тех же" -- это когда Date created столетней давности. но можно конечно и еще раз уточнить: что там у нас с датой создания файлов? и что в dbi_crdate y dbcc dbinfo with tableresults? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.02.2018, 22:57
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
Yasha123я лично понимаю "на тех же" -- это когда Date created столетней давности. но можно конечно и еще раз уточнить: что там у нас с датой создания файлов? и что в dbi_crdate y dbcc dbinfo with tableresults? dbi_crdate дает 1900-й год. Но это, наверное не важно - сами файлы старые. дата создания соответствует ожидаемой. С Default Trace опоздал - он перезаписался... Буду курить fn_dump_dblog... матчасть тут с налету не поддалась... Спасибо всем огромное! луч надежды есть. глядишь, раскопаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.02.2018, 10:30
|
|||
|---|---|---|---|
Странная самоликвидация базы |
|||
|
#18+
ContrastС Default Trace опоздал - он перезаписался... а точно искали по всем пяти файлам? поди ведь по одному текущему ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=46&tablet=1&tid=1690195]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 236ms |
| total: | 334ms |

| 0 / 0 |
