Kopírovanie údajov SQL. Nastavenie pravidelných záloh databázy MS SQL Server. Princíp zálohovania v modeloch Simple a Full Update

Existuje mnoho spôsobov, ako kopírovať tabuľku v databáze MS SQL Server. Prechádzam zoznamom možností na vytvorenie kópie tabuľky. Ktorý z nich si vybrať, závisí od štruktúry tabuľky, prítomnosti indexov, spúšťačov atď., Ako aj od potrebnej ručnej práce.

1. Manuálny spôsob kopírovania štruktúry tabuľky

V Microsoft SQL Management Studio vyberte databázu, vyberte tabuľku, kliknite pravým tlačidlom myši a vyberte položky „Tabuľka skriptu ako“ -> „VYTVORIŤ DO“ -> „Nové okno editora dotazov“. V okne sa zobrazí kód na vytvorenie tabuľky. Musíte zadať názov databázy, v takom prípade musíte vytvoriť kópiu tabuľky a nový názov, ak sa databáza nemení. Ako vytvoriť kód na vytvorenie štruktúry, ktorá je v tabuľke, je znázornené na obrázku nižšie.

Pomocou tejto metódy sa vytvoria indexy tabuliek, ale neskopírujú sa spúšťače. Je potrebné ich skopírovať podobným spôsobom.

Ak chcete skopírovať údaje do už vytvorenej tabuľky, musíte použiť nasledujúci SQL:

INSERT do ..tmp_tbl_Deps SELECT * FROM ..tbl_Deps

2. Kopírovanie SQL tabuľky v jednom riadku

Vytvorte kópiu tabuľky a dátovej štruktúry uprostred jednej databázy:

SELECT * do tmp_tbl_Dep FROM tbl_Deps

Skopírujte štruktúry tabuliek a údaje z jednej databázy do druhej:

SELECT * do ..tmp_tbl_Deps FROM ..tbl_Deps

Nevýhodou tohto riešenia je, že sa indexy nekopírujú.

Tento článok vám povie, ako manuálne vytvoriť novú záložnú kópiu databázy pomocou dodatočného programu Microsoft SQL Server Management Studio.

1. Vytvorte záložnú kópiu

V skutočnosti je všetko jednoduché. Spúšťame zariadenie" » (« Štart» — « všetky programy» — « SQL Server 2008 R2» — « Prostredie Microsoft SQL Server Management Studio") a zadajte údaje na autorizáciu.

Potom v prehliadači objektov otvorte kartu „ Baziho pocty»Klikneme pravým tlačidlom myši na databázu, pre ktorú je potrebné vytvoriť záložnú kópiu. V kontextovom menu zvoľte " zavdannya» ( Úlohy) — « Vytvorte záložnú kópiu» ( Zálohovať...) .

Spúšťacie okno" Zálohovanie databázy» ( Zálohovať databázu). Zmeňme to, o čom hovoríme povna» ( Plný), V prípade potreby dodáme názov a popis, ako aj v prípade potreby popis záložnej kópie. Ak to chcete urobiť, prejdite na pevný disk počítača a prejdite do priečinka Zálohovanie hlavnej databázy servera SQL. Ak chcete zmeniť umiestnenie kópie, kliknite na " vidality» ( Odstrániť), zrušte ostatné možnosti a potom „ Pridať» ( Pridať...) pridať niečo nové.

Tu zadáme názov záložného súboru a stlačíme „ OK" Takéto destinácie môžu byť špecifikované. V tomto prípade bude záložná kópia rozdelená na rovnaké časti, pričom každá časť bude v určenom súbore.

Keď je všetko urovnané, stlačíme „ OK„Skontrolujem dokončenie úlohy. Ak je všetko správne nakonfigurované, v zadanom adresári nájdeme záložnú kópiu súboru databázy SQL.

2. Aktualizácia databázy zo záložnej kópie

Aktualizácia prebieha podľa podobnej schémy. U " Middleware Microsoft SQL Server Management Studio»Vyberte základňu Kde je vytvorená záložná kópia?, Kliknite naň pravým tlačidlom myši a vyberte „ zavdannya» ( Úlohy) — « obnoviť» ( Obnoviť) — « Databáza...» ( Databáza...).

Otvorí sa okno " Aktualizácia databázy» ( Obnoviť databázu). Tu, ako hovorí dzherelo, „ Pridám rozšírenie» ( Zo zariadenia) Vyberiem záložný súbor (vytvorený v kroku 1).

Nainštalujeme prápor" obnoviť» ( Obnoviť) Na rozdiel od záložnej kópie. V prípade potreby na zálohu " parametre» ( možnosti), Môžete zadať ďalšie parametre aktualizácie, môžete si prečítať o ich význame.

Po dokončení všetkých prác vyrazíme „ OK»Dostávame oznámenie o úspešnej aktualizácii databázy.

3. Aktualizácia záložnej kópie do inej databázy (kopírovanie údajov)

Ak je potrebné importovať údaje do databázy, V účte, kde bola vytvorená záložná kópia, Potom, ak máte záujem o akcie popísané v odseku 2, je potrebné zadať „ parametre"(Možnosti) zadajte názvy súborov pre databázu a nastavte prápor" Prepíšte pôvodnú databázu"(S NÁHRADOU).

Pomohol ti Chi?

Poďme sa pozrieť na to, ako usporiadať dve najbežnejšie úlohy správy SQL Servera:

• Automatické zálohovanie databáz;
• Odstránenie starých záložných kópií.

Plánovanie záloh databázy

