Jak obnovit databázi SQL pomocí obnovení příkazového řádku pomocí NMM

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions


Tento článek dokumentuje postup, který je třeba dodržet pro úspěšné obnovení databáze SQL, která byla zálohována pomocí NMM pomocí VDI

. Obnovení databáze SQL ze zálohy pomocí příkazového řádku může být vyžadováno, pokud dojde k problému s obnovením z grafického uživatelského rozhraní (uživatel NetWorker pro grafické uživatelské rozhraní serveru SQL nebo doplněk SSMS). Úloha procházení z grafického uživatelského rozhraní je pomalá nebo se v grafickém uživatelském rozhraní nezobrazuje požadovaná databáze pro obnovení.


Při zálohování jedné databáze se obvykle vytvoří následující sady uložení:

Úplná záloha jedné databáze bude mít následující sady uložení:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:26:41 119 MB 3209027663 cb full MSSQL$FINANCE:testdb ==> Úplná záloha saveset
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE: testdb ==> metadata saveset.


Přírůstková záloha jedné databáze bude mít následující savesety:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:34:14 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb ==> Log backup saveset
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb ==> metadata saveset


Všimněte si, že každá záloha má uloženou sadu metadat, která je vždy vytvořena na úrovni "incr" a je obvykle velmi malá. Tato uložená sada obsahuje informace, díky nimž je možné zobrazit výpis databáze v grafickém uživatelském rozhraní "Networker User for SQL Server". Tato sada se vytvoří s každou zálohou SQL VDI. Je však možné, že tato sada uložení neexistuje, pokud proces ručního klonování nesprávně nezahrnul tuto sadu pro klonování a pokud původní sady již neexistují. V takovém případě je jedinou možností obnovení z příkazového řádku.

Jakmile určíte, ze které zálohy potřebujete provést obnovení, můžete vytvořit příkazový řádek. Níže je uveden příklad příkazu pro obnovení:

nsrsqlrc -s nsr-server -c sql12srv1 -t "25. 5. 2016 13:34:14" -d "MSSQL$FINANCE:testdb-recovered" -C " 'testdb' = 'c:\recover\testdb.mdf', 'testdb_log' = 'c:\recover\testdb_log.ldf', 'testdb_log1' = 'c:\recover\testdb_log1.ldf'" "MSSQL$FINANCE:testdb"

Ve výše uvedeném příkazu

-s je zadat název serveru Networker,
-c se používá k určení zdrojového klienta (pokud se obnovení provádí na jiném než zdrojovém klientovi),
-d zadejte cílovou databázi, do které se má provést obnovení. Tato databáze nebude existovat. Proces obnovení vytvoří databázi v cílové instanci.
-C určuje, že se jedná o obnovení kopie. Parametry za -C určují logické názvy souborů v databázi.  Všimněte si, že tyto názvy se musí přesně shodovat s logickými názvy obnovované databáze.  Pokud databáze existuje, proveďte vlastnosti názvu databáze z grafického uživatelského rozhraní SSMS a podívejte se do části Soubory.

Pokud se provádí obnovení na clusterovaný SQL Server, přidejte do příkazu

pro obnovení parametr "-A "název_virtuálního serveru".Poslední komponentou příkazu je název obnovované databáze, např. MSSQL$
FINANCE:testdb

Pokud si nejste jisti, jaké jsou logické názvy databázových souborů, můžete zadat neúplný příkaz, jak je uvedeno níže:

nsrsqlrc -s nsr-server -c sql12srv1 -t "25.5.2016 13:34:14" -d "MSSQL$FINANCE:testdb-recovered" -C " 'mydb' = 'c:\ recover\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(PID 2144):Čas zahájení: Wed May 25 15:37:42 2016
43621:(pid 2144):Název počítače: SQL12SRV1 Uživatelské jméno: NSR_CLIENT správce
: sql12srv1.jets.local;
                  NSR_SERVER: nsr-server;
37725:(pid 2144):Obnova databáze 'testdb' do 'testdb-obnoveno' ...
142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Vyhledání zálohy pro saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Chybějící přemístění logického souboru testdb.
37945:(pid 2144):Chybí přemístění logického souboru testdb_log.
37945:(pid 2144):Chybí přemístění logického souboru testdb_log1.
37946:(PID 2144):V příříření ného logého souboru pojmenovíní mydb v p
┼Ö├¡┼Ö├¡┼Öen├¡ 29401:(pid 2144):D┼╛├¡┼Ö Aktuální seznam souborů je:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf

