RESTORE iz druge baze pomocu TSQL

Zelim da napravim JOB koji ce mi svake noci restorovati TEST bazu od PRODUKCIONE. Na taj nacin zelim da omogucim azuriranu TEST bazu korisnicima koji... testiraju nesto :-)

E sad, imam RESTORE statement, ali ne moze (ili ja ne vidim!?) da se restoruje iz postojece baze. To mi je cudno, jer SSMS nudi to kao mugocnost, kad se baza restoruje iz druge baze i pritom koristi najsveziji (ili niz najsvezijih) bekap. Ta mi je opcija jednostavna, cesto je koritim i cini mi se da je korak viska (odradicu ga ako moram, naravno :-( ) pravljenje full bekapa produkcione baze, pa tek onda restore na test bazu.

Je l neko radio nesto slicno i kako je to odradio?

Potpis

Uhvatili ste me nespremnog

Snapshot replikacija?

Potpis

Every hamster has his day.

Nesto nisam siguran da moze restore (ili kopija kako god) a da ne koristi backup vec direkno bazu? Puko kopiranje bi trajalo predugo, a MS SQL 2005+ nudi Database Snapshots, ali to nije bas isto sto i "kopija" baze, ima svoja ogranicenja.

Kroz SSMS ako radiš restore, i odabereš da želiš restore from database, on ti prikazuje SAMO baze koje imaju backup u instalacijskom folderu (program files -> ms sql server -> ... -> backup). Ako nema baza svoj backup u tom folderu, nemožeš ni napraviti restore from database jer nema source za restore. Što dovodi do zaključka da nema restore-a bez backupa. E sad ti imaš dvije mogučnosti. Prvo raditi backup pa onda restore baze koja ti treba. A drugo i pametnije rješenje koje je baš namjenjeno za svrhu "ujednačavanja" dvije baze jeste replikacija.

Stoga bi ti bilo bolje da malo pogledaš po netu o replikaciji, nego da prihvatiš prvo rješenje. Kasnije ćeš i shvatiti prednosti ove metode.

Koce je spomenuo Snapshots, ali kroz njega možeš raditi samo select, jer je to zapravo preslika original baze u nekom trenutku u kojem je snapshot napravljen.

Mislim da nije istina da baza mora imati bekap u instalacionom folder, stavise siguran sam u to. Dovoljno je da IMA BEKAP, a ssms zna putanju do bekapa (gde je inicijalno snimljen). Ova opcija posle koriscenja full bekapa ide prirodnim nizom bekapa (dakle, poslednji diff bekap, pa niz trn bekapa) i na taj nacin dovodi bazu u stanje najblize moguce trenutnom stanju SOURCE baze.
Posto ja te bekape imam, redovno se prave i odrzavaju, ocekivao sam da mogu jednostavnom opcijom u RESTORE komandi da uradim isto ono sto uradim iz ssms-a, jer je bas to ono sto mi treba.
Sto se tice replikacije, podesavao sam kompleksne MERGE replikacije i ne zelim time da se bakcem za ovu trivijalnu potrebu. Znam da su snapshot replikacije jednostavnije, ali ne znam da li bih imao posla sa ogranicenjima na drugoj strani - treba mi baza koja je u potpunosti funkcionalna i koja ni koji nacin nece zavisiti od SOURCE baze. Zato nisam uzimao u obzir replikaciju - mozda gresim.

Ja sam podesio da radi COPY_ONLY full bekap, a zatim u sledecem koraku da iz njega radi RESTORE. Opet kazem, s obzirom da ja te bekape vec imam, cini mi se da tu gubim vreme i radim bespotreban korak.

Hvala u svakom slucaju.

Potpis

Uhvatili ste me nespremnog

Ja sam baš pokušavao kroz SSMS kad sam pročitao tvoju poruku da napravim RESTORE from database. I ako baza nema backup u tom folderu (koji sam ja nazvao instalacijski) onda SSMS ne može dokučiti source za restore. Ali kada sam prebacio backup u taj folder, tada je SSMS uspio da "pronađe" source i RESTORE je prošao. E sad, ti spominješ inicijalni folder, onda bi to trebao biti taj što sam ja nazvao instalacijski (znači vjerovatno mislimo na isto samo drugačije nazivamo). Probaj taj isti backup koji ti se nalazi u tom inicijalnom folderu CUT-at (ne kopirat) na desktop pa probaj napraviti RESTORE i vidit ćeš da neće iči jer ga ne može SSMS pronači.

i još jednom bi ti ipak predložio replikaciju, imaš dosta video tutoriala na netu po 15-minuta gdje je objašnjen korak po korak i nije tako teško za napraviti, a promjene ti se bilježe u istom trenutku kad su i napravljene, tako da u svakom trenutku imaš u testnoj bazi "prave" podatke.

Ovo prvo sto kazes je ok, razumeli smo se. Dakle, bekap mora biti u folderu u kojem je prvi put snimljen - to je ok. Tamo ce ga ssms potraziti.

Ovo drugo meni ni ne odgovara. Verovatno mislis na transakcionu replikaciju, gde se transakcije na PROD bazi automatski prenose u TEST bazu. ALi to meni ne odgovara. Zelim da se na TEST bazi radi nezavisno od desavanja na PROD bazi. Ako bi ih vezao replikacijom, bojim se da bi mi desavanja na PROD bazi menjala zalihe, pravila dokumente i svasta... na TEST bazi, a ja to ne zelim. Sve sto zelim jeste da se nocu, u okviru redovnih maintenance poslova, TEST baza azurira sa produkcionom,... u toku nastupajuceg dana nije bitno da se azurira svaki korak, bitno je da TEST baza ne kasni npr. mesec dana za PRODUKCIONOM pa pokazuje totalno druge cene, kupce i slicno. To povremeno "gazenje" TEST baze za sada ja radim rucno (na zahtev) i smara me - otud moja zelja da sve sredim sa ovakvim nocnim JOBom a ne zato sto imam potrebu da TEST bude bitno sinhronizovana sa PROD bazom.

Hvala u svakom slucaju na zelji da pomognes :-)

Potpis

Uhvatili ste me nespremnog

Moze naravno restore i ako je bekap na bilo kojoj drugoj lokaciji, samo je potrebno Mng Studio navesti na njega. Cak i ja mislim da ako uradis backup na bilo koju lokaciju i ne sklanjas ga odatle, da ce ti MnsStd dati tu lokaciju za restore, tj pamti lokaciju poslednjeg uspejsnog backup-a. A sto se tice replikacije, i za to ti treba backup, posebno za snapshot jer koliko se sjecam ona upravo to i radi - backup i restore na subscriber-a. I pri tom on dalje ne zavisi od source-a (tj publishera). Ja ipak najvise volim jednostavan job sa tri koraka - backup, move (ili copy bak fajla) i restore - sve ti je pod kontrolom a nije komplikovano.

i mene bi zanimala automatizacija (job) Restora differential backup-a jedne baze nad drugom bazom.