Microsoft SQL Server 7.0 – Механізм зберігання даних

Interface Ltd

Зміст:

Введення

Особливості

Архітектура механізму зберігання даних

Фізична організація бази даних

Розширені засоби блокування

Архітектура базисних таблиць та індексів

Типи даних

Архітектура менеджера журналу

Управління пам'яттю

Висновок

 

Введення

Десять років тому розробка програм для роботи з базами даних нерідко

тривала місяцями або навіть роками. Всі планувалося заздалегідь: розмір, схема,

кількість користувачів і т.д. Тепер подібні додатки створюються в

Протягом декількох тижнів або місяців, розвиваючись безпосередньо в процесі

розробки, і запускаються в експлуатацію ще до того, як всі аспекти остаточно

опрацьовані.

Оперативна розробка важливих додатків висуває суворі вимоги

до механізмів зберігання даних, які повинні бути легко доступні, комплектуватися

системою для швидкого відновлення даних і утилітами для автоматичного

адміністрування. Microsoft ® SQL Server ™ версії 7.0 – це масштабований,

надійний і простий у використанні продукт, що представляє собою прекрасну

основу для розробки додатків наступного століття.

 

Призначення

При розробці механізмів зберігання даних SQL Server 7.0 переслідувалося

кілька важливих цілей. Визначальним фактором стратегії з'явилася тенденція

до спрощення використання, яка дозволила б забезпечити широке впровадження

додатків, що використовують технології СУБД. В ідеалі СУБД повинні стати абсолютно

"Прозорими" для кінцевих користувачів і майже "прозорими" для адміністраторів.

 

Простота використання

Клієнти шукають рішення проблеми свого бізнесу. Більшість рішень на

основі баз даних дороги і складні. SQL Server версій 6.0 та 6.5 відкрив можливість

простого використання коштів реляційних СУБД (РСУБД). SQL Server 7.0

підняв цю концепцію на новий рівень, що зробило його однією з найменш

складних СУБД для створення, адміністрування та впровадження ділових додатків.

Простота і зручність використання SQL Server 7.0 забезпечується його

численними передовими можливостями, включаючи:

Масштабованість

Клієнти прагнуть захистити свої інвестиції в бізнес-додатки і, по

мірі зростання організації, бази даних повинні розвиватися, щоб забезпечити

обробку більшого обсягу даних, збільшеної кількості транзакцій і

обслуговування зростаючої кількості користувачів. SQL Server 7.0 надає

єдине ядро СУБД, масштабоване від портативних комп'ютерів під управлінням

операційної системи Microsoft Windows ® 95 або Windows 98 до кластерів

із симетричною мультипроцессорной архітектурою, що працюють в середовищі Microsoft

Windows NT ® Server, Enterprise Edition. Всі ці системи повинні задовольняти

вимогам високої безпеки і надійності, які висуваються з боку

критичних бізнес-додатків.

Наступні особливості служать основою високої масштабованості:

Надійність

SQL Server 7.0 усуває безліч проблем паралельного доступу, масштабованості

і надійності шляхом заміни складних структур даних і алгоритмів простими.

Нові структури краще масштабуються, породжують менше проблем при паралельній

обробці, менш складні, а, отже, і більш надійні.

У SQL Server 7.0 усунута необхідність перевірки цілісності бази даних

перед кожною операцією резервного копіювання. Перевірка найбільш важливих

структур даних "на льоту" забезпечує більшу стійкість. За рахунок цього

перевірка цілісності відбувається тепер значно швидше.

 

Особливості

У наступній таблиці перераховані основні особливості механізмів зберігання

даних в SQL Server 7.0.

 

Особливість

Опис і гідності

Розміри типів даних

Граничні розміри типів даних значно

збільшені.

Бази даних і файли

Спрощено створення баз даних. Тепер вони розміщуються

у файлах операційної системи, а не на логічних пристроях.

Динамічне управління пам'яттю

За рахунок оптимізації розподілу та використання

пам'яті підвищена продуктивність. Спрощена структура зводить до мінімуму

конкуренцію з іншими менеджерами ресурсів.

Динамічна блокування на рівні рядків

Повноцінна реалізація блокування на рівні

рядків, як для даних, так і для індексів. Динамічна блокування забезпечує

автоматичний вибір оптимального рівня (рядки, сторінки, діапазону сторінок

або всієї таблиці) для всіх операцій з базою даних. Завдяки цьому, досягається

підвищення продуктивності без додаткової настройки. Допускається

і явне вказівку конкретного рівня блокування.

Динамічне управління простором

Автоматична зміна розмірів допустимо

в регульованих межах, що зводить до мінімуму потребу у втручанні

адміністратора. Відсутня необхідність попереднього розподілу

простору і управління структурою даних.

Розвиток

Нова архітектура розроблена з урахуванням можливості

розвитку і забезпечує основу для реалізації об'єктно-реляційних властивостей.

Підтримка оперативної пам'яті великого обсягу

У поєднанні з Windows NT Server 2000 забезпечується

адресація більше 4 ГБ оперативної пам'яті, системи на базі процесорів Alpha

та інші технології.

Управління журналом

Спрощена архітектура забезпечує підвищення

продуктивності при виконанні операцій усікання, копіювання і відновлення.

Попередній виклик

Для підвищення продуктивності і виключення

ручний налаштування реалізовано інтелектуальні алгоритми попереджувального читання.

Текст і зображення

Текстові та графічні дані зберігаються окремо

в оптимізованому форматі

Unicode

Вбудована підтримка Unicode в поєднанні з інтерфейсами

ODBC і OLE DB для створення багатомовних Unicode-додатків.

Архітектура механізму зберігання даних

Microsoft SQL Server 7.0 масштабується в широких межах від корпоративних

додатків до додатків для портативних комп'ютерів. Це можливо завдяки

абсолютно новій структурі організації дискового простору, покликаної

задовольнити потреби додатків, які з'являться в майбутньому.

Початковий код був успадкований від Sybase і орієнтований на 8Мб UNIX-системи.

