Преглед на таблични пространства и файлове с данни

Разгледахме процеса на взаимодействие между инстанция и сесии: процеси и структури на паметта. В тази глава ще разгледаме самата база данни. Всички процеси на обработка на информация се случват в паметта на екземпляр на база данни, но данните се съхраняват във файлове на база данни на диск. Базата данни се състои от три вида файлове: контролен файл, лог файлове и файлове с данни. Данните се съхраняват във файлове с данни.

Потребителите никога не виждат физическия файл с данни. Те виждат логични сегменти. Системните администратори не знаят нищо за логическите сегменти - те виждат файловете. В базата данни на Oracle физическата структура е абстрахирана от логическата структура. Това е едно от изискванията на парадигмата на релационните бази данни. Като DBA вие трябва да знаете връзката между логическата и физическата структура на базата данни. Мониторингът и администрирането на тези структури - задача, често наричана управление на пространството - е голяма част от работата на DBA. Инструментите, предоставени в най-новите версии на бази данни, могат да автоматизират задачата за управление на пространството до известна степен и те със сигурност позволяват на DBA да конфигурира хранилището по такъв начин, че да направи задачата за поддръжка на сървъра възможно най-лесна.

Данните се съхраняват логически в сегменти (обикновено таблици), физически във файлове с данни. Табличното пространство абстрахира тези две концепции: едно таблично пространство може да съхранява множество сегменти и да се състои от множество файлове с данни. Няма пряка връзка между сегмент и файл с данни. Файловете с данни могат да бъдат файлове във файловата система или (от версия 10g) устройства за автоматично управление на съхранението (ASM).

Модел на съхранение на Oracle

Разделянето на логически и физически структури е необходима част от парадигмата на релационните бази данни. Парадигмата казва, че програмиститетрябва да работи само с логически структури и да остави базата данни да управлява картографирането им към физически структури. Това означава, че физическата структура може да бъде преобразувана или например цялата база данни да бъде прехвърлена на нов хардуер и операционна система, като това не би трябвало да има никакъв ефект върху работата на приложенията.

Фигура 5-1 показва модела на Oracle като диаграма обект-връзка, с логически структури отляво и физически структури отдясно.

На тази фигура една линия за връзка е показана като пунктирана линия: връзка много към много между сегменти и файлове с данни. Този ред е прекъснат, защото не би трябвало да бъде, релациите много към много не са разрешени от добрите DBA. Трансформирането на тази връзка в нормализирана форма е задачата за организиране на модела за съхранение.

Въвеждането на обекта таблично пространство позволява връзки много към много между сегменти и файлове с данни. Едно таблично пространство може да съдържа множество сегменти и да се състои от множество файлове с данни. Тези. един сегмент може да бъде споделен между много файлове с данни и един файл с данни може да съдържа данни от различни сегменти. Той решава много проблеми с организацията на съхранението на данни. Някои по-стари RDBMS използваха връзка едно към едно между шард и файл с данни: всяка таблица или индекс се съхраняваше като отделен файл. Това предизвика два големи проблема за големите системи.

Първо, едно приложение може да използва хиляди таблици и дори повече индекси; управлението на хиляди файлове не е лесна задача за системните администратори. Второ, максималният размер на таблицата е ограничен от максималния размер на файла. Дори в съвременните операционни системи, в които няма ограничения за размера на файла, те могатвъзникват проблеми поради хардуерни ограничения. Използването на таблични пространства решава и двата проблема. На табличните пространства в база данни се дават уникални имена. Сегментен обект е всеки обект на база данни, който съхранява информация и следователно се нуждае от място в таблично пространство. Типичен пример за сегмент е таблица, но има и други видове сегменти, индекси и сегменти за отмяна. Сегмент може да се съхранява само в едно таблично пространство, но самото таблично пространство може да бъде разделено на много файлове, които съставляват това таблично пространство. По този начин размерът на таблицата вече не е ограничен от максималния размер на един файл. Тъй като много сегменти могат да споделят едно и също таблично пространство, става възможно да имате много повече сегменти, отколкото файлове с данни. Сегментите са обекти, които принадлежат към схема и се идентифицират чрез име на сегмент с името на притежаващата схема. Обектите на програмируемата схема (като PL/SQL процедури, изгледи или последователности) не са сегменти: те не съхраняват данни и се съхраняват в речник на данни.

