Ātra DB datu atjaunošana

[girtas]

Labdien !

 

Gribēju lūgt padalīties ar pieredzi par labāko (ātrāko) risinājumu testa, akceptesta un demo (ne-produkcijas) datu bāžu datu atjaunošanā. Respektīvi ir uzdevums ātri "klonēt" vienas testa DB1 datus uz citu testa DB2. Risinājums šobrīd - sagatavojam DB1 dmp, importējam uz DB2 (pirms tam drop users, create users u.c. vajadzīgās darbības). Viss darbojas, taču aizņem pārāk daudz laika, kā arī ir čakars ar materialized view. Doma ir ar virtualizācijas (vai citiem) līdzekļiem procesu pāatrināt, veicot pēc iespējas mazāk operāciju. Viens varinats būtu klonēt virtuālo mašīnu, bet tad jāmaina OS paramateri (IP, host,..) un DB SID, global name (?) un nav skaidrs kas notiks EM aģentiem utt. Var apturēt abas DB un kopēt db failus, tad CREATE CONTROLFILE. Vai varētu izmantot kaut kādas Oracle fīčas (Oracle VM, ?)

 

HW vēl nav, tāpēc var plānot optimālāko konfigurāciju. Datu faili var būt lokāli (bez ASM), nav vajadzīga redundance, nav archlogu, nav RAC, var būt downtime.

 

G.

[Sandijs]

Sveiks,

Ja runā par labāko (ātrāk) risinājumu, tad jāprecizē budžets un, piemēram, vai plānots izmantot Enterprise Edition, kā arī, ko īsti nozīmē "ātrāk" ? Par kādiem apjomiem ir runa?

Akcents uz "mazāk čakara" vai tomēr "pēc iespējas ātrāk dabūt datus no 1 db otrā"?

- var optimizēt import procesus

- var atteikties no import un strādāt ar pilnu db dublicēšanu/kopēšanu (ja izmanto standard edition bez paralelizācijas iespējām, tad OS līmenī pārkopēt failus un pārkonfigurēt DB varētu būt ātrāk)

- var izmantot datu masīva  (NetApp) vai citas iespējas taisīt/atjaunot/izmantot snapshotus;

- var ieviest 2 vai vairāk rezerves DB variantu - kamēr dažas tiek izmantotas, citas tikmēr atjauno "pa vecam" lēnām un prātīgi;

- var ieviest 2 standby datu bāzes (EE + arhīvlogi), kamēr viena visu laiku tiek sinhronizēta, otra tiek izmantota testiem. Tiklīdz vajag svaigākos datus, pārtraucam standby atjaunošanas procesu un sākam lietot kā pilnvērtīgu DB. Ja izmaiņu apjomi nav lieli, tad mierīgi varam izmanto restore pointus un flashback database, lai standby visu laiku nav jāinicializē no jauna;

Sandijs

 

G.

--
Jūs saņēmāt šo ziņojumu, jo abonējāt Google grupu "Latvian Oracle User
Group" grupa.
Lai nosūtītu ziņojumu šai grupai, sūtiet e-pastu uz
lv...@googlegroups.com
Lai redzētu papildiespējas, apmeklējiet šo grupu
http://lvoug.lv

[Māris Gabaliņš]

Hi, 

Var uzlikt uz VMware un klonēt.

Tad atjaunojas ne tikai Oracle bet arī viss kas cits, kas verētu tikt izmantots.

ar cieņu

Māris

2013/1/15 Sandijs <san...@gmail.com>

--
ar cieņu
Māris Gabaliņš

GSM. +371-29242193 Skype: mgabalins

http://theartofsystems.com/
http://www.sunberry.lv/

[Andrejs Vorobjovs]

Sveiki,

Es domāju ātrākais variants ir pārkopēt datafailus un pārtaisīt controlfailu un pārkonfigurēt EM aģentu [ID 1099271.1]. Tad būs pilna kopija bloks pret bloka ar visam ieslēgtam featurem. Jo ar Export import var daudz ko aizmirst un pilno identisko kopiju nekad nedabūsi. Cik es saprotu jūs izmantojat <=10g versiju. Sakot  ar 11 exp/imp jau ir desuportets un ja jūs lietosiet EXPDP un IMPDP tad tur ātrums uzlabojies x10 reizes un tad kad taisi importu ar IMPDP neobligāti taisīt lietotāju, taisās automātiski, galvenais lai būtu vajadzīgi  tablespaci.

 Bet taisīt datafailu copiju labāk, ja ir atļauts downtime. Vel labāk ja jums starp production un preproduction ir viens tīkls tad DB clone(DUPLICATE TARGET DATABASE TO xxx). Es personīgi taisu RMAN 11 compreseto kopiju uz production un kopēju caur JUMPSERVERI uz preproduction serveri, jo mums nav caurumi starp production un preproduction un tad atjaunoju ar RESTORE CONTROLFILE  -> restore database -> switch datafile all -> recover database-> RESETLOGS.

Pats ātrākais manā vidē  ir ar Backupserveri(SBT_TAPE). Respektīvi pateikt SBT_TAPE klientam ka tev ir jauna IP(noradīt pre-production server IP) un atjaunot nakts backupu un arhivlogus.

