Локально керовані табличні простору, Інші СУБД, Бази даних, статті

Локально керовані табличні простору з’явилися в Oracle 8i і поступово набирають популярність. Проте використовуються вони все ще не дуже часто. У цій статті описано, що таке локально керовані табличні простору, ніж вони хороші, і пропонуються принципи їх використання.


Минуле й сьогодення табличних просторів


Табличний простір – логічна одиниця дискового простору. Воно може складатися з декількох файлів даних і містити безліч сегментів даних. Вільне місце в табличному просторі розбито на екстенти, і кожен сегмент даних складається з одного або більше екстентів, де екстент являє собою просто безперервний ділянку простору в одному файлі даних. Зазвичай сегмент даних відповідає самодостатньому набору взаємозв’язаних даних (такому як таблиця або фрагмент (секція) індексу), що має певний сенс для кінцевого користувача.


Цей огляд табличного простору відразу виявляє дві проблеми управління простором. Перша – які екстенти належать даному сегменту; а друга – які екстенти використовуються, а які – вільні. Методи вирішення першої проблеми не особливо змінилися в останні роки, а от для більш ефективного вирішення другої проблеми корпорація Oracle запропонувала локально керовані табличні простору (locally managed tablespaces – LMTs) .


Минуле


Історично, управління вільним місцем в табличному просторі реалізовувалося за допомогою двох таблиць: uet$ (used extent table – таблиця використаних екстентів) і fet$ (free extent table – таблиця вільних екстентів).


Коли необхідно виділити простір сегменту, сервер Oracle шукає в таблиці fet$ запис, що описує екстент відповідного розміру у відповідному табличному просторі. Фактично, при цьому пошуку сервер Oracle використовував безліч невеликих, але складних алгоритмів, які вимагали певного часу на виконання, але, в кінцевому підсумку, сервер видаляв (або змінював) рядок в таблиці fet$ і вставляв рядок в таблицю uet$.


Аналогічно, при звільненні екстента (скажімо, при видаленні таблиці) сервер Oracle видалить рядок з таблиці uet$ і вставить або змінить рядок в таблиці fet$.


Фактично, цей процес може також вимагати деяких змін в рядку в таблицях seg$ (У цій таблиці описуються сегменти даних) і tsq$ (У цій таблиці описуються квоти користувачів на використання просторів). Більш того, при додаванні екстента сегменту, карту в першому блоці сегмента (в блоці заголовка сегмента) Треба змінити, відобразивши в ній той факт, що екстент є частиною даного сегмента.


Отже, всі дії з управління простором для всіх табличних просторів бази даних сконцентровані на двох критичних таблицях в словнику даних (Звідси і назва – табличні простору, керовані за словником, dictionary managed tablespaces – DMT). Якщо АБД не знає точно, що відбувається, і не контролює систему, це може привести до проблем. У цих потенційних проблем було три основних причини.


По-перше, в корпорації Oracle вирішили захищати всі дії з управління простором однією чергою “просторових” транзакцій (space transaction enqueue – звідси і блокування “ST»), А не окремими блокуваннями для кожного табличного простору. Тому якщо кілька сеансів вимагають інтенсивного управління простором, вони легко можуть вишикуватися в чергу в очікуванні блокування, що збільшує час обробки.


По-друге, корпорація Oracle, по суті, змусила АБД інтенсивно генерувати завдання управління простором, додавши різні параметри зберігання для сегментів (такі як initial, next, pctincrease), Що обіцяють високий ступінь точності при завданні вимог до простору, але зі стандартними значеннями, які гарантують неефективне управління простором.


Нарешті, в суспільній свідомості було достатньо нерозуміння й невизначеності, щоб початківці АБД слідували процедурам, в результаті застосування яких рано чи пізно те, що може зіпсуватися, зіпсується гарантовано. Всіх проблем, пов’язаних з табличними просторами, керованими за словником, можна уникнути, якщо тільки витратити достатньо часу і розібратися, як саме вони працюють (а розташовують Чи нинішні АБД часом хоч коли-небудь?).


Справжнє


Локально кероване табличний простір саме відповідає за управління вільним місцем у ньому. У щойно встановленій системі кожен файл в табличному просторі ділиться на чанкі однакового розміру (За винятком перших 64 Кбайт файлу, які використовуються для зберігання бітової карти, що ідентифікує інші використовувані чанкі). Кожен біт в бітової карті відповідає чанк у файлі – якщо біт встановлений, чанк використовується, а якщо біт скинутий, то чанк вільний. На рис. 1 представлений схематичний вигляд новоствореного табличного простору, що містить єдиний файл, і стан цього файлу після створення і видалення ряду об’єктів.



Рис. 1. Чисте (вгорі) і частково використане (внизу) локально кероване табличний простір.


