v7: Проблемы с базой в sql 2000 #578099

Есть (была?) периферийная база. 7.7 на скл 2000. Бэкапы не делались, вина не моя-) В какой-то момент, заглючил сервак, то ли свет пропадал, то ли еще что-то, база перешла в состояние suspect. Примерно в это же время, грузился (и вроде загрузился) обмен из центра, с измененной конфой. Сами файлы .mdf и .ldf скопировал, дальше были танцы с бубном - Состояние suspect снял, проверил в самих таблицах - последние изменения мд были загружены, вроде ок все. Теперь ругается на "доступ к базе данных на сервере возможен бла бла бла". Single user снимал, перезагружал скл, сам сервер. Не помогло. dbcc checkdb показало ош

dbcc checkdb показало ошибку Could not find row in sysindexes for database ID 7, object ID 353367248, index ID -1. Run DBCC CHECKTABLE on sysindexes. CHECKTABLE sysindexes ничего не дало.

Периферийка на СКЛ - круто. Убей ее в центре и создай заново

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

Поверь быстрее будет

Ок, напомните как там это корректно сделать, в тестовой проверю. Удалить переферийку, потом создать с тем же кодом ИБ ? И сделать первую выгрузку?

монопольно запускаешься?

QA дает запросы выполнять?

правов хватает? (кто овнер базы)?

база от ЦБ сильно отличается? (по миграции доков)

По всякому, результат один Например? select? 90% центральной мигрирует именно в эту переферику. мдф файл переферийки -15ГБ

ошибка только одна была? отрицательный index id как-бы удивляет. а что возвращает object_name(353367248) ?

serverадминистратор

2. ну хотя бы селект десяти последних доков из журнала 3. тогда проще склонировать ЦБ. в "параметрах базы" он же стоит?

в параметрах базы скл? да

select * from _1sjourn проходит

Ошибка только одна

как посмотреть в qa?

select object_name(353367248)

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

Кстати, если пересоздать переферийку, будет проблема как в Именно в эту базу, и еще в парочку, стоит доплнительный признак мигарции у многих док-тов.

_1SCONNECT

дропни её...

Гонца с DVD отправляйте поездом

drop table 1SCONNECT выдает ту же ошибку как в

Жестоко ты базу сломал... :-)

чектабле с NOINDEX пробовал?

угу -) Есть мнение что с правами в самом скл что-то не так. Как думаете, снести скл-сервер, поставить и потом аттач, стоит тратить время?

да, ошибок нет

Скопирую селектами данные в другую базу. По этим селектам поймешь в чем дело.(моджеть дело не только в 1Сконнект - ее вообще можно дропать и пересоздать) Если селектами скопируешь то тогда проиндексруешь средствами 1С и можно будет работать. Если нельзя то тогда нужно будет смотреть конкретные данные. Хотя конечно луше подобную работу делать профессионалам. Если данные теоретически востанавливаются и база не огромных размеров - дело 5-и минут либо поправить либо выдать вередикт.

попробуй это применить: не стоит

какой там параметр в качестве indid указывать?

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

я пробовал и -1 и 1 . На -1 говорит что нет такого, а 1 - не позволяет.

База большая, мдф - 15 ГБ. Спецов которые могли бы быстро сделать, нет. Готовы платить, киев.

а что сказал товарищ профайлер?

Кстати теоритически можем удаленно пусть спеца, если сами в ближайшее время не починим.

Посмотрю позже, отпишусь

Организовывай доступ, Пиши завтра на мыло. Поручу своим сделать. Либо за 5-ть минут все готово,либо аргументированно скажем почему вообще это нельзя сделать. Редко(1 из 10 случаев) бывает ситуация когда нужно реально поработать(например востановить 1сджоурн из журнала регистрации,dh таблиц и т.п.) Разумеется не бесплатно. Хотя конкретно в этом случае(сбой при удалении таблицы) лучше бы перелить в другую БД. Настроил бы этой ночью дтс и глядишь к утру все работало, бесплатно к тому же.