Организация на базата данни и структурите за съхранение на данни
Oracle Database предоставя напълно независима дефиниция на логически и физически структури от данни. Логическият елемент от данни е сегмент. Има различни видове сегменти; типичен пример е таблица. Сегментите се съхраняват физически във файлове с данни. Разделянето на физическото и логическото представяне на данните се осъществява чрез въвеждане на концепцията за таблично пространство. Асоциацията на физически и логически представяния се съхранява в речника на данните.
Физически структури на базата данни
Има три основни типа файлове, които съставляват базата данни на Oracle, плюс допълнителни файлове, които се съхраняват отделно от базата данни и, грубо казано, не са необходими. Необходимите файлове са контролният файл, онлайн регистрационните файлове за повторение и файловете с данни. Допълнителните файлове, които обикновено присъстват (има и други за по-нататъшно персонализиране), са файл с параметри за инициализация, файл с парола, архив на журнал и т.н.
Контролен файл / Controlfile
Нека да разгледаме терминологията: някой казва, че базата данни може да има няколко контролни файла, докато други казват, че има един файл, който може да има няколко копия. Ще се придържаме към последната дефиниция, тъй като според Oracle "мултиплексиране на контролни файлове" означава точно възможността да има копия.
Controlfile е малък файл, но е жизненоважен. Той съдържа указатели за цялата база данни: местоположението на онлайн журнала за повторение, файлове с данни, критична системна информация за гарантиране на целостта (стойност на последователността и клеймо за време). Размерът на файла обикновено не надвишава няколко мегабайта, но базата данни не съществува без този файл.
Всяка база данни има един контролен файл, но добрият DBA винаги ще създава копия на файла, така че в случай на проблеми с някое копие, винаги можете бързо да възстановите системата. Ако всички копия са загубени, тогаваТеоретично можете да опитате да възстановите базата данни, но е по-добре никога да не изпадате в такава ситуация. Самият сървър на Oracle синхронизира контролните файлове - задачата на DBA е да реши колко копия са необходими и къде да ги съхранява.
Ако не сте указали количество или път по време на създаването на базата данни, това може да се промени по-късно, но ще изисква изключване на спирането на базата данни, така че е по-добре да планирате предварително. Няма конкретна стойност за това колко копия да направите, минимумът е един файл, максимумът е осем. Проблеми с всяко копие на контролния файл ще доведат до незабавно спиране на екземпляра на базата данни.
Регистрационни файлове/Регистрационни файлове за онлайн повторение
Регистърът за повторение е набор от хронологично подредени записи за промени в базата данни. Това е минимално необходимото количество информация, което е необходимо за възстановяване на всички действия, извършени в базата данни. Ако файловете с данни липсват или са изтрити, тези записи за промяна могат да се използват за повторение на всички действия от определен момент до момента, в който е възникнала грешка в архивираните файлове с данни. Този регистрационен файл може да се състои от два типа файлове: онлайн регистрационни файлове за повторение (необходими файлове, за да работи базата данни) и архивни регистрационни файлове (които не са необходими за работа, но са необходими за възстановяване на данни до даден момент).
Всяка база данни има поне два онлайн файла с регистрационни файлове за повторение, но както при контролния файл, добрият DBA създава копия на всеки файл. Онлайн журналът за повторение се състои от групи файлове, всеки файл в които се нарича член. Една база данни на Oracle трябва да има поне две групи от поне един член, за да работи. Можете да създадете повече от две групи, за да подобрите ефективността, и повече от един член, за да запазите данните в безопасност. Необходими са поне две групи, за да се запишат текущи промени в едната, а другата може да се използва по това времеза създаване на резервно копие.
Една от групите по това време е текущата (текущата група) - LGWR ще запише промени в нея от буфера на журнала. В момента, когато груповите файлове са пълни, LGWR ще извърши така наречената операция за превключване на журнала. Втората група става текуща и LGWR започва да записва данни във файловете от втората група и ако имате конфигуриран архивен журнал, ARCn ще архивира файловете от първата група. Когато втората група е пълна, LGWR ще направи първата група отново текуща и ARCn ще архивира втората група. По този начин групите от журнали за повторение работят в кръг и всяка операция за превключване на журнали създава архивиран журнален файл.
Както и за controlfile, ако имате няколко файла конфигурирани в група (желателно е да имате няколко копия!) не са необходими допълнителни настройки за синхронизирането им и т.н. LGWR ще запише една и съща информация във всички копия паралелно. Ако, например, някое копие на който и да е диск не е налично - стига да има поне едно копие - базата данни може да функционира нормално.
Размерът и броят на групите е проблем за оптимизиране на базата данни. Като цяло е необходимо да изберете стойности в зависимост от дейността по работа с базата данни. Минималният размер е петдесет мегабайта, но силно използваните бази данни с голям брой потребители могат да използват файлове с размер до няколко гигабайта. Броят на копията на файловете в една група е въпрос на това какво ниво на отказоустойчивост искате да постигнете. Във всеки случай настройката на тези параметри не е критична на етапа на създаване на база данни, тъй като те могат да бъдат променени в режим "онлайн" - без рестартиране на екземпляра на базата данни.
Файлове с данни / Datafiles
Третият тип файлове, необходими за работа, са файлове с данни. Необходими са поне два файла, които се създават по време на създаването на базата данни. Up версия10g - беше възможно да се създаде база данни с един файл - след това се създават два файла, един за табличните пространства SYSTEM и SYSAUX. Както и да е, в работната база данни ще има повече файлове.
Файловете с данни са място за съхранение на данни. Техният размер и брой са неограничени. Малките бази данни от няколко гигабайта могат да се състоят от половин дузина файлове, всеки с размер от няколкостотин мегабайта. Големите бази данни могат да се състоят от хиляди файлове, чийто размер е ограничен само от възможностите на операционната система и хардуера.
Физически файловете с данни са системни файлове, които системните администратори виждат. Логическата структура на файловете с данни е хранилище на сегменти (сегменти), в които се съхраняват потребителски данни и логическата структура е достъпна за програмистите, както и сегменти от речник на данни. Сегментът е структура за съхранение на данни; типичните сегменти са таблици и индекси. Файловете с данни могат да бъдат преименувани, премествани, изтривани, добавяни по всяко време през живота на базата данни. Но е важно да запомните, че някои операции изискват рестартиране на екземпляра на базата данни.
От гледна точка на ОС, файловете с данни са съставени от набор от блокове на операционната система. Вътре във файловете те са форматирани в блокове на Oracle. Тези блокове са последователно номерирани във всеки файл. Размерът на блока е фиксиран и в повечето случаи ще бъде еднакъв за цялата база данни. Изборът на размер на блока е задача за оптимизация. Валидните стойности са от 2KB до 64KB. Няма връзка между размерите на системните блокове и размерите на блоковете на Oracle.
Много администратори на бази данни използват същия размер на системния блок и размера на блока на Oracle. От гледна точка на производителността, системният блок не трябва да бъде по-голям от блока на Oracle. Все пак нищо не пречи системният блок да е по-малък от блока на Oracle. Например системен блок от 1Kb и блок на Oracle с размери от8KB е напълно приемлива конфигурация.
Вътре в блока има заглавка, област с данни и евентуално неизползвано пространство. Заглавката съдържа информация като: директория с редове, която изброява местоположението на редовете в областта с данни (ако блокът се използва като част от таблица), информация за заключвания на редове, ако данните се използват в транзакции. Областта за данни съхранява самите данни, като например редове, ако блокът е част от таблица, или индексни ключове, ако блокът е част от индекс.
Когато потребителска сесия трябва да работи с данни от блок, сървърният процес намира блок с необходимите данни на диска и копира този блок в свободен буфер в буферния кеш на базата данни. Ако след това данните се променят, в даден момент DBWn ще запише този блок обратно на диска.
Препоръчително е редовно да правите резервни копия на файловете с данни. За разлика от контролните файлове и регистрационните файлове за повторение, Oracle не поддържа копия на файлове с данни (въпреки че можете да изградите RAID масив или да използвате други функции на хардуера и операционната система). Ако файловете с данни се повредят, те могат да бъдат възстановени от резервно копие и след това възстановени (възстановено означава, че промените от журнала за повторение ще бъдат приложени към копието на файла с данни).
Логически структури на бази данни
Физическите структури на базата данни не са нищо повече от системни файлове. Потребителите виждат логически структури като таблица. Oracle използва термина сегмент, за да опише всяка структура, която съдържа данни. Типичен сегмент е таблица, състояща се от редове с данни, но има повече от 12 възможни типа, използвани в Oracle. Интересуваме се от таблици, индекси и UNDO сегменти. Таблицата съдържа действителните данни, индексите се използват за бърз достъп до конкретни данни, UNDO сегментите се използват засъхранение на временна информация, промени, които могат да бъдат отменени.
Oracle ви позволява да абстрахирате физическата структура от логическата структура чрез въвеждане на концепцията за таблично пространство. Табличното пространство е логически колекция от един или повече сегменти и физически колекция от един или повече файлове с данни. От гледна точка на релационната алгебра виждаме връзка много към много между сегменти и файлове с данни: една таблица може да бъде в различни файлове с данни и, от друга страна, много таблици могат да бъдат в един файл с данни. Чрез добавяне на концепцията за "tablespace" - Oracle управлява тези връзки.
Няколко сегмента се създават по време на създаването на база данни: това са сегментите, които съставят речника на данните. Тези сегменти се съхраняват в две таблични пространства SYSTEM и SYSAUX. SYSAUX се появи едва след версия 10g: в миналото целият речник на данните се съхраняваше в табличното пространство SYSTEM. Процесът на създаване непременно ще създаде най-малко две таблични пространства, с поне един файл с данни всяко, за съхраняване на речника на данните.
Сегментът се състои от блокове. Файловете с данни също се форматират с помощта на блокове, а блоковете от файла с данни се присвояват на сегменти, докато последните растат. Управлението на дисковото пространство на базата на един блок би било много скъпо, така че блоковете се групират в екстенти. Екстентът е група от последователни блокове във файл с данни и размерът на сегментите ще се увеличава с размера на екстента. Екстентите за един и същи сегмент не е необходимо да са съседни във файла и може дори да са в различни файлове, но файловете трябва да принадлежат към табличното пространство на този сегмент.
Фигура 1-8 изобразява връзката на структурите на Oracle с отделянето на логическите структури от физическите. Табличенедно пространство може да съдържа много сегменти, всеки от които се състои от екстенти. Екстентът е набор от блокове на Oracle. Файлът с данни се състои от блокове на операционната система. В обобщение, табличното пространство се състои от много файлове с данни, а блокът на Oracle е съставен от един или повече блокове на операционната система.
Речник на данни
Речникът на данните съхранява метаданни, описващи логическата и физическата структура на базата данни и нейното съдържание. Потребителска информация, пароли, ограничения за целостта и (от 10g) информация за производителността се съхраняват в речника на данните. Тези данни се съхраняват като набор от сегменти в табличните пространства SYSTEM и SYSAUX.
Като цяло сегментите, които съставляват речника на данните, са същите като останалите сегменти - обикновени таблици и индекси. Основната разлика е, че тези сегменти се създават в момента на създаване на базата данни и в тях няма директен достъп до информация. Разбира се, нищо не може да спре DBA от директен достъп до речника на данните - всяка промяна в тях обаче може да доведе до унищожаване на базата данни.
Речникът на данните се управлява от DML команди. Когато подадете командата CREATE TABLE, вие всъщност вмъквате редове в таблиците с речник на данни. Командите CREATE USER и GRANT и т.н. имат абсолютно същия механизъм на работа.
Връзката между табличните пространства и файла с данни се контролира от контролния файл. Вътре са изброени всички файлове с данни и информация за това от кое таблично пространство са част. Без контролен файл базата данни няма да може да намери файловете с данни и да определи кой от тях съхранява данните от табличното пространство SYSTEM. Едва след като табличното пространство SYSTEM бъде намерено и достъпно за четене на информация, става възможно да се чете информация от речника на данните, което ви позволява да отворите базата данни.
SQL командите са винагипрепраща към обекти, дефинирани в речника на данните. За да изпълни проста заявка към таблица, Oracle трябва първо да провери в речника на данните дали такава таблица съществува и какви колони съдържа. След това намерете файловете, където физически се съхраняват данните, т.е. прочетете списъка с екстенти, които съхраняват данните на този сегмент. Този списък съхранява информация в кой файл с данни се съхранява всеки екстент, с кой файл с данни започва екстентът и колко блока съдържа.