Microsoft переробила цей код, але на майбутнє SQL Server потребував кращої

основі. Використання нових форматів підвищує керованість, продуктивність

і масштабованість, забезпечуючи можливість масштабування сервера в широких

межах.

Серед багатьох переваг нової організації дискового простору в

SQL Server 7.0:

Підсистеми зберігання даних

Більшість реляційних СУБД складаються з реляційного ядра і механізмів

зберігання даних. У даному документі основну увагу приділено механізмам

зберігання даних, які включають різні підсистеми, що реалізують:

Фізична організація бази даних

Microsoft SQL Server 7.0 краще інтегрований з Windows NT Server, ніж

попередні версії SQL Server. Тепер бази даних розміщуються безпосередньо

у файлах Windows NT Server. Успадковані від UNIX логічні пристрої

бази даних і сегменти були замінені простою системою, яка "проектує"

кожну базу даних у індивідуальний набір файлів.

SQL Server більш пристосовано до вимог як великих, так і невеликих

додатків. Деякі розробники СУБД починають з середини і рухаються

у бік великомасштабних додатків. Вони представили різні продукти,

використовують різні формати даних, мови і інтерфейси програмування

для створення об'ємних і складних додатків. Оскільки багато користувачів

Microsoft Access переходять на SQL Server, Microsoft піклується і про них,

приділяючи увагу тим властивостям, які необхідні для створення компактних

недорогих додатків.

 

Сторінки і екстенти

Основна одиниця зберігання даних в SQL Server – сторінка. У SQL Server

7.0 розмір сторінки виріс з 2 до 8 КБ. На початку кожної сторінки розташований

заголовок (header) довжиною 96 байт, що використовується для зберігання системної

інформації, такої як тип сторінки, кількість вільного простору

на сторінці та ідентифікатора об'єкта-власника сторінки.

У файлах даних СУБД SQL Server 7.0 визначено 7 типів сторінок.

 

Тип сторінки

Вміст

Data

Рядки з даними всіх типів, крім text,

ntext

і

image

Index

Індекси

Log

Записи журналу з інформацією про зміну даних

для використання при відновленні

Text/Image

Дані типів text, ntext і image

Global Allocation Map

Інформація про розподілених екстент

Page Free Space

Інформація про доступне на сторінках вільному

просторі

Index Allocation Map

Інформація про екстент, використовуваних для таблиць

або індексів

Сторінки даних містять дані всіх типів, за винятком text, ntext

і image, які зберігаються на окремих сторінках. Рядки даних розташовуються

послідовно одна за одною відразу після заголовка сторінки. Таблиця

зміщень рядків починається з кінця сторінки.

Ця таблиця містить один елемент для кожного рядка на сторінці. Кожен

елемент вказує, на якій відстані від початку сторінки розташований перший

байт рядка. Елементи таблиці зміщень рядків мають зворотний порівняно

з розташуванням на сторінці самих рядків порядок. У SQL Server 7.0 рядки

не можуть переходити зі сторінки на сторінку, і максимальний обсяг даних

в одному рядку становить 8060 байт, не включаючи дані типів text, ntext

і image.

Екстент – основна одиниця розподілу простору для таблиць і індексів.

Один екстент складається з 8 суміжних сторінок і має розмір 64 КБ. Для забезпечення

ефективного використання простору SQL Server 7.0 може не розподіляти

всього екстент цілком для таблиці, яка містить невеликий обсяг даних.

У SQL Server 7.0 існує два типи екстент: однорідні і змішані.

Однорідний екстент має єдиний об'єкт-власник, і всі сторінки екстент

можуть використовуватися тільки цим об'єктом-власником.

Змішані екстенти, що вперше з'явилися в SQL Server 7.0, чудово

підходять для використання в невеликих додатках. У SQL Server простір

додається до таблиці по одному екстент. У SQL Server 7.0 це може призвести

до великого перевитрати простору для маленьких таблиць, оскільки розмір

сторінки збільшився до 8 Кб. Змішані екстенти дозволяють розподіляти

для маленьких таблиць або індексів по одній сторінці. Тільки в тому випадку,

якщо таблиця або індекс займають більше восьми сторінок, для них починається

розподіл однорідних екстент. Змішані екстенти розділяються між

декількома (до 8) об'єктами. Для нової таблиці або індексу виділяються

сторінки зі змішаних екстент. Коли розмір таблиці або індексу досягає

8 сторінок, він "переключається" на однорідні екстенти.

 

Виявлення "рваних" сторінок

Виявлення "рваних" сторінок гарантує підтримку цілісності бази

даних. Хоча розмір сторінки в SQL Server 7.0 дорівнює 8 КБ, Windows NT Server

здійснює операції введення-виведення сегментами по 512 байт. Така невідповідність

породжує можливість того, що сторінка буде записана лише частково –

це може статися при збої електроживлення або виникненні будь-яких

інших проблем у проміжку часу від того моменту, коли записаний перший

512-байтовий сегмент, до того, коли буде завершений запис всіх 8 КБ.

Після того, як записаний перший сегмент з 512 байт, може здатися,

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

позначка для сторінки розташована в заголовку, який займає перші 96

байт.) Існує кілька способів вирішення цієї проблеми. Ви можете використовувати

пристрої введення-виведення з резервним живленням від батарей. Якщо у вас одна

з таких систем – виявлення "рваних" сторінок необов'язково.

SQL Server виявляє незавершені операції введення-виведення шляхом формування

бітової маски, по одному біту для кожного сегмента сторінки. Кожен раз

при записі сторінки цей біт змінює свій стан з первісного

(Як він був записаний на диску) на протилежне і записується в заголовок

сторінки. Якщо при читанні сторінки виявляється невірне стан біта

– Це свідчить про те, що операція вводу-виводу не була завершена

і сторінка "рвана". Такий механізм потребує менших витрат, ніж підрахунок

контрольної суми.

Ви можете включити або відключити виявлення "рваних" сторінок, тому що заголовок

сторінки позначається при зміні стану бітів. При включенні і відключенні