Можна задати розмір файлу і розмір чанків для даного файлу. Наприклад, розглянемо сценарій:


create tablespace demo_01
datafile “c:oracleoradataD9202demo_01.dbf”
size 102464k
extent management local
uniform size 1024K;


Він створює табличний простір з одним файлом (вельми дивного на вигляд розміру), який розділений рівно на 100 чанків розміром 1024 Кбайта, але з додаванням додаткових 64 Кбайт для бітової карти файлу. Якщо звернутися до подання dba_free_space із запитом про вільне місце в цьому табличному просторі, ми отримаємо рівно 104857600 байтів. Якщо спробувати виділити екстент, виявиться, що екстент за розміром відповідатиме рівно одному чанк – при завданні uniform size один чанк відповідає одному екстента.


Типова проблема з локально керованими табличними просторами полягає в тому, що АБД задають розмір файлу без урахування місця під бітову карту; як наслідок, вони “втрачають” майже весь екстент в кінці файлу, оскільки в файлі не вистачає 64 Кбайта для виділення останнього екстента. Якщо ви зіткнетеся з цією проблемою, треба тільки збільшити розмір файлу файлу на бракуючі 64 Кбайта, і ви можете на свій подив виявити додатковий екстент в поданні dba_free_space.


Примітка: для локально керованих табличних просторів можна застосовувати опцію autoallocate замість uniform size X. В результаті файл все одно ділиться на чанкі однакового розміру (в даному випадку, завжди розміром 64 Кбайта), і в бітової карті використовується один біт на чанк. Однак замість зіставлення екстента одному чанк, сервер Oracle буде враховувати попередні дії та наявні вільні місця при виборі розміру виділяється екстента. При цьому виділяється екстент одного зі стандартних розмірів – 64 Кбайта, 1 Мбайт, 8 Мбайт, 64 Мбайта або 256 Мбайт. Для порівняно невеликих, простих систем, в яких для визначення вимог до простору недостатньо інформації, це може виявитися самим простим і прийнятним механізмом, але, в загальному випадку, слід використовувати екстенти однакового розміру.


Отже, що ж дають локально керовані табличні простору? Найважливіше, що при виділенні місця в локально урпавляемом табличному просторі серверу Oracle не доводиться переглядати таблицю в пошуках рядка, що описує відповідний чанк; замість цього достатньо переглянути перших кілька блоків файла в пошуках першого вільного біта, і встановити його. Це набагато більш ефективний метод пошуку і виділення вільного простору, та ще й з приємним побічним ефектом, – спочатку буде виділятися вільне місце ближче до початку файлу, а це допомагає зменшити розмір файлів і прискорити резервних копіювання за допомогою rman.


Звичайно, серверу Oracle як і раніше доводиться підтримувати таблицю seg$ і блок блок заголвка сегмента, а також може знадобитися змінити таблицю tsq$, Але найскладніша частина операції виділення простору виконується набагато ефективніше. Більш того, замість використання однієї черги просторових транзакцій (ST) для всієї бази даних, сервер Oracle використовує новий тип черги – черга TT – і використовує по одній черзі TT для кожного табличного простору, щоб скоротити кількість конфліктів при одночасному виділенні простору в декількох сеансах.


Не все так однозначно. Тепер стало набагато швидше і простіше виділяти і звільняти простір, але деякі з класичних звітів, що підраховують вільне або використане місце, стали менш ефективними. Замість запиту до однієї таблиці (fet$ і uet$, Відповідно), для отримання підсумкових результатів доведеться переглянути заголовок кожного файлу або заголовок кожного сегмента. Однак фактично продуктивність в даному випадку – не проблема, оскільки подібні звіти (я сподіваюся) не потрібно будувати часто.


І в чому ж переваги?


Нові можливості можуть давати переваги в трьох областях: (а) стратегічні перспективи, (б) продуктивність і (в) спрощення адміністрування. Я розгляну кожне з потенційних переваг по черзі.


З урахуванням перспективи, необхідно переводити всі системи на використання локально керованих табличних просторів. В Oracle 9.2 мастер створення баз даних (Database Creation Assistant) за замовчуванням створює базу даних з локально керованим табличним простором system. Якщо табличний простір system є локально керованим, ви не зможете створювати в базі даних табличні простору, керовані за словником. Ясно, що корпорація Oracle передбачає загальний перехід на локально керовані табличні простору в найближчому майбутньому – досить імовірно, що в Oracle 10 простору, керовані за словником, взагалі не будуть підтримуватися, так що буде мудро завершити перехід до того, як вийде наступна версія сервера Oracle. До речі, навіть якщо табличний простір system є локально керованим, все одно можна буде використовувати механізм переносите табличних просторів (transportable tablespace mechanism) для підключення до бази даних табличного простору, керованого за словником, але це табличне простір буде доступно тільки для читання.


