mi a figyelmeztetés: Adatbázis < db-név> gyanús? Valószínűleg látott már gyanúsítottként megjelölt adatbázist az SSMS – ben, és nem tudja, mit képvisel. Olvassa el az alábbi cikket, hogy további részleteket megtudjon erről!
mi a figyelmeztetés: adatbázis db-neve gyanús?
néha kritikus helyzettel szembesülhetünk, mivel az SQL Server adatbázis gyanús módba kerül. Ezen a ponton az adatbázis már nem használható, és nem lehet munkát végezni.
az adatbázis gyanús módba váltásának fő oka az, hogy az elsődleges fájlcsoport megsérült, és az adatbázis nem állítható helyre az SQL Server indításakor.
az adatbázis több más okból is gyanús állapotba kerülhet, amelyek magukban foglalhatják:
- rendszerhiba, amelyet az adatbázis-kiszolgáló nem megfelelő leállítása okozhat
- sérült naplófájl vagy sérült MDF-fájl
- abban az esetben, ha nincs több hely a lemezen
- az SQL Server nem tudja befejezni a görgetési vagy visszagörgetési műveletet
- korlátozások a FAT32 fájlrendszerek és egyéb okok miatt
az adatbázis javításához és ebből az állapotból való helyreállításhoz a következő lépéseket kell tennie:
- kezdjük azzal, hogy megváltoztatjuk az adatbázis állapotát az sp_resetstatus tárolt eljárás végrehajtásával
EXEC sp_resetstatus 'TestDB'
- állítsa az adatbázist “vészhelyzet” módba
ALTER DATABASE TestDB SET EMERGENCY;
- ellenőrizze az adatbázisban az esetleges ellentmondásokat
DBCC checkdb ('TestDB');
- abban az esetben, ha bármilyen hibát észlel a DBCC fázis során, akkor az alábbi lekérdezés segítségével azonnal állítsa az adatbázist egyfelhasználós módba:
ALTER adatbázis TestDB SET SINGLE_USER a visszagörgetés azonnali;
- ezen a ponton biztonsági okokból javasoljuk, hogy készítsen biztonsági másolatot az adatbázisról
- miután befejezte az adatbázis biztonsági mentését, folytassa a következő lekérdezés futtatásával. De ne feledje, hogy a következő lekérdezés használata közben a REPAIR_ALLOW_DATA_LOSS paraméterrel egyirányú műveletet hajt végre, amely javítja az adatbázist, de a folyamat során végrehajtott összes műveletet nem lehet visszagörgetni. Nincs megoldás az adatbázis korábbi állapotába való visszatérésre, ezért javasoljuk, hogy készítsen biztonsági másolatot, amelyet az előző pontban javasoltunk
DBCC CheckDB ('TestDB', REPAIR_ALLOW_DATA_LOSS);
- az utolsó lekérdezés, amelyet futtatnia kell, az adatbázis többfelhasználós módba állítása
ALTER DATABASE TestDB SET MULTI_USER;
- az utolsó lépés az adatbázis-kiszolgáló frissítése, és ellenőrizze, hogy az adatbázishoz való kapcsolat működik-e. Ezt követően a felhasználóknak lehetőséget kell biztosítani az adatbázishoz való csatlakozásra. Abban az esetben, ha bármilyen adatvesztés visszaállíthatja az adatbázist, amelyet korábban biztonsági másolatot készített