• Otvorte SQL Management Studio a pripojte sa k požadovanej databáze. Pozrite sa, čo robí SQL Server Agent;
• Otvorte ponuku Správa – Údržba (pre ktorú máte rolu „SYSADMIN“) – kliknite pravým tlačidlom myši a vyberte „Nový plán údržby“;
• Zadajte nový plán služieb;
• Kliknite na koniec kalendára vpravo v jednom riadku. Na Vikne nastavte hodinu poslušnosti Vikonny. Vyberte hodinu, kedy je databáza menej preplnená;
• V časti Toolbox presuňte položku Backup Database Task do hlavnej oblasti;
• Dvakrát kliknite na Backup Database Task - otvorí sa okno pre nastavenie úlohy zálohovania - nastavte požadované nastavenia;
• Kliknite na tlačidlo OK - teraz sa budú záložné kópie vytvárať pravidelne pred naplánovanou hodinou;

Odstránenie starých záloh

Keďže záložné súbory sa budú vytvárať často, miesto na pevnom disku sa nevyhnutne zmení. Preto budete musieť odstrániť zastarané záložné súbory. Plán služieb môžete jednoducho nakonfigurovať:

• Na paneli Toolbox potiahnite úlohu Maintenance Cleanup Task do hlavnej oblasti;
• Dvakrát kliknite na Maintenance Cleanup Task, aby ste otvorili okno Power. Je vašou zodpovednosťou zabezpečiť, aby boli záložné kópie rozšírené, rozšírené a počet súborov, ktoré je potrebné odstrániť. Je dobrou praxou uchovávať záložné kópie až jeden mesiac;
• Kliknite na tlačidlo OK a uložte plán služieb;
• Potom môžete buď skontrolovať nadchádzajúci čas plánu údržby, alebo ho vybrať manuálne (kliknite pravým tlačidlom myši na plán údržby v Prieskumníkovi objektov).

sqlcmd -S DECLSERVER\SQLGTD -E -Q 'deklaruje @s varchar(255) set @s = 'E:\backup\GTD_' + convert(varchar(1), datepart(dw, getdate())) + '. bak 'zálohovanie databázy GTD na disk = @s s init, noformat, skip, nounload "

sqlcmd umožňuje zadávať príkazy Transact-SQL, systémové procedúry a súbory skriptov z príkazového riadku do editora dotazov v režime SQLCMD,

• -S - nastaví názov servera, server[\názov_inštancie];
• DECLSERVER\SQLGTD - názov servera / názov inštancie, na ktorom sa má databáza spustiť;
• -E - pre pripojenie k serveru SQL je spoľahlivejšia výmena používateľského mena a hesla;
• -Q "cmdlinequery" - pri spustení programu sqlcmd Budete vyzvaní na ukončenie, inak nebudete môcť ukončiť programy po dokončení vášho programu. Môže existovať množstvo nápojov, medzi ktorými je medzi nimi niekoľko škvŕn. Umiestnite ho do labiek, ako je znázornené vyššie;
• vyhlásiť - premenlivé s vyslovujeme, názov premenlivého začína vždy na @, preto @s. Do našej vipadky @s- toto je priečinok (disk) na ukladanie záložných kópií;
• varchar(n) - nastavuje typ zmeny @s ako reťazec s dlhým riadkom n je v príklade 255 znakov;
• nastaviť - nastavuje hodnotu zmeny @s, V aplikácii je záložný priečinok na jednotke E ( E:\záloha\), Potom nastavte názov záložného súboru a vyberte funkciu convert(varchar(1), datepart(dw, getdate())) rotuje v textovom formáte s okrajom 1 znak presne v deň v roku (pondelok - 1 , Vitorok - 2 , atď.) a je k dispozícii rozšírenie bak. Výstupom je súbor s nasledujúcimi názvami: GTD_číslo dňa v týždni.bak;
• zálohovanie - vytvoriť zálohu;
• databázy - označuje vytvorenie zálohy celej databázy;
• GTD - v našej aplikácii je databáza na SQL serveri;
• na disk - označuje typ zálohovacieho zariadenia, súbor pevného disku a je zadaná zmena @s, Ktorá cesta a názov vytvoreného súboru je priradený;
• s init, noformat, skip, nounload - označuje, že je potrebné prepísať údaje podľa počtu s priradenými hlavičkami, čo nám umožňuje mať 7 záložných súborov na každý deň v roku, prepísať podľa počtu.

V prípade potreby môžete použiť ďalšie funkcie, ako je squeeze, pozrite si tému Pridávanie dotazov a funkcií Transact-SQL.

Croc 2. Zmena prípony textového súboru na .cmd

Pilník je možné z vrecka vybrať backupGTD.cmd. Príkazový súbor musíte spustiť z rovnakého počítača, na ktorom je nainštalovaná databáza MS SQL.

Krok 3. Tento proces je automatizovaný

Pozrime sa na túto prácu na MS Windows Server 2008: Pridať Server Manager -> Configuration -> Scheduler -> Scheduler Library.

Správcovia databáz sa delia na tých, ktorí budú vykonávať zálohy a tých, ktorí budú vykonávať zálohy.

Zadajte

Tento článok popisuje primárnu zálohu IB 1C pomocou ďalších nástrojov MS SQL Server 2008 R2, vysvetľuje, prečo by to malo fungovať tak a nie naopak, a vyvracia množstvo mýtov. O MS SQL dokumentácii máme čo povedať, tento článok sa skôr pozrie na zálohovacie mechanizmy a všetku potrebnú starostlivosť. Ale pre tých, ktorí s týmito úlohami zápasia ako prví, sú tu jednoduché a presné pokyny, ktoré vám pomôžu riešiť jednoduché situácie. Článok nie je určený pre správcovských guruov, guruov a tak vedieť všetko, ale je dôležité, aby si čitateľ nainštaloval MS SQL Server sám a pomocou tohto zázraku magickej technológie si vo vlastnom jadre vytvoril databázu, ktorá svojim spôsobom vytvorte databázu.starajte sa o údaje 1C.