виявлення "рваних" сторінок, стан бітів, які були "переключені",

перевіряється і коригується під час наступного читання сторінок.

 

Файли і групи файлів

SQL Server 7.0 використовує для зберігання баз даних набір файлів операційної

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

баз даних більше не можуть перебувати в одному файлі. Існує кілька

важливих переваг такого спрощення: файли можуть розростатися і скорочуватися,

управління простором також стало простіше.

Усі дані та об'єкти бази даних, такі як таблиці, збережені процедури,

тригери та подання, зберігаються в таких файлах.

 

Файл

Опис

Первинний файл даних (Primary data file)

Цей файл – відправна точка бази даних. Будь-яка

база даних має тільки один первинний файл даних. Рекомендоване розширення

— .mdf.

Вторинні файли даних (Secondary data files)

Ці файли є необов'язковими і можуть зберігати

всі дані і об'єкти, які не ввійшли в первинний файл даних. Деякі бази

даних можуть взагалі не мати вторинних файлів даних, а інші мати безліч

таких файлів. Рекомендоване розширення -. Ndf.

Файли журналу (Log files)

У цих файлах фіксується вся інформація про транзакції,

яка використовується для відновлення бази даних. Кожна база даних

має, принаймні, один файл журналу. Рекомендоване розширення -. Ldf.

При створенні бази даних все що входять до її складу файли "обнуляются"

(Заповнюються нулями), щоб стерти всі дані, які залишилися на диску

від раніше видалених файлів. Хоча це призводить до збільшення тривалості

створення БД, це рятує Windows NT від необхідності очищення файлів при

запису даних в них (оскільки вони вже "обнулені") під час нормальної

роботи з базою даних, що підвищує продуктивність системи.

База даних складається з одного або більше файлів даних і одного або більше

файлів журналу. Файли даних можуть бути згруповані у певні користувачем

групи. Таблиці та індекси можуть бути поставлені у відповідність різних

групам файлів для управління розміщенням даних на фізичних дисках.

Група файлів – зручна одиниця адміністрування, використання якої

підвищує його гнучкість. При обслуговуванні великих баз даних, обсягом у кілька

терабайт резервне копіювання всієї бази неможливо зробити в прийнятні

строки незалежно від швидкості копіювання. SQL Server 7.0 дозволяє виробляти

резервування різних частин бази даних у нічний час за циклічним

графіком.

"Просунуті" користувачі можуть з успіхом використовувати групи файлів

для того, щоб розмістити індекси і таблиці певним чином. SQL

Server 7.0 може ефективно працювати і без угруповання файлів, і в більшості

систем немає необхідності визначати користувацькі групи файлів. У цьому

випадку за замовчуванням до групи включаються всі файли, і SQL Server 7.0 може

самостійно планувати ефективний розподіл в межах бази даних.

Файли журналу ніколи не входять у групи, керування розподілом

простору для них здійснюється окремо від розподілу простору

для даних.

 

Використання файлів і груп файлів

Використання файлів і груп файлів дозволяє підвищити продуктивність

бази даних за рахунок розподілу по різних дисків, контролерам або

RAID-масивів. Наприклад, якщо у вашому комп'ютері встановлено 4 диски, ви

можете створити базу даних, що складається з трьох файлів даних і одного файлу

журналу, і кожен з них розмістити на окремому диску. При доступі до даних

4 магнітних головки зможуть здійснювати читання або запис одночасно,

що підвищить швидкість виконання цих операцій.

Крім того, використання файлів і груп файлів дозволяє краще розмістити

дані, завдяки тому, що конкретна таблиця може бути створена в певній

групі. Продуктивність в даному випадку підвищується за рахунок того, що

всі операції введення-виведення для цієї таблиці здійснюються із зазначеним диском.

Наприклад, інтенсивно використовується таблиця може перебувати в певному

файлі, який належить до певної групи, розташованої на певному

диску, а інша таблиця, використовувана рідше – в іншому файлі, що належить

до іншої групи, розташованої на другому диску.

Ось декілька загальних рекомендацій щодо використання файлів та груп файлів:

Управління простором

Засоби SQL Server 7.0 в чому вдосконалені в аспекті управління

і розподілу простору. Наприклад, структури даних для управління

відносинами сторінка-об'єкт були спроектовані наново. Замість пов'язаних

списків сторінок тепер використовуються бітові карти, що є більш "чистим"

і простим рішенням, що допускає паралельне сканування. Тепер кожен

з файлів більш "автономний", він містить більше відомостей про самого себе.

Це дуже корисно при копіюванні файлів бази даних або їх пересилання по

електронною поштою.

SQL Server 7.0 також оснащений більш ефективною системою відстеження

простору в таблицях. Вироблені удосконалення дозволяють:

У більш ранніх версіях SQL Server при додаванні великого обсягу даних

механізм розподілу простору міг викликати блокування. Алгоритм розподілу

простору і структури даних в SQL Server 7.0 простіше, ефективніше і не

викликає блокування, так як SQL Server 7.0 відстежує вільний простір

на сторінці. При видаленні рядки з таблиці, для якої не використовуються

кластерізованние індекси, простір, що звільнився може повторно використовуватися

для вставки нового рядка. Таким чином забезпечується більш ефективне

використання дискового простору і прискорюється перегляд сторінок за рахунок

більш щільного зберігання даних.

SQL Server 7.0 швидко розподіляє сторінки для об'єктів і повторно

використовує простір, звільнене у видаленні рядків. Ці операції

є внутрішньосистемні і використовують структури даних, невидимі для

користувача. Тим не менше, ці процеси і структури іноді згадуються

в повідомленнях SQL Server. Це обговорення алгоритмів розподілу простору

і структур даних ставить собі за мету надати користувачам і адміністраторам

інформацію, необхідну для розуміння повідомлень, що генеруються SQL Server.

У SQL Server 7.0 зроблені значні зміни в структурі внутрішніх

даних, керуючих розподілом і повторним використанням сторінок.

