Твърде често виждам хора да задават въпроси относно стратегиите за архивиране, които трябва да използват за своите бази данни. Изглежда никога не се проваля, всеки въпрос от този вид, който срещам в различни форуми, никога не включва техните изисквания за възстановяване. Често съм се затруднявал да обмисля вашите изисквания за възстановяване, преди да проектирам вашата стратегия за архивиране. Когато бъде натиснат за изисквания, често ще получавам резервни изисквания, например:
- Резервните копия не трябва да водят до престой
- Трябва да можете да архивирате архивирани регистрационни файлове за повторно изпълнение
- Резервните копия трябва да бъдат записани на лента
Тези изисквания са добри и добри, но според мен никога не трябва да проектирате стратегията си за архивиране, без първо да документирате изискванията си за възстановяване и да получите управление.
Ето някои въпроси, които си задавам, когато проектирам стратегия за архивиране. Забележете, че всички тези въпроси са фокусирани върху възстановяването на нещата.
- Колко загуба на данни мога да си позволя, когато възстановя базата данни? Нулева загуба на данни? Приемливо ли е един час загуба на данни след възстановяване на базата данни?
- Трябва ли да претърся някакви транзакции, т.е. да извърша възстановяване в даден момент?
- Ще трябва ли да възстановя съдържанието на една схема, като оставя останалите схеми непокътнати?
- Колко време трябва да стартирам базата данни след грешка?
- От какъв вид неуспехи трябва да се възстановя? Очевидно трябва да мога да възстановя от пълна повреда на сървъра или загуба на диск. Но трябва ли да мога да се възстановя от човешки неуспехи като някой, който случайно е изтрил таблица?
- Ще се изисква ли да възстановя архива на други сървъри като част от опресняване на разработка или тестване на бази данни от копие на продукцията?
Ако попитате повечето хора в общността на Oracle тези дни, те ще ви кажат да използвате RMAN за архивиране на вашата база данни. RMAN е страхотен продукт и за много неща е по-добър от стария стил, управлявани от потребители, горещи или студени архиви. Някои DBA на Oracle ще ви кажат да използвате RMAN за извършване на горещо архивиране и стартиране на вашата производствена база данни в режим на архивен журнал. По този начин ще покриете много от сценариите за възстановяване, пред които е вероятно да се сблъскате. Но какво ще стане, ако отговорът ви на въпрос 4 е, че имате 1 час за възстановяване и работа и вашата база данни е с размер 10TB. Успех в опитите да направите пълно възстановяване на 10TB база данни за 1 час с RMAN. И RMAN няма да може да помогне с въпрос 3, тъй като RMAN не архивира на ниво схема.
Има много инструменти на разположение на DBA за архивиране и възстановяване на данни в базата данни. Тези инструменти включват, но не са ограничени също:
- Мениджър за възстановяване на Oracle (RMAN)
- Архивни копия на Oracle, управлявани от потребителя
- Експортиране/импортиране на Oracle или помпа за данни
- Базирани на диск моментни снимки
- Репликация на базата на диск
- Data Guard на Oracle
И така, кое използвате? Е, всеки има своите плюсове и минуси. След като разберете изискванията си за възстановяване, инструментите за архивиране на вашата база данни започват да стават по-ясни. И може да се наложи да използвате повече от един инструмент за архивиране, за да изпълните всичките си изисквания за възстановяване. Ако използвате, като някакво предложение, RMAN с режим на архивен дневник и нищо друго, и вашият мениджър идва при вас и казва „трябва да възстановите тази база данни от 10TB и да работи за 1 час!“ вашата работа може да е на линия.
Което води до следващата точка, документирайте вашите изисквания за възстановяване и ги вкарайте във вашето Споразумение за ниво на обслужване (SLA). Когато пише и проверява SLA, вашето ръководство може да каже, че иска нулева загуба на данни. Точно в този момент можете да посочите плюсовете и минусите на внедряването на решение за нулева загуба на данни...и също така да споменете разходите! Много компании се противопоставят на високата цена на решението за нулева загуба на данни, но за други компании цената е малка в сравнение с финансовата тежест от загуба на транзакция. Тук влизат пазарлъците и размяната. Ако ръководството настоява за решение с нулева загуба на данни, тогава те трябва да излязат със средства, за да го поддържат, защото RMAN (безплатно) няма да го предостави. След като вашите изисквания за възстановяване са документирани в SLA, тогава ще бъде трудно за ръководството да ви помоли да възстановите нещо, което вашата стратегия за архивиране не е предназначена да поддържа. Ако SLA е в сила и те ви молят да възстановите всяка отделна транзакция и вашата стратегия за архивиране не позволява това, тогава имате документ, който казва, че никога не е била необходима нулева загуба на данни и това може да ви помогне да спасите работата си.
Като се има предвид това, след като вашите изисквания за възстановяване са документирани в SLA, уверете се, че вашата стратегия за архивиране ще ви позволи да изпълните всеки сценарий за възстановяване, който е документиран в SLA. Вашата работа може да зависи от това. Ако SLA казва нулева загуба на данни и не внедрите Data Guard, въпреки че ръководството е било готово да го финансира, тогава те може да ви прекратят, защото не сте изпълнявали работата си.
И накрая, нито една стратегия за архивиране/възстановяване не е завършена, освен ако не е щателно тествана. Трябва да тествате всяка необходима стратегия за възстановяване, за да сте сигурни, че можете да изпълните всички изисквания, посочени в SLA. Тестването трябва да се извършва не по-рядко от веднъж годишно по две причини... една, гарантира, че промените в системата няма да влияят негативно на способността ви да извършвате необходимо възстановяване и две, ви държи в течение за това как да извършите възстановяване, така че ако трябва да го направите наистина, вие не се мъчите за процедурата. При тестване може да откриете, че вашата методология за архивиране ще поддържа сценарии за възстановяване, които са необходими, но е хубаво да имате, ако имате нужда от тях.
И не мога да го кажа достатъчно... Тествайте, тествайте и тествайте!