Що ж стосується продуктивності, то вона при використанні локально керованих табличних просторів не є істотною перевагою. Хоча “приголомшливе” підвищення продуктивності за рахунок використання бітових карт вважається загальновідомою причиною переходу з табличних просторів, керованих за словником, на локально керовані, достатньо лише пару хвилин подумати про те, коли, де і як ви можете отримати це перевага, щоб зрозуміти, що воно практично не має значення. Запитайте себе: “Як часто доведеться виділяти і незабаром звільняти простір?”. Правильна відповідь – вкрай рідко. Розглянемо найбільш типові випадки, коли це відбувається:



Всіх представлених вище “проблем продуктивності” можна уникнути або звести їх вплив до мінімуму і без переходу на використання локально керованих табличних просторів, і багато АБД роками виконували необхідні кроки, що дозволяють їх уникнути. Є добре відома стаття на цю тему, доступна через Metalink або OTN (“How to Stop Defragmenting and Start Living” – “Як перестати дефрагментувати і почати жити “), але коротко рекомендації наступні:



  1. Не задавайте конструкції зберігання для об’єктів; завжди використовуйте стандартні значення табличного простору.
  2. Встановіть pctincrease = 0 в якості стандартного значення для табличного простору.
  3. Встановіть стандартне значення initial = next для табличного простору.
  4. Встановіть мінімальний розмір екстента для табличного простору рівним initial/next.
  5. Поміщайте об’єкти в табличні простору, які підходять для них з урахуванням передбачуваних розмірів об’єктів.
  6. Чи не експортуйте із зазначенням compress = y якщо плануєте пересоздавать таблиці за допомогою імпорту.
  7. Оцініть, скільки тимчасового простору знадобиться, оголосіть і виділіть (кілька) тимчасових табличних просторів відповідно до цих оцінками
  8. Намагайтеся не використовувати постійні таблиці для розміщення проміжних даних – спробуйте використовувати глобальні тимчасові таблиці.

Отже, нарешті, ми дісталися до переваг при адмініструванні. Чому використання локально керованих табличних просторів допомагає адміністраторам баз даних контролювати їх бази? По суті, відповідь дан в згадуваній статті про дефрагментацію – там даються хороші поради, і при переході на локально керовані табличні простору з однаковими екстента поради ці, фактично, враховуються і реалізуються на рівні бази даних.


Якщо проаналізувати представлений вище список, виявляється, що кроки 2, 3 і 4 автоматично і безумовно виконуються при створенні табличного простору як локально керованого з екстента одного розміру – розміри всіх екстентів виявляться однаковими. Крім того, кроки 1 і 6 стають практично непотрібними: навіть при невідповідності параметрів в конструкціях зберігання при створенні або імпортуванні об’єктів, сервер Oracle враховує суть запиту, ігноруючи деталі і виділяючи екстенти відповідно до визначення табличного простору. Як наслідок, велика частина стратегічних рішень, за реалізацію яких хороші АБД боролися роками, є стандартними при використанні локально керованих табличних просторів. Ключове слово тут – “боролися”. Незважаючи на всі зусилля адміністраторів баз даних, при використанні табличних просторів, керованих за словником, проблеми могли виникати, а ось в локально керованих табличних просторах з екстента однакового розміру жоден користувач не зможе змінити заданий розмір екстента.


Але що дає примусове зведення всіх ╨ кстентов табличного простору до одного розміру? (Якраз час згадати мій колишній коментар про те, що слід уникати використання локально керованих табличних просторів з автоматичним визначенням розміру екстента, оскільки вони допускають шість різних розмірів екстентів.) По-перше, це спрощує контроль простору, по-друге, упаковувати дані серверу стає зручніше, а по-третє, підвищується надійність при пересоздании об’єктів.


Є у вас невеликий, але хитромудрий сценарій, що визначає, чи вистачить місця у відповідному табличному просторі для наступного екстента того чи іншого об’єкта? При використанні локально керованого табличного простору з екстента одного розміру цей сценарій спрощується до наступної перевірки: “Чи є вільне місце в табличному просторі; якщо є, то місця під екстент вистачить. Можна навіть будувати звіти на базі кількох дуже простих запитів:


Rem Rem Знайти розмір екстента для кожного локально керованого табличного простору Rem Визначити, скільки об’єктів в кожному табличному просторі Rem Визначити обсяг вільного місця в кожному табличному просторі
Rem
select tablespace_name, initial_extent
from user_tablespaces
where extent_management = “LOCAL”
and allocation_type = “UNIFORM” – Можна також включити “SYSTEM
;
select tablespace_name, count(*)
from dba_segments
group by tablespace_name
;
select tablespace_name, sum(bytes)
from dba_free_space
group by tablespace_name
;