Príkaz TSQL BACKUP DATABASE (a jeho brat BACKUP LOG) používam v podstate ako jedinú metódu zálohovania databáz 1C, ktoré používajú MS SQL Server ako DBMS. prečo? Poďme sa pozrieť na naše spôsoby spaľovania:

Hlavné ťažkosti pri používaní záložných kópií pomocou metód MS SQL vyplývajú z elementárneho nepochopenia princípov fungovania. Čiastočne sa to vysvetľuje dlhým radom, sčasti chýbajúcim jednoduchým a rozumným vysvetlením na úrovni „hotových receptov“ (hmm, povedzme, že som nedostal žiadne nápady) a tiež situáciou sa vysvetľuje mytologickými radami „nie doguru“ na fórach. Neviem, čo s tým robiť, ale pokúsim sa vysvetliť základy zálohovania.

Na čo šetríme teraz?

Už dávno, vo vzdialenej galaxii, sme vytvorili taký produkt inžinierskeho a účtovného myslenia ako 1C: Enterprise 7.7. Možno preto, že prvé verzie 1C: Businesses boli vyvinuté, aby nahradili populárny formát súborov dbf, ktorého verzia SQL neuložila do databázy dostatok informácií na to, aby bola záloha MS SQL dôležitá, ale tiež, keď sa zmení vzhľad, štruktúry mysle sú zničené nový model, musel ísť ďaleko, aby prinútil záložný systém stratiť svoju hlavnú funkciu. Ale, odvtedy, odkedy sa objavila verzia 8, si správcovia databáz mohli oddýchnuť. Štandardné funkcie zálohovania vám umožňujú vytvoriť úplný a úplný systém zálohovania. Do záložnej kópie nevkladajte iba registratúrny protokol a ďalšie úkony ako je úprava polohy formulárov (v starších verziách), inak nie je indikované plytvanie týmito údajmi na funkčnosť systému, ak chcete zálohovať kópia denníka registra ї funguje správne a správne.

Prečo potrebujeme záložnú kópiu? Hm. Na prvý pohľad vyzerá úžasne dobre živená. No, po prvé, je možné napáliť kópiu systému a obnoviť systém iným spôsobom v prípade zlyhania? Som vhodný na účely prvého, ale z iného dôvodu - prvého mýtu zálohovania.

Záložné kopírovanie je posledným krokom na zabezpečenie integrity systému. Keďže správca databázy musí aktualizovať produktový systém zo záložných kópií, znamená to, že s veľkou dôverou nedošlo k žiadnym závažným chybám v organizácii práce. Nemožno ho nainštalovať pred zálohovaním, pretože je to hlavný spôsob zabezpečenia integrity údajov, ale skôr bližšie k hasiacemu systému. Vyžaduje sa hasiaci systém. To je všetko, ale bolo to opravené, overené a správne. Ako povedala, je to samo o sebe vážny PP s množstvom negatívnych dôsledkov.

Aby sa zabezpečilo, že záloha bude uložená len na „mierové“ účely, použite tieto ďalšie funkcie na zabezpečenie efektívnosti:

• Zaistite fyzickú bezpečnosť svojich serverov: požiare, záplavy, poškodenie elektrickým prúdom, čistiace stanice, budíky, meteority a divoké tvory - všetci smradi čakajú na klaksón, aby ochránili váš server.
• Dávajte si pozor na hrozby informačnej bezpečnosti.
• Správne vykonajte zmeny v systéme a potom postupujte čo najviac, aby zmeny neviedli k narušeniu. Okrem plánu na vykonanie zmien musí matka naplánovať, „čo robiť, pretože všetko nie je v poriadku“.
• Namiesto toho aktívne skúmajte technológie na zvýšenie dostupnosti a spoľahlivosti systému, aby ste potom mohli vyčistiť dedičstvo nehôd. Pre MS SQL je možné sledovanie rozšíriť na najnovšiu dostupnosť:
  • Výber klastrov MS SQL (aby som bol úprimný, rešpektujem to je jeden z najdrahších a zbytočných spôsobov, ako najať správcu databázy pre systémy, ktoré nevyžadujú 24x7)
  • Zrkadlenie databázy (v synchrónnom a asynchrónnom režime v závislosti od dostupnosti, produktivity a dostupnosti)
  • Doručenie denníka transakcií
  • Replikácia pomocou metód 1C (rozdelenie databázy)

V závislosti od dostupnosti systému a rozpočtu vyčleneného na tento účel si môžete vybrať riešenie, ktoré vám umožní znížiť prestoje a obnovu v prípade porúch o 1-2 rády. Pokročilých technológií prístupnosti sa netreba báť: dajú sa ľahko naučiť za pár dní so základnou znalosťou MS SQL.

Ale, bez ohľadu na to, záložná kópia je stále potrebná. Ide o rovnaký záložný padák, ktorý môžete použiť, pokiaľ zvládnete všetko ostatné. Ale, ako užitočný záložný padák, pre ktorý:

• Tento systém musí byť správne a odborne nastavený,
• Fakhіvet podlieha systému, má na svedomí teoretické aj praktické zručnosti a stagnáciu (pravidelné posilňovanie),
• Systém musí byť vytvorený z najspoľahlivejších a najjednoduchších komponentov (to je naša trvalá nádej).

Základné informácie o ukladaní a spracovaní údajov MS SQL

