На днях успешно завалили базу. Неразобравшись почему висит
(в конце оказалось, што изза переполнения лога, и как догадываемся, места для записи инф необходимой для востановления тоже небыло)
перезапустили сервер. После чего БД пошла в суспект. Зaпустили c T3608, перемутили, короче как зашли в базу, сразу глюки пошли разные-разнообразные.
Назапускались dbcc checkalloc, dbcc checktable и дургого. Кроме того, что последние изменения в БД (перед зависоном) откатились на половину (толи закрепились на половину) - не как транзакции
выборка по индексам творила чудеса (выбораешь одно, выдаёт чёт-то другое), но самое страшное что dbcc tablealloc (table, full, fix) не пофиксил много чего,
в т.ч. данные (indid = 0). Спасает пересоздание обектов, но индексы удалять не хочется, т. к. с их помощью (как мне расказывали) можно постаратся вятянуть данные
з таблиц которые не читаются полностью( чтобы списать в строну данные, и пересоздать таблицы). Может кто делал уже такое?

извиняюсь, что не писал небыло времени даже зайти на форум , было много работы, в том числе разгребал последствия нашего подвига. Даже не поблагодарил за ответы.
Тот кто мне рассказывал про индексы в битых таблицах, и вытаскивание данных имел ввиду как выяснилось, то что нужно иметь небитый наиболле селективный индекс и по нему ходить.

An attempt was made to fetch logical page '5534231' in database 'Keeper' from cache 'default data cache'. Page belongs to object with id '1847062685', not to object 'Offtake'.
Такого типа ошибки происходили при select * into Offtake1 from Offtake и для других таблиц тоже.

Странно но мы сделали 5-6 попытокт выгрузить данные через bcp (для отдельной таблицы "Offtake") и в двух случаях это получилось, в остальных bcp получал ту-же ошибку. Мы то и сами понимали что проблема в данных записанных на диске, и кеш вообщем то не виноват. Но думали, что если 2 раз проскочило может стоило попробовать перенести таблицу в отдельный кеш (правда это уже была другая битая таблица), может там ошибку не определит. Вообщем ошибка происходила та-же.. Даже объекта которому должна была принадлежать страница (типа 1847062685 в случае с Offtake) в базе к этому моменту уже небыло (мы его тоже пересоздавали и ID стал другой). Настроились на вытаскивание записей построчно, но для начала вытянуть наибольшую часть данных которые вытянуться большими кусками (по диапазону ПК). И странное дело, разделив таблицу на 5 диапазонов, как бы для начала, вытащились все данные и не на одном из них не выдало ошибки. Сейчас уже ошибок нету, dbcc ошибок тоже не выдает , пока результат - около тысячи пропавших записей в некоторых таблицах.
К стати в некоторых таблицах остались записи, у которых нет главной записи. При создании fk ошибок не происходило. Это можно включить где-то чтобы проверялось налиичие главных записей при создании ФК.

MasterZiv
Селективность здесь ни при чем вообще. А ходить -то по нему можно,
но некуда, если таблица сама битая.

Таблица битая не вся. Мы то быстро вычислили, запортились данныйе в таблицах котороые менялись во время близкое до "зависания", и только те пейджи в которых находились последие данные. Ошибка возникала при выполненние запроса который обращался к тем данным например сканирование всей таблицы. Чтобы извлечь хотябы стороки которые находились на нормальных пейджах нужен наиболее селективный индекс, по которому можно вытягивать строки хоть и по одной.

MasterZiv
Это с кэшем не связано. Это - ошибки в аллокациях страниц под таблицы.

Я же сказал, что мы и сами то понимаем что это не ошибка кеша, даже знаем из-за чего база полетела, просто из шести попыок выгрузить таблицу через bcp, первая и последняя оказались удачными, и все таки была какая-то причина в том что проверка не сработала. Вот и подумали, что если в кеше будет только одна таблица, то есть вероятность можно списать таки данные. Мы ведь не знаем что и как там внутри ASE,А пытаться таки что-то сделать нужно было, потому так и пробывали, ведь другую таблицу выгрузить через bcp, или insert так и не удалось. Подконец нам не пришлось идти позаписно, ведь как ни странно таблица списалась вся до единой строчки, но скопировали мы ее 5 кусками задавая достаточно большой диапазон ПК (~5 000 000 строк в табице ).

gewsawsПодконец нам не пришлось идти позаписно, ведь как ни странно таблица списалась вся до единой строчки, но скопировали мы ее 5 кусками задавая достаточно большой диапазон ПК (~5 000 000 строк в табице ).
Я ж написал, что у нас получилось, то есть таблицу мы списали причём полостью. Когда таблицу одним махом списать неудалось, мы решили йти по кускам табицы. Для начала решили поделить таблицу на 5 кусков, чтобы за тем куски которые не смогли скопироваться поделить пополам и т.д. 2-4 раза пока бы часть данных которая не скопировалась, не стала настолько малой что не неочень долго было бы идти позаписно по оставшимся данным. Но как не удивительно, когда мы копировали таблицу поделив ее на 5 частей не при одном копировании не выдало ошибки, и скопировалитсь все до единой строчки. Это была последняя таблица с кототрой у нас были проблеммы , и теперь таких таблиц больше нет. В общем после запора бд, у нас было гдето 6-7 таблиц у которых checkalloc говорил что повреждены данные (indid = 0) и которые не копировались через select * into плюс 9-8 таблиц где только индексы, проблема решалась пересозданием объектов.