Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
повреждена БД
The Index Allocation Map (IAM) page (1:20850) is pointed to by the next pointer of IAM page (0:0) in object ID 0, index
ID -1, partition ID 0, alloc unit ID 72057825695105024 (type Unknown), but it was not detected in the scan.

все существующие бэкапы имеют эту ошибку.

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

К сообщению приложен файл. Размер - 65Kb
17 окт 17, 11:04    [20875105]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36972
Делать новую базу, переливать туда данные.
17 окт 17, 11:25    [20875198]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Гавриленко Сергей Алексеевич
Делать новую базу, переливать туда данные.

Как думаете - коллега натолкнулся на эту ошибку, поскольку у него в таблицах varchar свыше 8060 байт, при записи оперативная память сбойнула или кэш RAID-контроллера - и получилось повреждение на диске?
17 окт 17, 18:34    [20877055]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
odisssey,
Из чистого интереса - случаем не десктопное железо + SATA диски + разгон тактовой частоты? Большая база?
17 окт 17, 18:35    [20877058]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
Andy_OLAP
odisssey,
Из чистого интереса - случаем не десктопное железо + SATA диски + разгон тактовой частоты? Большая база?

нет, все ВМ, в облаке.

Гавриленко Сергей Алексеевич
Делать новую базу, переливать туда данные.
,

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

https://www.sql.ru/forum/1137373-3/kakim-instrumentom-perelit-dannye
17 окт 17, 20:43    [20877293]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Rankatan
Member

Откуда:
Сообщений: 250
Я так понимаю что-то сдохло в системных таблицах. Не знаю насколько вариант рабочий, но попробуй зайти в DAC и снова проделать CHECKDB. По результату отпишись.
17 окт 17, 22:38    [20877535]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
Rankatan
Я так понимаю что-то сдохло в системных таблицах. Не знаю насколько вариант рабочий, но попробуй зайти в DAC и снова проделать CHECKDB. По результату отпишись.


результат не поменялся

Msg 2575, Level 16, State 1, Line 2
The Index Allocation Map (IAM) page (1:20850) is pointed to by the next pointer of IAM page (0:0) in object ID 0, index
ID -1, partition ID 0, alloc unit ID 72057825695105024 (type Unknown), but it was not detected in the scan.
18 окт 17, 09:07    [20877936]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
Andy_OLAP
Как думаете - коллега натолкнулся на эту ошибку, поскольку у него в таблицах varchar свыше 8060 байт, при записи оперативная память сбойнула или кэш RAID-контроллера - и получилось повреждение на диске?

просто интересно, и при чем тут вообще варчары?
какая же разница вообще, что в таблицах?
18 окт 17, 09:57    [20878051]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
o-o
Andy_OLAP
Как думаете - коллега натолкнулся на эту ошибку, поскольку у него в таблицах varchar свыше 8060 байт, при записи оперативная память сбойнула или кэш RAID-контроллера - и получилось повреждение на диске?

просто интересно, и при чем тут вообще варчары?
какая же разница вообще, что в таблицах?

Так это же IAM
а IAM штука хитрая
и даже интересная
и если есть смелость
то можно попробовать в HEX редакторе починить
18 окт 17, 10:05    [20878084]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
Andy_OLAP
o-o
пропущено...

просто интересно, и при чем тут вообще варчары?
какая же разница вообще, что в таблицах?

Так это же IAM
а IAM штука хитрая
и даже интересная
и если есть смелость
то можно попробовать в HEX редакторе починить

не надо мне ваших ссылок на 5 строк,
я хочу понять, по-вашему, если в таблице нет варчаров, то у ней нету IAM-страниц что ли?
18 окт 17, 10:16    [20878133]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
o-o
я хочу понять

Все нормально, я хотел понять, почему IAM испортился, была мысль, что это из-за активной записи больших текстовых кусков. А у товарища БД в ВМ, ВМ в облаке, облако в интернете, в общем, как в мексиканском сериале.
18 окт 17, 13:38    [20878961]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
Andy_OLAP
А у товарища БД в ВМ, ВМ в облаке, облако в интернете, в общем, как в мексиканском сериале.

так каким местом варчары к IAM page?
еще раз, есть ли какое вменяемое обоснование, почему вдруг
"активная запись больших текстовых кусков" может отразиться на IAM page?
---
это именно у вас какой-то нескончаемый сериал,
где все на свете объясняется первым попавшимся на глаза типом данных
18 окт 17, 14:28    [20879196]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
o-o
Andy_OLAP
А у товарища БД в ВМ, ВМ в облаке, облако в интернете, в общем, как в мексиканском сериале.

так каким местом варчары к IAM page?
еще раз, есть ли какое вменяемое обоснование, почему вдруг
"активная запись больших текстовых кусков" может отразиться на IAM page?
---
это именно у вас какой-то нескончаемый сериал,
где все на свете объясняется первым попавшимся на глаза типом данных

Страницы IAM сопоставляют экстенты с одним из 3 типов единиц распределения. Если в строке данных в сумме выше 8060, чем годится для IN_ROW_DATA - данные переезжают в ROW_OVERFLOW_DATA. Когда снова в сумме меньше либо 8060 - обратно тип меняется. Следовательно, массивная работа с изменением длины в столбцах типа varchar как минимум приводит к активной работе с IAM, которая может "сломать" IAM page.
Ну то есть мне просто любопытно, какая в целом нагрузка на базу может привести к тому, что в IAM появляется мусор.
18 окт 17, 14:38    [20879240]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
Andy_OLAP
Ну то есть мне просто любопытно, какая в целом нагрузка на базу может привести к тому, что в IAM появляется мусор.

