Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 25)

1. Экспортируйте данные всех таблиц в табличном пространстве с помощью утилиты ехр. Для индек­сов предусмотрите запись в файл сценариев SQL, необходимых для их воссоздания.

2. Удалите все объекты в табличном пространстве с помощью команд drop table и/или drop index.

3. Удалите табличное пространство с помощью команды drop tablespace.

4. Вновь создайте табличное пространство, используя команду create tablespace.

5. Импортируйте данные в табличное пространство с помощью утилиты imp. В результате импорта бу­дет вновь создана таблица базы данных. Вручную воссоздайте индексы с использованием получен­ных сценариев SQL.

Производительность базы данных уменьшают не только фрагментированные и перемещенные строки, но и фрагментация, поскольку она заставляет чаще перемещаться головки дисковода при выполнении запросов к таблице базы данных. Очевидно, что фрагментированные табличные пространства следует деф-рагментировать при любой возможности. Чтобы свести фрагментацию к минимуму, создавайте и удаляйте новые таблицы и индексы (особенно если они используются в качестве временных или экспериментальных таб­лиц) только в отдельных табличных пространствах.

Сегментированные таблицы

Таблицы можно заставить занять несколько экстентов, чтобы разнести полосы дан­ных по нескольким устройствам. В OracleS предусмотрена возможность сегментировать таблицы, группируя по таблицам наборы данных и размещая эти группы по отдельным табличным пространствам и/или уст­ройствам.

Например, предположим, что вам нужно создать таблицу под названием mailingJist. Зная о том, что это будет очень большая и интенсивно используемая таблица, вы должны распределить эту таблицу по двум табличным пространствам и разместить каждое табличное пространство на отдельном устройстве. Эти два табличных пространства называются mail_tsl и mail_ts2:

create table mailing_list (last_name varchar2(30) not null, first_name varchar2 (15) not null, address varchar2(40) not null, city varchar2 (20) not null, state varchar2 (2) not null, zip varchar2 (5) not null) partition by range (last_name)

(partition mail_partl values less than ('N') tablespace mail_tsl, partition mail_part2 values less than (maxvalue) tablespace mail_ts2);

Table created.

Представления

Представления — это операторы SQL, которые можно считать виртуальными таблицами. Они позво­ляют скрыть подробности о сложных соединениях таблиц и фильтров, чтобы этот код не приходилось ис­пользовать в каждом операторе, выполняющем аналогичную операцию. Однако важно учитывать, что этот оператор не будет выдан до тех пор, пока по отношению к этому представлению не будет выполнен ка­кой-либо оператор SQL.

Для настройки производительности представления лучше всего применить превентивный подход. Вы­полняйте каждое созданное представление через EXPLAIN PLAN и анализируйте его производительность. За исключением редких случаев, неэффективные представления, требующие продолжительного времени для получения данных, применять не следует. Если представление, которое до сих пор выполнялось, вдруг начинает тормозить работу, нужно выполнить еще один EXPLAIN PLAN или снова применить SQL*Trace к запросу на этом представлении.

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

Триггеры

Еще одним новым средством Oracle?, которое вызывает трудности при настройке, является триггер базы данных. Если вы работали с SQL*Forms/Oracle*Forms или с другой программой обработки на основе со­бытий, то вы уже встречались с триггерами, в противном случае вам будет нелегко понять их работу.

Триггер активизируется при возникновении определенного события, например до или после модифи­кации таблицы базы данных. При этом выполняется раздел кода PL/SQL. Если код SQL, содержащийся в сегменте PL/SQL, оптимизирован на основе EXPLAIN PLAN, триггеры работают хорошо. Однако триг­геры могут вызвать непредвиденные проблемы. Это обычно происходит при их применении неопытным раз­работчиком или при их неудовлетворительном тестировании.