Dáta v MS SQL sa zvyčajne ukladajú do dátových súborov (ďalej len FD - krátkodobo sa neformátuje, v tejto štatistike bude desaťročie ani nie širšie ako najkratšie) s príponami mdf alebo ndf. Okrem týchto súborov existujú aj transakčné protokoly (TJ), ktoré sú uložené v súboroch s príponou ldf. Pre nových administrátorov je často ťažké a náročné začať pracovať, a to z dôvodu produktivity a spoľahlivosti. Toto je veľmi kruté odpustenie. V skutočnosti, keďže existuje spoľahlivo funkčný zálohovací systém a aktualizácie systému sú viditeľné dlhé hodiny, môžete dáta uložiť na zabezpečený alebo extrémne nespoľahlivý RAID-0, alebo dokonca veľmi spoľahlivý. miestneho spoľahlivého a produktívneho zdroja (chcel by som RAID-1). Prečo tak? Poďme sa pozrieť na správu. Hneď poviem, že záver bol zjednodušený, ale pre pochopenie to dokončím.

FD ukladá dáta v sekciách po 8 kilobajtoch (ktoré sú kombinované v rozsahu 64 kilobajtov, ale nie celé). MS SQL nezaručuje, Ihneď po vydaní príkazu na zmenu údajov sa zmena odošle na FD. Nie, ide len o to, že stránka v pamäti je označená ako „úspory“. Ak má server dostatok zdrojov, údaje sa nevyhnutne objavia na disku. Server navyše funguje „optimisticky“ a keďže sa tieto zmeny vykonajú v transakcii, môžu sa úplne minúť na disku skôr, ako sa transakcia potvrdí. V tomto prípade, keď je FD robot aktívny, je potrebné odstrániť rozhádzané kusy nezapísaných údajov a nedokončené transakcie, pri ktorých nie je známe, či budú zbierané alebo zaznamenávané. Existuje špeciálny príkaz „CHECKPOINT“, ktorý prikazuje serveru „okamžite“ vypísať všetky neuložené údaje na disk, inak je oblasť, kde je tento príkaz uložená, špecifická. Stačí povedať, že 1C nie je vikoristický (nie som zaseknutý) a pochopiť, že počas hodiny práce sa FD nezastaví na celej stanici.

Aby sme sa dostali z tohto chaosu, potrebujeme práve ten správny ST. Píše tieto slová:

• Informácie o začiatku transakcie a jej identifikátor.
• Informácie o skutočnosti registrácie alebo viazanosti transakcie.
• Informácie o všetkých zmenách údajov v FD (zhruba povedané, čo sa stalo a čo sa stalo).
• Informácie o zmene samotného FD alebo štruktúry databázy (zväčšenie súborov, zmena súborov, viditeľné a odstránené stránky, vytvorené a odstránené tabuľky a indexy)

Všetky tieto informácie sú zapísané podľa určeného identifikátora transakcie, v takom prípade bol zadaný a postačujú na to, aby ste pochopili, ako postupovať pred touto operáciou a ako pokračovať po tejto operácii. ї operácie a problémy (na vine je aktualizačný model s nekonzistentným protokolovaním) .

Je dôležité, aby sa tieto informácie okamžite zapísali na disk. Pokiaľ informácie nie sú zaznamenané v CT, príkaz nie je zo strany používateľa rešpektovaný. V bežnej situácii, ak je veľkosť priestoru dostatočná a ak nie je veľmi fragmentovaný, záznamy v ňom sa zapisujú postupne v malých záznamoch (nie nevyhnutne v násobkoch 8 kb). Protokol transakcií spotrebúva iba údaje, ktoré sú nevyhnutne potrebné na aktualizáciu. Zokrema NIE stratia sa informácie o tom, aký text bol použitý pred úpravou, aký plán bol použitý na úpravu, aký typ aplikácie bol spustený a ďalšie informácie nie sú potrebné na aktualizáciu. Vyhlásenie o štruktúre údajov v protokole transakcií je možné zapísať

Vyberte * z :: fn_dblog (null, null)

Vďaka tým, že pevné disky fungujú efektívnejšie pri sekvenčných zápisoch, a nie s chaotickým tokom príkazov na čítanie a zápis, a vďaka tým, ktoré príkazy SQL kontrolujú na moment dokončenia zápisu do VT, prichádza k naplneniu nasledujúceho odporúčania:

Ak chcete čo najmenšiu flexibilitu, tak uprostred trhu je ST povinný rozširovať sa na okolité (ako všetko ostatné) fyzické časti, je potrebné mať minimálnu hodinu prístupu pre konzistentné nahrávanie a s maximálnym spoľahlivosť stu. Pre jednoduché systémy je RAID-1 úplne vhodný.

Ak sa dotknete transakcie, všetky zmeny vykonané na serveri sa vrátia do popredia. Preto

Náklady na transakciu v MS SQL Server možno porovnať s celkovými nákladmi na zmenu údajov samotnej transakcie. Bankové transakcie a rozhodnutia o bankových transakciách určite nerobte skôr.

Ak server z akéhokoľvek dôvodu nechce spustiť robota, potom pri jeho reštartovaní bude analyzovaný, či údaje v FD neodrážajú celý stav (nezaznamenané, iné ako zaznamenané transakcie a zaznamenané, iné ako prepojené transakcie i) a tieto údaje budú upravené. Preto, ak ste napríklad začali prestavovať indexy veľkej tabuľky a reštartovali ste server, potom keď ho reštartujete, bude trvať značnú hodinu na zavedenie tejto transakcie a nie je možné tento proces prerušiť.