Ці структури даних залишаються невидимими для кінцевого користувача, і,

таким чином, ніяк не впливають на його роботу, за винятком підвищення

швидкості.

Скорочення файлів

Портативні та настільні комп'ютери можуть мати обмеженим дисковим

простором, тому ви можете автоматично скорочувати розмір файлів,

якщо включена відповідна можливість. Сервер періодично перевіряє

використання простору в кожній базі даних. Якщо виявлено велику

кількість вільного простору, розмір файлу бази даних буде зменшений.

І файли даних, і файли журналу можуть бути скорочені. Ці операції відбуваються

у фоновому режимі і не впливають на роботу користувача з базою даних. Ви

можете також використовувати засоби SQL Server Enterprise Manager або DBCC

для індивідуального або групового скорочення розмірів файлів.

При скороченні файлу рядки з сторінок, розташованих в кінці файлу,

переміщуються в сторінки, розподілені раніше. У індексах вузли також переміщуються

з кінця файлу на сторінки, що лежать ближче до початку. В обох випадках сторінки,

розташовані в кінці файлів, звільняються і повертаються у файлову систему.

Бази даних можуть скорочуватися тільки до того моменту, поки в них не залишиться

вільного простору. Компресія даних не використовується.

Розширення файлів

Автоматичне збільшення файлів скорочує потребу в управлінні

базою даних і усуває безліч проблем, що виникають при виході бази

даних чи журналу за межі відведеного простору. При створенні бази

даних повинен бути заданий початковий розмір файлів. SQL Server створює

файли даних, розмір яких вказується творцем бази. Додаються дані

поступово заповнюють ці файли. За замовчуванням файли даних можуть, у міру

необхідності, збільшуватися в розмірі, поки не буде вичерпано всі дисковий

простір. Альтернативна настройка передбачає автоматичне збільшення

розмірів файлів при їх заповненні даними, проте до певної межі.

Це запобігає переповнення дисків.

Розглянута можливість корисна в тих випадках, коли SQL Server

використовується в якості вбудованої в додаток СУБД або коли користувач

не має доступу до послуг системного адміністратора. При необхідності

користувач може дозволити автоматичне збільшення файлів, щоб скоротити

накладні витрати на адміністрування, уникнути стеження за вільним

простором в базі даних і ручного розподілу додаткового простору.

При створенні бази даних файли даних повинні бути великі, як тільки

можливо, з урахуванням максимального очікуваного обсягу даних. Ви можете дозволити

автоматичне збільшення розмірів файлів, але вказати при цьому обмеження.

Якщо спочатку зазначений розмір перевищено і файл почав автоматично

збільшуватися, проведіть повторну оцінку максимального розміру бази

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

створіть і додайте до бази даних додаткові файли або групи файлів.

Збільшення розміру бази даних понад спочатку зазначеного може

бути заборонено. Тоді при заповненні файлів нові дані не можуть бути

додано, поки не будуть додані нові файли даних. Автоматичне збільшення

файлів може призвести до фрагментації простору, якщо на одному диску

розташована велика кількість файлів. Тому рекомендується створювати

файли або групи файлів на якомога більшій кількості локальних фізичних

дисків. Об'єкти, інтенсивно конкуруючі за дисковий простір, слід

розміщувати в різних групах файлів.

Розширені засоби блокування

Засоби блокування в Microsoft SQL Server 7.0 отримали розвиток в декількох

напрямках.

Блокування на рівні рядків

У SQL Server 6.5 вперше з'явилася блокування на рівні рядків при виконанні

операцій вставки. SQL Server 7.0 підтримує повноцінну блокування на

рівні рядків, як для рядків даних, так і для елементів індексу. У процесі

виконання транзакцій окремі записи можуть бути оновлені без блокування

сторінок. Багато OLTP-додатки вступають в інтенсивну конкуренцію, особливо

при доданні рядків в таблиці або індекси. Менеджер блокувань динамічно

регулює використання ресурсів у великих базах даних, усуваючи необхідність

в настройці параметрів блокування на сервері. Він автоматично здійснює

вибір між блокуванням сторінки (кращою при перегляді таблиць)

і блокуванням на рівні рядків (кращою при вставці, оновленні

або видалення даних).

Динамічна блокування

SQL Server 7.0 оснащений чудовим механізмом блокування, який рідко

використовується в промислових СУБД: динамічної блокуванням. Під час роботи

механізми зберігання даних динамічно взаємодіють з процесором обробки

запитів для вибору, виходячи з параметрів схеми і запиту, стратегії блокування,

вимагає найменших витрат.

Динамічна блокування володіє наступними перевагами:

Динамічна блокування дозволяє при виконанні транзакцій здійснювати

блокування різних типів ресурсів. Для зменшення накладних витрат

SQL Server автоматично блокує ресурси на рівні, найкращим чином

відповідному ситуації. Виборча локальна блокування, наприклад,

окремих рядків, підвищує можливості паралельної роботи, проте збільшує

завантаження системи, тому що доводиться керувати великою кількістю блокувань,

коли кількість заблокованих рядків велике. Блокування на більш високому

рівні, наприклад, таблиць, ускладнює паралельну роботу, оскільки блокування

всієї таблиці обмежує доступ до будь-якого фрагменту цієї таблиці з боку

інших транзакцій. Однак, навантаження на систему знижується, оскільки необхідно

підтримувати меншу кількість блокувань.

SQL Server може динамічно блокувати такі ресурси (в міру

підвищення рівня).

 

Ресурс

Опис

RID

Ідентифікатор рядка. Використовується для блокування

окремого рядка в таблиці.

Key

Блокування рядка індексу. Використовується для

захисту діапазону ключів у транзакціях обробних послідовності.

Page

Сторінка даних або індексу розміром 8 КБ.

Extent

Безперервна група з 8 суміжних сторінок даних

або індексу.

Table

Вся таблиця, включаючи всі дані та індекси.

DB

Вся база даних.

Режими блокування

У SQL Server блокування ресурсів проводиться в різних режимах, що визначають

