Участвах в скорошна тема в общността на OTN, където някой задаваше въпроси за понижаване след надграждане на базата данни. Един от отговорите попита колко хора всъщност практикуват понижаване на базата данни. Създадох тази анкета, за да разбера.
Бях изненадан да открия един принос към тази тема, който казваше:
Сега този плакат не го казваше изрично, но сякаш този човек казваше, че практикуването на понижаване на рейтинга е загуба на време, защото никога няма да има нужда от него. Ще дам на плаката полза от съмнението и че този служител на Oracle всъщност не е казал това. Не се опитвам да се заяждам с този човек. Ще оставя тази тема да ми даде възможност да обсъдя темата от по-обща гледна точка. (Актуализация: постерът, който ме подтикна да напиша този запис в блога, се върна към темата през времето, което ми отне да напиша това и каза, „не означаваше да намеква, че не трябва да „тестваме“ понижения.“ )
Още през юли написах публикация в блога за The Data Guardian. В тази публикация в блога казах:
DBA трябва да защити данните. Това е работа №1. Задача №2 е DBA да осигури ефективен и навременен достъп до данните. Каква е ползата от данните, ако хората, които имат нужда от достъп до тях, не могат да стигнат до данните? Ако тези хора имат ужасна производителност, когато взаимодействат с данните, може и да нямат достъп.
Като DBA, ние трябва да извършваме управление на риска. Трябва да определим какви рискове могат да станат реалност. Работата на DBA е да измерва тези рискове и да определя два плана за действие. Какви стъпки могат да се предприемат, за да се избегне този риск да стане реалност и какви стъпки трябва да предприема, за да разреша проблема, когато този риск стане реалност?
Дори DBA на младше ниво ще разбере важността на архивирането. Архивирането е стратегия за управление на риска. Ако данните бъдат загубени, можем да възстановим данните от архива. И дори DBA от по-ниско ниво разбира важността на възможността за възстановяване от архива.
В тази OTN тема написах това:
За мен това е нещо като Закона на Мърфи. В миналото съм казвал подобни неща. Идеята (и целият смисъл на този запис в блога) е, че ако не предприема подходящи стъпки за управление на риска, тогава просто моля боговете да превърнат този риск в реалност. Ако откажа да настроя огледалото си за обратно виждане и да го използвам, когато придвижвам автомобила си назад, това е денят, в който се връщам в нещо. Ако откажа да си завържа връзките на обувките, това е денят, в който стъпвам на една и се препъвам. Денят, в който отказвам да нося защитни google, когато използвам електроинструмент, е денят, в който попадна нещо в окото си. Денят, в който отида на плажа и откажа да сложа слънцезащитен крем, е денят, в който ще се прибера вкъщи със слънчево изгаряне. Разбирате идеята.
Някои читатели може да си мислят, че съм луд и че Вселената няма този главен план, който да се прецака с мен, само защото съм самодоволна. И бих се съгласил. Така че ще го кажа по друг начин, ако не планирам да смекча риска, значи не съм направил нищо, за да го попреча да стане реалност. Шансовете това да стане реалност не намаляват поради моето бездействие.
Има два основни компонента за управление на риска. 1) определяне на вероятността за възникване на този рисков елемент и 2) определяне на въздействието, когато този риск все пак възникне. Елементите, които имат най-висока вероятност на възникване се смекчават първо. Това е лесно и често правят много хора, работещи по управление на риска. Те поставят рисковите елементи в електронна таблица и попълват някаква стойност за вероятността този риск да възникне. Когато завършат, те сортират по колоната на вероятностите и започват смекчаване на риска отгоре надолу. Много стратегии за управление на риска теглят линия някъде в средата на списъка и решават, че всеки рисков елемент под тази линия има твърде ниска вероятност, че няма да се тревожим за този рисков елемент. Не можем да смекчим всички възможни рискове във Вселената. Просто няма достатъчно време да се справя с всичко. Така че трябва да теглим линията някъде.
Един от недостатъците, които виждам през цялото време, е, че управлението на риска не отделя много време на фокусиране върху въздействието на този риск да стане реалност. Електронната таблица трябва да включва подобна колона, предоставяща оценка на въздействието върху бизнеса за този рисков елемент. Мениджърът на риска също трябва да сортира електронната таблица в тази колона. Всички елементи, които имат голямо въздействие, трябва да имат дейности за смекчаване на риска, дори ако този елемент има малка вероятност да се появи! За съжаление, твърде много в бизнеса за управление на риска не успяват да включат тази стъпка за оценка на въздействието на риска. Отново, когато електронната таблица се сортира по въздействие върху бизнеса, някъде се начертава линия.
Може да откриете, че рискови елементи с ВИСОКА вероятност имат НИСКО или дори МНОГО НИСКО въздействие към бизнеса. Харесвам електронни таблици за управление на риска, които включват трета колона, която е „вероятност х въздействие“. Тази колона помага да се разбере връзката между двата рискови компонента.
Нека се върнем към въпроса за надграждане на базата данни, който предизвика тази публикация в блога. Мисля, че всеки, който чете тази статия в блога, трябва да се съгласи, че надграждането на база данни на Oracle е рисковано предложение. Има толкова много различни неща, които могат да се объркат с надстройка на база данни на Oracle. Вероятността на грешка при надграждане е ВИСОКА. Елементите за смекчаване на риска често включват, но не се ограничават до, практикуване на надстройка на клонинги на продукцията и архивиране на базата данни, преди да започне процесът на надстройка. Защо правим това? Ами въздействието към бизнеса е МНОГО ВИСОКА. Ако не успеем при надграждане на нашата производствена база данни, тогава нашите бизнес потребители нямат достъп до данните. Не сме много добър пазител на данни, ако не можем да преодолеем този провал. Ако практикуваме надстройката в достатъчна степен в непроизводствена среда, можем да намалим вероятността за рисковия елемент до СРЕДНА. Но по всяка вероятност не можем да намалим тази специфична вероятност за риск до НИСКА. Ето защо правим резервно копие, преди да започне надстройката. Все още трябва да има проблеми, въпреки че сме направили всичко възможно - да намалим вероятността на този рисков елемент, въздействието към бизнеса все още е МНОГО ВИСОКА. Така че стратегията на DBA за отстраняване на риска е да води бележки за това къде и какво е причинило неуспехът на надстройката и да възстанови от резервното копие. Базата данни е готова и работи и ние елиминирахме въздействието към бизнеса. След това DBA се връща към чертожната дъска, за да определи как да разреши това, което се обърка. DBA се опитва да намали вероятността на този проблем, който се появява отново, когато се върнат в по-късен момент, за да извършат процеса на надстройка отново.
Така че нека се върнем към коментара в нишката на OTN, където изглежда се казваше, че практикуването на понижаване на базата данни не си струва времето. Не съм съгласен. И моето несъгласие има всичко общо с въздействието към бизнеса. Съгласен съм с коментара, който постера каза в отговора си.
Съгласен съм с това на 100%. Защо правим това „задълбочено тестване“? Всичко е заради намаляване на риска. Опитваме се да намалим вероятността че надстройката ще причини лоша производителност или ще доведе до прекъсване на функционалността на приложението. Но дори както каза този плакат, „Винаги ще има проблеми, които изскачат в производството след надстройката, защото е невъзможно да се тества 100% от приложението си.“ Отново съм съгласен на 100% с това, което казва този плакат тук. Но какво да кажем за въздействието към бизнеса? Ще стигна до това след минута, но първо трябва да се отклоня малко в следващия параграф...
Наскоро надстроих критична производствена система от 11.2.0.4 до версия 12.1.0.2. Там, където работя, имаме повече тестове на приложения, отколкото съм виждал на другите си работни места. Имаме пълен QA екип, който прави тестове вместо нас. Имаме дори екип, който отговаря за нашите автоматизирани усилия за тестване. Имаме автоматизирани роботи, които упражняват кода на нашето приложение всяка вечер. На всичкото отгоре имаме още една автоматизирана рутина, която всеки път, когато хората натискат промени в кода към Test или Prod, тази рутина прави бърз преглед на критичните кодови пътища. Надстроих среди за разработка (повече от 15 от тях) до 12.1.0.2 и след това изчаках един месец. След това надстроих Test и изчаках 3 седмици, преди да надстроя производството. Имаше открити и разрешени проблеми, преди да надстроим производството. Но дори след всичко това имах големи проблеми, след като производството беше надстроено. Можете да посетите публикациите ми в блога от средата на октомври до средата на декември, за да видите някои от тези проблеми. Бях много близо до понижаване на тази база данни, но вместо това успях да преодолея проблемите. Сега да се върнем към точката, която казах...
След като надстройката приключи, базата данни се отваря за бизнес. Потребителите на приложението вече имат право да използват приложението. Какво се случва в базата данни в този момент? Транзакции! А транзакциите означават промени в данните. В момента, в който DBA отваря базата данни за бизнес след завършване на надстройката, започват да се извършват промени в данните. След всичко това това е целият смисъл на базата данни, нали? Улавяйте промените в данните и правете данните достъпни за крайните потребители на приложението.
И така, какво ще стане, ако сте в лодката, в която бях миналата есен с надстройката на моята база данни? Удрях неща, които не видяхме при непроизводство, дори след всичките ни тестове. Въздействието за бизнеса беше ВИСОКО. Трябва да мога да намаля това въздействие върху бизнеса. Имах три варианта. 1) Отстранете проблемите един по един. 2) Възстановете от архива, който направих преди надстройката, за да мога да върна базата данни към старата версия. 3) Намалете базата данни и се върнете към чертожната дъска. Избрах първия вариант. както винаги съм правил през кариерата си. Но какво ще стане, ако това не беше достатъчно? Може да отнеме време за разрешаване на проблемите. Някои фирми просто не могат да си позволят такова време с това отрицателно въздействие към бизнеса. Колко уебсайта са били изоставени, защото производителността е била ужасна или нещата не работят правилно? И за по-голямата част от производствените бази данни, вариант 2 има много ужасно влияние към бизнеса! Ще загубите транзакции след завършване на надстройката! DBA няма да може да продължи напред след надстройката, като запазва базата данни в старата версия, така че данните ще бъдат загубени и за много производствени бази данни това е неприемливо. Бизнесът може да е в състояние да си позволи един час загуба на данни, но колко хора биха дръпнали спусъка за това действие в рамките на един час след надстройката? По всяка вероятност това действие ще бъде извършено дни след надстройката и въздействието за бизнеса за този вид загуба на данни е много над МНОГО ВИСОКА. Така че остава опция 3 като опция с най-малко въздействие към бизнеса, за да помогне за разрешаването на въздействията, които бизнесът изпитва след надстройката.
Вероятно можете да разберете от последния параграф, че смятам, че е важно за Oracle DBA да знае как да понижи своята база данни след завършване на надстройката. Ще призная, че вероятността от DBA, нуждаещ се да извърши понижаване, е МНОГО НИСКО. Но въздействието това да не се понижава може да бъде катастрофално за бизнеса. (Отново има тези две думи). Защото вероятността е нисък, не практикувам понижаване често, а защото въздействието невъзможността за понижаване е много висока, аз ги практикувам от време на време.
Така че в заключение, ще се върна отново към това нещо със Закона на Мърфи. Вселената не заговорничи срещу мен, но като пазител на данните трябва да прилагам добри принципи за управление на риска. Това означава оценка на вероятността и въздействието на рисковите елементи, наложени от моята промяна. Въпреки че Вселената и боговете може да не накарат Закона на Мърфи или неговите братовчеди да се задействат, аз няма да си направя никаква услуга, като смекчавам рисковите елементи. Не намалявам с малко вероятността.
