Порівняння Borland InterBase 4.x, Sybase SQL Server і Microsoft SQL Server, MS SQL Server, Бази даних, статті

Переклад: Кузьменко Дмитро


1. Введення

Motorola, Nokia, MCI, Northern Telecom, Philadelphia Stock Exchange, Bear Stearns, First National Bank of Chicago, the Money Store, the US Army, NASA, Boeing. Всі ці компанії, незалежно від напрямку бізнесу, мають одне спільне: вони вибрали InterBase в якості ключового компонента їх інформаційних систем. Borland InterBase однаково добре застосовується і для “Домашнього” управління ракетними системами, збору даних для аерокосмічних досліджень або зберігання і обробки даних біржі. Програми подібного роду мають багато спільних вимог: легкість використання та управління, продуктивність, масштабованість, переносимість, використання ресурсів і відновлення після збою. Borland InterBase розроблений саме з метою задовольняти всім цим вимогам.

Навіть якщо більшість систем не вимагають екзотичних можливостей, як вишеперчісленние, вони все одно бажають від РСУБД тих-же характеристик для реальних завдань і вирішення реальних проблем бізнесу. Перераховані характеристики Borland InterBase також дуже добре підходять для робочих груп, відділів, та програм рівня підприємства. Мета цього документа – продемонструвати переваги Borland InterBase в порівняно з SQL-серверами Microsoft SQL Server і Sybase, або дати вам можливість порівняти архітектури та особливості цих SQL-серверів.

1.1. Зауваження

До випуску Microsoft SQL Server 6.0, Sybase SQL Server і Microsoft SQL Server були одним і тим-же продуктом. Microsoft SQL Server 4 був ліцензований у Sybase і продавався під маркою Microsoft. У 1995 році Microsoft викупив вихідні тексти у Sybase і модифікував їх для того, щоб випустити Microsoft SQL Server 6.0. Sybase продовжила розробку свого SQL Server і в даний час випускає його під назвою Sybase SQL Server System 10 і System 11. Тим не менше, і Microsoft SQL Server і Sybase SQL Server мають одне і те-ж ядро ​​сервера баз даних. Тому в більшості випадків вони ведуть себе абсолютно однаково. З цієї причини, термін “SQL Server” в цьому документі буде ставитися і до Microsoft SQL Server і до Sybase SQL Server. Там, де ці продукти відрізняються, будуть згадуватися їх відповідні повні імена.

1.2. Трохи Історії

InterBase був придуманий і створений групою співробітників Digital Equipment Corporation [DEC], бажали втілити в RDBMS ряд унікальних технологічних рішень, забезпечують великі преімушества по порівнянні з існуючими серверами баз даних. InterBase почався в 1985 році як Groton Database Systems (GDS) і незабаром був перейменований в InterBase. Група була придбана Ashton Tate в 1991 році. Borland отримав InterBase в 1992 році як частина придбання Ashton Tate.

Як і планувалося розробниками, InterBase продемонстрував цілий ряд технологічних нововведень. Серед них Множинні покоління записів, автоматичне двофазне подвержденіем транзакцій, дзеркалювання бази даних, великі двійкові об’єкти [BLObs], бітові індекси, многмерние масиви та повідомлення про події.

Боьшінства існуючих RDBMS не змогли відтворити або створити еквівалентні технології. Наприклад, архітектура SQL Server використовує комбінацію сторінкових, індексних і табличних блокувань для забезпечення конкурентного доступу до даних. SQL Server також підтримує двофазне підтвердження транзакцій, однак вимагає великої кількості коду для реалізації підтвердження або відкату. SQL Server забезпечує зберігання даних типу BLOb, але в більш обмеженому і менш швидкодіючому варіанті ніж це реалізовано в InterBase.


2. Механізми блокувань

2.1. Background

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

2.2. SQL Server

2.2.1. Сторінкові Блокування

Для того, щоб гарантувати цілісність даних, архітектура SQL Server використовує механізм блокувань сторінок даних. Сторінка даних це набір записів, що зберігаються в деякій області жорсткого диска на сервері. Всі сторінки мають один і той-же розмір, що визначається конфігурацією сервера та бази даних. В Залежно від довжини записів і розміру сторінки, сторінка може містити певний кількість записів. Записи в більшості випадків додаються в кінець таблиці. Базовий розмір сторінки в SQL Server дорівнює 2K, і це є мінімальної одиницею блокіровкіl. Сторінкові блокування вимагають від розробника глибоких знань про конкурентну роботі з даними і налаштування коду для отримання максимально конкурентного доступу. Сторінкова блокування блокує всі записи або відповідні посилання в індексах, що зберігаються на одній сторінці. Наприклад, якщо розмір запису в таблиці дорівнює 100 байт, а розмір ключа індексу дорівнює 10 байт, то блокування однієї сторінки даних і однієї сторінки індексу призведе до кумулятивного ефекту блокування 18-ти записів і 180-ти ключів індексу.

Figure 1 SQL Server Page Locks

Коли відбувається запис в таблицю, то для забезпечення цілісності записи RDBMS блокує сторінку, на якій знаходиться цей запис. Блокування цілої сторінки набагато швидше блокування окремого запису, і вимагає набагато менше ресурсів сервера для управління блокуваннями. Разом з тим, блокування цілої сторінки, призводить до блокування інших користувачів від зміни даних на цій-же сторінці. На додаток до блокування сторінки, на якій знаходиться цікавить запис, SQL Server додатково блокує попередню і наступну сторінку (щодо блокируемой). Доступ до записам на блокованих сторінках буде неможливий протягом дії блокування. Блокування може виникнути у багатьох ситуаціях. Найбільш часта причина блокування – додавання запису або її модифікація. Крім цього, використання курсорів клієнтським додатком може також виробляти велику кількість блокувань сторінок. В таких ситуаціях користувач, всього-лише переглядає записи, блокує інших користувачів від внесення змін на ці-ж сторінки до тих пір, поки не закриється курсор або блокування не переміститься на інші сторінки.

Те, що “читач” записи блокує сторінку на якій цей запис знаходиться, і її суміжні сторінки, може привести до проблем продуктивності для користувачів, які потребують доступу до даних на заблокованих сторінках. Замість того, щоб зосередитися на розробці правил управління даними, розробник змушений описувати складну обробку можливого виникнення конфліктів блокувань. Це збільшує складність додатки, і підвищує вартість розробки і супроводу.

2.2.2. Блокування Індексів