можливість доступу до них з боку конкуруючих транзакцій. Використовуються

наступні режими:

Спільне використання

При блокуванні в режимі спільного використання конкуруючі транзакції

можуть здійснювати читання. Ніякі інші транзакції не можуть модифікувати

дані, поки для ресурсу встановлена блокування в режимі спільного використання.

Такі блокування знімаються, як тільки читання ресурсу завершено, крім

тих випадків, коли рівень ізоляції транзакції встановлений для багаторазового

читання або вище, або використано явне вказівку на збереження блокування

протягом всієї транзакції.

Оновлення

Блокування в режимі оновлення використовується для ресурсів, які можуть

зазнавати змін. Використання такого режиму запобігає виникненню

традиційних форм тупикових ситуацій. Якщо дві транзакції, що запитав

блокування ресурсів у режимі загального використання, потім одночасно спробують

модифікувати дані, відбувається невдала спроба перекладу блокувань

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

однієї з них не буде знято блокування в режимі спільного використання

– Таким чином, виникає тупикова ситуація. Блокування в режимі оновлення

усуває цю небезпеку, тому що тільки одна транзакція в кожен момент часу

може встановити для ресурсу блокування в режимі оновлення.

Виключне використання

Блокування в режимі виключного (монопольного) використання застосовується

при операціях модифікації, таких як UPDATE, INSERT або DELETE (оновлення,

вставка або видалення). Таким чином, гарантується, що кілька змін

не можуть бути внесені в один ресурс одночасно (тобто конкуруючими транзакціями).

Ніяка інша транзакція не може здійснювати читання або модифікацію

даних, для яких встановлена блокування в режимі виключного використання.

Попереджувальна блокування

Попереджувальна блокування свідчить про те, що SQL Server справив

спробу встановити блокування в режимі спільного або виняткового

використання для нижележащих в ієрархії ресурсів. Застосування попереджувального

блокування підвищує продуктивність, коли будь-які транзакція запитує

блокування на рівні цілої таблиці для з'ясування того, чи може вона бути

коректно здійснена, SQL Server достатньо перевірити наявність попереджувальної

блокування для цієї таблиці замість того, щоб перевіряти, чи не заблоковані

Чи окремі рядки або сторінки цієї таблиці.

Блокування схеми

Існує два типи блокування схеми. Блокування Sch-M встановлюється

при виконанні операцій мови опису даних (data definition language

– DDL), таких як додавання стовпця або видалення таблиці. Блокування Sch-S

застосовується при компіляції запитів і не впливає на блокування з боку

транзакцій, в тому числі і в режимі виключного використання. Таким

чином, під час компіляції запиту можуть виконуватися інші транзакції,

навіть ті, які вимагають монопольного використання всієї таблиці. При цьому

виконання DDL-операцій над таблицею заборонено.

Архітектура базисних таблиць та індексів

Серйозні зміни, які були внесені в організацію базисних таблиць

Microsoft SQL Server 7.0, дозволяють процесору обробки запитів використовувати

більшу кількість вторинних індексів, що значно збільшує продуктивність

роботи додатків для прийняття рішень. Оптимізатор запитів використовує

багатий набір стратегій виконання, а більшість обмежень оптимізації,

властивих більш ранніх версій SQL Server, усунені. Зокрема, SQL Server

7.0 менш чутливий до проблем вибору індексу, завдяки чому витрати

на налаштування скорочуються.

Організація таблиць

Дані таблиць тепер зберігаються в наборі сторінок даних, які мають

розмір 8 КБ. Кожна сторінка має заголовок довжиною 96 байт, який містить

таку системну інформацію, як ідентифікатор володіє даною сторінкою

таблиці та покажчики на наступну і попередню сторінки у зв'язаному списку.

У кінці сторінки розташована таблиця зміщень рядків; інший простір

сторінки зайнято рядками даних.

У SQL Server 7.0 для таблиць застосовується один з двох методів організації

сторінок даних:

Організація індексу

Індекс (кластерізованний чи ні) прискорює пошук рядків в таблиці. Індекс

містить значення ключів, побудованих на підставі значень одного чи

більше стовпців таблиці. Ці ключі зберігаються таким чином, що SQL Server

може швидко і ефективно здійснювати пошук рядків, пов'язаних з тим або

іншим значенням ключа. Якщо таблиця не має індексів, дані зберігаються в

ній без будь-якого порядку.

Кластерізованние індекси

У кластерізованном індексі порядок значень в індексі відповідає

порядку даних в таблиці (у деякому сенсі, індекс сам є місцем

зберігання даних). Кластерізованний індекс схожий на телефонний довідник,

де дані впорядковані за прізвищами абонентів.

Оскільки кластерізованний індекс визначає порядок зберігання даних,

кожна таблиця може мати тільки один кластерізованний індекс; проте

він може бути створений на підставі значень з декількох стовпців. Наприклад,

телефонний довідник впорядкований за прізвищами, а всередині прізвищ – за іменами.

Кластерізованние індекси містять ієрархічне дерево із зазначенням діапазонів

значень, що зберігаються в певній галузі індексу. Якщо пошук виконується

за значенням кластерізованного індексу, SQL Server швидко виявляє сторінку,

містить потрібне значення, а потім здійснює на ній пошук записів з

цим значенням. Самий нижній рівень дерева індексу (листя) – сторінки,

містять дані.

Некластерізованние індекси

Некластерізованние індекси схожі на предметний покажчик у книзі, коли

дані розташовані в одному місці, а покажчик – в іншому. Посилання вказують

на те, де знаходиться інформація, перерахована в індексі. Листом дерева

в некластерізованном індексі є адреса даних (номер сторінки і зсув).

Таким чином, в некластерізованном індексі є проміжний рівень

між його внутрішньою структурою та власне даними.

При пошуку з використанням некластерізованного індексу SQL Server знаходить

в індексі задане значення, визначає місце розташування рядка даних,

а потім витягує їх прямо звідти. Таким чином, некластерізованние індекси

