Розглянуто питання, необхідні розробнику для створення клієнт-серверних додатків з використанням СУБД Firebird, що стала розвитком СУБД Borland Interbase 6. Утримується огляд концепцій і моделей архітектури клієнт / сервер, а також практичні рекомендації по роботі з клієнтськими бібліотеками Firebird. Детально описані особливості типів даних SQL, мова маніпулювання даними (Data Manipulation Language, DML), а також синтаксис і оператори мови визначення даних (Data Definition Language, DDL). Велика увага приділена опису транзакцій і наведено поради щодо їх використання при розробці додатків. Описано програмування на стороні клієнта і сервера написання тригерів і збережених процедур, створення і використання подій бази даних, обробка помилок в коді на сервері і багато іншого. Матеріал супроводжується численними прикладами, порадами та практичними рекомендаціями.
Для розробників баз даних
Книга: Firebird КЕРІВНИЦТВО РОЗРОБНИКА БАЗ ДАНИХ
Перевірка і ремонт
Розділи на цій сторінці:
Перевірка і ремонт
Firebird надає утиліти для перевірки логічних структур в базі даних і ідентифікації незначних проблем, а також деякий їх ремонт. Безліч таких помилок може з'являтися час від часу, особливо в середовищах, де мережі нестабільні або галасливі або електропостачання є нестабільним. Поведінка користувача, а також дефекти в проектуванні програми або бази даних також часто призводять до логічних руйнувань.
Ненормальне завершення клієнтських з'єднань не впливає на цілісність бази даних, оскільки сервер Firebird перевіряє втрату з'єднання. Він зберігає підтверджені зміни даних і виконує відкат для будь-яких даних, які очікують підтвердження. Чистка є важливим питанням обслуговування, оскільки сторінки даних, які були призначені непідтвердженими даними, залишаються у вигляді "осиротілих". Перевірка буде виявляти такі сторінки і звільняти їх для подальшого використання.
Інструменти перевірки достовірності здатні визначити і усунути незначні аномалії, які є наслідком помилок операційної системи або обладнання. Такі помилки зазвичай призводять до появи проблем цілісності бази даних через помилки запису даних в сторінки або втрати сторінок даних або індексів.
Коли перевіряти достовірність і навіщо
Періодична перевірка достовірності повинна бути частиною обслуговуючої діяльності адміністратора бази даних щодо виявлення та усунення невеликих аномалій для повторного використання дискового простору. Це також буде потрібно, коли будуть виявлені структурні пошкодження або виникнуть підозри про їхню наявність. Ознаки включають:
* Помилки "corrupt database" або "consistency check";
* Відмова або зміна напруги електроживлення при відсутності джерела безперебійного живлення (UPS) або при припущенні про відмову UPS;
* Передбачувані або повідомлені системою помилки жорсткого диска, мережі або пам'яті;
* Тіньова копія замінює собою базу даних після руйнування диска;
* База даних була перенесена з іншої платформи або системи зберігання;
* Очікуване несанкціоноване звернення до мережі або базі даних з боку зовнішніх атак.
Подробиці використання gfix для виконання перевірки бази даних див. У розділі 39.
Що робити зі зруйнованою базою даних
Якщо ви підозрюєте, що у вас зруйнована база даних, важливо дотримуватися правильної послідовності кроків відновлення, щоб виключити подальше руйнування. Перше, і найважливіше справу - завершити роботу всіх користувачів і відключити їх від бази даних.
У додатку 4 міститься докладний опис процедур лагодження зруйнованої бази даних.
Як зруйнувати базу даних Firebird
Модифікація системних таблиць
Firebird зберігає і веде всі свої метадані і ваші певні користувачем об'єкти в. базі даних Firebird! Більш точно він зберігає їх у відносинах (таблицях) прямо в самій базі даних. Ідентифікатори системних таблиць, їх стовпців і деяких інших типів системних об'єктів починаються з символів "RDB $".
Оскільки це звичайні об'єкти бази даних, їх можна запитувати і маніпулювати ними як певними користувачем об'єктами. Однак те, що ви можете. не означає, що ви повинні.
Не можна настійно рекомендувати, щоб ви використовували тільки оператори DDL - непрямі операції SQL над системними таблицями - щоразу, коли вам потрібно змінювати або видаляти метадані. Відкладіть всякі "прямі зміни", поки ваші вміння в SQL і ваші знання сервера Firebird не стануть більш повними. Потерпіла аварію база даних не є ні предметом приємного споглядання, ні легкої ремонту.
Скасування примусового запису для Firebird 1.0.x в Windows
Firebird за замовчуванням встановлюється з можливістю примусового запису (forced writes, синхронної записом). Змінені і нові дані записуються на диск негайно після завершення операції (post).
Можливо конфігурація бази даних для використання асинхронної записи даних, коли змінені або нові дані зберігаються в пам'яті кеша і періодично скидаються на диск підсистемою введення / виводу операційної системи. Загальний термін для такої конфігурації - скасування примусової записи. Іноді це значення відновлюється для поліпшення продуктивності великих пакетних операцій.
Сервер платформ Win32 не зберігається на диск кеш сервера Firebird 1.0.x, поки не буде закритий сервіс Firebird. Не кажучи вже про збої в харчуванні, може багато чого погано-го статися з сервером Windows. Якщо він зависне, система введення / виведення припинить роботу, і робота вашого користувача буде втрачена в процесі перезавантаження.
Щоб зробити це практично, рекомендується відновлювати базу на резервне дисковий простір, використовуючи gbak -з [reate]. Перш ніж зробити відновлену базу даних активної, перевірте її в резервної області, використовуючи isql або ваш бажаний інструмент адміністратора.
Дозвіл користувачам з'єднуватися з базою даних в процесі її відновлення
Якщо вашої організації подобається жити на вістрі ножа, використовуйте перемикач -restore і дозвольте користувачам з'єднуватися з базою даних і виконувати зміни. Процес відновлення створює базу даних з нуля, і як тільки будуть створені таблиці, ваші користувачі зможуть (принаймні, потенційно, або якщо вони все SYSDBA) звертатися до них з операціями DML, в той час як довідкова цілісність і інші обмеження знаходяться ще тільки на підході. У кращому випадку вони отримають виключення і купу непідтверджених транзакцій в частково сконструйованої базі даних. У гіршому, вони повністю знищать цілісність даних.