Schweißtreibend

Ich glaube, hierbei…

15:47 <@name_changed> hua, hier wird gerade Desaster Recovery “geübt”
15:53 <@name_changed> spannend ja 0_0
15:54 <@name_changed> wir haben uns die Oracle 11g zerschrotet
15:56 <@name_changed> eins von frisch angelegten ASM volumes (multipathed) hat durch selfown auf die Flash Recovery Area geschrieben (2-Lun volume via LVM single pathed angebunden)
15:59 <@name_changed> tja, dummer manueller fehler… off-by-one error bei vielen /dev/mapper/mapth?p1 devices, das >xTB FRA Volume war vergessen worden mit auf mpath zu stellen (wegen LVM)
15:59 <@name_changed> es wäre das mpath(n+2)p1 gewesen
16:01 <@name_changed> der kollege dem das passiert ist den haben wir eben nach xxh recovery gegen seinen willen aus’m verkehr gezogen
16:03 <@name_changed> ich wette er schläft immer noch nicht
16:04 <@name_changed> aber wir machen jetzt halt mal nen live test wie lange band- backup zurückholen, restore und recovery wirklich dauert
17:49 <@name_changed> cite: jain, db ist wieder konsistent
17:49 <@name_changed> jetzt gehts ans feintuning, was kann man noch aus den tomcat logs usw. rausholen. die kür halt.
17:53 <@name_changed> band rücksicherung, restore und recover hat bis jetzt ~45h gedauert
18:53 <@name_changed> cite: DB: 2.xT, auf Dxxxxx und IBM Tivoli, aber frag mich nicht welche Tivoli Version
18:55 <@name_changed> cite: DB ist ne Hxx, xxx Core Xeon xxxG RAM
18:58 <@name_changed> hightower: crash war um ~xx:00h am Xxxxxxx
19:58 <@name_changed> cite: und wir sind nach aussen immer noch down
19:58 <@name_changed> $CHEF hat xx Pizzen kommen lassen

…kommt man ganz schön in’s Schwitzen.