Čo sa stane, keď budete pracovať až do konca súboru? Je to jednoduché - ak je na klase voľné miesto, tak by ste mali začať písať na voľné miesto na klase do súboru až po obsadené miesto. Ako slučkový magnetický steh. Keďže tu nie je miesto pre začiatok, server sa pokúsi rozšíriť súbor protokolu transakcií, čo poskytne serveru vízie novú informáciu o novom súbore virtuálneho protokolu transakcií, ktorý môže obsahovať súbor fyzického transakčného súboru. nestačí ani obťažovať sa záložnou kópiou. Ak server nedokáže rozbaliť súbor (miesto na disku sa minulo alebo je zablokované nastaveniami rozšírenia), aktuálna transakcia je ovplyvnená chybou 9002.

Ojoj Čo potrebuješ zarobiť, aby si mal v budúcnosti miesto v ZT? Tu sme sa dostali k zálohovaciemu systému a k aktualizačným modelom. Aby bolo možné zaregistrovať transakciu a aktualizovať správny stav servera počas búrky, je potrebné uložiť záznamy v ST, počnúc od začiatku najskoršej z kritických transakcií. Toto minimum je zapísané a uložené v ZT obov'yazkovo. Bez ohľadu na počasie, nastavenie servera a zodpovednosť administrátora. Server nemôže dovoliť stratu týchto informácií. Ak otvoríte transakciu v jednej relácii a zrušíte rôzne transakcie v iných reláciách, denník transakcií sa môže neočakávane ukončiť. Najskoršia transakcia môže byť identifikovaná príkazom DBCC OPENTRAN. Toto je len nevyhnutné minimum informácií. Ďalej ležať aktualizované modely. SQL Server má tri:

• Jednoduché- šetrí sa len prebytočné palivo potrebné pre život.
• Full (Povna)- všetky KT sa uložia od okamihu zostávajúcej zálohy denník transakcií. Získajte späť svoj rešpekt a nerobte si starosti s vytvorením úplnej zálohy!
• Hromadne prihlásený- časť (aj malá časť) operácie je zaznamenaná vo veľmi kompaktnom formáte (v podstate len záznam, ktorý mení takú a takú stranu dátového súboru). Inak totožné s Fullom.

S modelmi obnovy sa spája množstvo mýtov.

• Jednoduché vám umožňuje znížiť zaťaženie diskového subsystému. Nie tak. Píše sa presne toľko, ako keď Bulk logoval, len sa to skôr bohato rešpektuje.
• Hromadné protokolovanie vám umožňuje znížiť zaťaženie diskového subsystému. Toto nie je prípad 1C. V skutočnosti jedna z mála operácií, ktorá sa dá urobiť bez ďalších tancov s diamantom, spadá pod minimálny protokol, je získavanie údajov z vizualizácie vo formáte dt a reštrukturalizácia tabuľky.
• Pri predvolenom modeli hromadného protokolovania sa žiadne operácie neodrážajú v záložnej kópii protokolu transakcií a neumožňuje aktualizáciu stavu v čase záložnej kópie. Nie je to celkom pravda. Ak je operácia minimálne logovaná, potom sa do záložnej kópie uložia presné stránky s údajmi a bude možné „prehrať“ transakčný protokol až do konca (hoci na dlhšiu dobu to možné nie je, keďže minimálne transakcie sú prísne zaznamenávané).

Hromadný protokolovaný model pre databázy 1C možno použiť opatrne, takže ho ďalej nevidíme. A os voľby medzi Full a Simple bude diskutovaná v ďalšej časti správy.

• Štruktúra denníka transakcií
• • Aktualizácia protokolu transakcií a modely správy
  • Správa denníka transakcií
• Zálohovanie protokolov transakcií

Princíp zálohovania v modeloch Simple a Full Update

V závislosti od typu zálohy existujú tri typy:

• Plný(Povna)
• Diferenciál(Differentsiyana, riznitseva)
• Log(Záložná kópia protokolov transakcií, lekárov, tých, ktorí sa často zneužívajú tento výraz, bude rýchlo aktualizovaná na RKZhT)

Tu sa nemusíte zmiasť: nový model a nová záložná kópia sú úplne odlišné slová. Aby nedošlo k zámene, nižšie budem používať anglické výrazy pre model aktualizácie a ruské výrazy pre typy záložných kópií.

Úplné a rozdielové kópie fungujú rovnako pre Jednoduché a Úplné. Záložná kópia transakčných protokolov je k dispozícii počas dňa v Simple.

Úplná záložná kópia

Umožňuje vám kedykoľvek aktualizovať stav databázy (v tej, v ktorej bola vytvorená záložná kópia). Pozostáva z historickej kópie poškodenej časti dátových súborov a aktívneho záznamu transakčného protokolu za hodinu, počas ktorej sa vytvárala záložná kópia.

Diferenciálna záloha

Ukladá údaje, ktoré sa od poslednej zálohy zmenili. Ak potrebujete začať odznova, musíte vytvoriť novú záložnú kópiu (v režime NORECOVERY budú pažby nasmerované nižšie), potom môžete pôvodné maloobchodné kópie uložiť pred odstránením „obrobku“ alebo, samozrejme, len z tých, ktoré boli vytvorené do ďalšej novej záložnej kópie. Na tento účel môžete výrazne znížiť množstvo miesta na disku potrebné na uloženie záložnej kópie.

Dôležité body:

• Bez predchádzajúcej úplnej zálohy sa rozdielová kópia stratí. Preto je dôležité ukladať ich tu, jeden po druhom.
• Ďalšia rozdielová záloha uloží všetky stránky, ktoré sú zahrnuté v predchádzajúcej rozdielovej zálohe vytvorenej po predchádzajúcej (aj keď možno namiesto toho s inou). Vzhľad preto dostane rozdielnu kópiu väčšiu ako predchádzajúce, kým sa znova nevytvorí nová kópia (ak sa zničí, potom iba pomocou kompresných algoritmov)
• Pre obnovenie kedykoľvek dokončite zostávajúceÚplná záloha v tomto čase zostávajúce rozdiel kópie pre túto chvíľu. Medzikópie nie sú potrebné na aktualizáciu (aj keď môžu byť potrebné na výber momentu aktualizácie)

RKZhT

Umiestnite kópiu TT za aktuálne obdobie. Zoberme si od okamihu minulej RKZhT do okamihu formovania radového RKZhT. RKZhT umožňuje z kópie aktualizovanej v režime NORECOVERY kedykoľvek zadať obdobie aktualizovanej kópie ST, zadať obdobie aktualizovanej kópie ST, aktualizovať stav na ktorúkoľvek ďalšiu hodinu po aktuálnom hodinu, zadajte interval obnovy ї záložné kópie. Keď sa vytvorí záloha pomocou štandardných parametrov, miesto v súbore protokolu transakcií sa zmení (kým transakcia zostane otvorená).

Je zrejmé, že RKZhT v jednoduchom modeli nedáva zmysel (takže odstraňuje informácie z momentu zostávajúcich neuzavretých transakcií).

Keď vikorystanny RKZhT obviňuje dôležitý koncept - neprerušovaný kopijník RKZhT. Tento reťazec je možné prerušiť buď plytvaním niekoľkých záložných kópií tohto reťazca, alebo prenesením databázy do Simple a späť.

Upozorňujeme: sada RKZhT je v podstate mary, pretože nemá nepretržitú slučku a na vine je moment začiatku zostávajúcej úspešnej plnej alebo maloobchodnej zálohy v strede obdobie tejto Lanzyuzhky.

Časti milosrdenstva a mýtu:

• "RKZhT umiestni údaje do protokolu transakcií v čase prvej úplnej alebo maloobchodnej zálohy." Takto vôbec nie. RKZhT umiestni na prvý pohľad nepotrebné dáta medzi prvú RKZhT a ďalšiu zálohu zálohy.
• "Nová alebo maloobchodná záloha má na svedomí lepšie miesto v strede denníka transakcií." Takto vôbec nie. Prvá a druhá záloha nevyčistia šnúrku RKZhT.
• Zariadenie sa musí čistiť ručne, meniť a skartovať. Nie, nie je potrebné neúmyselne hovoriť - nie je to dobré. Ak odstránite ST medzi RKZhT, svorka RKZhT sa zničí, čo je potrebné na obnovu. A postupné zmeny / rozšírenia súboru povedú k fyzickej a logickej fragmentácii.

Ako to funguje v jednoduchosti

Poď, databáza má 1000 GB. Každý deň sa databáza rozrastie o 2 GB, čím sa zmení 10 GB starých dát. Rozsiahle aktuálne zálohy

• Úplná kópia F1 o 0:00 1 divoká (pokrytá 1000 GB, komprimovaná pre jednoduchosť obrazu nie je možné obnoviť)
  • Diferenciálna kópia D1.1 o 0:00 2-krát (objem 12 GB)
  • Diferenciálna kópia D1.2 v 0:00 3 divoká (pokrytá 19 GB)
  • Diferenciálna kópia D1.3 v 0:00 4 divoká (25 GB)
  • Diferenciálna kópia D1.4 v 0:00 5 divokých (pokrytých 31 GB)
  • Diferenciálna kópia D1.5 v 0:00 6 divokých (36 GB)
  • Rozdiel kópie D1.6 vs 0:00 7 divoký (pokrytých 40 GB)
• Úplná kópia F2 o 0:00 8 divokých (kapacita 1014 GB)
  • Diferenciálna kópia D2.1 o 0:00 9 divokých (objem 12 GB)
  • Diferenciálna kópia D2.2 v 0:00 10 divokých (celkom 19 GB)
  • Rozdiel kópie D2.3 vs 0:00 11 divoký (25 GB)
  • Rozdiel kópie D2.4 vs 0:00 12 divoký (celkom 31 GB)
  • Rozdielová kópia D2.5 vs 0:00 13 divoká (pokrytá 36 GB)
  • Rozdiel kópie D2.6 vs 0:00 14 divoký (celkom 40 GB)

Pre túto dodatočnú sadu môžeme aktualizovať údaje v čase 0:00 v ktorýkoľvek z dní od 1 do 14. Na to potrebujeme vziať novú kópiu F1 pre dni 1-7 alebo novú kópiu F2 pre roky 8-14, aktualizovať ich v režime NORECOVERY a potom uložiť rozdielovú kópiu požadovaného dňa.

Ako to funguje naplno

Môžeme mať rovnakú sadu záloh a maloobchodných záloh ako v predchádzajúcom príklade. Okrem toho kroky RKZhT:

• RKZhT 1 na obdobie od 12:00 31 Pondelok do 12:00 2 divoký (približne 30 GB)
• RKZhT 2 na obdobie od 12:00 2 zúrivé do 12:00 4 zúrivé (približne 30 GB)
• RKZhT 3 na obdobie od 12:00 4 zúrivé do 12:00 6 zúrivé (približne 30 GB)
• RKZhT 4 na obdobie od 12:00 6 divokých do 12:00 7 divokých (približne 30 GB)
• RKZhT 5 na obdobie od 12:00 8 divokých do 12:00 10 divokých (približne 30 GB)
• RKZhT 6 na obdobie od 12:00 10 divokých do 12:00 12 divokých (približne 30 GB)
• RKZhT 7 na obdobie od 12:00 12 divokých do 12:00 14 divokých (približne 30 GB)
• RKZhT 8 na obdobie od 12:00 14 divokých do 12:00 16 divokých (približne 30 GB)