– Оптимальний вибір при виконанні запитів із зазначенням точної відповідності.

Може існувати кілька некластерізованних індексів. Ви можете

визначити некластерізованний індекс для кожного з стовпців, які зазвичай

використовуються при пошуку даних в таблиці.

Оскільки некластерізованние індекси зберігають ключі кластерізованного

індексу для вказівки на рядки даних, важливо, щоб ключі кластерізованного

індексу були якомога менше. Уникайте вибору стовпців, з великим обсягом

інформації як ключі для кластерізованного індексу, якщо для таблиці

використовуються також і некластерізованние індекси.

SQL Server 7.0 підтримує до 249 некластерізованних індексів для кожної

таблиці. У некластерізованних і кластерізованних індексах використовуються

схожі структури двійкового дерева. Різниця в тому, що некластерізованние

індекси не роблять впливу на розташування рядків даних. Набір сторінок,

використовуваних для зберігання неупорядкованого масиву даних, не залежить від

того, чи визначено для цієї таблиці некластерізованний індекс.

Статистика розподілу індексу

Для всіх індексів ведеться збір статистичної інформації про селективності

і розподілі значень ключа. Селективність – це характеристика, що показує,

скільки рядків зазвичай ідентифікується одним значенням ключа. Коли ключ

має унікальні значення, селективність висока; часто зустрічаються значення

ключа (наприклад, в 1000 рядків) призводять до низької селективності.

Селективність і статистика розподілу використовуються SQL Server для

оптимізації пошуку в таблицях при обробці операторів Transact-SQL. Статистична

інформація не зосереджена на який-небудь одній сторінці, а зберігається в

вигляді довгої бітової рядки, що переходить зі сторінки на сторінку, подібно

того, як зберігаються зображення.

Типи даних

У Microsoft SQL Server 7.0 доповнено новими можливостями зберігання даних

та обробки тексту та зображень.

Дані Unicode

SQL Server 7.0 підтримує типи даних з використанням Unicode, що

полегшує зберігання інформації на різних мовах в одній базі даних і

усуває необхідність перетворення символів або установки декількох

кодових сторінок. При використанні Unicode для зберігання кожного символу

відводиться не 1, а 2 байта. Оскільки для 2 байт існує 65536 різних

бітових комбінацій, Unicode може використовувати одну стандартну кодування

для подання всіх символів у всіх мовах, включаючи такі, як китайський,

в якому дуже багато символів. Типи даних, що використовують Unicode, підтримуються

і з боку мов програмування.

Той факт, що дані Unicode вимагають для зберігання вдвічі більшого простору,

компенсується усуненням необхідності перетворення символів з різних

кодових сторінок. Нові типи даних, що використовують Unicode, це ntext, nchar

і nvarchar. Вони повністю аналогічні типам text, char і varchar за винятком

того, що підтримують більшу кількість символів і вимагають для зберігання

більшого простору.

У звичайних типах даних, що не використовують Unicode, допускається вживання

символів, визначених у деякому стандартному наборі символів, який

вказується при установці SQL Server і залишається незмінним протягом

всій його "життя". При використанні типів даних, котрі підтримують Unicode,

у стовпці можуть міститися будь-які символи, визначені в стандарті Unicode,

який включає в себе всі символи з усіх наборів.

Зберігання даних різних типів

Гнучкість зберігання даних була підвищена за рахунок збільшення максимальної

довжини даних таких типів як char, varchar, binary і varbinary з 255 байт

до 8000. Тепер не доводиться використовувати типи text і image ні для чого,

крім даних дуже великого обсягу. Строкові функції Transact-SQL підтримують

обробку довгих рядків даних типу char і varchar, а функція SUBSTRING

може застосовуватися для обробки стовпців з даними типу text і image.

Крім того, поліпшена обробка "нульових" і порожніх рядків. Новий тип даних

uniqueidentifier надає можливість використання унікальних глобальних

ідентифікаторів GUID.

Типи даних text, ntext і image

SQL Server забезпечує надійну основу для розвитку об'єктно-реляційних

можливостей. Одне з удосконалень в SQL Server 7.0 зачіпає зберігання

тексту і зображень, для чого використовуються нові ефективні структури

даних.

Типи даних ntext, text і image в SQL Server 7.0 можуть зберігати значення,

обсяг яких досягає 2 ГБ. При цьому навіть одне значення перевищує той

обсяг, який зазвичай обробляється додатком за один крок; обсяг деяких

величин може навіть перевищити розмір віртуальної пам'яті комп'ютера клієнта.

Це означає, що для передачі таких даних у додаток необхідно вжити

спеціальні заходи. Якщо значення не перевищує за обсягом звичайної символьної,

двійковій або Unicode-рядка (8000 символів, 8000 байт або 4000 символів,

відповідно), то воно може бути оброблено за допомогою операторів SELECT,

UPDATE і INSERT точно так само, як і дані інших, більш компактних типів.

Значення даних типів text, ntext і image зберігаються не як частина рядків,

а на окремих сторінках. Для кожного значення в рядку запам'ятовується лише

покажчик на розташування даних, який має довжину 16-байт. Рядок,

містить декілька стовпців з даними типу text, ntext або image, має

в кожному з них по одному покажчику.

Дані, що зберігаються в наборі 8-кілобайтні сторінок, не обов'язково розташовуються

одне за іншим. У SQL Server 7.0 сторінки організовані в логічну структуру

двійкового дерева. У більш ранніх версіях вони були пов'язані в послідовність.

Переваги двійкового дерева полягають в тому, що операція, що почалася

з середини рядка, виконується більш ефективно, оскільки позиціонування

здійснюється швидше. У разі використання простої послідовності

сторінок це найчастіше призводило б до "безладного метання" по файлах

бази даних. Структура двійкового дерева злегка змінюється залежно

від того, чи перевищує обсяг даних 32 КБ.

Архітектура менеджера журналу

Журнал Microsoft SQL Server 7.0 складається з декількох фізичних файлів

із записами. Раніше журнал представляв собою системну таблицю, розташовану

