|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
Приветствую! Имею базу 'SERVICEDESK_TEST' После некоторого сбоя, не удается полностью починить базу. Подскажите пожалуйста, как ее починить? Лог чека и лог восстановления во вложенном файле ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2022, 19:17 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
lcnet, ну хотя бы в ZIP выложите ... |
|||
:
Нравится:
Не нравится:
|
|||
03.02.2022, 20:05 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
lcnet, у вас побиты 2 таблицы SDeskAttachment (752057765) Arc_ChargesTable (1175779346) восстановитесь из последнего бекапа до момента сбоя и перелейте таблицы, если это логически возможно ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 14:27 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
Из сообщений проверки и восстановления я понял про таблицы. После сбоя прошло много времени, еще до моего появления в данной компании. Сама система (это ManageEngine) работает нормально, ошибки валятся при снятии бэкапа, по этому решил заняться восстановлением. Но, когда увидел разные записи в таблицах, на которые ругется "чек" и "рестор", решил поинтересоваться вариантами. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 15:45 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
Можно ли попытаться удалить упоминания о данных записях? Что-то вроде: Delete from servicedesk_test.Arc_ChargesTable Where "здесь должен быть идентификатор объекта, но я хз как он обозначается, в таблице идет первый столбец - CHARGEID, видимо он" 1175779346 ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:08 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
Конструкция такая, думаю: Delete from servicedesk_test.dbo.Arc_ChargesTable Where CHARGEID = 1175779346; go Но, результатов нет, пишет (строк обработано: 0) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:15 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
lcnet Можно ли попытаться удалить упоминания о данных записях? Что-то вроде: Delete from servicedesk_test.Arc_ChargesTable Where "здесь должен быть идентификатор объекта, но я хз как он обозначается, в таблице идет первый столбец - CHARGEID, видимо он" 1175779346 у вас побита служебная информация на нескольких (многих?) страницах таблиц нащупать битый диапазон можно последовательно проверяя блоки записей (select * from table where id between xxx and yyy) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:28 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
lcnet Конструкция такая, думаю: Delete from servicedesk_test.dbo.Arc_ChargesTable Where CHARGEID = 1175779346; go Но, результатов нет, пишет (строк обработано: 0) как вы бесстрашно машете командой delete - аж прям завидую тот номер, что вы указали, есть ID таблицы, а не ID записи ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:30 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
У вас по одной проблемной странице в каждой из таблиц "SDeskAttachment_PK". (ключ = 215307). "Arc_ChargesTable_PK". (ключ = 302260). нужны ли вам записи с этими ключами? 1. Что будет, если вы выполните ? select * from dbo.Arc_ChargesTable where ключ_таблицы = 215307 select * from dbo.SDeskAttachment where ключ_таблицы = 302260 2. Если будет ошибка, то попробуйте найти эти проблемные страницы. Например через dbcc page двигаясь от root-а индекса до нужных ключей 3. Как бы вы не получили данные по этим ключам, решите что же делать с этими записями ( судя по всем, у вас более 1 записи по каждому из этих ключей) 4. Перелейте корректные данные в другую таблицы (попробуйте использовать условие ключ_таблицы < проблемного значения и ключ_таблицы > проблемного значения ) 5. Плюс долейте (или просто проигнорируйте) записям с проблемными ключами (но только так, чтобы соблюсти уникальность) 6. переименовывайте старые таблицы в какой-нибудь ..._old а новые таблицы в исходные имена Тут где-то еще могут вылезти проблемы с FK ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:30 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
lcnet Из сообщений проверки и восстановления я понял про таблицы. После сбоя прошло много времени, еще до моего появления в данной компании. Сама система (это ManageEngine) работает нормально, ошибки валятся при снятии бэкапа, по этому решил заняться восстановлением. Но, когда увидел разные записи в таблицах, на которые ругется "чек" и "рестор", решил поинтересоваться вариантами. похоже, что побитые страницы таблиц содержат данные, которые не используются системой (архив или исторические) на вашем месте я бы сделал следующее: скопировал данные из таблиц в новые таблицы, старые таблицы удалил, новые переименовал ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2022, 16:33 |
|
Восстановление после сбоя
|
|||
---|---|---|---|
#18+
komrad msLex Спасибо! Попробую, отпишусь. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2022, 15:56 |
|
|
start [/forum/topic.php?fid=46&fpage=3&tid=1683859]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 143ms |
0 / 0 |