Obnoviť rešpekt:

1. Veľkosť RKZhT bude približne konštantná.
2. Záložné kópie môžeme spúšťať menej často alebo častejšie a možno aj častejšie, takže budú menšie.
3. Teraz môžeme aktualizovať stav systému kedykoľvek od 0:00 1., ak máme novú kópiu, do 12:00 16.

V najjednoduchšom prípade na obnovenie potrebujeme:

1. Zostávajúca kópia do aktualizácie
2. Zostávajúca rozdielová kópia do aktualizácie
3. Všetky RKZhT, od okamihu zostávajúcej rozdielovej kópie až do okamihu aktualizácie

• Úplná kópia F2 o 0:00 8 divoký
• Rozdiel kópie D2.2 o 0:00 10 divoký
• RKZhT 6 na obdobie od 12:00 22:00 do 12:00 12:00 hod.

F2 sa aktualizuje od začiatku, potom D2.2, potom RKZhT 6 do 13:13:13 dňa 10. Hlavnou výhodou modelu Full je, že máme na výber - buď zostane opäť vikorista alebo rozdiel kópia alebo NIE. Napríklad sa ukázalo, že kópia D2.2 bola zazipovaná a potrebovali sme aktualizovať údaje pre moment pred 13:13:13 22:00, potom pre model Simple to znamenalo, že sme mohli aktualizovať údaje iba pre moment D2.1. S Full - "DON" T PANIC ", máme nasledujúce možnosti:

1. Obnovte F2, potom D2.1, potom RKZHT 5, potom RKZHT 6 do 13:13:13 22:00.
2. Obnovte F2, potom RKZHT 4, potom RKZHT 5, potom RKZHT 6 do 13:13:13 22:00.
3. V opačnom prípade aktualizujte F1 a jazdite všetky RKZhT až po RKZhT 6 do 13:13:13 dňa 10.

Zdá sa, že druhý model nám dáva väčší výber.

A teraz je jasné, že sme ešte prefíkanejší. A pár dní pred haváriou (13:13:13 22:00) vieme, že dôjde ku havárii. Databázu aktualizujeme novou záložnou kópiou na aktuálnom serveri, čím eliminujeme možnosť sťahovania nových maloobchodných kópií alebo RKZHT, t.j. v režime NORECOVERY. Zakaždým po sformovaní RKZhT stagnuje na rezervnú základňu, ktorá sa odstráni v režime NORECOVERY. Wow! Ale teraz máme len 10-15 minút na aktualizáciu databázy, aby sme aktualizovali veľkú databázu! Myslím, že sme znovu vynašli mechanizmus doručovania protokolov, jeden zo spôsobov, ako znížiť prestoje. Ak prenášate dáta týmto spôsobom nie raz za periódu, ale nepretržite, potom dostanete zrkadlo, a ak základná tryska kontroluje, kým sa základné zrkadlo aktualizuje, potom je synchrónne so zrkadlom, ak nekontroluje, je asynchrónny.

Viac podrobností o funkciách vysokej dostupnosti si môžete prečítať v kapitole:

• Vysoká úroveň dostupnosti (komponent Databázový modul)
  • Správy od verejnosti o riešeniach s vysokou dostupnosťou
  • Vysoká úroveň dostupnosti. Mutualizmus a spolupráca

Ďalšie aspekty zálohovania

Túto časť môžete bezpečne preskočiť, ak ste prišli s teóriou a vaše ruky sa vŕtajú a pokúšate sa vytvoriť záložnú kópiu.

skupiny súborov

1C: Obchod sa v podstate nemôže zaoberať skupinami súborov. Jedna skupina súborov a to je všetko. V skutočnosti môže programátor alebo správca databázy v MS SQL vytvárať tabuľky, indexy alebo vytvárať tabuľky a indexy okolo skupiny súborov (v najjednoduchšom prípade okolo súborov). Je to potrebné buď kvôli zrýchleniu prístupu k akýmkoľvek dátam (ktoré sa nachádzajú aj na tých najpopulárnejších médiách), alebo kvôli obetovaniu dát ich umiestniť na lacnejšie zariadenie (napríklad maloobjemové resp. objemné údaje). Pri práci so skupinami súborov je možné pracovať priamo s ich záložnými kópiami a tiež je možné aktualizovať, prípadne obnovovať, takže všetky skupiny súborov musia byť „chytené“ naraz. migrácie RKZhT.

dátové súbory

Ak osoba umiestni údaje do rôznych skupín súborov, potom ak je v strede skupiny súborov veľa súborov, MS SQL Server do nich skopíruje údaje nezávisle (ak sú súbory spracované rovnako, pokúsi sa to urobiť rovnomerne). V aplikovanom bode sa pohľad používa na paralelizáciu vstupno-výstupných operácií. A z pohľadu záložných kópií je tu iný moment. Dokonca aj pre veľké databázy v ére pred SQL 2008 bolo bežným problémom vidieť neustále okno pre trvalú zálohu a cieľový disk pre túto zálohu to jednoducho nezvládol. Najjednoduchším spôsobom v tomto prípade bolo vytvoriť záložnú kópiu každého súboru (alebo skupiny súborov) do vášho okna. Súčasne s aktívnym rozšírením kompresie záložných kópií sa tento problém zmenšil, ale túto metódu možno stále brať do úvahy.

Kompresia zálohy

