12 вариант 2 (954078), страница 23

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

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

• Следите за такими параметрами базы данных, которые распространяются на каждого пользовате­ля, например SORT_AREA_SIZE. He устанавливайте их настолько высокими, чтобы они застави­ли систему начать страничный обмен и подкачку.

• Тщательно планируйте изменения. Помните пословицу: "Семь раз отмерь, один раз отрежь".

• Учитывайте изменения, влияющие на другие параметры. Например, изменение размера блока базы данных может повлиять на значения многих других параметров INIT.ORA и заставить экземпляр базы данных занять больше памяти, чем ожидалось.

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

Вопросы конкуренции (состязаний). Уменьшение вероятности отказа.

Администраторы базы данных часто игнорируют физические характеристики системы. Работая день за днем с логическими структурами, легко забыть о тех физических элементах, которые ее поддерживают, — о SCSI-адаптерах, пропускной способности или шинах ввода/вывода. Если не учитывать эти физические компоненты, в базе данных может возникнуть конкуренция.

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

Конкуренция ввода/вывода и уравновешивание нагрузки

Наиболее распространенным типом конкуренции является конкуренция между физическими устройства­ми памяти. Каждый дисковод имеет головки, которые передвигаются назад и вперед по магнитному но­сителю (диску) при чтении и записи информации. База данных состоит из нескольких физических файлов данных, которые часто находятся на одном и том же физическом диске, так что легко понять, почему может возникнуть конкуренция. Если база данных запрашивает доступ к нескольким файлам данных на одном и том же диске, возникает конкуренция, поскольку головки дисковода должны продвинуться по диску к первому участку и обратиться к файлу, затем — ко второму участку и т.д. К счастью, конкурен­цию ввода/вывода можно свести к минимуму.

Важно знать, какие существуют типы файлов базы данных и какого типа операции на них выполня­ются. Сопоставление типов файлов и операций приведено на' рис.2.

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

РИСУНОК 2. Файлы и доступ.

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

• Сегменты отката

• Журналы обновлений

• Архивные журналы

Эти файлы распределяются так, чтобы доступ к этим областям не конкурировал с доступом к дру­гим файлам, таким как файлы базы данных и управляющий файл. Важно оптимизировать физическую ком­поновку, чтобы конкуренция между процессами ARCH, DBWR и LGWR была минимальной. В связи с большим объемом информации, вырабатываемой при каждой транзакции, обычно лучше всего размещать сегменты отката на отдельном диске.

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

Разделение таблиц и индексов — это первый шаг достижения эффективной пропускной способности и уменьшения конкуренции ввода/вывода, но его вряд ли будет достаточно для обеспечения оптималь­ной производительности. Необходимо выяснить, доступ к каким файлам базы данных происходит наибо­лее часто, и распределить их по дискам для уравновешивания нагрузки. Выдав следующий запрос в качестве пользователя SYS или другого пользователя, имеющего доступ к представлениям V$, можно определить текущую нагрузку ввода/вывода файлов базы данных. Эти показания нужно снять несколько раз в тече­ние определенного времени для получения точной статистики. Например;

SQL> select d.name, f.phyrds, f.phywrts

2 from v$datafile d, v$filestat f

3 where d.filet = f.file»

1. /

РИСУНОК 3. Разделение таблицы и индекса

К сожалению, до создания базы данных трудно определить, какова будет нагрузка дисков. По этой при­чине, обнаружив значительную конкуренцию на одном из дисков, переместите файл базы данных. Ис­пользуйте команду alter database rename на смонтированном, но не запущенном экземпляре базы данных. Это позволит оптимально распределить нагрузку на дисководы.

Существуют также ситуации, когда ключевые файлы базы данных выполняют большую часть ввода/ вывода Перемещение их на другой диск может оказаться невозможным или не будет наилучшим реше­нием Для таких ситуаций в Oracle предусмотрена полосовая организация — разбиение одного большого файла базы данных на несколько меньших фрагментов, которые могут быть распределены по дисководам. На­пример

SVRMGR> create tablespace dba_ts