Labs un dārgs risinājums mums eksistē ar masīva sinhronizācija. Respektīvi, datafailu klons uz citu masīvu, tad kad vajag apturi replikāciju piestartē DB kopiju, testējies. Ieslēdz atkal replikāciju/sinhronizāciju un tad pēc vajadzības var dabūt svaigu kopiju no dzīvas. Te būs tikai wizard podziņas jāspiež un jāpalaiž Oracle startup skripts.

Ir arī VM image sinhronizācija ar masīvu, tur arī dārgi, bet kad nokonfigurēsi visu tad atjaunošana ļoti ātrā.

 

p.s. jūs par savu vidi neko nepateicat grūti piedāvāt  ātrāko. Tiklā uzbūve, vai ir SBT_TAPE serveris, masīvs, Oracle versija, vai ir VMware vai Oracle VM, budžets. Jo lielāks budžets, jo ātrāka atjaunošana. Var sataisīt vidi kur var pacelt kopiju pēc 10 sekundēm citā tiklā.

 Andrejs.

[Andrey Chervonets]

Kas ir labākais, atrākais - atkarīgs no resursiem un kā jums prod/dev/test vides ir organizētas, downtime prasības utt.

Jau bija nosaukts:

1) clone VM (ja ir virtualizēta vide)

2) copy Db + recreate controlfile (arī var pārsaulk un nomainīt DB ID ar nid utilitu)

2,1. offline (cold) copy

2.2 online  (hot) copy: switch DB/TBS backup mode on , copy, switch backup mode off

a) copy DB or DB-files one by one

b) make snapshot at storage level (ļoti populārs NetApp gadījumā, bet Linux LVM arī mak taisīt snapshots, ja kāds nezina)

3) exp/imp

4) expdb/impdb

Vēl viena opcija ar RMAN palidzību

5.1 RMAN DUPLICATE komanda (sameklē note metalinkā - tur bija smuki aprakstīts, vai RTFM)

5.2. Backup DB ar RMAN, un kur vajag Restore+Recovery ar RMAN

6. Ja tas ir 10g+ un Flashback DB fičas tiek izmantotas - izmantojam vairākas inkarnācijas (restelogs) iespējas 

step1 - 1 reizi taisam klasistu klonu kā priekš Stand By (bez DG avi ar DG)

step2 - do testing DEV/TEST vide

step3 - kad vajag svaigu klonu

testā DB:

step 3.1  flashback DB līdz brīdim kād bija pēdējo reizi pielietots archive-logs no produckijas (attiecīgi pēdēja clone refresh laikā)

step 3.2  apply svaigas archive-logs  no prod par attiecīgu periodu

step 4 - go to step 2

7. Gadījumā, ja mainas tikai daati dažās tabultelpās var noderēt exp/imp ar Transfrerable Tablespaces.

Tagad liekas saraksts būs pilnāk. :)

Kad der jums - tev pašam jāizrēķinā. Vai var pieteikties uz konsultāciju kolēģiem ar lielāku pieredzi.

Ar cieņu,

Andrejs Červoņecs
-------------------------
SIA CoMinder
http://www.cominder.eu/
 

[girtas]

Paldies par atbildēm !

 

Licence - Standard edition, 10g. Apjomi ap 100 GB uz vienu datubāzi, kopā 10 bāzes .
Budžets nav liels, bet ir paredzēts jauns serveris ar kopēju disku masīvu un visas testa bāzes atradīsies tur. Produkcija ir citur un ja ir nepieciešami dati no produkcijas testa vidēm, tad tas notiks ar exp / imp (šiet arī nav prasības par ātrumu). Ātri ir jāatjauno dati no vienas testa/development vides uz citu, jeb precīzāk testa bāze jāatdod akceptesta bāzei un tālāk demo bāzei. Sveros par labu virtualizācijai (VMWare, RedHat, Oracle VM - brīva izvēle, ko rekomendējiet ?), jo tad varētu neatjaunot datus, bet pacelt visu mašīnu ar citu nosaukumu. Jautājums ir kāda būtu optimālā konfigurācija attiecībā uz datu failu glabāšanu ? Katrai VM savs "lokālais" disks (bez ASM) ? Pluss - var kopēt datufailus starp VM, ja nepieciešams un izmantot RMAN vai copy database.

Vēl, cik ir liela problēma nomainīt DB nosaukumu (pēc VM klona) - vai pēc tā strādās EM, listener etc, vai to visu izdara NID utility ?

 

G-as.

[Andrejs Vorobjovs]

Sveiki,

1. Par virtualizāciju  no Oracle rekomendācija ir ORACLE VM, jo neko citu viņi neatbalsta kopā ar DB, bet stādās arī VMWARE un RED HAT VM, šeit viennozīmīgas atbilde nav.  Tā ir brīvprātīga izvēle. Ir baumas kā VMWARE ir labāk, bet ar ko nepateikšu. Cik es zinu ORACLE VM ir arī lētāk un Enterprise featurem bagāts.

2.NID utilīta tikai pārsauc SID datubāzei zem controlfailiem un dbf failiem, to darīt neobligāti, gadījumā ja jūs taisiet kopiju uz cita IP. Ja kopēsiet atpakaļ uz to pašu hostu tad gan vajadzēs. EM aģentu, Listeneri būs jāpārkonfigurē/ jāpareinstale pēc IP host maiņas abos gaidījumos ar NID vai bez NID pielietošanas.

Andrejs.