Распространенной проблемой, связанной с триггерами, является бесконечный цикл. Один триггер ак­тивизирует другой, который активизирует третий, и т.д. пока один из триггеров не вызовет изменение, которое запустит первый триггер, и все начнется сначала. Эти ошибки трудно обнаружить, и они могут создать неуловимые проблемы. Избежать их поможет тщательное исследование и проверка перед внедре­нием новых триггеров.

Блокировка базы данных

Блокировка базы данных имеет большое значение для DBA, поскольку она может замедлить работу базы данных. Распознавание этой проблемы может оказаться нелегким делом, поскольку она не всегда очевидна.

Блокировки в базе данных предотвращают одновременное внесение изменений в одни и те же данные пользователями базы данных в многопользовательской среде. Блокировки базы данных, предписывая од­новременность и непротиворечивость, обеспечивают целостность данных в базе данных. Одновременность означает, что база данных обеспечивает возможность для пользователей читать данные из блока базы данных, не беспокоясь о том, не записывается ли сейчас в этот блок базы данных другая информация; пользователь, записывающий данные, должен ждать завершения предшествующих операций записи. Непротиворечивость означает, что запрос базы данных возвращает данные точно в таком виде, в каком они находились при первоначальном выполнении запроса; изменения, внесенные после выдачи запроса, в него не попадают.

Типы и классы блокировок

В базе данных Oracle? применяются блокировки двух типов: блокировки словаря данных (DDL — data dictionary lock) и блокировки манипуляции данными (DML — data manipulation lock). Блокировка DDL обеспечивает постоянство компоновки объекта базы данных (его определения) на время его использова­ния в запросе базы данных. Блокировка DML защищает данные, к которым пытаются одновременно об­ратиться несколько пользователей.

Все транзакции распадаются на две категории: исключительные или разделяемые. Исключительные тран­закции не позволяют другим пользователям получить доступ к данным. Разделяемые транзакции позволя­ют другим пользователям обращаться к тем же данным, но не изменять их. Блокировки снимаются после фиксации или отката.

При каждом обращении оператора SQL к данным в таблице он приобретает в этой таблице блокировку DDL. Эта блокировка не дает возможности DBA вносить изменения в таблицу, пока она находится в работе.

Блокировки DML, с другой стороны, применяются к таблицам базы данных. Существует пять типов блокировок DML:

Проблемы неразрешенных блокировок

Распространенными ситуациями блокировки базы данных являются неразрешенные блокировки, которые называют также взаимоблокировками. При взаимоблокировке две операции базы данных ожидают, пока одна из них не освободит блокировку.

В Oracle? предусмотрено распознавание взаимоблокировок, но оно не всегда бывает успешным. Могут возникнуть транзакции, которые приобрели блокировки и ожидают, пока одна из них не освободит свои блокировки, чтобы можно было продолжить работу. К сожалению, единственным реальным способом раз­решения этой проблемы является их непосредственное обнаружение и устранение. Oracle рекомендует два способа предотвращения взаимоблокировок:

• Приложения должны приобретать блокировки в одном и том же порядке.

• Всегда используйте блокировку минимального уровня. Например, не блокируйте всю таблицу, когда нужно обновить только одну строку.

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

Проверка состояния блокировок

В Oracle предусмотрен вспомогательный сценарий проверки текущего состояния блокировки базы данных. Этот сценарий, utilockt.sql, создает дерево, показывающее, какие блокировки установлены и какие про­цессы находятся в ожидании:

SQL> @$ORACLE_HOME/rdbms/admin/utllockt

Можно выполнить запрос к таблице DBA_WAITERS, чтобы определить, какие сеансы ожидают бло­кировок и какие сеансы ими владеют. В ней показаны не все сеансы, владеющие блокировками, а толь­ко те, которые вызвали состояние ожидания. Следующий запрос позволяет просмотреть только те сеансы, которые могут вызвать проблемы блокировки:

select waiting_session, holding_session, lock_type, mode_held, mode_requested

from dba_waiters

/