Побудувавши на базі (уточнених варіантів) цих трьох запитів підставляються подання з підказкою /*+ no_merge */ і з’єднуючи їх відповідним зовнішнім з’єднанням, можна, наприклад, побудувати звіт, що показує, скільки сегментів даних знаходиться в кожному табличному просторі і скільки з них може одночасно збільшитися без проблем.


Аналогічно, можна почати з простого запиту виду:


select
tablespace_name, segment_name, partition_name, extents
from dba_segments


Потім можна комбінувати отримані результати з першим з представлених вище запитів для отримання, щодня або щотижня, кількості екстентів в кожному об’єкті. Це дозволяє будувати звіти (“diff” report) про зростання сегментів, які можна використовувати для прогнозування вимог до простору в майбутньому. При наявності механізму, що дозволяє зіставити кількість екстентів з розміром об’єкта, виявлення тенденцій істотно спрощується.


Мета, таким чином, полягає в гарантованому використанні екстентів одного розміру, що дозволяють будувати відповідні корисні звіти для аналізу та прогнозування. Ключ до корисності полягає в тому, щоб видавалися тільки важливі дані або зміни, і щоб вони не ховалися серед великого обсягу тривіальної або несуттєвою інформації.


Принципи, викладені у статті по дефрагментації, має сенс застосовувати і для локально керованих табілчних просторів. Проклассіфіціруйте об’єкти за додатками, стилю використання і, нарешті, за розміром. Зазвичай вдається вибрати три-чотири типових розміру об’єктів – скажімо, “маленький”, “середній”, “великий” і “величезний” – створіть табличний простір, відповідне кожному з цих розмірів. (Я віддаю перевагу працювати з розмірами, кратними 8 або 16, так що для чотирьох “типорозмірів” я б міг створити табличні простору з однаковими екстента розміром 64 Кбайта, 512 Кбайт, 4 Мбайта і 16 Мбайт). Потім ви прив’язуєте об’єкти до табличним просторам виходячи з припущення, що порівняно статичні об’єкти повинні містити, скажімо, від 1 до 16 екстентів, а для постійно зростаючих може додаватися по одному екстента раз в пару місяців. В результаті застосування цієї стратегії база даних виходить адекватного розміру, і при зростанні обсягів даних ніяких сюрпризів не буде.


Звичайно, можливі помилки, і первинні оцінки можуть привести до розміщення об’єкта не в тому табличному просторі. Перенести об’єкти з одного табличного простору в інше досить просто, і при цьому не буде ніяких проблем з розміщенням об’єктів. Якщо для об’єкта досить вільного місця в табличному просторі, в цьому місці його можна буде помістити. Згадайте ті жахливі часи, коли при наявності 100 Мбайт вільного місця в табличному просторі ви не могли імпортувати в нього таблицю розміром 51 Мбайт просто тому, що ці 100 Мбайт складалися з двох не йдуть підряд шматків по 50 Мбайт кожен? Цього не буває в локально керованих табличних просторах. Всі дірки – одного розміру, і кожен об’єкт автоматично створюється як набір шматків, розмір яких в точності відповідає цим діркам. При перенесенні таблиці розміром 24 Мбайта з “64 Мбайтного” табличного простору в “1 Мбайтное”, їй не знадобиться екстент розміром 64 Мбайта (вона його і не зможе отримати); вона автоматично розміститься в 24 екстента по 1 Мбайту.


Для користувачів сховищ даних зручність і надійність використання простору також спрощує розробку стратегії перенесення та упаковки даних перед переведенням їх в режим тільки читання. (А Oracle 9.2 пропонує багатообіцяючу можливість зберігання даних у таблиці тільки для читання із стисненням.) Безпосередньо перед переведенням набору даних (наприклад, фрагментів, – “секцій” – за останній місяць) в режим тільки для читання можна перенести і стиснути дані, перебудувати індекси і усікти відповідні файли до мінімально можливого розміру. І це можна зробити настільки зручно і наждежно, як ніколи раніше при використанні табличних просторів, керованих за словником.


Фактично, може мати сенс перенести об’єкти в табличні простору “не того” однакового розміру просто тому, що кількість екстентів при цьому стає оптимальним по відношенню до використовуваних пристроїв, файлів і особливостям розпаралелювання. Перехід на локально керовані табличні простору відкриває дуже цікаві можливості стратегічного управління простором (proactive space management) і підвищення продуктивності за рахунок ефективного управління простором.


Висновок


Отже, що ж насправді дає використання локально керованих табличних просторів?



Чи треба використовувати локально керовані табличні простору? Безсумнівно – все, що допомагає позбутися від складності і знижує ймовірність помилок, особливо при виконанні рутинних, але тривалих за часом виконання завдань, – це добре. Особливо якщо врахувати, що використання локально керованих табличних просторів дає ще й ряд переваг з точки зору проізводітельтності.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*