Vlákno názorů k článku Nestřílejte specialisty aneb Co způsobilo rozsáhlý databázový výpadek v Alza.cz od WIFT - Technicky vzato souhlas (tak trochu dělám s obojím,...

Aneb z h0ven do sr4ček...

Taky delam s Oracle a musim rict ze se mi podobna vec stala i na 9i. SGA memory corruption, crash databaze, poskozene redo-logy. Databaze segfaultovala behem media recovery. Jako reseni se nabizelo full restore, preskoceni media recovery & dump dat do nove db. Kvulil casovemu presu a hrozicim ztratam, jsme nakonec jen preskocili media recovery, rebuildovali indexy jelo se dal.

U msft se to jmenuje logshipping nebo mirroring, podle latence jakou si prejete. Oboji technologie vic nez 10 let stara.

Záleží, jestli se zprasí už před odesláním k uložení do replik, nebo až při fyzickém zápisu na médium. V případě a) jseš na tom jak Baťa s dřevákama, v případě b) by služby v clusteru měly dál běžet proti zdravému nodu a na nemocném si to opravíš replikací ze zdravého. Ale pokud máš dvě identická pole a řadič má chybu ve firmwaru, která se manifestuje v důsledku toho co přiteče k uložení, jseš slušně řečeno v hajzlu, protože se to zapíše do obou replik a systém o tom vůbec neví, dokud se tam znova nekoukne, načež zjistí že zdravá kopie neexistuje a celý to padne na hubu.

oracle redolog multiplexing je tak doby proti user chybe (takze je pekne ked ma db dve kopie) a na nejakom lokalnom serveri s malou DB. Vyzera ze im naozaj padol storage controller a nestihol zapisat data z cache na disky, cim vznikol takzvany lost write a to je smrt. Ked sa to stane, kedze do transakcneho loku pise db skoro da sa povedat nepretrzite. Keby mali multipliexing na rovnakom storage, zrejme to chyti oba zapisy (ktore databazova instancia vykonava paralelne) a su tam kde boli...

Něco mi tu zasmrada. Z opačného soudku. Každý bere cache (nvram) jako něco co se smaže a zhroutí po pádu controlleru. Ale ví někdo jak to funguje? Když už byl zápis commitnuty z cache směrem k sql serveru, tak byl ok. Je pak na controlleru kdy zapíše obsah na disky. Vždy se to dělá na velkých polích tak, že ta cache je tam minimálně ve dvou kopiích a je replikovana. To aby pád controlleru neznamenal zastavení provozu. A i kdyby celé pole padlo a data zůstaly v cachich tak prvni věc je zapsat data z cache na disky, kdyby ne tak to nenajde s nějakou hlaskou a volá se vendor. Pokud by padl jeden controller a bylo by něco s nvram ve startovanem controlleru kontrola by na to přišla a opět by to stoplo, pokud ne, nvram se smaže a jede se dal, protože to obsloužil běžící kontrolér. No a při mirroringu na další pole je ten zápis hazeny na druhé pole při zápis do nvram a ne při zápisu na disky (teda očekával bych za ty dve Tesly) alespoň synchronní mirror. A v případě redologu či jiných transakcnich dat jsem měl dojem, že je vyžadováno aby byla uložena jinde, než na místě kde jsou produkční data, proboha, stačilo by i na lokálním disku odehrávanym do backup řešení. Asi tak. Musel jsem se z toho vypsat. Když už si najímají odborníky tak at to delaji z různých oblastí, může se jim to vyplatit.

A co tak pouzit Oracle? Uz ste o takej moznosti poculi?
MS sa moze zakopat do zeme!