Блоковете на Oracle са основната единица за операции за четене и запис за база данни. Файловете с данни са форматирани в последователно номерирани блокове на Oracle. Размерът на блока се определя за таблично пространство (като цяло той е еднакъв за всички таблични пространства в базата данни), по подразбиране (версия 11g) е 8Kb. Един ред може да заема само няколкостотин байта, така че няколко реда могат да бъдат съхранени в един блок, но когато една сесия иска да получи ред, целият блок ще бъде прочетен от диска и поставен в буферния кеш. Също така, ако стойността само на една колона за един ред в буфера се е променилакеш - DBWn ще презапише целия блок на диск във файла с данни, откъдето е прочетен, като презапише стария. Размерът на блока на Oracle може да бъде от 2 до 16 KB на операционни системи Linux или Windows и до 32 KB на някои други системи. Размерът на блока се контролира от параметъра DB_BLOCK_SIZE. Не можете да промените тази настройка, след като базата данни е създадена, защото тя се използва за форматиране на файловете с данни на табличното пространство SYSTEM. Ако по-късно се окаже, че е необходимо да промените стойността на този параметър, единственото решение е да създадете нова база данни и да копирате всичко от вече създадената в нея. Блок във файл може да бъде идентифициран чрез неговия уникален номер.

Управлението на дисковото пространство блок по блок би било много времеемка задача, така че блоковете се групират в екстенти. Екстентът е набор от последователни блокове в рамките на един файл с данни. Всеки сегмент се състои от един или повече екстенти, последователно номерирани. Тези екстенти могат да бъдат във всеки или във всички налични файлове с данни на табличното пространство. Екстентът може да бъде идентифициран както в рамките на сегмент (екстентите са последователно номерирани в рамките на сегмент, започвайки от нула), така и във файл с данни (всеки сегмент е само в един файл с данни, започвайки от конкретен блок на Oracle).

Файлът с данни е физически съставен от блокове на операционната система. Начинът, по който блоковете на операционната система са структурирани във файл с данни, зависи изцяло от файловата система, използвана от операционната система. Някои файлови системи имат добре известни ограничения и затова не се използват в съвременните системи (например старата файлова система MS-DOS FAT поддържа файлове с размер до 4 GB и общо 512 файла в една директория). Повечето бази данниинсталира се на файлови системи без практически ограничения, като NTFS на Windows или ext3 на Linux. Алтернатива на файловата система е да съхранявате файлове с данни на необработени устройства или автоматично управление на съхранението (ASM).

Блокът на операционната система е основната единица на операция за четене/запис на файлова система. Ако даден процес иска да прочете един байт от диска, I/O подсистемата все още чете целия системен блок. Размерът на блока на операционната система може да бъде конфигуриран в някои операционни системи (например, когато форматирате диск под файловата система NTFS, можете да посочите размер на блока от 512 байта до 64 KB), но обикновено системните администратори оставят стойностите по подразбиране (512 байта за NTFS и 1 KB за ext3). Ето защо връзката между блоковете на Oracle и блоковете на ОС обикновено е едно към много, както е показано на фигура 5-1. Нищо не ви пречи да направите размера на блока на ОС равен на размера на блока на Oracle, ако операционната ви система го позволява. Единствената конфигурация, която трябва да се избягва, е когато размерът на системния блок е по-голям от размера на блока на Oracle.

Сегменти, екстенти, блокове и редове

Данните се съхраняват в сегменти. Изгледът на речник на данни DBA_SEGMENTS съхранява информация за всички сегменти в базата данни. Заявката по-долу показва всички типове шардове в проста база данни

Разгледайте тези сегменти:

