При попытке сделать чего-либо с базой на SQL серваке, Error 605 #255611

Error 605: Attempt to fetch logical page (110192) inb database 'vso2' belogs to object '267147997', not to object 'sysindexes'. и трындец... чем его поковырять?

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

Даже выгрузку нельзя сделать?

eue

угу

Error 605 Severity Level 21 Message Text Attempt to fetch logical page %S_PGID in database '%.*ls' belongs to object '%.*ls', not to object '%.*ls'. Explanation This error occurs when Microsoft® SQL Server™ detects database corruption. The second object specified in the text not to object '%.*ls' is probably corrupt. Because this error can mask the existence of other errors, execute DBCC CHECKDB to determine the extent of the damage. If DBCC CHECKDB does not report additional errors, the first object mentioned is not corrupt. SQL Server detects database corruption when it traverses the pages of an object and finds a page in the chain whose object ID does not match that of the object being accessed. There is probably a damaged page chain, a corrupt Index Allocation Map (IAM), or an invalid entry in the sysobjects system table for that object. A clustered table has one doubly-linked page chain for the table data as well as one for each index level. A nonclustered index has a page chain for each level of the index. Pages in a heap are not linked. The IAM is used to find the pages of a heap. Although error 605 usually displays two object names, other variations can occur: If instead of an object name the error displays a number greater than 0, it means that an attempt was made to reference an object ID that does not exist in a system table for that object. If the error reports the first object ID as 0, an unallocated page was probably encountered. (There is no object ID equal to 0.) If the error states that a page belongs to object ALLOCATION, some of the allocation structures used by the database might be corrupted. Usually this error occurs after the corruption has been written to the database on disk, but it can also occur entirely in the cache without the damage ever being written to the disk. This is known as a transient 605 error and is not associated with data corruption. If error 605 occurs during data access, but subsequent DBCC CHECKDB statements complete without error, the 605 error was probably transient. Transient 605 errors can be caused by the operating system prematurely notifying SQL Server that an I/O operation has completed; the error message is displayed even though no actual data corruption exists. Nontransient 605 errors are often caused by hardware or disk device driver failure.

пасип, а дальше че с ним делать?

вся .опа в том, что похерилась таблица sysindexes, которую он мне даже очистить не дает...

бэкапы есть? :-)

Есть, но много добивать ручками придется

Короче вопрос - при попытке DELETE FROM sysindexes он у меня ругается, что типа системные таблицы я не дам трогать, обратись к админу и он те разрешит... Собственно где там в скуле это разрешить?

up

а переиндексироватьпри помощи SQL  не получается &

?

неа, я даж список таблиц глянуть не могу, на экспорте тож вспотыкается, хотя работают конструкции типа select * from sc199 но если б хотя бы знать имена таблиц, то можно вытащить их все ручками....

сча я тебе выдам военную тайну: Как переиндексировать базу на MS SQL Server Чтобы произвести переиндексацию необходимо выполнить такой запрос (например в QA): Код:USE base_1c EXEC _1sp_DBReindex где base_1c - имя базы данных. Если хранимой процедуры _1sp_DBReindex нет в базе данных (база не 1С), то можно выполнить такой код (это и есть код хранимой процедуры _1sp_DBReindex): DECLARE @TableName char DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U' OPEN SysCur FETCH NEXT FROM SysCur INTO @TableName DBCC DBREINDEX(@TableName) FETCH NEXT FROM SysCur INTO @TableName END где base_1c - имя базы данных. Соответсвенно код для создания хранимой процедуры: Код:if exists (select * from sysobjects where id = object_id('dbo._1sp_DBReindex') and sysstat & 0xf = 4)    drop procedure dbo._1sp_DBReindex CREATE PROCEDURE _1sp_DBReindex AS  SET NOCOUNT ON  DECLARE @TableName char  DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U'  OPEN SysCur  FETCH NEXT FROM SysCur INTO @TableName  FETCH NEXT FROM SysCur INTO @TableName ====================================================================== Как проверить (восстановить) базу на MS SQL Server средствами сервера    Проверку логической целостности нужно выполнять штатными средствами 1С:Предприятия (Тестирование и исправление ИБ). В случае, если такую проверку не удается выполнить, следует проверить физическую целостность БД средствами MS SQL. Для проверки целостности средствами MS SQL нужно выполнить следующую команду: Код:DBCC CHECKDB ('<имя базы>',REPAIR_REBUILD) Перед выполнением этой команды нужно базу данных перевести в режим "single user": Код:sp_dboption '<имя базы>','single user',true В процессе работы DBCC CHECKDB могут быть обнаружены ошибки и часть может быть сразу же исправлена. Если ошибки остались, то по всей видимости их нельзя восстановить без потери некоторых данных. В этом случае нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS (перед запуском желательно сделать копию файлов базы данных). Код:DBCC CHECKDB ('<имя базы>',REPAIR_ALLOW_DATA_LOSS) После выполнения DBCC CHECKDB нужно не забыть вернуться в нормальный режим (выйти из режима "single user"): Код:sp_dboption '<имя базы>','single user',false Переиндексацию базы данных на MS SQL не нужно делать так часто, как в случае с DBF-версией 1С:Предприятия (например, при аварийном завершении работы пользователя). MS SQL автоматически поддерживает индексы в актуальном состоянии. Пересоздавать индексы имеет смысл в одном из следующих случаев: 1) Индекс физически поврежден. Это случается довольно редко и для восстановления нужно использовать вышеупомянутый DBCC CHECKDB. 2) Страницы индекса сильно фрагментированы и требуется их упорядочить. 3) Нужно изменить степень заполнения индексных страниц (fill factor). 4) Требуется изменить тип индекса (кластерный/некластерный). При использовании 1С это обычно неакту

реиндекс на системных таблицах он не дает сделать :( checkdb обламывается с той же ошибкой.... вот такая вот засада

ап

Вот до чего дошел. Поставил EMS манагер, с помощью стандартного (т.к. EMS даже коннектиться не хочет к базе) сделал бекап, MDF и LDF файлы переместил от греха подальше, и с помощью EMS сделал ресторе... жду когда отресторит... надежды нет :( ЗЫ вся соль в том, что все таблички можно отселектить... т.е. ручками переташить в новыю базу... но влом :)

фуф ё.... руками перетащил все, 2 таблички побились, но они нах не нужны были :)