даних по суті регулює швидкість виконання контрольних точок.
Якщо в параметрі FAST_START_MTTR_TARGET встановлено занадто низьке значення, сервер бази даних буде писати на диск дуже часто, і це може привести до зниження швидкості роботи системи. Тому цей параметр необхідно налаштовувати так, щоб сервер не виконував надмірна кількість контрольних точок, але при цьому час відновлення залишалося б в прийнятних межах. З цією метою в СУБД Oracle9i Release 2 введена нова консультативна довідка за MTTR (MTTR Advisory). Ця довідка дозволяє екземпляру оцінювати (у відсотках) зміна кількості записів на диск, яке могло б статися при інших значеннях в параметрі FAST_START_MTTR_TARGET. Використовуючи оцінку, отриману при типовою робочого навантаження на екземпляр, ви можете визначити вплив підвищення або зниження значення в даному параметрі. Значення консультативної довідки за MTTR містяться в поданні V $ MTTR_TARGET_ADVICE. Це подання має п'ять рядків, які показують передбачувану дискову активність при різних значеннях в параметрі FAST_START_MTTR_TARGET: поточне значення; приблизно десята частина поточного значення; приблизно половина поточного значення; приблизно півтора поточного значення і приблизно подвійне поточне значення. У Enterprise Manager можна отримати графічне представлення консультативної довідки за MTTR (див. рис. 6).
Тепер АБД мають інструментарій для управління часом відновлення екземпляра і можуть це робити без компрометації продуктивності системи. Вони повинні використовувати цей інструментарій, оскільки він дозволяє зробити час відновлення примірника передбачуваним, а також дає ручки настройки цього часу відповідно до їх потреб.
Рис. 6. Консультативна довідка за MTTR.
5.2 Планування відновлення носія
.2.1 Стратегія резервування
Відновлення носія потрібно завжди, коли втрачаються дані. Найбільш загальні причини втрати даних: збої носія і людські помилки. Для того щоб можна було відновлювати носій, сервер бази даних повинен функціонувати в режимі ARCHIVELOG (архівування журналу). Його легко включити за допомогою оператора ALTER DATABASE. Потім АБД повинні вибрати метод резервування. Минулого АБД писали свої власні скрипти для резервування бази даних. Зараз робити це вже недоцільно, так як утиліта Recovery Manager (диспетчер відновлення) краще оснащена для управління резервуванням. Утиліта Recovery Manager має варіант з інтерфейсом командного стоки, а також варіант з графічним інтерфейсом, вбудованим в Enterprise Manager. Утиліта Recovery Manager дозволяє користувачам специфікувати всі їхні вимоги резервування, наприклад, повне оперативне резервування бази даних на стрічку, автономне резервування всієї бази даних на диск і т.п. Більше того, використання засобів планування в Enterprise Manager дозволяє запускати завдання створення резервних копій в заданий час, як регулярно, так і по потребі. Хороша практична рекомендація: разом з резервними копіями файлів даних бази даних створювати резервну копію керуючого файлу. Резервну копію керуючого файлу, як мінімум, необхідно створювати при зміні структури бази даних.
Для тих адміністраторів, яким потрібні також файли систем резервування, корпорація Oracle ініціювала, спільно з постачальниками систем управління носіями, програму вирішення проблем резервування (Backup Soluti...