Таблица (Table) е структура, която съхранява редове от данни. Въпреки че най-често срещаният сегмент е таблица, никога не трябва да бъркате таблица със сегмент и има много по-сложни таблици, които използват различен тип сегмент.
Индекс (Индекс) е сортиран списък от ключ-стойности, всяка от които съхранява ROWID указател към физическото местоположение на реда. ROWID определя коеБлок Orace от кой файл с данни е редът и номерът на реда в блока.
TYPE2 UNDO Това са сегменти за отмяна, които съхраняват данни преди промени, за да осигурят целостта на транзакцията: отмяна на транзакция, цялост на четене на данни и изолация
ROLLBACK сегментите за връщане назад не трябва да се използват при нормална работа от версия 9i. Започвайки с версия 9i, се използва автоматичен контрол за отмяна на базата на TYPE2 UNDO (или просто отмяна) сегменти. Винаги ще има един сегмент за връщане назад за поддържане на транзакции по време на създаване на база данни (защото няма сегменти за отмяна по време на създаване), но той не трябва да се използва след създаването на база данни
ДЯЛ НА МАСАТА Една маса може да бъде разделена на няколко дяла. Ако това е конфигурирано, тогава всеки дял ще бъде отделен сегмент и самата разделена таблица няма да бъде сегмент: тя ще съществува като обобщение на всички дялове. Всеки дял ще бъде таблица, отделен сегмент. Тъй като всеки сегмент може да бъде в отделно таблично пространство, става възможно да се раздели таблица на множество таблични пространства
Разделяне на индекс (INDEX PARTITION) По подразбиране индексът е един сегмент, но индексите, като таблиците, могат да бъдат разделени. Ако разделяте таблица, обикновено трябва да разделите и индекса.
Големи обектни сегменти (LOBSEGMENT, LOBINDEX, LOB PARTITION) Ако една колона е декларирана като тип голям обект, тогава таблицата съхранява само указател към запис в отделен сегмент, където се съхраняват данните на тази колона. Големите обекти могат да бъдат индексирани за по-бърз достъп до данните в обекта и разделени
Клъстер (CLUSTER) е сегмент, който съдържа няколко таблици. За разлика отразделяне, което ви позволява да разпределяте таблици между различни сегменти, клъстерирането ви позволява да събирате много таблици в един сегмент
ВГЛАДЕНА ТАБЛИЦА Ако колона в таблица е декларирана като дефиниран от потребителя обект, който от своя страна съдържа колони, тогава тези колони се съхраняват в отделен сегмент като вложена таблица.

Всеки сегмент се състои от един или повече екстенти. Когато се създаде сегмент, Oracle разпределя екстент за инициализация в указаното таблично пространство. Когато данните се добавят, екстентът ще се запълни и Oracle ще разпредели друг екстент в същото таблично пространство, но не непременно в същия файл с данни. Ако знаете, че даден сегмент ще се нуждае от повече дисково пространство, можете ръчно да разпределите екстента за този сегмент. Фигура 5-2 показва как да намерите сегмент. Първо, таблицата HR.NEWTAB се създава с помощта на параметрите по подразбиране. След това резултатът от заявката DBA_EXTENTS показва, че сегментът се състои от един екстент, номериран с нула. Този екстент е във файл номер четири и обхваща 8 блока. Първият от осемте блока е с номер 1401. Размерът на екстента е 64 KB, което означава, че размерът на блока е 8 KB. Следващата команда казва на Oracle да разпредели още един сегмент за този сегмент, въпреки че първият екстент все още не е запълнен. Следната заявка показва, че новият номер на екстент е едно, файлът с данни също е номериран с четири и блоковете се разпределят веднага след първите блокове на екстент.

Обърнете внимание, че от този пример не е напълно ясно от колко файла се състои табличното пространство, тъй като алгоритъмът за избор на файл за създаване на следващия екстент не е просто опашка. Ако е табличенпространството се състои от множество файлове с данни, можете да посочите на кой файл да разпределите екстент, като използвате следния синтаксис

ALTER TABLE име на таблица ALLOCATE EXTENT STORAGE(DATAFILE 'име на файл');

Последната заявка на Фигура 5-2 осъществява достъп до изгледа DBA_DATA_FILES, за да намери името на файла, в който е разпределен екстентът, и името на табличното пространство, към което принадлежи файлът с данни. Можете също да използвате изгледа DBA_SEGMENTS, за да дефинирате табличното пространство на таблица.

Екстентът се състои от набор от последователно номерирани блокове. Всеки блок има област за заглавка и област за данни. Заглавната област е с нефиксиран размер и се записва от началото на блока. Освен всичко друго, заглавката съдържа информация за редовете (където започва всеки ред в блока) и информация за ключалки. Областта с данни се запълва от края на блока. Може да има или да няма празно пространство между тези две области. Събитията, които ще доведат до увеличаване на областта на заглавката, са вмъкване на данни и заключване на ред. Областта с данни първоначално е празна и след това се запълва, когато се записват нови редове (или индексни ключове, ако е блок на индексен сегмент). Празното пространство ще бъде фрагментирано, когато редовете се вмъкват, изтриват и модифицират (което може да промени размера на реда), но това не е важно, тъй като всички операции с данни се извършват в буферния кеш. Фрагментираното пространство се обединява, когато е необходимо, обикновено преди блокът да бъде записан обратно във файла с данни от процеса DBWn.