Індекси SQL Server блокуються точно так-же, як і сторінки даних відповідних таблиць, проте ефект блокування сторінки індексу значно ширше. Записи в таблиці зберігаються в більшості випадків у випадковому порядку (виняток складають кластерні індекси). Коли оновлюється сторінка даних, то повинен оновитися відповідний індекс. Як і у таблиць, дані індексів зберігаються на сторінках. Для поновлення сторінки індексу, ця сторінка повинна бути спочатку заблокована. Якщо дані в таблиці розподілені випадковим чином, то блокування сторінки індексу призведе до блокуванні великої кількості сторінок даних, оскільки сторінка індексу посилається на велику кількість сторінок даних. Це означає що модифікація одного ключового значення на сторінці може заблокувати безліч абсолютно сторонніх записів на сторінках даних. Якщо для таблиці визначено декілька індексів, то зміна одного запису призведе до лавиноподібного зростання блокувань сторінок, не відносяться до сторінки де знаходиться модифікується запис. У додатках, що працюють з великими обсягами даних, це може сильно знизити продуктивність системи.

2.2.3. Блокування Таблиць

Целостностние подання бази даних іноді вимагає рівня ізоляції “Відтворюване читання”. “Відтворюване читання” гарантує незмінність видимих ​​даних на час дії транзакції. Це дуже важливо у фінансових додатках або при створенні звітів по великих обсягами даних в той час як інші користувачі модифікують записи. Для забезпечення цілісного уявлення даних в Sybase або Microsoft SQL Server розробник повинен використовувати блокування таблиць. Блокування таблиці викликає повне блокування, що розділяється, для оновлення або виняткову [Shared, Update, or Exclusive]. Уявіть собі звід балансу бухгалтером – Поки звід не закінчений, архітектура SQL Server вимагає щоб розробник повністю заблокував таблицю на час зводу. Крім цього може знадобитися повне блокування пов’язаних таблиць. Більш докладно ця тема обговорюється в секції 6.3.

2.2.4. Ескалація сторінкових блокувань в Блокування Таблиць

Довгі транзакції, що зачіпають велике кількість записів, вимагають великої кількості сторінкових блокувань. Як тільки кількість сторінкових блокувань досягає певного межі, SQL Server автоматично включає повну блокування таблиці. Призначення такого механізму в тому, щоб зменшити роботу RDBMS з управління блокуваннями та забезпечення конкурентного використання даних, і щоб запобігти деградацію продуктивності. Природно, що повне блокування таблиці заблокує іншим користувачам доступ до цієї таблиці. Ескалація може відбутися як при оновлення, так і при звичайної вибірці даних. Для того, щоб забезпечити оптимальну продуктивність при многопользовательском доступі, адміністратор БД повинен ретельно проаналізувати структури БД та алгоритми клієнтських додатків на пересічні запити з читання та оновлення даних. Після цього адміністратор повинен визначити рівень ескалації табличних блокувань щоб збалансувати управління великою кількістю блокувань сторінок і блокування доступу при ескалації табличних блокувань. Розробники додатків також повинні розуміти особливості сторінкових і табличних блокувань, і відповідно програмувати обробку доступу при блокування. Такі вимоги додають до додаткам додаткову складність коду, збільшуючи вартість розробки і супроводу.

2.2.5. Варіанти вирішення проблем

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

2.2.6. Операція Вставки в Microsoft SQL Server

У Microsoft SQL Server 6.5 механізм блокувань поліпшений по порівнянні з версією 6.0 і Sybase SQL Server підтримкою блокувань на рівні записів при вставці. Це збільшує продуктивність вставки записів, але ніяк не вирішує інші проблеми зі сторінковими, індексними або табличними блокуваннями. Тому, незалежно від версії, оновлення даних в архітектурі SQL Server все-одно вимагає табличних або сторінкових блокувань для забезпечення цілісності даних.

2.3. InterBase

2.3.1. Архітектура Багатоверсійність Записів

InterBase забезпечує оптимістичні блокування за допомогою Архітектури Багатоверсійність Записів (Multi-Generational Architecture-[MGA]). Цей механізм створює оптимізовані версії для нових, віддалених або оновлюваних записів, які видно тільки в контексті конкретної транзакції, змінює дані. Реально, InterBase версіонірует тільки змінювані стовпці (поля) шляхом створення deltas. Це забезпечує максимальну продуктивність і мінімальні вимоги до дискового простору.

