Порівняння Borland InterBase 4.x

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


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 (мільйон). Для запису такого
кількості елементів у звичайному випадку
треба було-б 100000 оновлень сторінок даних і
індексів. Читання такої кількості елементів
так-же зажадало-б 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 вимагають
попереднього розподілу простору і
для РСУБД і для бази даних. Адміністратор
системи чи бази даних повинен слелать
необхідний простір доступним. Якщо розмір
БД перевищить відведений їй простір під час
роботи, то РСУБД може припинити свою роботу (у
час додавання, зміни, або навіть виконання
запиту до даних. Ось причини, за якими це
може відбутися:

  • Великі запити, що викликають створення тимчасових
    таблиць на диску.
  • Переповнення файлу, що реєструє роботу
    транзакцій (Transaction logs).
  • Додавання більшої кількості даних ніж
    передбачалося.
  • Переповнення файлу даних при модифікації
    полів типу VARCHAR через їх видалення і додавання.
  • Переповнення файлу даних через велику
    кількості вилучень (Д.К. – простір на диску
    може не звільнятися, а log-і будуть рости).

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

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

  • На протокол транзакцій потрібно додатково
    від 20% до 30% від загального обсягу даних.
  • Додатково 150% розміру таблиці при
    використанні кластерного індексу.
  • 5% розміру таблиці на внутрішні витрати
    SQL-сервера.
  • Додатково по 2K на запис, якщо вона містить
    полі text або image навіть якщо поле пусте.
  • Ще простір для протоколу транзакцій якщо
    передбачаються часті оновлення полів типу
    VARCHAR.
  • І ще простір, якщо в деяких таблицях
    будуть часто проводитися видалення записів.

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 повинен
підрахувати вимоги до пам'яті грунтуючись на:

  • Статичної пам'яті для ядра 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>

*

*