на звичайних сторінках бази даних. Ці сторінки з журналом розподілялися

точно так само, як сторінки з іншими таблицями і конкурували зі сторінками

даних за дисковий простір і пам'ять кеша.

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

називаються віртуальними файлами журналу і є функціональними одиницями

протоколювання транзакцій. Коли віртуальний файл журналу перестає бути

актуальним – тобто більше не містить записів, що відносяться до активних транзакцій,

він може бути усічений, і займане ним простір стає доступним

для протоколювання нових транзакцій.

У SQL Server 7.0 вжито заходів для запобігання використання надмірно

великої кількості маленьких віртуальних файлів журналу. Їх кількість

зростає повільніше, ніж розмір. Якщо розмір файлів збільшується з малим

инкрементом, це звичайно призводить до появи безлічі невеликих віртуальних

файлів. Якщо інкремент збільшений, SQL Server буде створювати менше число

більших віртуальних файлів журналу.

У міру додавання записів у журнал, логічний кінець журналу переміщається

з одного віртуального файлу в іншій. Якщо в базі даних існує більше

одного фізичного файлу журналу, логічний кінець журналу переміщається

по всіх віртуальним файлів у всіх фізичних файлах, перш ніж повернутися

в перший віртуальний файл першого фізичного файлу.

Найменший розмір віртуального файлу журналу становить 256 КБ. Мінімальний

розмір журналу транзакцій – 512 КБ, що відповідає двом віртуальним

файлів по 256 КБ. При збільшенні розмірів журналу зростає як кількість,

так і розмір віртуальних файлів. Невеликий журнал може містити кілька

маленьких віртуальних файлів. Дуже великий журнал складається з більшої

кількості великих віртуальних файлів.

Збільшення і зменшення розмірів журналу може відбуватися автоматично.

Якщо відсутній простір, який може бути використано повторно,

журнал збільшується за рахунок додавання нових логічних фрагментів. Якщо

необхідно більше простору, буде додано більше логічних файлів.

Менеджер журналу підрозділяє фізичні файли журналу на логічні. Логічний

файл може бути активний або доступний для повторного використання. Резервна

копія логічного файлу може бути створена, якщо він не містить записів

активного журналу. Після створення резервної копії журнал може бути використаний

повторно.

Управління протоколюванням транзакцій

Журнал транзакцій допомагає відновити цілісність бази даних у випадку

збою системи. Записи журналу для однієї бази даних містяться в одному або

декількох файлах операційної системи, званих файлами журналу, вони

зберігають протокол послідовності всіх змін, що вносяться до бази даних,

та інформацію про те, в рамках якої транзакції вони були зроблені.

Журнал безперервно зростає в міру виконання протоколіруемих операцій.

Для деяких великомасштабних операцій фіксується лише той факт, що

вони мали місце. У журналі фіксується успішне завершення або відкат кожної

транзакції. Це дозволяє SQL Server скасовувати транзакції або "відтворювати"

їх.

Відкат транзакції відбувається при відмові від виконання незавершеної транзакції.

SQL Server відновлює базу даних в стан, що передує початку

транзакції, виробляючи зворотні зміни.

Відтворення транзакцій відбувається при відновленні транзакцій

по журналу. Зміни вносяться до бази даних в тій же послідовності,

що і при виконанні самих транзакцій. У результаті цього база даних наводиться

у стан, який існував на момент створення резервної копії журналу.

У менеджер журналу транзакцій SQL Server 7.0 внесені наступні удосконалення:

Управління пам'яттю

У міру необхідності Microsoft SQL Server 7.0 динамічно запитує

і звільняє пам'ять. Тепер адміністратору не треба вказувати, як багато

пам'яті повинно бути виділено SQL Server, хоча така можливість збереглася.

У SQL Server існує кілька конкуруючих підсистем, спільно

використовують доступну пам'ять: журнал і система відновлення потребують

в пам'яті для читання сторінок і скасування внесених змін, а оброблювачу

запитів вона необхідна для кешування і сортування. Серед інших підсистем

– Кеш процедур, буферний пул, менеджер блокувань і структури даних. У

SQL Server 7.0 всі ці системи динамічно розподіляють необхідну їм

пам'ять і можуть повернути назад, коли потреба в ній зникне.

Операційні системи Microsoft Windows NT, Microsoft Windows 95 і Windows

98 підтримують віртуальну пам'ять, метод розширення встановленої на комп'ютері

фізичної пам'яті. При використанні віртуальної пам'яті операційна система

створює сторінковий файл (файл підкачки) і розбиває пам'ять на фрагменти,

звані сторінками. Сторінки, звернення до яких відбувалося недавно,

розташовані у фізичній пам'яті (ОЗУ). Якщо протягом деякого часу

до сторінки не відбувається звернень, вона записується (витісняється) в сторінковий

файл. Якщо пізніше додаток звертається до цього фрагменту пам'яті, операційна

система зчитує сторінку назад з сторінкового файлу у фізичну пам'ять

(Це і називається підкачкою). Загальний обсяг пам'яті, яка стає доступна

додаткам, складається з обсягу встановленої фізичної пам'яті і розміру

сторінкового файлу.

Одна з першорядних завдань при проектуванні СУБД – скорочення операцій

дискового введення-виведення, оскільки читання і запис є одними з найбільш

ресурсномістких операцій. Для зберігання сторінок, лічених з бази даних,

SQL Server створює в пам'яті буферний кеш. Значна частина коду SQL Server

призначена для скорочення кількості операцій обміну даними між буферним

кешем і фізичним диском. Чим більше розмір буферного кешу, тим менше

операцій введення-виведення з файлами бази даних доводиться виконувати SQL Server.

Однак, якщо буферний кеш зажадає пам'яті, яка перевищує обсяг встановленої

на сервері фізичної пам'яті, операційна система почне активну витіснення

і підкачування з сторінкового файлу. Це призведе до того, що фізичний обмін

з файлами бази даних буде просто замінений зверненнями до файлу підкачки.