Стан “невидимості” версіонірованних записів триває тільки протягом транзакції. Після підтвердження (committing) транзакції, змінені записи стають видимі транзакціях, що стартував до завершення цієї транзакції (Д.К. – тільки якщо ці транзакції ReadCommitted або стартували після завершення транзакції, змінювала дані. Для транзакцій RepeatableRead, що стартували до завершення такої транзакції, зміни записів не видно). Взагалі, всі інші транзакції мають своє власне уявлення змінюваних записів, поки вони (транзакції) не закінчаться підтвердженням або скасуванням. Як тільки транзакції, що читали або оновлюють записи, завершилися, InterBase звільняє старі версії записів. Коли дві транзакції намагаються оновити одну і ту-же запис, транзакція, першою зробила оновлення є “власником”, і друга транзакція отримає повідомлення про помилку. Розробники додатків як для SQL Server так і для InterBase однаково можуть управляти такими ситуаціями. У кожному разі, додаток для SQL Server має спочатку перечитати запис щоб переконатися що вона не змінена. В залежності від засобів розробки додатків, розробнику, використовує SQL Server, може знадобитися написати додатковий код для такої операції. Замість того, щоб писати код обробки сторінкових, індексних і табличних блокувань, розробник при використанні InterBase повинен обробляти тільки конфлікти оновлення з іншими транзакціями. Це означає значно менші витрати при розробці та супроводі для корпорацій, що використовують InterBase.
(Д.К..– Насправді механізм Багатоверсійність значно складніше. Наприклад, блокування в термінах MS SQL, Sybase, Oracle навіть на рівні записів в InterBase відсутні.

2.4. Продуктивність

Результати тестів на продуктивність в основному залежать від механізмів блокувань, використовуваних в тестованої СУБД. Сторінкові і табличні блокування SQL серверів Microsoft і Sybase можуть сильно впливати на продуктивність, коли багатьом користувачам потрібен доступ до одних і тим-же даними (або перебувають на прилеглих сторінках). Наприклад, в реальних ситуаціях, сторінкові блокування в SQL Server можуть уповільнювати доступ до даних (очікування звільнення блокувань сторінок, індексів або таблиць). Цей ефект може бути помітний у системах з великим обсягом даних або коли користувачі виконують створення тривалих звітів за даними в той момент, коли інші користувачі модифікують дані. Архітектура Багатоверсійність Записів InterBase гарантує доступність даних на читання для будь-яких користувачів і в будь-який час. Клієнтський додаток ніколи не чекає доступності таблиць, записів або індексів, незалежно від числа користувачів в системі або тривалості і складності будь-якої транзакції. Розробники, що використовують InterBase, автоматично отримують максимум продуктивності додатків, безвідносно складності обробки даних.


3. Двофазне Підтвердження Транзакцій

3.1. Background

Слово “транзакція” походить від злиття слів “акція трансформації”. Транзакція це дія або група дій, які переводять систему з одного цілісного стану в інший. Наприклад, при переказі грошей з одного рахунку на іншої, повинна бути змінена сума або обох рахунків, або ні одного у разі помилки.

Транзакції характеризуються властивостями ACID:

Atomicity (Атомарность) – “все або нічого “. Або вся транзакція завершується, або жодна з її частин. Якщо транзакція не може бути завершена, то всі операції, вироблені усередині транзакції, скасовуються.

Consistency (Цілісність) – Транзакція має переводити базу даних з одного цілісного стану в інший. Цілісність визначається бізнес-правилами (логікою бази даних) і вводиться в дію додатком.

Isolation (Ізоляція, ізольованість) – Оскільки може виникати безліч конкурентних транзакцій, кожна транзакція повинна бути ізольована від дій, вироблених іншими транзакціями. Тобто транзакції повинно “здаватися”, що вона є єдиною, що виконується над базою даних.

Durability (Міцність) – Зміни, підтверджені транзакцією, зобов’язані вступити в силу.

Якщо використовувати в якості прикладу оплату по кредитній карті, то все ACID-властивості повинні мати місце. Уявімо що інформація кредитної картки зберігається в одній БД, а інформація про рахунок клієнта – В інший. В цьому випадку при зміні кількості грошей на кредитній карті відповідно повинен змінитися рахунок клієнта, і виконуватися це має в одній транзакції. Такі ситуації обробляються за допомогою двофазного підтвердження транзакцій (Two Phase Commit – 2PC). Це механізм, який застосовує до змін в обох базах даних властивості ACID.Двухфазное підтвердження транзакцій має дві окремі фази: підготовка та підтвердження. Якщо по якоїсь причини процес не може бути виконаний в Протягом фази підготовки, наприклад після зняття грошей з кредитної карти але до зміни суми рахунку клієнта, то транзакція повинна бути скасована (rollback). Це гарантує що на рахунку не залишиться грошей більше, ніж на кредитній карті (Або навпаки). Поки обидві бази даних не будуть змінені правильним чином, будь-які дії над БД повинні залишатися непідтвердженими. Якщо все порції транзакції виконалися успішно, то підтвердження проводиться над двома БД. Це називається двофазним підтвердженням транзакцій.

3.2. Microsoft SQL Server

Архітектура SQL Server дозволяє програмувати 2PC використовуючи Координатор розподілених Транзакцій (Microsoft Distributed Transaction Coordinator [MSDTC]). MSDTC вимагає щоб розробник створював об’єкти транзакцій використовуючи OLE. Якщо змінюється додаток, то код 2PC повинен бути повторно протестований і супроводжуватися весь час життя додатки. При цьому супроводжуватися повинні не тільки клієнтську програму і база даних, а й об’єкти MSDTC також повинні супроводжуватися і координуватися з іншими частинами системи. Це погіршує переносимість, і вимагає додаткових витрат на розробку і супровід. .

3.3. Sybase SQL Server

В Sybase SQL Server, розробники повинні використовувати 2PC для забезпечення цілісності транзакцій, вироблених над різними БД. В двадцятитомна документації на Sybase System 10 є тільки одне згадка 2PC. Звичайно, на WEB-сервері Sybase є деяку кількість документів, що пояснює як обробку 2PC можна писати на C, FORTRAN, Pascal і COBOL. Кожен з цих прикладів містить більш ніж 100 рядків коду. В результаті розробникам доводиться створювати складні зовнішні процедури, недокументовані Sybase, і використовувати інші мови програмування замість використання природних можливостей RDBMS. Перехід на іншу платформу може зажадати перекомпіляцію або переписування коду. Як і в випадку Microsoft SQL Server, необхідно супроводжувати і синхронізувати зовнішні (по відношенню до БД) об’єкти, що збільшує вартість розробки і ускладнює супровід. Ситуація може ще більше ускладнитися, якщо використовуються сервери Sybase для різних платформ.

3.4. InterBase

InterBase забезпечує автоматичну обробку 2PC у відповідності з усіма вимогами ACID без додаткового програмування на будь-яких платформах (Windows NT, DEC UNIX, HP-UX, Irix і т.д.). Це забезпечує максимум легкості супроводу при відсутності додаткових витрат.


4. CHAR і VARCHAR

4.1. Зберігання

4.1.1. SQL Server

4.1.1.1. CHAR або VARCHAR

Практично у всіх SQL-серверах реалізовано два головні типи даних для зберігання символьної інформації. Перший – фіксованої довжини, і відомий як CHAR. У більшості РСУБД CHAR займає простір фіксованої довжини незалежно від довжини дійсно збережених даних. Вільне простір поля типу CHAR “доповнюється” до оголошеної довжини пробілами. Тип CHAR корисний якщо довжина збережених даних практично не змінюється, наприклад як для кодів країн і штатів США. CHAR може бути використаний і для зберігання імен або адрес, але це призведе до великих втрат дискового простору.

VARCHAR зберігає символьні дані зі змінною завдовжки. Це означає що на диску розподіляється простору стільки-ж, скільки потрібно для зберігання символьних даних. Максимальна довжина поля типу VARCHAR вказується при створенні таблиці. Коли значення типу VARCHAR записується на диск, РСУБД визначає його фактичну довжину, і відводить під його зберігання стільки-ж байт на диску. VARCHAR забезпечує ефективне використання дискового простору при зберіганні символьних даних, коли довжина значення символьного поля варіюється у великих межах.

4.1.1.2. Обмеження Довжини

Довжина типу VARCHAR в SQL Server обмежена 255 байтами. Якщо потрібно зберігання рядків довжиною більше 255 символів, то необхідно використовувати тип поля TEXT. Дані в поле типу TEXT зберігаються як дані BLOb з розміром сегмента 2K (мінімальний розмір сторінки). Іншими словами, навіть якщо дані в поле TEXT займають один байт або 1500 байт, SQL Server розподіляє блок розміром 2K для зберігання значення поля. SQL Server жертвує дисковим простором з метою забезпечення продуктивності при роботі з полями BLOb. Розробник повинен ретельно планувати структуру бази даних для балансу між займаним дисковим простором і продуктивністю, і іноді йти на компроміс, використовуючи комбінацію з двох або більше VARCHAR для зберігання строкових даних, які перевищують 255 символів але гарантовано менше 2К. Відповідно і додаток повинен витягувати дані з таких полів і групувати їх в одне поле для нормального представлення даних ..

4.1.2. InterBase

4.1.2.1. CHAR або VARCHAR

Як і сімейство СУБД SQL Server, InterBase підтримує типи як CHAR так і VARCHAR. З точки зору клієнтського додатка вони виглядають так-же, як і в SQL Server. Це забезпечує сумісність додатків. Всередині, InterBase забезпечує зберігання цих типів даних інакше, ніж SQL Server. У InterBase, дані CHAR і VARCHAR зберігаються однаково – кінцеві пробіли обрізаються, і тільки рядок фактичної довжини зберігається в базі даних. У разі VARCHAR, коли дані запитуються з сервера, клієнтського додатку повертається значення змінної довжини. У разі CHAR, InterBase доповнює рядок пробілами до довжини, зазначеної в структурі таблиці, і повертає дані як рядок з фіксованою довжиною. Крім цього, InterBase використовує алгоритм стиснення (RLE) для економії місця, займаного даними на диску, як для типу CHAR так і для VARCHAR.

4.1.2.2. VARCHAR

Максимальна довжина поля типу VARCHAR в InterBase дорівнює 32K (таке-ж обмеження довжини має й CHAR). Розробник може використовувати всю вигоду від VARCHAR без обмеження в 255 символів. Така можливість має велике значення для розробників, які хочуть проводити пошук або маніпулювати великими потоками тексту, такими як поля MEMO, без необхідності використовувати поля BLOb та їх обмежень [в реалізації Sybase і Microsoft]. Якщо розмір даних MEMO може перевищити 32K, то тільки InterBase дозволяє ефективно використовувати тип BLOb з визначеним розміром сегмента. Крім цього, операції пошуку LIKE, CONTAINING і STARTING WITH можна застосовувати до CHAR, VARCHAR і BLOB-полів будь-якого типу.

4.2. Продуктивність

4.2.1. SQL Server

При всій очевидності гнучкості та ефективності зберігання символьних даних в полях типу VARCHAR може здатися, що це найкращий вибір для зберігання символьних даних. Навпаки, використання VARCHAR в SQL Server призводить до погіршення продуктивності через додаткових витрат на вилучення даних. Тому розробники повинні вибирати між ефективним зберіганням і ефективним витяганням даних.

4.2.2. InterBase

І навпаки, оскільки спосіб зберігання CHAR і VARCHAR в InterBase ідентичний, розробник ніколи не піклується про вибір типу даних з урахуванням продуктивності. Замість цього розробник може заснувати свій вибір на тому, як представляється відповідний тип даних в клієнтському додатку. Розробник також може не турбуватися про оптимальний зберіганні даних і про витрати дискового простору, оскільки InterBase використовує алгоритми стиснення строкових даних.

4.3. Модифікація CHAR і VARCHAR “на місці”

4.3.1. SQL Server

Простір, розподіляється для індивідуальних значень VARCHAR, визначається при першому збереженні запису на диск. Будь-які довільні модифікації значень VARCHAR можуть вимагати іншого простору для зберігання даних. Зміна розміру даних призводять до того, що SQL Server перерозподіляє простір для даних на основі їх нової довжини. Наприклад, якщо користувач оновлює список постачальників, і модифікує адресу з “6475 Christie Avenue” на “100 Borland Way “, то SQL Server повинен видалити запис цілком і додати її в таблицю щоб зробити оновлення даних.
Існує кілька зауважень, які стосуються цього процесу:

  1. Transaction Log: Кожне видалення або вставлення призводить до реєстрації цієї дії в Transaction Log. Періодично адміністратор БД повинен очищати записи в Transaction Log. Неправильно або нерегулярно обслуговуються transaction logs можуть переповнитися і викликати “падіння” SQL Server. Для невеликих організацій, без спеціально виділеного адміністратора БД, це може стати катастрофою.
  2. Довгі транзакції: Довгі транзакції, оновлюючі велику кількість значень полів VARCHAR можуть блокувати останні сторінки даних таблиці на тривалий період часу. Транзакція, оновлююча поле типу VARCHAR у кожній записи таблиці призведе до того, то всі записи будуть видалятися з таблиці і додаватися в її кінець. Це може привести до зростання transaction log більшого, ніж зростання даних в базі даних.
  3. Вільний простір: Простір, займане віддаленими записами залишається незаповненим, поки над базою даних не будуть проведені процедури по її супроводу. В результаті таблиця може займати простір більш ніж удвічі перевищує реальний обсяг даних плюс розмір transaction log, який виріс в результаті реєстрації видалення старих записів і додавання оновлених.
  4. Неуспішні транзакції: Додавання оновленої записи переміщує змінну запис в кінець таблиці. Ця дія блокує останні сторінки таблиці поки не завершиться транзакція. Інші користувачі, що створюють нові записи, або редагують записи з полями VARCHAR, можуть також робити спроби запису в кінець таблиці. В архітектурі SQL Server, існує багато ситуацій, коли “читачі” блокують “письменників”. Тому, інші користувачі можуть заблокувати оновлення записів з полями VARCHAR через блокувань останніх сторінок таблиці, викликаючи неуспішне виконання транзакції.
  5. Продуктивність: Блокування додаткових сторінок погіршить пропускну здатність БД, змушуючи користувачів чекати закінчення блокувань сторінок. При великій кількості записів, що містять поля VARCHAR, продуктивність може істотно впасти.

4.3.2. InterBase

InterBase перерозподіляє простір для зберігання VARCHAR “на льоту”. Це означає що процес “видалення-додавання”, використовуваний в архітектурі SQL Server, не виникає в InterBase. Замість цього на сторінці даних додається версія значення CHAR або VARCHAR (delta), а модифікується запис залишається на своєму місці і не модифікується. Результатом такого механізму є максимальна продуктивність при оновленнях CHAR і VARCHAR. Крім цього, в InterBase відсутня transaction log (завдяки Багатоверсійність записів), що не тільки підвищує продуктивність, а й позбавляє адміністратора БД від додаткової роботи. Ніяких інших блокувань, крім блокування оновленої запису від оновлення її іншими користувачами, не виникає.


5. Багаторозмірний Масиви

InterBase забезпечує унікальний тип даних званий Многоразмений Масив (Multi Dimensional Array [MDA]). Тип MDA не реалізований ні в одній іншій РСУБД. Тип MDA дозволяє розробнику зраніть масиви будь-якої довжини і до 16 вимірювань. Оскільки масив зберігається в одному полі, тільки один запис і стовпець потрібні для вибірки даних з масиву. Масиви надають можливість зберігання і подання даних у випадках, в більшості неможливих для архітектури SQL Server. Ключовий особливістю є продуктивність масивів. Уявіть собі набір даних, яких повинен бути представлений як масив 100x100x100 елементів. Загальна кількість елементів буде одно 1,000,000 (мільйон). Для запису такого кількості елементів у звичайному випадку знадобилося-б 100 000 оновлень сторінок даних і індексів. Читання такої кількості елементів так-же зажадало-б 1,000,000 читань. При використання полів типу масив, тільки одна запис потребує читанні або оновленні. Додатково, якщо елемент масиву містить значення NULL, то InterBase не виділяє для нього дисковий простір. В реляційних термінах, доступ до набору даних з одного боку відносини, не має соответствющая значення, зажадає використання outer joun в будь-якому запиті, використовує таке ставлення. У більшості РСУБД, продуктивність запитів з outer join невелика. Доступ до масивів InterBase здійснюється іншим способом, і тому не погіршує швидкість доступу до даних.

Компанія Bear Stearns використовує масиви InterBase для зберігання частини своїх даних, і саме по причині високій швидкості обробки масивів. Bear Srearns виробляє покупку товарів на біржі і їх швидку продаж з невеликою націнкою. Оскільки ціна на різних біржах варіюється, ключ до успішної перепродажу це обчислення максимальної різниці в ціну поки ціни на біржі не змінилися. Масиви InterBase за своїми характеристиками відповідають вимогам такого завдання ..

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

Висока продуктивність і багате подання даних, забезпечувані багатовимірними масивами, дозволяють розробникам створювати рішення, неможливі при використання інших РСУБД.


6. Обробка транзакцій

6.1. Моделі Транзакцій

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

6.1.1. OLTP

Інтерактивна обробка транзакцій [OLTP] найбільш характерна для банківських операцій. За таким сценарієм, додаток виконує серію коротких (по вмісту і за часом) транзакцій. Додатком може знадобитися зміна однієї-двох записів або невеликий звіт. Великі та тривалі звіти виконуються неінтерактивному.

6.1.2. DSS

Системи підтримки прийняття рішень (або аналізу інформації) [DSS] преназначени для підтримки тривалих транзакцій, таких як підсумкові звіти або статистичний аналіз. Цей тип систем залежить від відносно статичної “Виду” бази даних, для того щоб забезпечити цілісність даних на весь час дії тривалої транзакції.

6.1.3. OLCP

Інтерактивна комплексна обробка [OLCP] є сумішшю моделей OLTP і DSS. Така модель намагається підтримати баланс між цими двома моделями, і призначається для більшості реальних додатків. Такі вимоги призводять до необхідності мати високу продуктивність, можливість виконання резервування даних “На ходу”, виконувати тривалі запити або тривалі звіти поки користувачі оновлюють поточну інформацію. Інформація повинна бути доступна в будь-який час без обмеження доступу як для OLTP так і для DSS транзакцій.

6.2. SQL Server

Архітектура SQL Server розроблена для підтримки або OLTP або DSS, але не для одночасної підтримки обох. Крім цього, не підтримується більшість вимог до режиму OLCP для реальних додатків. Такі обмеження викликані механізмом блокування, що використовується в SQL Server.

6.3. Типовий Сценарій

Уявіть собі таблицю, в якій записи є щомісячними записами балансу рахунків. За визначенням, сума по всіх записів повинна бути дорівнює нулю (тобто сума дебету має дорівнювати сумі кредиту). Уявіть також, що в системі працюють одночасно два користувачі – аналітик і оператор. Якщо аналітик вирішить запустити тривалий звіт, наприклад по всіх періодів, то такий запит повинен буде прочитати всі записи в таблиці. Якщо аналітик почне запит, а в цей час оператор виконає оновлення (пам’ятаєте, що сума дебету і кредиту мають дорівнювати 0) самої верхньої записи таблиці (Яку запит аналітика вже прочитав) і декількох самих нижніх записів (які запит аналітика ще не встиг прочитати через тривалості свого виконання), то аналітик побачить тільки другу частину транзакції оператора. Підсумок у аналітика не зійдеться і запит доведеться виконувати знову.
 
У більшості випадків аналітику доведеться дійсно повторити запит (правда, тут ще треба здогадатися – дійсно-ли це не зійшовся баланс або це сталося через втручання оператора). Але оскільки невідомо, скільки на Насправді записів змінив оператор, та й скільки всього операторів працюють в цей момент, єдиним рішенням для аналітика може бути тільки адміністративне – заборонити всім операторам вводити дані до тих пір, поки аналітик не завершить формування звіту. Ще більше найгірша ситуація може виникнути, якщо звіт виконується не по одній а по двох таблиць – головною і підлеглою. Більшість генераторів звітів спочатку збирають дані з підлеглих таблиць, а потім виконують розрахунок по головній. Роздільне оновлення даних в цих таблицях може привести до появи повністю непридатного звіту. Це неприпустимо в базах даних, контролюючих наукові дані реального часу або виробничий процес.
 
В архітектурі SQL Server, є тільки один спосіб гарантувати цілісність і відтворюваність читання – це блокування всієї таблиці. Блокування такого типу блокує доступ до таблиці для інших користувачів. У наведеному вище сценарії, SQL Server автоматично переведе сторінкові блокування в блокування всієї таблиці. Однак блокування таблиці не виникне поки достатню кількість сторінок не буде прочитано (рівень ескалації блікроовкі). Так що ймовірна ситуація, коли оператори, оновлюють дані, заблокують можливість установки блокування таблиці, і запит аналітика “Зависне” в очікуванні до нескінченності або просто не зможе виконатися. Розробник повинен знати особливості ескалації блокувань і вручну протестувати всі ситуації. Виникнення повного блокування таблиці в системах, що працюють 24 години на добу, може бути дуже важкодосяжним або взагалі неможливо, оскільки таке блокування призведе до блокуванні всіх інших користувачів, працюють інтерактивно і в реальному часі. Багато розробників не мають іншого вибору крім як виконувати подібні звіти по розкладом, в години найменшої активності основної маси користувачів, і коли повна блокування таблиці нікому не завадить.
 
Розробники повинні також витратити багато часу, розробляючи систему управління блокуваннями, для того щоб забезпечити роботу програми при виникненні конфліктів блокувань. Часто стан заблокованості не може бути визначено поки користувач не завершить транзакцію. Розробники повинні періодично намагатися зберегти транзакцію поки блоковані дані не стануть доступними, або писати складні процедури кешування оновлень на клієнтських машинах (для скорочення часу виконання транзакції). Локальне кешування даних викликає багато інших проблем, наприклад як наслідок – більшість користувачів у час кешування їх оновлення бачать невірну інформацію в базі даних.
 
Складність програм, що розробляються в Нині, досить висока і без обмежень, що накладаються архітектурою SQL Server.
(Д.К. – в даний час фірма Sybase випустила спеціальний продукт, що дозволяє працювати з DSS-транзакціями – Sybase IQ. Це спеціальний продукт, який призначений для виконання транзакцій DSS тільки в режимі читання (і фактично тільки по архівних, а не оперативними даними). Оновлення такий БД в режимі OLTP практично неможливо через спеціально застосовуваних структур даних. Таким чином завдання OLTP і DSS у Sybase вирішуються за допомогою двох окремих продуктів – Sybase System 11 і Sybase IQ відповідно).

6.4. InterBase

Borland InterBase повністю підтримує модель OLCP. Унікальна архітектура Багатоверсійність записів гарантує, що користувачі транзакцій OLTP не виявлять блокувань при оновленні даних, використовуваних транзакціями DSS, в той час як транзакціях DSS гарантується відтворюване читання. У тому-ж сценарії: коли аналітик починає транзакцію, IB створює ідентифікатор цієї транзакції. Коли оператор починає свою транзакцію, то IB для нього теж виділяє ідентифікатор транзакції. Якщо виявляються інші активні транзакції на цей момент, то IB для забезпечення відтворюваності читання створювати версії записів, модифікуються будь-який з інших активних транзакцій. Під час дії транзакції аналітика йому видно тільки версії записів, пов’язані з його транзакцією. Під час дії транзакції оператора, йому видно теж тільки ті версії записів, які пов’язані з ідентифікатором його транзакції. Таким чином аналітик і оператор ізольовані один від одного на час дії їх транзакцій, незалежно від їх тривалості. При завершенні обох транзакцій нові версії записів оператора стають видні аналітику, а старі версії записів видаляються.

Будь-які інші записи, змінювані під час дії згаданих транзакцій автоматично обробляються IB тим-же способом. Це стандартну поведінку IB і розробник не повинен докладати жодних додаткових зусиль для реалізації такого режиму роботи. Крім цього, користувач не зіткнеться зі сторінковими, індексними або табличними блокуваннями ні в якій ситуації (Д.К. – природно, якщо два користувача спробують відредагувати одночасно одну і ту-же запис, то виникне конфлікт оновлення, який блокуванням в Загалом-то не є). Замість блокувань IB забезпечує версії записів, які завжди представляють цілісний вид на базу даних під час дії транзакції. Багатоверсійність записів гарантує відтворюваність стану БД як для читання, так і можливість поновлення даних незалежно від рівня ізоляції транзакції. Це знижує складність і час розробки клієнтських програм, і забезпечує доступність корпоративних даних у будь-який момент.

7. Установка і Супровід

Оптимальне використання ресурсів є фундаментом для нормальної роботи будь-якої організації. Ресурси робочих груп, відділів та невеликих організацій вимагають чіткого і надійного управління. Такі організації як правило не можуть собі дозволити утримувати кваліфікованого адміністратора на повний робочий день (що навпаки, прийнято у великих корпораціях). Для цього у цих організацій немає достатнього бюджету на висококваліфікованих розробників або потужне апаратне забезпечення. Тому, бази даних, що використовуються в таких організаціях повинні легко встановлюватися і супроводжуватися персоналом, який не має високої кваліфікації адміністратора БД. Постачальники рішень на основі готових продуктів (VAR) або компанії, які діють в цій-же області бізнесу, поширюючи рішення рівня підприємства сильно зацікавлені у вартості установки і обслуговування, оскільки вони самі не можуть стежити за базами даних клієнтів повне робочий час (або виділяти для цього спеціальних співробітників).

Більшість корпорацій вже стандартизували свої операційні системи. Установка нової операційної системи може бути неприйнятна корпоративним тандартом, і навіть якщо це можливо, небажана з наступних причин:

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

7.1. Установка і Займане Простір

7.1.1. Background

Вимоги установки РСУБД залежить від виробника і операційної системи. Деякі РСУБД працюють без модифікації операційної системи, інші-ж вимагають зміни ядра до або під час процесу установки. Розробник повинен переконатися, що модифікації ядра операційної системи не позначаться на продуктивності та сумісності з його програмним забезпеченням.

7.1.2. Займане простір

До установки, і MS SQL Server і Sybase SQL Server вимагають попереднього розподілу простору і для РСУБД і для бази даних. Адміністратор системи або бази даних повинен слелать необхідний простір доступним. Якщо розмір БД перевищить відведений їй простір під час роботи, то РСУБД може припинити свою роботу (у час додати, змінити, або навіть виконання запиту до даних. Ось причини, за якими це може відбутися:

7.1.3. Визначення розміру бази даних

Визначення розміру БД, необхідного для SQL Server може бути досить складним через безліч факторів. Розмір повинен бути достатнім для розподілу системних таблиць, користувальницьких таблиць і всіх індексів. Ось деякі фактори, які обов’язково потрібно враховувати:

7.1.4. Microsoft SQL Server

7.1.4.1. Установка

Microsoft SQL Server існує тільки для Windows NT. Це виключає можливість використання обладнання, розрахованого на потужні UNIX-системи. Відповідно неможливі і багатоплатформні, масштабовані рішення.

Бази даних Microsoft SQL Server вимагають ретельного розподілу дискового простору і моніторингу доступності цього простору. Зупинка через відсутність вільного простору в БД може викликати серйозні наслідки. Установка і супровід Microsoft SQL server не дуже проста для відділів або робочих груп, особливо якщо ресурси апаратури обмежені. Ці особливості відображаються на витратах як постачальників так і покупців рішень на основі MS SQL Покупець не завжди може мати достатньо кваліфікованого адміністратора БД, щоб правильно розподіляти простір БД і управляти ресурсами SQL-сервера.

7.1.5. Sybase

Sybase має реалізації для кількох платформ, які включають Windows NT, Novell NetWare і різні платформи UNIX. Як і для Microsoft SQL Server, установка Sybase вимагає попереднього розподілу простору для баз даних і РСУБД, включаючи всі проблеми виникають з файлами протоколів транзакцій, редагуванням полів VARCHAR, видаленням записів, пакетної завантаженням записів і великими запитами.

Крім цього, для досягнення оптимальної продуктивності на платформах UNIX [включаючи SCO], адміністратор БД повинен створювати “сирі” (Raw) розділи диска (Д.К. – то-же саме можна робити в Informix і Oracle). Коли база даних встановлюється на “Сирий” розділ, всі дискові операції виконуються безпосередньо РСУБД. При деякому увеличениипроизводительности додається і складність в установці і супроводі такої бази даних. Оскільки операційна система не має доступу до “сирому” розділу, з ним неможливо працювати за допомогою стандартних утиліт UNIX в випадку збою. І на платформах UNIX, Sybase виробляє зміни ядра операційної системи. Такі зміни можуть викликати проблеми при оновленні або РСУБД або операційної системи.
 

7.1.6. InterBase

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

Оскільки InterBase не вимагає модифікації ядра ОС, він захищений від проблем сумісності при оновленні ядра ОС. Це дозволяє розробнику супроводжувати операційну систему без оглядки на працездатність РСУБД.

(Д.К. – власне процес установки являє собою переписування на жорсткий диск файлів дистрибутива IB. Це відбувається за 3-4 хвилини, після чого можна відразу створити базу даних (1 команда в ISQL, час 2-3 секунди), і приступити до створення таблиць і інших об’єктів БД)

7.2. Обслуговування

7.2.1. Backup

7.2.1.1. SQL Server

Збереження БД в архів має виконуватися періодично (наприклад ночами). Підтримується два типи backup, виробленого SQL Server – повний (full) і збереження змін (incremental). Повний backup [іноді званий dump] створює повний образ бази даних включаючи системні таблиці і та файли протоколів. Backup зі збереженням (incremental) робить тільки копію файлів протоколів. Адміністратор БД повинен чітко виконувати послідовні full і incremental backup. Це необхідно тому, що backup не скидає файли протоколів. Якщо-ж не робити періодично incremental backup, то файли протоколів можуть переповнитися, і РСУБД в результаті зупинить свою роботу. Така зупинка вимагає втручання кваліфікованого адміністратора БД для усунення проблем. Це також блокує роботу користувачів на час, необхідний для відновлення БД в робочий стан.

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

7.2.1.2. InterBase

Завдяки Багатоверсійність записів, база даних може бути сархівірована (backup) у будь- час при будь-якій кількості користувачів, працюють з даними в цей же час. Backup являє собою транзакцію з рівнем ізоляції RepeatableRead, яка виробляє тільки читання всієї БД. Таким чином backup “не бачить” змін, вироблених або вироблених після старту backup. Це гарантує цілісне стан архівованої БД на момент архівації. У сенсі продуктивності виконання backup означає підключення ще одного користувача, який читає дані. У Borland InterBase існує тільки один тип архівування – повний (full), коли архівуються абсолютно всі дані, що знаходяться в БД.

(Д.К. – на жаль, incremental backup у IB відсутня. Це можна пояснити тільки тим, що при відсутності механізму Transaction Log і наявності механізму Багатоверсійність записів, для incremental backup довелося-б або все нові версії записів, починаючи із закінчення full backup, класти в окреме місце, або неявно не завершувати транзакцію full backup, що призвело-б до появи невиправдано великої кількості версій записів і витрачанню дискового простору. м.б. щось нове з’явиться в IB 5.0)

7.2.2. Реєстрація транзакцій (Transaction Logs)

7.2.2.1. SQL Server

Ttransaction log – системна таблиця, в яку записуються всі послідовні модифікації кожного об’єкта БД. Він також зберігає інформацію, необхідну для забезпечення цілісності даних при модифікації даних. Простір, необхідне для реєстрації транзакцій важко передбачувано. Уявіть собі, що log повинен містити інформацію по кожній оновленої записи плюс зміни індексів. Також, уявіть що у таблиці багато індексів. Обсяг transaction log залежить від довжини запису. Для коротких записів відношення розміру log до розміру даних може досягати 10:1. Для довгих записів це ставлення менше. Операції пакетної “Заливки” даних або видалення також можуть вимагати більшого розміру transaction log. Як уже вказувалося вище, при модифікації записів з полями VARCHAR потрібно ще більший розмір transaction log, т.к. реєструється не одна операція модифікації, а дві – видалення і вставки.

Якщо розклад архівування БД включає суміш повного (full) і часткового (incremental) архівування, то це теж потрібно враховувати при визначенні розміру transaction log. Причина в тому, що incremental backup – це механізм, який використовується в SQL Server для очищення transaction log. Великий вплив чинять також і тривалі транзакції, особливо якщо вони оновлюють велику кількість записів – в цьому випадку розмір transaction log повинен бути встановлений в 200% від розміру збережених даних.

Розміщення transaction log також критично – якщо він переповниться, і не залишить вільного місця на диску, всі операції з БД будуть припинені (Буквально відбудеться crash). Тому розміщувати БД і transaction log бажано на різних пристрою.

7.2.2.2. InterBase

Borland InterBase не використовує transaction log для зберігання інформації про транзакції та зміни, які вони виробляють. Замість цього використовуються Transaction Inventory Pages [TIP]. На цих сторінках зберігається інформація про стан будь-якої транзакції: активна, підтверджена, скасована або подоготовленная (для двофазного потдтвержденія транзакцій (2PC). У разі системного збою, як тільки сервер буде запущено, будуть автоматично просканувати TIP з метою пошуку непідтверджених транзакцій. Всі записи, знайдені в непідтвердженому стані, будуть скасовані. Цей процес практично для будь-якого БД розміру відбувається протягом кількох секунд. (Д.К. дійсно кілька секунд, тому що скасовані записи при цьому не видаляються – скасовані версії записів будуть зібрані як сміття тільки тоді, коли який-небудь користувач не звернеться до цих даних (Кооперативна збірка сміття).

Оскільки transaction log відсутня, то немає потреби піклуватися про його розмір. Навіть якщо у вашій БД часто виконуються тривалі транзакції, створюють багато версій записів, то автоматичні збільшення БД буде незначним – версії записів створюються не як повна копія запису, а як “різниця” (delta) між старою версією і нової, розміщуються версії на тих-же сторінках даних. Крім того, як тільки версії стають непотрібними, займане ними простір автоматично станоітся доступним для нових даних.

7.2.3. Контрольні точки
(Checkpoints)

7.2.3.1. SQL Server

Архітектура SQL Server вимагає щоб адміністратор встановив контрольні точки для БД. Контрольні точки – це інтервали часу, через які відбувається запис накопичених в кеші SQL-сервера змін на диск (transaction logs та сторінки даних). Якщо зміни відбувалися між двома checkpoint, і в цей час стався збій, то зміни даних взагалі не потраплять в transaction log, відповідно відкат до попереднього стану буде зроблений за даними, збереженим під час останнього checkpoint перед збоєм. Інтервал checkpoint впливає як на збереження даних від збоїв так і на продуктивність системи – встановивши великий інтервал, ви прискорите продуктивність, але можете втратити багато змін при збої. Встановивши маленький інтервал (1-2 хвилини), погіршиться продуктивність системи.
(Д.К. – цей-же абзац в оригіналі звучить дещо по іншому – автор помилково думає, що інтервал checkpoint прямо впливає на час відновлення системи після збою. Наприклад, при checkpoint = 20 хвилин, на відновлення буде потрібно теж 20 хвилин. Це зовсім не так – зміни даних, вироблені між checkpoint при збої просто будуть втрачені).

7.2.3.2. InterBase

Контрольні точки в Borland InterBase не використовуються. Замість цього застосовується синхронне і асинхронне збереження змінених даних. Синхронне кешування при дещо меншою продуктивності гарантує негайне відновлення БД після збою. Адміністратор БД може встановити і асинхронне кешування, в І тут швидкість оновлення БД зросте, однак підвищиться ризик втрати великого кількості змін при збої, тому за вивантаження кешу на диск вже відповідає операційна система.
Можливість негайного відновлення після збою без необхідності будь-б то не було втручання адміністратора БД робить Borland InterBase найкращим вибором для робочих груп, відділів, або постачальників рішень, особливо для тих, які не можуть мати в штаті висококваліфікованого адміністратора бази даних.

7.2.4. Конфігурування та налаштування

7.2.4.1. SQL Server

Microsoft SQL Server і Sybase SQL Server мають міріади конфігураційних опцій і параметрів настройки для оптимізації продуктивності бази даних. Багато з цих параметрів досить складні і можуть впливати один на одного. Тільки достатньо кваліфікований адміністратор БД може керувати всіма цими параметрами для настройки сервера. Наприклад, в Sybase System 11 з’явилося більше 200 параметрів настройки. Це додає складності до управління сервером, вартість навчання адміністратора БД, і припускає що в міру ускладнення використовуваної бази даних може знадобитися налаштування півночі.

7.2.4.2. InterBase

Borland InterBase автоматично конфігурується і налаштовується, і не вимагає ніякого втручання адміністратора в настройки. Це максимально полегшує управління та супровід. У загальному випадку, у IB існує не більше конфігураційних 20 параметрів, які практично ніяк не впливають один на одного (Основних параметрів всього 3 – розмір кеша і ліміти займаної пам’яті). Це зроблено спеціально для зменшення вартості супроводу та обслуговування. Після установки, втручання адміністратора БД потрібно хіба що у разі катастрофічного збою обладнання, або для регулярного виконання bakup (Д.К. – який можна автоматизувати за допомогою утиліти AT на Windows NT, або спеціальних утиліт на UNIX).

7.3. Відновлення при збоях

7.3.1.1. SQL Server

Автоматичне відновлення бази даних SQL Server включає в себе “відтворення” вмісту transaction logs. Цей процес послідовно застосовує до БД транзакції, збережені в transaction log для того щоб відновити стан БД на момент останнього
checkpint.

Якщо база даних не відновлюється з існуючого transaction logI, отже її треба видалити і відновити з архіву. При цьому відновлюється спочатку повна копія БД, а потім все “часткові” архіви (incremental backups), які були створені від моменту збереження повної копії БД. Це досить складний і тривалий процес.

7.3.1.2. InterBase

Відновлення бази даних Borland InterBase відбувається автоматично без втручання адміністратора БД. Транзакції, які не встигли завершитися на момент збою, будуть повністю скасовані, і БД залишиться в цілісному стані. Недоліком є ​​відсутність “Часткового” архівування, тобто якщо в результаті збою було пошкоджено носій даних, відновити вдасться тільки БД в її останньому повному архівуванні. Це компенсується швидкість виконання backup, його виконанням “на ходу “, а також швидкістю відновлення даних.

Як уже згадувалося, при запуску Borland InterBase він перевіряє БД на наявність непідтверджених записів. При існуванні таких вони переводяться в скасоване стан. Цей процес займає кілька секунд. Така особливість була ключовим фактором при виборі InterBase для американського танка M1 Abrams. Коли відбувається постріл з гармати танка, виникає дуже сильний електромагнітний імпульс, який “Перевантажує” комп’ютер танка. Після перезавантаження комп’ютера, InterBase миттєво відновлює БД в цілісне стан і тут-же робить її доступною для роботи. Це властивість, не доступне в будь-який інший РСУБД, гарантує доступність бази даних в життєво важливих ситуаціях. Навіть якщо буде потрібно відновити БД з backup, це виробляється фактично одним натисненням кнопки в Server Manager, або запуском командного файлу (що викликає утиліту gbak), що може зробити навіть некваліфікований користувач. Оскільки Borland InterBase є стерпним SQL-сервером, дії по відновленню БД будуть абсолютно ідентичні для будь-якої платформи.

Figure 2. Restoring an InterBase database using the InterBase Server Manager.

Відновлення БД може здійснюватися між будь-якими операційними системами. Тобто файл backup може розташовуватися наприклад на Windows NT 3.51, а відновлювана БД – на SCO UNIX.

7.3.1.3. Віддзеркалення БД (Database Shadowing)

Borland InterBase використовує техніку “гарячого” резервування за допомогою так званої “Тіні” (shadow). “Тіньова” БД – дублікат бази даних, що знаходиться на іншому фізичному пристрої. Оновлення “тіні” виробляється з кожним оновленням сторінки основної бази даних. У разі апаратного збою носія основної бази даних, Borland InterBase в залежності від режиму “затінення” перемикає користувачів на “тінь”, роблячи її основний базою даних. Це може відбуватися або автоматично, або по команді адміністратора бази даних. Таким чином, вирішується або завдання забезпечення безперервного доступу до БД (online), або гарантування наявності цілої копії робочої бази даних. “Тіней” бази даних може бути стільки, скільки потрібно для гарантії збереження даних.


8. РЕСУРСИ

8.1. Microsoft SQL Server

Microsoft SQL Server вимагає наявності як мінімум 60M на диску для установки і 16MB RAM під NT 3.51 (Д.К. напевно, мається на увазі 16Мб фізичної пам’яті). Кожен користувач займає по 48K пам’яті. Тобто у разі 20-ти користувачів потрібно близько 17Мб фізичної пам’яті, не рахуючи пам’яті, необхідної для обробки таблиць і буферизації даних.

Незважаючи на те, що при установці Microsoft SQL Server не потрібно конфігурування пам’яті, Microsoft вважає цей параметр найважливішим, і рекомендує встановлювати його вручну. Microsoft не надає формули для визначення оптимального значення, натомість рекомендується запустити монітор продуктивності, і аналізувати параметр “Page faults / sec”. Далі, оскільки Microsoft SQL Server блокує пам’ять і тимчасові таблиці в пам’яті, то інші програми, які виконуються на цьому-ж комп’ютері можуть видати повідомлення про брак пам’яті. Взагалі, визначення необхідного обсягу пам’яті достатньо складне завдання, яке вирішується тільки в реальних умовах, і досить кваліфікованим адміністратором.

8.2. Sybase SQL Server

Установка Sybase вимагає приблизно 50M на диску. Додаткове простір потрібно для пристроїв дампа, тимчасового робочого простору і т.п. Також плюс 2-3 MB на установку підтримки національної мови.

Вимоги до пам’яті відрізняються на різних платформах. Адміністратор Sybase SQL Server повинен підрахувати вимоги до пам’яті грунтуючись на:

Тобто також, як і для Microsoft SQL Server, Sybase SQL Server створює великі витрати на супровід.

8.3. InterBase

Ядро Borland InterBase використовує менш 2Мб пам’яті (що на 1Мб менше, ніж наприклад займає утиліта FastFind з Microsoft Office). При установці на диску потрібно близько 8Мб, причому більшість цього простору займають довідкові файли, приклади, бібліотеки клієнтського API, і приклади БД. Borland InterBase не вимагає пам’яті більше, ніж базова пам’ять для операційної системи. Він динамічно використовує ресурси диска і пам’яті без втручання адміністратора БД.

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


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

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

Ваш отзыв

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

*

*