Как такое могло получиться, навскидку сказать трудно. Могла просто записаться на диск всякая лабуда из-за сбоя в операционной системе. А я добился стабильной повторяемости одного глюка (похожего) при запуске мастера копирования базы данных. В одной из таблиц в качестве значения по умолчанию используется UDF. Так вот из-за этого работа DTS-пакета обрывается с ошибкой.
Изначально была сделана таблица без значения по умолчанию. Потом UDF, которая использует данные этой таблицы. Потом с помощью Alter Column эта UDF была пришпандорена в качестве значения по умолчанию столбцу этой же таблицы. При работе мастера копирования БД он должен прогнать скрипты именно в таком порядке. Попытка прогнать их в конечном виде приводит к ошибке. При создании в первую очеред таблицы с Default-значением приводит к ошибке потому, что UDF еще не существует. При попытке создать UDF тоже возникает ошибка, потому что таблица еще не существует.
Так вот, когда возникает ошибка при работе мастера копирования БД, целевая БД оказывается таки созданной (в ней отсутствует всего пара объектов). И даже пытается некоторое время работать. При выдаче некоторых запросов - даже корректно. Однако, при прогоне DBCC CHECKDB выскакивает куча сообщений о разрушеных страницах индексов. Если пытаться такую БД эксплуатировать, разрушения прогрессируют.
Если ты когда-либо копировал БД мастером и затем полученную копию пытался эксплуатировать, не обращая внимания на ошибку трансформации, то отсюда ноги и выросли.
Для меня такое поведение SQL-сервера несколько странно. Судя по всему, при копировании БД задействуются механизмы низкого уровня. Если бы просто прогонялись скрипты по созданию всех объектов, а уже потом заполнялись бы таблицы данными, то подобных сбоев происходить не должно. Похоже, скрипты не прогоняются, а втупую копируются страницы данных вместе с метаданными (хотя при этом каким-то чудным образом проверяется взаимная увязка объктов).