2> datafile '/иОЗ/oradata/norm/dbatsOl.dbf size 50M,

3> '/u05/oradata/norm/dbats02.dbf size 50M,

4> '/u07/oradata/norm/dbats03.dbf' size 50M,

5> '/u09/oradata/norm/dbats04.dbf size 50M

б> /

Statement processed.

Распределив табличное пространство по нескольким файлам базы данных на нескольких дисках, вы разбиваете его на полосы и размещаете на каждом диске полосу данных размером 50 Мб. Полосовая организация позволяет базе данных распределить данные по дискам и ускоряет доступ ввода/вывода, сводя к минимуму конкуренцию за дисководы.

Конкуренция за сегменты отката

Одним из средств базы данных Oracle является ее способность отменять или выполнять откат изме­нений, не зафиксированных в базе данных. Иными словами, транзакции, физически изменяющие данные базы данных, — операторы INSERT, UPDATE или DELETE SQL — вырабатывают информацию, которую Oracle записывает в свои оперативные сегменты отката. Многие администраторы базы данных забы­вают о том, что Oracle, пытаясь обеспечить непротиворечивость данных при выполнении запроса с оператором SELECT при обращении к данным, использует сегменты отката. Если при выполнении зап­роса какая-то строка была изменена, но не зафиксирована, RDBMS Oracle возвращает информацию из сегментов отката для обеспечения непротиворечивости чтения. Сегменты отката используются также пос­ле принудительного останова экземпляра или аварийного завершения.

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

select r.name, s.gets, s.waits

from v$rollstat s, v$rollname r where s.usn = r.usn

/

Следующее отношение позволяет сравнить, как часто происходил доступ к сегменту отката и как часто базе данных приходилось ждать доступа к информации в сегменте отката:

ratio = ( waits/gets ) * 100

Если результат больше или равен 2, в сегментах отката существует конкуренция. Создайте дополнитель­ные сегменты отката, что позволит уменьшить вероятность одновременного обращения транзакций в одни и те же блоки сегмента отката. Это уменьшает конкуренцию, но устранить ее полностью не может. Ниже приведены некоторые рекомендации по расчету числа сегментов отката:

• Если число одновременных транзакций не превышает 16, используйте четыре сегмента отката.

• Если число одновременных транзакций меньше 32, но не меньше 16, используйте восемь сегмен­тов отката.

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

Необходимо также определить размеры сегментов отката. Это не так сложно, поскольку нужно учитывать только две среды: OLTP и среду, отличную от OLTP. Среда OLTP (online transaction processing — инте­рактивная обработка транзакций) отличается большим объемом транзакций базы данных, выполняемых пользователями, как, например, в системе ввода заказов. Среда OLTP лучше работает с большим чис­лом небольших сегментов отката. Для среды, отличной от OLTP, назначьте более крупные сегменты от­ката, чтобы дольше сохранялись данные продолжительных транзакций и запросов. Допустимо смешивать большие и малые сегменты отката и явно указывать сегменты отката для использования.

Как и таблицы, сегменты отката ограничены максимальным размером экстента, в котором они могут расти, и объемом доступного физического пространства в табличном пространстве. После достижения этих пределов база данных не станет пользоваться новым сегментом отката. Поэтому, если размер сегмента от­ката или его табличного пространства выбран неправильно, может случиться так, что объем требуемого пространства отката будет превышать общий размер сегмента отката. Oracle рекомендует распределять 20-40 экстентов одинаковых размеров, где каждый экстент составляет по размеру от 0,25 до 0,5 процентов са­мой большой активной таблицы в базе данных. Кроме того, попытайтесь распределить сегменты отката по наибольшему числу дисков в целях максимального распределения ввода/вывода.

Конкуренция за журналы обновлений

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

Запросы защелки wait ожидают выполнения запроса, "засыпают", а затем снова выполняют запрос до тех пор, пока он не приобретет защелку. А запросы защелки immediate не ждут, они продолжают обра­ботку. Используйте следующий запрос для определения состояния защелок обоих типов:

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

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