Jag deltog nyligen i en tråd om OTN-communityt där någon ställde frågor om nedgradering efter en databasuppgradering. Ett av svaren frågade hur många som faktiskt utövar databasnedgraderingar. Jag skapade den här omröstningen för att ta reda på det.
Jag blev förvånad över att hitta ett bidrag i den tråden som sa:
Nu stod det inte uttryckligen på den affischen, men det var nästan som om den personen sa att nedgraderingar var ett slöseri med tid eftersom de aldrig kommer att behöva det. Jag ger affischen fördelen av tvivel och att den här Oracle-anställda faktiskt inte sa detta. Jag försöker inte välja den här personen. Jag låter den här tråden ge mig möjligheten att diskutera ämnet från en mer allmän synvinkel. (Uppdatering: affischen som fick mig att skriva det här blogginlägget har kommit tillbaka till tråden under den tid det tog mig att skriva detta och sa, ”menade inte att antyda att vi inte skulle ”testa” nedgraderingar.” )
Redan i juli skrev jag ett blogginlägg om The Data Guardian. I det blogginlägget sa jag:
DBA måste skydda data. Det är jobb nr 1. Job #2 är för DBA att ge effektiv och snabb tillgång till data. Vad hjälper det att ha data om de personer som behöver tillgång till den inte kan komma åt datan? Om dessa personer har dåliga prestanda när de interagerar med data kan de lika gärna ha ingen åtkomst.
Som DBA måste vi utföra riskhantering. Vi måste avgöra vilka risker som kan bli verklighet. DBA:s uppgift är att mäta dessa risker och fastställa två handlingsplaner. Vilka åtgärder kan vidtas för att undvika att den risken blir verklighet och vilka åtgärder måste jag vidta för att lösa problemet när den risken blir verklighet?
Även en DBA på juniornivå kommer att förstå vikten av säkerhetskopior. Säkerhetskopiering är en riskhanteringsstrategi. Om data går förlorade kan vi återställa data från säkerhetskopian. Och även en DBA på juniornivå förstår vikten av att kunna återställa från säkerhetskopian.
I den här OTN-tråden skrev jag detta:
För mig är detta en sorts Murphys lag. Jag har sagt liknande saker tidigare. Tanken (och det är hela poängen med det här blogginlägget) är att om jag inte vidtar lämpliga riskhanteringssteg, så ber jag bara gudarna att förvandla den risken till verklighet. Om jag vägrar att justera min backspegel och använda den när jag backar mitt fordon, så är det den dagen jag backar in i något. Om jag vägrar att knyta mina skosnören, ja det är den dagen jag kliver på ett och snubblar. De dagen jag vägrar att bära skyddande googles när jag använder ett elverktyg är dagen jag får något i ögat. Dagen jag går till stranden och vägrar att ta på mig solskydd är dagen då jag kommer hem med en solbränna. Du fattar.
Vissa läsare kanske tänker att jag är galen och att universum inte har den här masterplanen att tjata med mig bara för att jag är självbelåten. Och jag skulle hålla med. Så jag säger det på ett annat sätt, om jag inte planerar att minska risken, så har jag inte gjort något för att hindra det från att bli verklighet. Chanserna att det blir verklighet minskar inte på grund av min passivitet.
Det finns två huvudkomponenter för riskhantering. 1) bestämma sannolikheten för att riskposten ska inträffa och 2) bestämma effekten när den risken inträffar. De objekt som har högst sannolikhet av inträffande mildras först. Detta är enkelt och något som många som arbetar med riskhantering ofta gör. De lägger in riskposterna i ett kalkylblad och fyller i ett värde för sannolikheten för att den risken ska inträffa. När de är klara sorterar de på sannolikhetskolumnen och börjar riskreducera uppifrån och ner. Många riskhanteringsstrategier drar en linje någonstans i mitten av listan och beslutar att varje riskpost under den linjen har för låg sannolikhet att vi inte kommer att oroa oss för den riskposten. Vi kan inte minska alla möjliga risker i universum. Det finns helt enkelt inte tillräckligt med tid för att hantera allt. Så vi måste dra gränsen någonstans.
En av de brister jag ser hela tiden är att riskhanteringen inte lägger mycket tid på att fokusera på effekten risken att bli verklighet. Kalkylarket måste innehålla en liknande kolumn som ger en bedömning av påverkan på verksamheten för den riskposten. Riskhanteraren måste sortera kalkylarket i den här kolumnen också. Alla föremål som har en stor inverkan måste ha riskreducerande aktiviteter även om det är låg sannolikhet att det inträffar! Tyvärr misslyckas alltför många i riskhanteringsbranschen att inkludera detta steg att bedöma riskpåverkan. Återigen, när kalkylarket sorteras efter påverkan på verksamheten dras en linje någonstans.
Man kan upptäcka att riskobjekt med HÖG sannolikhet har LÅG eller till och med MYCKET LÅG påverkan till verksamheten. Jag gillar riskhanteringskalkylark som innehåller en tredje kolumn som är "sannolikhet x påverkan". Den här kolumnen hjälper till att förstå sambandet mellan de två riskkomponenterna.
Låt oss gå tillbaka till databasuppgraderingsfrågan som föranledde detta blogginlägg. Jag tror att alla som läser den här bloggartikeln borde hålla med om att det är ett riskabelt förslag att uppgradera en Oracle-databas. Det finns så många olika saker som kan gå fel med en Oracle-databasuppgradering. sannolikheten av ett uppgraderingsfel är HÖG. Riskreducerande objekt inkluderar ofta, men är inte begränsade till, att öva på uppgraderingen på kloner av produktion och säkerhetskopiera databasen innan uppgraderingsprocessen börjar. Varför gör vi det här? Tja effekten till verksamheten är MYCKET HÖG. Om vi misslyckas när vi uppgraderar vår produktionsdatabas, har våra affärsanvändare ingen tillgång till datan. Vi är inte en bra dataväktare om vi inte kan komma förbi detta misslyckande. Om vi övar uppgraderingen tillräckligt i icke-produktionsmiljöer kan vi minska sannolikheten för riskposten till MEDIUM. Men med all sannolikhet kan vi inte minska den specifika risksannolikheten till LÅG. Det är därför vi tar backupen innan uppgraderingen påbörjas. Borde fortfarande ha problem trots att vi har gjort vårt bästa för att minska sannolikheten av den riskposten, effekten till verksamheten är fortfarande MYCKET HÖG. Så DBA:s risksaneringsstrategi är att anteckna var och vad som gjorde att uppgraderingen misslyckades och att återställa från säkerhetskopian. Databasen är igång och vi har eliminerat effekten till verksamheten. DBA går sedan tillbaka till ritbordet för att avgöra hur man ska lösa det som gick fel. DBA försöker minska sannolikheten att problemet uppstår igen när de återkommer vid en senare tidpunkt för att göra uppgraderingsprocessen igen.
Så låt oss gå tillbaka till kommentaren i OTN-tråden där det verkade säga att det inte är värt tiden att öva nedgraderingar av databasen. Jag håller inte med. Och min oenighet har allt att göra med påverkan till verksamheten. Jag håller med om kommentaren som affischen sa i sitt svar.
Jag håller med till 100%. Varför gör vi dessa "grundliga tester"? Allt beror på riskreducering. Vi försöker minska sannolikheten att uppgraderingen kommer att orsaka dålig prestanda eller göra att applikationsfunktioner går sönder. Men även som den affischen sa:"Det kommer alltid att finnas problem som dyker upp i produktionen efter uppgraderingen eftersom det är omöjligt att testa 100 % av din applikation." Återigen, jag håller med till 100 % om vad den här affischen säger här. Men hur är det med effekten till verksamheten? Jag kommer till det om en minut, men först måste jag avvika lite i nästa stycke...
Jag har nyligen uppgraderat ett kritiskt produktionssystem från 11.2.0.4 till 12.1.0.2-versionen. Där jag arbetar har vi fler applikationstester än jag någonsin sett i mina andra jobb. Vi har ett komplett QA-team som gör tester åt oss. Vi har till och med ett team som ansvarar för våra automatiserade tester. Vi har automatiserade robotar som använder vår applikationskod varje natt. Utöver allt detta har vi en annan automatiserad rutin som varje gång folk trycker kodändringar till Test eller Prod, gör denna rutin en snabb undersökning av kritiska kodvägar. Jag uppgraderade utvecklingsmiljöer (mer än 15 av dem) till 12.1.0.2 och väntade sedan en månad. Jag uppgraderade sedan Test och väntade 3 veckor innan jag uppgraderade produktionen. Det hittades problem och löstes innan vi uppgraderade produktionen. Men även efter allt detta hade jag stora problem när produktionen uppgraderades. Du kan besöka mina blogginlägg i mitten av oktober till mitten av december för att se några av dessa problem. Jag var väldigt nära att nedgradera den här databasen men jag lyckades gå igenom problemen istället. Nu tillbaka till punkten jag gjorde...
När uppgraderingen är klar öppnas databasen för företag. Applikationsanvändare får nu använda applikationen. Vad händer i databasen vid det här laget? Transaktioner! Och transaktioner innebär dataförändringar. Vid den tidpunkt som DBA öppnar databasen för företag efter att en uppgradering är klar, börjar dataändringar ske. Efter allt detta är det hela poängen med databasen, eller hur? Fånga dataändringar och gör data tillgänglig för applikationens slutanvändare.
Så vad händer om du är i båten jag var förra hösten med min databasuppgradering? Jag träffade saker som vi inte såg i icke-produktion, även efter alla våra tester. påverkan till verksamheten var HÖG. Jag måste kunna minska denna påverkan på verksamheten. Jag hade tre alternativ. 1) Åtgärda problemen, ett efter ett. 2) Återställ från säkerhetskopian jag tog innan uppgraderingen så att jag kunde få tillbaka databasen till den gamla versionen. 3) Nedgradera databasen och gå tillbaka till ritbordet. Jag valde det första alternativet. som jag alltid har gjort under min karriär. Men tänk om det inte var tillräckligt? Det kan ta tid att lösa problemen. Vissa företag har helt enkelt inte råd med den typen av tid med den negativa påverkan till verksamheten. Hur många webbplatser har övergivits för att prestandan var dålig eller att saker och ting inte fungerade korrekt? Och för den stora majoriteten av produktionsdatabaser där ute har alternativ 2 en mycket fruktansvärd effekt till verksamheten! Du kommer att förlora transaktioner efter att uppgraderingen har slutförts! DBA kommer inte att kunna rulla framåt förbi uppgraderingen medan databasen behålls i den gamla versionen, så data kommer att gå förlorade och för många produktionsdatabaser är detta oacceptabelt. Verksamheten kanske har råd med en timmes dataförlust, men hur många människor skulle ta avtryckaren på denna åtgärd inom en timme efter uppgraderingen? Med all sannolikhet kommer den här åtgärden att utföras dagar efter uppgraderingen och effekten till verksamheten för den typen av dataförlust är långt över MYCKET HÖG. Så det lämnar alternativ 3 som alternativet med lägst påverkan till företaget för att hjälpa till att lösa alla konsekvenser som företaget upplever efter uppgraderingen.
Du kan nog se från det sista stycket att jag känner att det är viktigt för Oracle DBA att veta hur man nedgraderar sin databas efter att en uppgradering är klar. Jag medger att sannolikheten av DBA som behöver utföra en nedgradering är MYCKET LÅG. Men effekten att inte nedgradera kan vara katastrofalt för verksamheten. (Det är de två orden igen). Eftersom sannolikheten är låg övar jag inte nedgraderingar ofta, utan eftersom effekten att inte kunna nedgradera är väldigt högt, jag tränar dem då och då.
Så avslutningsvis ska jag gå tillbaka till det där med Murphys lag igen. Universum konspirerar inte mot mig, men som Data Guardian måste jag träna på bra riskhanteringsprinciper. Det innebär att bedöma sannolikheten och effekten av riskposter som min förändring medför. Även om universum och gudarna kanske inte får Murphys lag eller dess kusiner att sätta igång, gör jag inte mig själv någon tjänst genom att mildra risker. Jag minskar inte sannolikheten ett dugg.