Rakt av Nej!
Varje index och heap har sin egen IAM.

Den primära datafilens första EXTENT, dvs första åtta datasidorna, inleds med ett par specifika datasidor.
Först har du en File_Header, sedan en Page_Free_Space för att lokalisera lediga datasidor (för övrigt denna som är orsaken att du vill ha en datafil per processorkärna i TempDB), därefter kommer Global_Allocation_Map och en Secondary_Global_Allocation_Map för att lokalisera Uniform/Mixed/Empty extents. Ett Index eller Heap inleds med en FirstIAM för att lokalisera B-trädet som håller reda på objektets egentliga datasidor (extremt förenklat).

Du får gärna berätta lite er utförligt om felet, om du har nåt i ERRORLOG osv.

Fick ni fel på partitionen/volymen där databasernas primära datafiler, de som heter .MDF, ligger på blir databaserna suspecta. Dvs det går inte att lokalisera innehållet i databasen. Dock behöver du inte se det så i Management Studio/Object Explorer, inte alltid gränssnittet förljer verklig status.

Jag bedömmer det tveklöst som ett I/O problem. NET HELPMSG 21 ger "The device is not ready.", t.ex.

När du säger att du bara ser de tabeller som ligger i master så undrar jag om du syfter på de som egentligen ligger i resursdatabasen. Om så, så är det en smula mer troligt. Kom ihåg, till exempel, att system tabellerna, och säkert en hel del "i master" enegtligen är vyer, vars definitioner ligger i resurs databasen.

Man ska ju inte hålla det för osannoligt att då fått "pekarfel" (ordet används i lös bemärkelse) så att det resulterar i det du beskrev. Låter lite som en chans på miljarders miljarder, men mar man vart i datasvängen ett tag så vänjer man vid att ibland bara acceptera "det okända".

SQL Server ska inte på något sätt falla tillbaka på masterdatabasens filer och därmed filheaders, GAM, SGAM, PFS och IAM etc., på något sätt. Om du kan reproducera (svårt antar jag), och det ser ut som om så är fallet så skulle jag öppna ett case med MS (eller rapportera på connect).