Рефераты | Рефераты по информатике, программированию | Oracle9i. Обзор некоторых новых возможностей |
Администратору
Администратор базы данных – человек, отвечающий в первую очередь за сохранность данных и работоспособность системы. Новые способы обеспечения бесперебойной работы позволят ему жить более спокойно.
Остановки базы данных можно разделить на плановые (например, для изменения параметров экземпляра) и внеплановые (различные сбои). Oracle9i позволяет существенно понизить частоту плановых остановок, поскольку допускает динамическое изменение почти всех параметров экземпляра, в том числе и таких параметров системной глобальной области, как размер кэша буферов базы данных или разделяемого пула. Что же касается сбоев, то гарантировать их отсутствие не может никто. Oracle9i содержит средства для снижения вероятности сбоев и максимально безболезненного устранения их последствий.
Технология Oracle Data Guard – развитие старой идеи резервной базы данных (Standby Database). Основным недостатком старого варианта была невозможность полного восстановления резервной базы перед ее активизацией. Если при аварии основного сервера повреждался текущий журнал (current redo log), то все изменения базы данных, записанные в этот журнал, терялись безвозвратно. Для многих OLTP-систем это было неприемлемо. Технология Oracle Data Guard позволяет администратору базы данных самому выбрать, что для него важнее – недопущение потери даже самого малого количества данных или максимальная производительность. Если потеря данных недопустима, то можно заставить Oracle отправлять изменения на резервный сервер в синхронном режиме, т.е. пока эти изменения не выполнятся на резервной базе данных, транзакция не считается зафиксированной. Естественно, это может привести к некоторым потерям в производительности. Можно использовать старый метод – изменения передаются на резервный сервер только после заполнения очередного журнала на основном сервере. Тут мы жертвуем сохранностью данных ради производительности. И есть компромиссный вариант – изменения передаются на резервный сервер «почти синхронно», тогда небольшая потеря данных в случае аварии возможна, но маловероятна.
Особого внимания заслуживает новая возможность Recovery Manager – восстановление отдельного блока файла данных. Раньше одним из стандартных способов восстановления при обнаружении поврежденного (corrupted) блока было копирование файла, содержащего этот блок, из резервной копии и применение к нему архивных и оперативных журналов. Это требовало как минимум перевода поврежденного табличного пространства в автономный режим на время копирования файла, что приводило к недоступности части данных на довольно длительный срок. Теперь Recovery Manager может извлечь из резервной копии только поврежденный блок, выполнить его восстановление при помощи журналов и записать восстановленный блок в файл данных. В этом случае временно недоступными оказываются только данные в поврежденном блоке.
Так называемые возобновляемые операции (Resumable Operations) позволяют бороться с другим очень распространенным видом сбоев – нехваткой пространства в базе данных. Каждый администратор наверняка не раз попадал в ситуацию, когда операция вроде перестроения большого индекса или реорганизации огромной таблицы работает несколько часов и обрывается из-за нехватки места в табличном пространстве (постоянном или временном) или невозможности расширить сегмент отката. В Oracle9i такую операцию можно объявить возобновляемой. Тогда в случае возникновения подобной ошибки процесс не прерывается, а приостанавливается до тех пор, пока администратор не устранит препятствие или не истечет заданный таймаут. Вот как это выглядит.
Создадим таблицу (для чистоты эксперимента – в управляемом системой (dictionary managed) табличном пространстве, т.к. в локально-управляемом (locally managed) не действует параметр Maxextents):
|
create table Small_extent_table tablespace dict_tbs storage (initial 10K maxextents 1) as select * from emp; |
Несколько раз продублируем в ней данные:
|
insert into Small_extent_table select * from Small_extent_table; |
Примерно на пятой-шестой попытке получим ошибку «ORA-01631: max # extents (1) reached in table SCOTT.SMALL_EXTENT_TABLE». Включим возобновляемые операции (для этого пользователь должен иметь привилегию Resumable):
|
alter session enable resumable; |
Попробуем еще раз:
|
insert into Small_extent_table select * from Small_extent_table; |
Сессия зависает и ждет возможности добавить экстент в таблицу. Из другой сессии обнаружим это:
|
select name, sql_text, error_msg from dba_resumable; |
Получим:
|
User SCOTT(70), Session 7, Instance 1 insert into small_extent_table s select * from small_extent_table Рекомендуем скачать другие рефераты по теме: налоги в россии, сочинение. Предыдущая страница реферата | 1 2 3 4 5 6 7 8 9 10 11 | Следующая страница реферата Поделитесь этой записью или добавьте в закладкиКатегории: |
