ORACLE PILLAR #1

Zašto Oracle sistemi padaju u produkciji (i kako to sprečiti)

Produkcioni pad nije incident. To je posledica dizajna.

Uvod: Produkcioni pad nije slučajnost

Većina Oracle sistema ne pada zato što je Oracle nepouzdan.

Padaju zato što sistem oko Oracle‑a nikada nije dizajniran da preživi vreme, pritisak ili proveru.

U produkciji, problemi se retko pojavljuju iznenada. Oni se akumuliraju.

Godinama sve deluje stabilno:

Onda se desi jedno od sledećeg:

I sistem kolabira.

Ne zato što je Oracle prestao da radi — nego zato što sistem nikada nije bio dizajniran da objasni sebe.

U realnim produkcionim okruženjima, Oracle retko jeste najslabija karika.

Pravi problemi su arhitektonski:

To nisu operativne greške. To su dizajnerske odluke — često rane, često neprimećene.

Timovi veruju da su “best practices” dovoljne. Konfigurišu RMAN. Uključe logovanje. Tune‑uju parametre. Dokumentuju procedure u Confluence‑u.

Ipak, kada nešto pođe po zlu, uvek se vraćaju ista pitanja:

U većini Oracle sistema, odgovori ne postoje.

Zato produkcioni pad nije slučajnost. To je neizbežan rezultat sistema koji Oracle tretiraju kao bazu, a ne kao system of record.

Kada se Oracle svede na storage:

Sistem možda radi — ali ne može da izdrži pritisak.

Ovo nije članak o tuning savetima, listama parametara ili Oracle feature‑ima.

Ovo objašnjava:

Ne dodavanjem alata. Ne zapošljavanjem više DBA‑eva. Već promenom načina na koji sistem tretira istoriju, odgovornost i dokaz.

Ako Oracle mora da preživi audit, migracije, promene timova i vreme — ovo je mesto gde realan posao počinje.

Failure Pattern #1: History That Can Be Rewritten

U većini Oracle produkcionih sistema, istorija se tretira kao promenljiva.

Ne namerno. Ne zlonamerno. Strukturalno.

Redovi se update‑uju. Vrednosti se prepisuju. Prethodna stanja nestaju.

Ovo je najčešći root cause kada sistemi padnu pod audit, recovery ili spor.

Iluzija ispravnosti

Tehnički, sistem radi: UPDATE prolazi, constraints su zadovoljeni, transakcije se commit‑uju, korisnici vide „tačne“ trenutne podatke.

Ali sistem je izgubio sposobnost da objasni sebe.

Trenutak kada se failure vidi

Ovo ostaje skriveno dok sistem ne bude ispitan:

Tada se očekuje da sistem odgovori:

U sistemima sa prepisivom istorijom, odgovori više ne postoje.

Zašto je UPDATE pravi problem

Problem nije SQL UPDATE kao takav. Problem je UPDATE bez kvalifikacije — prepisivanje poslovno značajnih podataka bez traga, bez namere, bez odgovornosti.

„Imamo logove“ nije odgovor

Logovi nisu istorija. Nisu autoritativni, mogu se rotirati, filtrirati ili izgubiti. I pravno su slabi.

Najvažnije: logovi nisu system of record. Kada se log i podaci ne slažu, nema ground truth‑a.

Tiha erozija poverenja

Vremenom, timovi prestaju da veruju starim podacima. Izveštaji se ručno „ispravljaju“. Objašnjenja zamenjuju dokaze.

Sistem radi — ali istina više ne živi u njemu.

Zašto ovo ne može da se popravi kasnije

Prepisiva istorija ne može retroaktivno da se popravi. Ne možeš rekonstruisati prošla stanja, dokazati nameru ili odgovornost.

Jednom kada je istorija izgubljena — izgubljena je zauvek.

Arhitektonski zahtev

Zaključak

Failure Pattern #1 nije bug. Nije pogrešna konfiguracija. Nije nedostatak DBA znanja.

To je posledica sistema koji Oracle tretiraju kao mutable storage umesto kao čuvara istine kroz vreme.

Failure Pattern #2: Backups Without Recovery Reality

Većina Oracle sistema ponosno izveštava da backup uspeva. RMAN je zelen, schedule radi, dashboard „OK“.

Ipak, kada recovery stvarno zatreba — sistem pada.

Backup ≠ recovery

Backup dokazuje samo jedno: podaci su kopirani. Ne dokazuje da se sistem može vratiti u konzistentno stanje, da su podaci pouzdani ili da poslovanje može da se nastavi.

Kada se iluzija raspadne

Ovo se vidi tokom korupcije podataka, slučajnih brisanja, neuspelih deploy‑a, storage failure‑a, ransomware incidenta ili audit recovery testa.

Najopasnija pretpostavka

„Ako RMAN restore prođe, sistem je OK.“ Ne.

Restore garantuje fajlove, control files, redo. Ne garantuje poslovnu istinu.

Recovery bez istorije je pogađanje

