В загруженной системе, если все процессы ожидают ресурсов, может оказа­ться, что они ждут один и тот же ресурс чаще, чем мы себе это представляем. Это и есть конкуренция. Как было описано в главе "Метод, стоящий за безуми­ем", при столкновении с проблемами производительности Oracle мы должны сделать первой линией обороны представления V$SYSTEMEVENT, V$SESSION_EVENT и V$SESSION_WAIT. Комбинированная информация, пред­лагаемая этими представлениями, снабжает нас сведениями о различных типах конкуренции, связанных с защелками, вводом/выводом, структурами SGA или буферами базы данных (если не упоминать обо всех остальных). Идя рука об ру­ку с этими представлениями, мы должны отследить операторы SQL, вызываю­щие конкуренцию. Помимо всех тех динамических представлений производительности V$, которые обсуждались в упомянутой главе, мы хотим поближе познакомить читателей с представлением V$WAITSTAT. Оно будет по­лезным при проверке статистики для конкуренции.

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

списков свободных блоков 

(freelists) в главе "Настройка

базы 

данных". Здесь мы также коснемся вопроса, как некоторые сложности при­ложения, связанные с системными вопросами, могут вызвать у пользователей ложное ощущение проблем конкуренции. Это те самые области, которые АБД способен проверить и настроить. Относительно проще иметь дело с временными сегментами и сегментами отката. Мы познакомимся с такими динамическими представлениями производительности, как V$ROLLSTAT, V$SORT_SEGMENT и V$SORT USAGE.

Однако в Oracle 7.3.x имеется более 50 защелок, а в Oracle8i их около 150.
Только очень небольшую их часть можно изменять пользователю, а может быть,
в этом и вовсе нет необходимости. Поэтому познакомьтесь с теми, которые по-
зволено изменять. Установите их на разрешенные максимальные значения, и
продолжим движение. Отсылаем читателя к динамическому представлению
производительности        за полным перечнем защелок в его систе-

ме, и предлагаем взглянуть на        чтобы определить, сколь-

ко всего защелок конфигурировано для каждого их типа.

Сегменты отката: почему, как и как много?

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

Многоверсионная согласованность по чтению

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

Грязные чтения - это данные, которые еще не зафиксированы. Только пред­ставьте себе, какой вред могут причинить грязные данные некоторым финансо­вым приложениям или приложениям из области здравоохранения. В Oracle, даже если изменения в данных были зафиксированы уже после того, как начал­ся запрос пользователя, вы по-прежнему будете видеть данные в том виде, в ка­ком они существовали в момент старта запроса. Однако, если сегменты отката не сконфигурированы должным образом и к тому времени, как данные будут за­фиксированы, запрос выполнялся уже длительное время, можно столкнуться с ошибкой, называемой "моментальный снимок слишком старый". Эта ошибка не имеет ничего общего с моментальными снимками состояния объектов Oracle. Мы познакомимся с ней очень близко. Но сначала давайте рассмотрим, как ис­пользуются сегменты отката и как создаются совместимые по чтению представ­ления данных.