előszó
Emmm, egy nap, amikor dolgozni megyek, beszélgetek a barátaimmal, és módosítom az adatbázis adatait. Véletlenül feltételes nyilatkozat nélkül frissítettem. Körülbelül 6W további lemezek közül a táblázatban mind véletlenül módosították. Az egész ember hirtelen pánikba esett, majd nyugodtan elgondolkodott. Ez a helyi adatbázisom, ami pánikba esik. Azonban az adatok több mint 6W-val változtak, és nem szeretném szinkronizálni a hivatalos adatbázisból. Mindenféle keresés és megoldáskeresés az interneten. Mivel a helyi adatbázis verzióm SQL Server 2008, már régóta olvasok blogokat, és a legtöbb blognak legalább egyszer teljesen le kell mentenie az adatbázist. Sajnálom, de még nem mentem le a helyi adatbázisomat. Ez a módszer nem működik, így csak megvalósíthatóEz egy másik módon. Amíg nem találtam egy eszközt, ami az adatbázisnaplókból adatokat vissza tudja állítani –ApexSQL Log。 Ez a szoftver, az eredeti verzió fizetni kell, néhány száz dollárt, az ingyenes verzió minden adat működését lekérdezheti, egyetlen adatdarab vissza tudja állítani, természetesen az SQL utasításokat is exportálhatod és visszaállíthatod adagokban, de csak egyet exportálsz minden tíz adatdarabhoz, vagyis az én 6 wattos adatom csak egy tizedet tudnak visszanyerni adagokban. Még mindig nem felel meg az igényeimnek. Találtam egy ingyenes, feltört ApexSQL Log verziót (https://down.itsvse.com/item/11530.html)。 Letöltheted magad.
Környezet
>SQL Server2008
eszközök
>ApexSQL Log 2016 önhasználatra cracked
SMS
1. lépés: Letöltés után bontsd ki közvetlenül és keresd megApexSQLLog.exe- > dupla kattintás a megnyitáshoz。
2. lépés:A megnyitás után néhányan felnyílnak a frissítési felület, és közvetlenül kiválaszthatod a Cancel opciót.
3. lépés: Most lépj be a fő felületre, és a következő képet látod, a szerver kiválasztja a helyreállítandó szervert, és a következő tartalmat is ennek megfelelően választják ki。 Mivel tört verzió, az adatbázis kiválasztásában szereplő sorok egy része nem jelenik meg, de ez nem befolyásolja a használatot. Végül válaszd a Nextet.
4. lépés: Válaszd ki a megfelelő adatbázis-naplófájlt, és menj a következő lépésre。
5. lépés: A következő négy opciót láthatod, mi az elsőt választjuk, egyértelműen láthatod az összes műveleti rekordot, természetesen a második elemet is közvetlenül visszaállíthatod, alábbiakban az első elemet választjuk。
6. lépés: Először válaszd ki az időtartományt a megfelelő forgatókönyv szerint, itt az utolsó 24 órát választjuk。
7. lépés: Ezután válaszd a megfelelő művelettípus szerint。
8. lépés: Ezután válaszd ki a helyreállítandó űrlapot > Befejezést。
9. lépés: Láthatjuk, hogy ez az interfész 24 órán belül tisztán megjeleníti működési adatainkat: a végrehajtás típusát – frissítés, részletes idő, az adatok megváltoztatása, a változtatás előtti adatok és a változtatás utáni adatok。
Még a következő felületen is közvetlenül láthatjuk a sor műveleti rekordját, visszafordíthatjuk a szkriptet, és újra megpróbálhatjuk a szkriptet.
Mi vagyunkAz adatok visszaállításához közvetlenül beillesztheted a mondatot a fenti Undo Scriptbe, és futtathatod. Természetesen, ha az adatmennyiség nagy, folytassuk az alábbi köteges exportáló szkriptek műveletét
10. lépés: Válaszd ki az összes visszaállítani kívánt adatot, ,——> válaszd a menüsávban a Visszavonja a Scriptet.
11. lépés: Láthatjuk a következő felületet, amely tele van SQL szkriptekkel. Közvetlenül az adatbázisba illesztheted a végrehajtáshoz, vagy folytathatod az adatbázishoz való csatlakozást az eszközben, hogy végrehajtsd a végrehajtást, használjuk tovább ezt az eszközt, kattints az Execute gombra.
12. lépés: Az alábbiakban látható, hogy a végrehajtás sikeres.
Epilógus
Így minden rosszul kezelt adat visszanyerhető. Bár vissza lehet állítani, a barátoknak mégis óvatosnak kell lenniük az adatbázis-adatok kezelésével kapcsolatban. Ha ilyen nagy hibát követnek el a gyártási környezetben, annak nagyon súlyos következményei lesznek. Ha az utolsó lépés nem egyértelmű, hagyhat üzenetet lent.
|
Közzétéve 2019. 03. 31. 19:07:37
|
|
|
|
Háziúr|
Közzétéve 2019. 04. 01. 10:03:02
|
Közzétéve 2019. 04. 01. 9:15:09
|