Дополнительную информацию о блокировках позволяют получить другие представления. Они отобра­жают следующую информацию:

DBA_BLOCKERS Сеансы, которые заставили другие сеансы ждать блокировок, а сами не

находятся в состоянии ожидания DBA_DDL_LOCKS Блокировки DDL, полученные и затребованные в базе данных DBA_DML_LOCKS Блокировки DML, полученные и затребованные в базе данных DBAJLOCKS Все блокировки, полученные и затребованные в базе данных

DBA_WAITERS Сеансы, ожидающие блокировок базы данных, и сеансы, владеющие в

настоящее время этими блокировками V$ACCESS Заблокированные объекты базы данных и сеансы, которые к ним обращаются VSLOCK Блокировки базы данных V$SESSION_WAIT Сеансы базы данных, которые находятся в состоянии ожидания

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

Выводы

Чтобы улучшить производительность СУБД Oracle, необходимо подробно изучить все процессы происходящие в системе ПРИЛОЖЕНИЕ<->CУБД – изучить статистику, предоставляемую RDBMS, найти узкие звенья системы и попытаться их устранить. В настоящей работе были рассмотрены основополагающие понятия настройки производитель­ности. Было показано, как измерять и анализировать характеристики памяти и дискового пространства в целях устранения конкуренции. Были представлены рекомендации и сценарии, применимые для проверки производительности базы данных.

Как было показано, задача оптимизации работы базы данных не сводится к простому выводу всех статистических показателей и определения слабых звеньев. Это многогранная задача, решение которой необходимо в будущем возложить на ЭВМ. Необходимы программные средства, которые будут моделировать производительность СУБД, исходя из характеристик операционной системы, над которой надстроено ядро базы данных, и настроек самой базы данных. Основной инструмент, которым оперирует СУБД, является запрос. Поэтому нельзя не учитывать схему выполнения каждого отдельного запроса, которая практически для любого запроса является уникальной. Рассмотрению базовых топологий выполнения запросов из которых, как из кубиков состоит схема выполнения реального запроса, будет посвящена вторая часть данной работы.

СПИСОК ЛИТЕРАТУРЫ

1. Стив Бобровски.«Oracle8. Архитектура». Издательство «Лори», Москва, 1999.

2. «Oracle8. Внутренний мир» Издательство «DiaSoft», 2000

3. Сопроводительная документация к продуктам Oracle:

   • Oracle Installation and Configuration Guide

   • Oracle8 Server Utilities Guide

Приложение 2. Реферат на тему:

Оптимизация запросов в реляционных базах данных

Введение

Одной из наиболее ответственных задач, решаемых при создании автоматизированных информационных систем является оптимизация поисковых операций при работе с реляционными базами данных большой размерности. Поисковые операции или, иначе говоря, запросы к БД являются, по сути, композицией из различных "простейших" операций: сортировки (внешней), последовательного сканирования, индексного сканирования и различных методов соединения.

Анализ потоков данных, поступающих на вход автоматизированной системы управления, и потока результирующих данных позволяет оценить различные аспекты деятельности организации. Характер анализа поисковых операций и формируемых отчетных форм определяется спецификой деятельности той или иной службы. Это может быть контроль эффективности выбранного плана (стоимостная оценка), оценка эффективности алгоритма перебора планов, контроль точности метода оценки. Таким образом, возникает потребность в автоматизированной системе генерации пространства планов выполнения запросов к БД и метода оценки ресурсов, требуемых для выполнения планов, а также алгоритма перебора пространства возможных планов . В связи с этим одной из важнейших задач, возникающих при создании такой системы, является задача выбора метода перебора планов в зависимости от ресурсов, предоставляемых для выполнения плана.

Двумя ключевыми подкомпонентами компонента вычисления запросов в SQL-ориентированной системе баз данных являются оптимизатор запросов и подсистема выполнения запросов.

Характеристики

Список файлов домашнего задания