Dotaz: Algoritmus pro replikaci databaze

[Petr Susak]

Dobry den, v praci resim problem ze potrebujeme obcas (1x za mesic) zreplikovat priblizne polovinu databazovych tabulek z produkcniho systemu na vyvoj, databaze je oracle. Produkcni databaze je opravdu velika (15TB) a ja chci napsat software/skript ktery to udela co nejefektivneji otazka zni jak? Jako nejjednodussi a nejmene efektivni je asi v cilovem systemu promazat kompletne pozadovane tabulky a pak je z produkce cele zkopirovat coz by trvalo neumerne velke mnozstvi casu, nejvetsi tabulka ma 1TB :). Urcite musi existovat nejaky efektivni zpusob jak nejsnadneji zjistim ktere radky se lisi v produkci a vyvoji a ktere radky kompletne chybi ve vyvoji a pak pouze tyto radky prekopirovat z produkce na vyvoj. Urcite to nedelat zpusobem nactu radky v produkci a pak delam select za selectem jestli konkretni radek je i ve vyvoji a kdyz neni tak ho tam kopiruju. Proste co nejefektivnejsi algoritmus s nejnizsimi naklady na prenosovou kapacitu (produkce > vyvoj a opacne), CPU, IO atd. Diky

Odpovědi

[Tomáš]

Nelze použít metodu s replikačním serverem? Měl by jste tři databáze. Produkce, replika, vývoj. Z produkce na repliku průběžně replikujete to, co potřebujete na vývoji. V požadovaný čas databázi vývoj nahradíte kopií databáze replika. Replika se stále replikuje z produkce.

Nebo jsem to pochopil špatně?

[Ivan]

Obavam se, ze mate dva pozadavky ktere jdou vice-mene proti sobe.
1. Chcete kopirovat jen cast DB
2. Vase database je dost velika.
Protoze je ta databaze velika tak nemuzete pouzit replikaci na urovni radek. Replikaci na urovni bloku taky nemuzete pouzit protoze chcete klonovat jen cast databaze. Pokud chcete cast tabulek(treba jen jedno schema) a nepotrejute taky cast radek, tak se zkuste podivat na "transportable tablespaces". Popr. muzete pouzit "tablespace point in time recovery". Pokud byste mel uz na zdrojove databazi tu podmnozinu tabulek v dedikovanem tablespace, tak by to slo klonovat za pouziti RMANu. PS: v Oracle je nekde procedura, ktera vam rekne zda tabulky v jednom tablespace zavisi na jinem tablespace. Ono je tech moznosti vice, ale vsechny zavisi na fyzickem layoutu dat ve zdrojove databazi. A taky na tom, jestli ho muzete zmenit nebo ne.

[Ivan]

Joo jeste jsem si vzpomel - to co hledate je "self-containing tablespace restore". Udelate tzv. cross-site restore. Rekneme, ze mate na produkci tablespaces: SYSTEM, SYSAUX, UNDO, TBLSPACE_A, TBLSPACE_B a TEMP. VSechny tabulky ktere potrebujete jsou v TBLSPACE_A.

Pomoci RMANu na DEVu zrestorujete SYSTEM, SYSAUX, UNDO, TBLSPACE_A. (TBLSPACE_B se vynecha). Ta obnovena databaze pujde normalne nahodit a cela procedura nebude mit zadny vliv na produkcni system.

[l0gik]

Co mít v každý tabulce datum posledního updatu u každýho záznamu a exportovat jenom ty s novym datem? Popř. jenom bool flag: exportováno. Dá se to udržovat automaticky triggerem a ty trigery přidat skriptem ke všem tabulkám najednou. Asi lepší než to ale dělat v userspace je udělat si logical standby database a použít redo logy: http://www.orafaq.com/node/957, asi vy výsledku i s méně práce.

To vše řeší jen změny na straně produkce, změny na straně vývoje bych pak řešil asi další instancí databáze: jednu bych nechával čistou a na ní aplikoval redo logy, a tu pak zkopírovat celou: u stroje na vývoj nevadí, že v noci v sobotu na neděli hodinku nepojede, protože se bude obnovovat.

[kuka]

Toto se asi hodne odviji od frekvence zmen na te produkcni instanci a logice ulozeni dat. Predpokladam napr., ze tabulka velikosti 1TB bude nejak partitionovana. Neni treba pro nektere partitions zarucena nemennost? A podobne, mnozina zmen se muze znacne omezit a v principu pak nemusi byt nutne uplne vyloucene postupovat i po radcich, napr. podle SCN, i kdyz idealni to asi nebude. Pokud to rozumne omezit nejde a je treba pocitat se zmenou kdekoliv, tak nakonec nejrychlejsi muze byt presouvat cele tablespaces, to muze bezet de facto rychlosti disku/site. Pripadne asi existuji zalohy te produkce, takze vyvoj se muze plnit odtamtud, coz produkci usetri vsech dopadu - ne vzdy je mozne pozadovat, aby kvuli vyvoji probihaly jakekoliv dodatecne cinnosti na produkci at uz s dopadem na datovy model (to byva fakticky vylouceno), nebo na vykon (rozdilove dotazy co se zmenilo apod.).

[Petr Susak]

Tak jsem nasel popis tohohle algoritmu: http://www.maatkit.org/doc/mk-table-sync.html#algorithms , tak to skusim implementovat i kdyz si nejsem uplne jisty jestli ho chapu dobre.

[l0gik]

Pochybuji, že je to správná cesta. Jestli to dobře chápu, tak to počítá checksumy a počítat checksumy z 15TB....

Ty potřebuješ něco, abys jednoduše bez procházení celé db poznal, co se změnilo. Což lze buďto použitím redo logů (to je ta standby databáze) nebo na aplikační vrstvě nějakejma flagama či časem modifikace.

Jakmile musíš procházet celou db, tak je to na nic.

[mfo]

Ahoj, Tiez rozmyslam ako vymysliet znova koleso. Tak po 1. na kej verzii oracle Db bezi? aj na 11g skus hladat nieco o replikacii. 2. co tak backup/restore - ak mas zapnuty arch mod. ( nevyhoda ze sa replikuje cela db) 3. ak chces len cas dat.. expdp/impdp

Je tu este jedna moznost ako to cele vyriesit a to je split mirror na urovni storage.

Ale po pravde - popis co potrebujes je velmi malicky. Potrebujeme vediet viac detailov. Alebo ak nemoze refreshnut celu db, ale napr len schemu... postup bude iny. hod sem viac detailov.

[Iq]

Myslim si ze to jde vyresit dbLinkem a prikazem Merge

Pripadne pouzit materializovane View o5 pres dblink a v pripade potreby jej do synchronizujete.