Великий обсяг операцій введення-виведення – характерна риса всіх СУБД. За

замовчуванням SQL Server намагається встановити баланс між наступними двома

цілями:

SQL Server починає свою роботу з прийнятим за замовчуванням об'ємом пам'яті.

У міру запуску нових додатків система періодично запитується про кількість

доступною вільної фізичної пам'яті. SQL Server збільшує або скорочує

буферний кеш так, щоб залишалися близько 5 МБ вільної фізичної пам'яті,

що запобігає активний обмін зі сторінковим файлом. Якщо вільної пам'яті

залишається менше 5 МБ, SQL Server повертає частину пам'яті Windows NT, яка

зазвичай включає її до списку вільної пам'яті. Якщо вільної пам'яті більш

5 МБ, SQL Server "забирає" її частину для збільшення буферного кешу. Додаткова

пам'ять для буферного кешу запитується SQL Server тільки, якщо цього вимагає

поточна робоче навантаження; сам по собі сервер не збільшує буферного кешу.

Управління буфером і введенням-виведенням

Замість списку давності використання в SQL Server 7.0 для управління

буфером введення-виведення застосовується механізм, що залежить від таймера. Це підвищує

продуктивність, тому що вимагає менших витрат на синхронізацію. При цьому

збільшується масштабованість у великих системах з мультипроцессирования,

а в малих системах ефект залишається незначним. Продуктивність обробки

запитів покращується за рахунок використання, як паралельного введення-виведення,

так і обміну великими обсягами даних з файлами, що містять об'єкти бази

даних.

Об'єкт Buffer Manager підтримує лічильники для стеження за тим, як

SQL Server використовує пам'ять для зберігання сторінок даних, внутрішніх структур

даних і кеша процедур. Операції фізичного введення-виведення обліковуються за

міру того, як SQL Server зчитує з диска і записує сторінки бази

даних на диск.

Стеження за використанням пам'яті в SQL Server може допомогти, наприклад,

у виявленні існуючих вузьких місць через брак доступної фізичної

пам'яті для зберігання найбільш часто використовуваних даних в кеші, коли SQL

Server змушений зчитувати їх з диска. Здійснюючи стеження, ви можете визначити,

чи може бути підвищена продуктивність обробки запитів шляхом установки

додаткової пам'яті або звільненням існуючої пам'яті для кеша даних

або внутрішніх структур SQL Server. Моніторинг операцій фізичного введення-виведення

особливо важливий для визначення того, як часто SQL Server змушений читати

дані з диска.

У порівнянні з іншими операціями, такими як доступ до оперативної пам'яті,

фізичний ввід-висновок споживає набагато більше часу. Скорочення фізичного

введення-виведення може значно підвищити продуктивність обробки запитів.

Попередній виклик

Вироблювані системою запити на читання контролюються реляційних

ядром, а потім оптимізуються механізмами зберігання. Метод доступу, що використовується

для читання сторінок, визначає загальний характер операцій читання, які

будуть проведені. Реляційне ядро визначає найбільш ефективний метод

доступу, наприклад, перегляд таблиці, перегляд індексу або читання по ключу.

Потім запит передається механізму зберігання даних, який оптимізує

операції читання, що вимагаються для реалізації методу доступу. Операції читання

ініціюються потоком (thread), який виконує пакет.

Механізм читання, що в SQL Server 7.0 вдосконалений і значно

спрощений. Завдяки розміщенню відповідних інструкцій, як в обробнику

запитів, так і в механізмі зберігання даних, було скорочено більше тисячі

рядків вихідного тексту програми, а також усунуті стали зайвими параметри

налаштування.

Перегляд сторінок в SQL Server 7.0 вдосконалено за рахунок використання

нових структур даних. Механізм зберігання може формувати послідовні

списки адрес даних на диску, які повинні бути лічені. Це дозволяє

SQL Server оптимізувати операції введення-виведення і виконувати їх за один

крок, як одну операцію читання великої порції даних. SQL Server запитує

множина послідовних операцій негайного читання, що для

кожного файлу, що проглядається. Таким чином ефективно використовуються переваги

дискових масивів з чергуванням.

Механізм паралельного читання, що дозволяє дискової підсистеми

досягти максимальної швидкості роботи. Механізм розподіляє сторінки між

доступними процесорами. Операції введення-виведення виконуються одночасно

для декількох файлів.

У SQL Server 7.0 усунуто поділ потоків читання, і

зведені до мінімуму перемикання контексту. Нові структури розміщення даних

дозволяють здійснювати попередній виклик без проходження по ланцюжку сторінок.

Оброблювач запитів допомагає оптимізувати попередній виклик за рахунок

використання проміжного індексу для передбачення наступної сторінки

при перегляді індексів (включаючи перегляд кластерізованних таблиць).

SQL Server 7.0 також здійснює попередній виклик послідовно

розташованих на диску сторінок індексу для підвищення швидкості його перегляду.

Додатково обробка індексу прискорена за рахунок завчасного виконання

операцій, що дозволило організувати послідовне попередній виклик

некластерізованних індексів.

Висновок

Microsoft SQL Server 7.0 являє собою досконалу реалізацію СУБД

Microsoft, створену на міцній основі SQL Server 6.5. Для SQL Server 7.0

було заявлено більше десятка нових патентів в області технологій СУБД. Серед

аспектів, яких торкнулися передові нововведення:

Microsoft відповідає на запити клієнтів новими і розширеними можливостями.

Архітектура механізмів зберігання даних в SQL Server 7.0 була розроблена

для підтримки користувальницьких додатків наступного століття. Microsoft

проробила величезну роботу з акуратною реалізації підсистем, так що згодом

компоненти можуть бути поліпшені і легко замінені. Механізми зберігання даних

в SQL Server 7.0 розроблені з урахуванням, як загальної можливості подальшого

розширення, так і специфічних засобів, реалізація яких запланована

в наступних версіях.

За додатковою інформацією звертайтеся в Interface Ltd.

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


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

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

Ваш отзыв

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

*

*