Microsoft SQL Server 7.0 – Механізм зберігання даних, MS SQL Server, Бази даних, статті

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>

*

*