V MS SQL Server 2008 sa rock stal super-mega-ultra výkonným. Záložné kópie môžu byť z času na čas komprimované na hárok. Toto zmení veľkosť záložnej kópie databázy 1C 5-10 krát. A pre lekárov to vzhľadom na produktivitu diskového subsystému a úzke miesto DBMS znamená nielen zníženie efektivity šetrenia, ale aj ešte rýchlejšie zrýchlenie zálohovania (a stále väčší dôraz sa kladie na procesory, inak či je zaťaženie procesora na serveri DBMS úplne dostatočné).

Kým verzia 2008 mala len možnosti pre edíciu Enterprise (ktorá je dosť drahá), v roku 2008 R2 bola táto funkcionalita pridaná do verzie Standard, čo je veľmi potešujúce.

Nižšie pri analýze aplikácií nie je kompresia viditeľná, ale dôrazne vám odporúčam použiť kompresiu zálohy, pretože neexistujú žiadne špeciálne dôvody na jej zapnutie.

Jeden záložný súbor – veľa odvahy

Záložná kópia v skutočnosti nie je len súbor, ale skladací kontajner, do ktorého môžete uložiť veľa záložných kópií. Tento prístup má dlhú históriu (obzvlášť sa obávam verzie 6.5), ale v súčasnosti pre správcov „primárnych“ databáz, najmä databáz 1C, neexistujú žiadne vážne dôvody, aby tento prístup nepoužívali na zálohu – jeden súbor“ . Pre komplexný vývoj je dôležité zvážiť možnosť vložiť niekoľko záložných kópií do jedného súboru, inak nebudete môcť vikorist na všetko (alebo ak áno, potom budete môcť vyriešiť sutiny rádoby správca, ktorý bude môcť nekvalifikovane vikoristov c).

Kopa zrkadlových kópií

SQL Server má ďalšiu zázračnú funkciu. Záložnú kópiu môžete vytvoriť paralelne do dávky zariadení. Jednoducho si môžete uložiť jednu kópiu na lokálny disk a okamžite ju uložiť na back-end zdroj. Lokálna kópia je praktická, keďže aktualizácie z nej už boli dokončené, vzdialená kópia potom oveľa rýchlejšie prenesie fyzické obmedzenia hlavného databázového servera.

Aplikácie zálohovacích systémov

Dokončite teóriu. Je čas ukázať praxou, že celá kuchyňa funguje.

Nastavenie typickej zálohy servera pomocou plánu údržby

Táto časť vyžaduje, aby ste videli hotové recepty s vysvetleniami. Táto časť je veľmi únavná a dlhá na sériu obrázkov, takže ju môžete preskočiť.

Majster je zodpovedný za vytvorenie plánu služieb

Nastavte zálohovanie servera pomocou skriptov TSQL, vyskúšajte nejaké triky

Hlavným problémom je jedlo, ale čo ešte potrebujete? Čím to je, že si každý všetko upravil a stále funguje ako starý dobrý pán? Musíte bojovať so všetkými možnými scenármi? Plány údržby neumožňujú:

• Vikoristuvati dzerkalne rezervannya
• Vikoristovať úpravu obmedzenia servera od úpravy servera
• Nedovoľuje jednotlivcovi reagovať na núdzové situácie (nie je možné získať náhradu)
• Vikorista nepripúšťa bezpečnostné úpravy
• Je ťažké rozvíjať plány služieb (a udržiavať ich aktuálne) na veľkom počte serverov (možno už 3-4)

Nižšie sú uvedené typické zálohovacie príkazy

Úplná záložná kópia

Úplná záložná kópia pôvodného súboru (teda) a overenie kontrolných súčtov strán pred nahrávaním. Pri vytváraní záložnej kópie sa počítajú stovky pokroku

ZÁLOHA DATABÁZY NA DISK = N "C:\Backup\mydb.bak" S INIT, FORMÁT, ŠTATISTIKA = 1, KONTROLNÝ SÚČET

Diferenciálna záloha

Podobné - maloobchodná kópia

ZÁLOHA DATABÁZY NA DISK = N "C:\Backup\mydb.diff" S DIFERENCIÁLNY, INIT, FORMÁT, ŠTATISTIKA = 1, KONTROLNÝ SÚČET

RKZhT

Záložná kópia denníka transakcií

ZÁLOŽNÝ DENNÍK NA DISK = N "C:\Backup\mydb.trn" S INIT, FORMÁT

zrkadlová rezervácia

Často je potrebné manuálne vytvoriť nielen jednu záložnú kópiu, ale dve. Napríklad jeden môže ležať lokálne na serveri (ako keby bol po ruke) a druhý môže byť okamžite vytvorený, fyzicky odstránený a chránený pred nepríjemnými návalmi kŕčov:

ZÁLOHA DATABÁZY NA DISK = N "C:\Backup\mydb.bak", MIRROR TO DISK = N "\\safe-server\backup\mydb.bak" S INIT, FORMÁT

Dôležitý bod, ktorý sa často neberie do úvahy: používateľ, pod menom ktorého je proces MSSQL Server spustený, musí mať prístup k zdroju "\\safe-server\backup\", inak kópia skončí bez milosti. Ak je MSSQL Server spustený pod názvom systému, potom musí byť udelený prístup ku klientskej doméne „server_name$“, alebo jednoduchšie správne nakonfigurovať spustenie MS SQL pod menom špeciálne vytvoreného klienta.

Ak nezadáte MIRROR TO, nebudú existovať 2 zrkadlové kópie, ale jedna kópia rozdelená do 2 súborov podľa princípu zrkadlenia. A koža okolo nich bude mokrá.