142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Vyhledání zálohy pro saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Chybějící přemístění logického souboru testdb.
37945:(PID 2144):Chybí přemístění logického souboru testdb_log.
37945:(pid 2144):Chybí přemístění logického souboru testdb_log1.
37946:(pid 2144):V p┼Öedn├¡ datab├
ízen├¡ 29401:(pid 2144):D chyba seznamu přemístění souboru atabase. Aktuální seznam souborů je:
37947:(pid 2144):       testdb = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Program Files\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf

Operace obnovení byla dokončena s chybami. Podrobnosti naleznete v souboru protokolu zálohování modulu. Neznámá chyba XBSA 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Spuštění funkce cleanUp(). NSR/db_apps/BSMSQL/rcovmain.cpp(500): Ukončení funkce cleanUp().
43709:(PID 2144):Čas zastavení: Wed May 25 15:37:49 2016


***********************

Ve výše uvedeném příkazu jsem zadal náhodný logický název 'mydb' a příkaz vyplivne skutečný logický název souborů DB a jejich původní umístění. Tyto informace můžete použít k vytvoření příkazu obnovení. Upozorňujeme, že pro obnovení dat je nutné zadat jinou cestu. V příkazu obnovení nemůžete a neměli byste zadat původní zdrojovou cestu, abyste předešli riziku přepsání existujících dat.

Čas zálohování pro obnovení lze získat příkazem mminfo. Buď můžete použít savetime, jak je znázorněno ve výstupu, nebo můžete nahlásit nsavetime a místo toho použít tento čas.

např.:

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday"

SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:26:41 119 MB 3209027663 cb plná MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 13:34:14 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 Datum akce 25.05.2016 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday" -r volume,client,sumflags,sumsize,level,savetime(25),nsavetime,name

SQLbackups.001 sql12srv1 cb 119 MB full 25.05.2016 13:26:41 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 25.05.2016 13:29:16 1464197356 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 1320 MB incr 25.05.2016 13:34:14 1464197654 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 25.05.2016 13:40:31 1464198031 MSSQL$FINANCE:testdb

Poznámka: Můžete zadat nsavetime/savetime buď sady uložení metadat, nebo skutečné sady uložení dat. Bude fungovat kterákoli z těchto možností.

Scénář 2:

Pokud jsou zálohy registrovány v databázi média bez názvů databází, pak čas požadované zálohy nebude tak zřejmý. Například všechny zálohy databáze mají stejné názvy sad pro ukládání, jak je uvedeno níže:

SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:43:15 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:

Z výše uvedeného nelze zjistit, která sada pro ukládání má potřebnou zálohu.

Pokud sada pro ukládání dat medata existuje, zálohy bude možné procházet z grafického uživatelského rozhraní a název databáze a čas zálohování můžete zjistit v grafickém uživatelském rozhraní. Např. pokud byl vyžadován DB24, GUI zobrazí čas zálohování jako "5/25/2016 4:49 PM". 

kA5j0000000TNJYCA4_1_0

Pokud k dispozici není sada pro uložení metadat, bude nutné spustit příkaz nsrinfo a zjistit čas uložení pro obnovení. např. pokud mminfo zobrazí sady uložení takto:

SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:43:15 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:47:34 151 KB 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:49:42 151 KB 2621837279 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:51:50 151 KB 2605060191 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25. 5. 2016 16:53:58 151 KB 2588283103 cb incr MSSQL$FINANCE:

Spuštěním nsrinfo v níže uvedených časech ukládání získáte informace o databázi, která je součástí uložené sady:

nsrinfo -n mssql -t "25.5.2016 16:43:15" SQL12SRV1 Vyhledávání času pro Save 1464208995 Time klienta SQL12SRV1
(25.5.2016 16:43:15) z oboru názvů
mssql MSSQL$FINANCE:/ DB21
MSSQL$FINANCE:/DB21%/files.1464208995.1464209044
Nalezeny

2 objekty nsrinfo -n mssql -t "25.5.2016 16:49:42" SQL12SRV1 Hledání 1464209382 záchranného času v klientovi SQL12SRV1
(25.5.2016 16:49:42) z oboru názvů
MSSQL MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
Nalezeny

2 objektyVzhledem k tomu, že sady uložení nezobrazují názvy databází, může být výše uvedený postup trochu pokus a omyl ve scénáři, kdy sada uložení metadat neexistuje. Přibližná velikost databáze slouží jako vodítko k zúžení dotazu nsrinfo na několik sad uložení.

Article Properties
Article Number: 000022417
Article Type: How To
Last Modified: 09 Aug 2022
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.