Sacuvajte svoj kôd (Backup your source code)

Monday, 02.04.2007 – Dejan

Zamislite ovu situaciju…

Prepravili ste jedan veliki paket ili proceduru na testnom serveru, odradili nekoliko testova i odlucili taj paket ili proceduru prebaciti na live production server. Uvjereni ste da bi i na tom serveru sve trebalo raditi bez problema.

Medjutim, nakon sto ste prebacili paket ili proceduru na live server, vec nakon par minuta javljaju se korisnici i kazu kako im program ne radi, kako dobijaju neke greske itd.

Ali, istestirano je i sve bi trebalo da radi…” – zbunjeno odgovarate.
Prije par minuta je sve radilo, a sad odjednom ne…” – nestrpljivi i ocajni korisnici s druge strane.

E sad, najelegantnije rjesenje bi bilo vratiti nazad prethodnu verziju paketa ili procedure, dok se ne ustanovi uzrok greske.

Ali avaj – vi niste osigurali sigurnosnu kopiju prethodne verzije tog paketa ili procedure, a u CVS-u ne mozete u kratkom roku izabrati, koja je prava i ispravna verzija!?

Takav scenario sam dozivljavao i u prethodnoj firmi, a i u ovoj. Dzaba govoriti kolegama da uvijek naprave backup trenutno ispravne verzije…

Zbog toga sam odlucio doskociti tom problemu i automatizovati kreiranje sigurnosne kopije (source code backup).

Evo kako sam ja to uradio…

Cilj: Prije nego sto programer ubaci novu verziju nekog paketa ili procedure, kompletan source code aktuelne verzije treba biti sacuvan u slucaju da novija verzija ne funkcionise kako treba.

Realizacija: Napravio sam jedan “ON DATABASE trigger“, koji se okida na database event “BEFORE CREATE“, sto znaci da ce source code aktuelne verzije biti sacuvan PRIJE nego sto se nova verzija ubaci u bazu. U triggeru mozemo odabrati nacin cuvanja source code-a: u datoteku ili u neku tabelu. Ja sam odabrao drugu opciju, jer je optimalnija od prve (brza je, preglednija, ne moram se bakcati sa UTL_FILE_DIR podesavanjima i td.).

Dakle, kreirao sam tabelu pod nazivom TAB_BACKUP_SOURCE i u njoj jedno CLOB polje u koje ce biti smjesten source code aktuelne verzije (download: DDL izraz za kreiranje tabele TAB_BACKUP_SOURCE).

Nakon sto je tabela kreirana, mozemo kreirati i “ON DATABASE” trigger. Za selektovanje source code-a mozemo koristiti dvije metode: DBMS_METADATA.get_ddl ili preko data dictionary “pogleda” DBA_SOURCE. Procedura GET_DDL u paketu DBMS_METADATA nam vraca kompletan DDL izraz (DDL je skracenica od Data Definition Language) potreban za rekreiranje doticnog objekta (paket, procedura, trigger i td.), ali se u njemu nalaze i suvisni podaci, koji nama nisu potrebni, tako da sam ja za “poglede” (views) odabrao metodu DBMS_METADATA.get_ddl, a za ostale objekte (paketi, procedure, funkcije, triggeri) sam odabrao DBA_SOURCE.

Za kreiranje ovog triggera je potrebna DBA privilegija (DBA role), ali niposto nemojte da koristite SYS nalog, nego ukoliko vec nemate jednog pomocnog DBA korisnika, onda kreirajte jednog i dodijelite mu DBA rolu.

Ako je taj uslov ispunjen, kreirajte “ON DATABASE” trigger (download: DDL izraz za kreiranje triggera).

Gotovi ste? Odlicno!
Napravite par testova da se uvjerite, kako je sve u redu.

Nakon ovoga se vise ne morate brinuti zbog nemarnosti ili lijenosti vasih kolega programera. 🙂

  1. 5 Responses to “Sacuvajte svoj kôd (Backup your source code)”

  2. Jeste da je post objavljen poodavno ali evo jedno pitanje:
    Zasto “niposto nemojte da koristite SYS nalog”?

    By igor on Nov 5, 2007

  3. Zato sto sve “user defined” stvari ne bi trebale biti kreirane u SYS shemi. SYS shema je zamisljena kao “interna” shema u bazi, namjenjena samo za Oracle software, a ne za korisnicke aplikacije i prckarije.

    Osim toga, ukoliko kreiras neki “user defined” objekat SYS shemi (tabelu, trigger, view i sl.), onda se moze desiti da ti Oracle Support otkaze saradnju, jer po njihovim uslovima, ne smijes nista kreirati u SYS shemi. Nama se to desilo prije godinu-dvije kad smo imali neke globalne kontekste (za sys_context funkciju u parametrizovanim view-ovima).

    By Dejan on Nov 5, 2007

  4. OK, hvala za odgovor. Naravno to onda prevashodno vazi za produktivnu bazu dok se za test sisteme valjda moze malo “progledati kroz prste” 🙂 Mi cesto ceprkamo po SYS shemi ali istina je da su to sve promene u bazi u svrhu raznih testova na simulatorima.

    By igor on Nov 5, 2007

  5. Ni na test sistemima ne bi trebali koristiti SYS shemu, jer ona jednostavno nije namijenjena za bilo kakve korisnicke objekte (procedure, funkcije, triggere i td.).

    Ako ti zaista treba DBA privilegija, onda kreiraj jednog korisnika, koji ce imati DBA privilegiju, cime rjesavas mnoge potencijalne probleme…

    By Dejan on Nov 6, 2007

  6. Citam ovaj tekst dok mi se izvrsava skripta sa sys userom… Hvala na tesktu, kao i komentarima!

    By Vladimir on Jul 4, 2013

Post a Comment