Posle restore‑a, prepisani redovi ostaju prepisani, obrisane činjenice ostaju obrisane, odobrenja i namera su izgubljeni.

Zašto testovi recovery‑ja lažu

„Smoke test“ potvrđuje da aplikacija radi, ne da je istorija ispravna ili da su finansije tačne.

Data Guard ne popravlja ovo

Replikacija širi i pogrešnu istoriju. Availability nije isto što i correctness.

Recovery je arhitektonska osobina

Ako sistem ne može da objasni šta se desilo, recovery vraća stanje — ne istinu.

Zaključak

Problem nisu backupi. Problem je što backup štiti podatke, a ne istinu.

Append‑Only obrasci (Schema Patterns)

Arhitektura, ne SQL recepti.

  1. Fact Table (Append‑Only Core) — činjenice se nikad ne update‑uju ili brišu.
  2. State Projection — state se derivira, nije autoritet.
  3. Change as Fact — promene su nove činjenice.
  4. Explicit Responsibility — svaki fact ima aktera i autoritet.
  5. Time as First‑Class Data — vreme je poslovna istina.
  6. Recovery From Facts — state mora biti rebuild‑ovan iz facts.
  7. Read‑Only Verification — audit čita facts, ne mutable state.
  8. Deletion Is a Fact — prestanak važenja je nova činjenica.
  9. Tool Independence — pravila važe svuda.

Ako možeš da rebuild‑uješ state iz facts, backup postaje zaštita. Ako ne — backup je kopija laži.

Failure Pattern #3: Performance Tuning Without Accountability

Performance tuning se radi pod pritiskom. Sistem uspori. SLA kasni. Neko mora da “popravi”.

Dodaje se indeks, menja se parametar, prepisuje query, povećava memory. Sistem postaje brži — i dugoročno krhkiji.

Performanse nisu neutralne

Svaka optimizacija menja ponašanje. Ali u većini sistema to je nedokumentovano i bez konteksta.

Kasnije pitanje

Zašto je ovaj indeks? Zašto ovaj parametar? Može li da se ukloni?

Odgovor: „Ne znam, to je rađeno tokom incidenta.“

Zaključak

Problem nije loš tuning. Problem je tuning bez odgovornosti.

Inkrementalna migracija: Mutable → Append‑Only

  1. Fact Ledger — dodaj FACT_LEDGER bez diranja legacy tabela.
  2. Dual‑Write — critical akcije upisuju i legacy i fact.
  3. Read‑Only Verification — audit čita samo facts.
  4. State Projection — shadow state iz facts, bez uticaja.
  5. Switch Authority — facts postaju izvor istine selektivno.
  6. Freeze Legacy Mutations — zabrani UPDATE bez fact zapisa.
  7. Optional Cleanup — refactor kasnije.

Istorija počinje danas — i nikad se više ne gubi.

Failure Pattern #4: Migrations Treated as Technical Tasks

Migracije se planiraju kao tehnički projekti. Ali migracije su istorijski događaji, ne copy operacije.

Lažna definicija uspeha

„Aplikacija radi“ nije isto što i „sistem je sačuvao istinu“.

Rollback ne vraća realnost

Biznis se dešava tokom migracije. Rolling back state ne vraća realni svet.

Zaključak

Migracije menjaju značenje i ponašanje. Ako se razlozi ne zabeleže — rizik raste zauvek.

Oracle primeri mapirani na failure pattern‑e

Oracle radi tačno ono što mu kažeš. Ne čuva razloge. Ne čuva značenje.

Failure Pattern #5: Audit and Compliance as Afterthought

Sistemi padaju audit ne zato što nisu compliant, već zato što compliance nikada nije bio deo dizajna.

Audit ne traži konfiguraciju — traži dokaz

Ko je odobrio? Kada je promenjeno? Može li da se verifikuje?

Logovi ne prolaze audit

Logovi nisu autoritativni, nisu pravno čvrsti i ne žive u system of record‑u.

Zaključak

Compliance se ne dodaje. Compliance se dizajnira.

Oracle Diagnostic Checklist

Ulazni proizvod — Expert Systems Services

  1. Historical Integrity — da li se istorija prepisuje?
  2. Responsibility & Approvals — da li se može pripisati akter?
  3. Recovery Reality — da li je recovery testiran i pouzdan?
  4. Performance Accountability — da li su tuning odluke zabeležene?
  5. Migration & Change History — da li su migracije evidentirane?
  6. Audit & Verification — postoji li read‑only verifikacioni sloj?

Oracle System Diagnostic & Risk Assessment
€750 – €1,500 (fiksna cena)

INTERNI LINKOVI

System Diagnostic & Risk Assessment

Ne popravljamo sisteme koje nismo dijagnostikovali.

Ako želiš da znaš koji od ovih failure pattern‑a postoje u tvom sistemu, kreni od oracle system diagnostic.

Zatražite dijagnostiku → Oracle & Enterprise usluge

Povezano: arhitektura koja nameće istinu