да никакая.
эта ошибка не зависит вообще никак от наличия варчаров.
но если ваш сериал требует наличия минимум N серий,
продолжайте постить фигню в том же духе
---
мало было своих Козловых, еще и OLAP нам их начал поставлять
18 окт 17, 15:46    [20879512]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
o-o
Andy_OLAP
Ну то есть мне просто любопытно, какая в целом нагрузка на базу может привести к тому, что в IAM появляется мусор.

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


почему база поломалась - известно

ссылки тут можно публиковать ? [url=]http://www.vmgu.ru/news/vmware-vsphere-esx-snapshots-are-bad[/url]

если коротко - «расширение диска виртуальной машины со снапшотом приводит к потере данных»

теперь вопрос как восстановить малой кровью, с переливкой на данный момент мне не понятно как, пока читаю...
18 окт 17, 16:24    [20879640]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
odisssey
если коротко - «расширение диска виртуальной машины со снапшотом приводит к потере данных»

Понял, спасибо, еще один аргумент в моей копилке против использования снапшотов.
18 окт 17, 16:28    [20879659]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
odisssey
если коротко - «расширение диска виртуальной машины со снапшотом приводит к потере данных»

да ну что вы...
расширение диска оно же только варчары трогает, вернее, их IAM-страницы
---
копирование базы(визард) уже пробовали? отвалился?
18 окт 17, 16:30    [20879669]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
o-o
odisssey
если коротко - «расширение диска виртуальной машины со снапшотом приводит к потере данных»

да ну что вы...
расширение диска оно же только варчары трогает, вернее, их IAM-страницы
---
копирование базы(визард) уже пробовали? отвалился?

копи датабэйс? я правильно понял? скопировал, на копии выдаёт туже ошибку, может нужно экспортировать?

К сообщению приложен файл. Размер - 142Kb
18 окт 17, 22:55    [20880596]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
o-o
Guest
Вы точно выбрали copy (SMO), а не detach/ attach?
Когда copy, он именно что переливает данные,
вы можете сохранить созданный SSIS - пакет,
открыть и убедиться.
Там обычный перелив, кучками таблиц, параллельно.
Если именно этим методом все без ошибок перелилось,
значит, все таблицы читаемы.
Только ошибка не должна была перекочевать,
создаются новые объекты в новой базе, у них свои IAM-ы
18 окт 17, 23:52    [20880704]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
o-o
Вы точно выбрали copy (SMO), а не detach/ attach?
Когда copy, он именно что переливает данные,
вы можете сохранить созданный SSIS - пакет,
открыть и убедиться.
Там обычный перелив, кучками таблиц, параллельно.
Если именно этим методом все без ошибок перелилось,
значит, все таблицы читаемы.
Только ошибка не должна была перекочевать,
создаются новые объекты в новой базе, у них свои IAM-ы


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


- Add log for package (Success)

- Add task for transferring database objects (Success)

- Create package (Success)

- Start SQL Server Agent Job (Success)

- Execute SQL Server Agent Job (Error)
Messages
The job failed. Check the event log on the destination server for details. (Copy Database Wizard)
19 окт 17, 18:25    [20883669]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
odisssey
Member

Откуда:
Сообщений: 64
также пробовал через экспорт.

тоже вылетело с ошибками, вот часть лога

+
Information 0x402090df: Data Flow Task 3: The final commit for the data insertion in "Destination 12 - _AccRgAT015522" has started.
(SQL Server Import and Export Wizard)

Information 0x402090e0: Data Flow Task 3: The final commit for the data insertion in "Destination 12 - _AccRgAT015522" has ended.
(SQL Server Import and Export Wizard)

Information 0x4004800c: Data Flow Task 3: The buffer manager detected that the system was low on virtual memory, but was unable to swap out any buffers. 14 buffers were considered and 14 were locked. Either not enough memory is available to the pipeline because not enough is installed, other processes are using it, or too many buffers are locked.
(SQL Server Import and Export Wizard)

Information 0x4004800f: Data Flow Task 3: Buffer manager allocated 9 megabyte(s) in 3 physical buffer(s).
(SQL Server Import and Export Wizard)

Information 0x40048010: Data Flow Task 3: Component "Source 10 - _AccRg15542" (1) owns 3 megabyte(s) physical buffer.
(SQL Server Import and Export Wizard)

Information 0x4004800c: Data Flow Task 3: The buffer manager detected that the system was low on virtual memory, but was unable to swap out any buffers. 12 buffers were considered and 12 were locked. Either not enough memory is available to the pipeline because not enough is installed, other processes are using it, or too many buffers are locked.
(SQL Server Import and Export Wizard)

Information 0x4004800f: Data Flow Task 3: Buffer manager allocated 3 megabyte(s) in 1 physical buffer(s).
(SQL Server Import and Export Wizard)

Information 0x402090df: Data Flow Task 3: The final commit for the data insertion in "Destination 10 - _AccRg15542" has started.
(SQL Server Import and Export Wizard)

Information 0x402090e0: Data Flow Task 3: The final commit for the data insertion in "Destination 10 - _AccRg15542" has ended.
19 окт 17, 18:27    [20883673]     Ответить | Цитировать Сообщить модератору
 Re: повреждена база,REPAIR_ALLOW_DATA_LOSS не лечит  [new]
Eleanor
Member

Откуда:
Сообщений: 2867
odisssey
The buffer manager detected that the system was low on virtual memory, but was unable to swap out any buffers.

Пишет, что не хватило памяти.
Вот аналогичная ошибка. Ограничили max server memory в Sql Server и нормально отработало.
19 окт 17, 23:14    [20884253]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить