Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

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

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Почему снижение нагрузки так полезно


Очевидно, что исключение бесполезной работы в первую очередь ска­зывается на производительности приложения, выполнявшего ее пре­жде. Однако не все осознают огромный сопутствующий эффект от сни­жения нагрузки. Избавляясь от лишнего запроса к ресурсу, мы уменьшаем вероятность образования очереди из остальных пользователей к этому ресурсу. Понять дополнительную выгоду от снижения нагруз­ки довольно просто. Представьте себе программу, использующую про­цессор почти без перерывов в течение примерно 14 часов (профиль ре­сурсов такой программы приведен в примере 1.4). Пусть эффектив­ность программы увеличилась настолько, что теперь ей требуется все­го десять минут процессорного времени. (Такое улучшение обычно достигается работой с планом выполнения критических команд SQL.)
Понятно, почему будет доволен пользователь отчета, выполняемого те­перь за десять минут вместо четырнадцати часов. Но представьте себе и радость остальных пользователей, которых тоже коснулось это улуч­шение. До улучшения пользователи, претендовавшие на время процес­сора, конкурировали с процессом, занимавшим его больше половины су­ток. Теперь же отчет претендует лишь на десять минут процессорного времени. Вероятность образования очереди на обслуживание процессо­ром уменьшилась во много раз. При таком 14-часовом периоде выгода для системы сопоставима с эффектом от установки второго процессора.
В описанном случае преимущество от сокращения нагрузки на самом деле будет даже больше, чем от дополнительного про­цессора, т. к. второй процессор потребует от операционной сис­темы дополнительных действий по диспетчеризации процессор­ного времени. Кроме того, уменьшение нагрузки обойдется де­шевле, чем установка второго процессора.
Сопутствующая выгода от уменьшения нагрузки может быть ошелом­ляющей. Математически это обосновано в главе 9.
Запросы и услуги в технологическом стеке
Как же исключить бесполезную нагрузку? Ответ зависит от уровня технологического стека. Понятие технологического стека системы было введено в главе 1, когда рассматривалось представление времени отклика пользовательской операции при помощи диаграммы последовательности. Технологический стек состоит из взаимодействующих друг с другом уровней, выступающих в роли поставщиков и потреби­телей, как показано на рис. 10.1. Отношения между ними просты.
Такое представление технологического стека помогает понять фунда­ментальную аксиому повышения производительности:
Почти всегда проблемы производительности бывают вызваны чрезмерны­ми запросами к одному или нескольким ресурсам.
Практически в любом случае ухудшение производительности может быть устранено за счет уменьшения потребности в некотором ресурсе. Эта задача сокращения решается проходом «вверх» по технологиче­скому стеку от перегруженного устройства. (Направление вверх в сте­ке соответствует направлению влево на диаграмме последовательности на рис. 10.1) Вопрос, которым следует задаться, занимаясь повышени­ем производительности, звучит так:
Действительно ли оправдан столь высокий спрос на данный ресурс?
Рассмотрим профиль ресурсов, приведенный в примере 10.3. Без ма­лого 97% времени отклика исследуемой пользовательской операции, составляющего 1,3 часа, расходуется на ожидание дискового ввода/ вывода. Согласно профилю ресурсов, возможны два решения:
Уменьшить количество вызовов, сделав так, чтобы оно не превыша­ло 12165.
Уменьшить среднюю длительность вызова, сделав так, чтобы она не превышала 0,374109 секунды.
Учтите, что улучшение любого из этих показателей линейно сказыва­ется на вкладе данного компонента в значение времени отклика. Если, например, уменьшить количество вызовов вдвое, то и длительность уменьшится вдвое. Аналогично, если сократить вдвое среднюю продолжительность вызова, длительность также уменьшится вдвое. Не­смотря на то, что сокращение количества вызовов и их продолжитель­ности одинаково сказывается на результирующем значении, обычно бывает значительно легче добиться существенного уменьшения коли­чества вызовов, чем снизить их среднюю продолжительность. Я специ­ально выбрал для этой книги такую последовательность столбцов про­филя ресурсов, чтобы лучшее решение первым бросалось в глаза.
Пример 10.3. Во времени отклика выбранной пользовательской операции доминируют вызовы чтения подсистемы дискового ввода/вывода

Response Time Component
Duration
# Calls
Dur/Call
db file scattered read
4,551.0s
96.9%
12,165
0.374109s
CPU service
78.5s
1.7%
215
0.365023s
db file sequential read
64.9s
1.4%
684
0.094883s
SQL*Net message from client
0.1s
0.0%
68
0.001324s
log file sync
0.0s
0.0%
4
0.010000s
SQL*Net message to client
0.0s
0.0%
68
0.000000s
latch free
0.0s
0.0%
1
0.000000s
Total
4,694.5s
100.0%


Как исключить вызовы
Как уменьшить количество событий, выполняемых пользовательской операцией? Во-первых, выясните, что именно делает потребляемый ре­сурс. Что заставляет процесс Oracle, профиль которого приведен в при­мере 10.3, выполнять 12 165 вызовов многоблочного чтения? Затем выясните, можно ли обеспечить требуемую функциональность мень­шим числом обращений к ресурсу. В главе 11 объясняется, как это сделать для нескольких часто встречающихся событий Oracle. Опреде­лите, можно ли ограничить потребность в перегруженном ресурсе, пройдя по всем уровням технологического стека. Например:
Многие аналитики полагают, что, увеличивая размер кэша буферов базы данных (т. е. выделяя больше памяти системе Oracle), они уменьшают вероятность обращения к дисковым устройствам, вы­полняемого вслед за просмотром памяти.
Однако поднявшись чуть выше по стеку, часто можно достичь го­раздо лучших результатов, и не прибегая к увеличению объема па­мяти в системе. Оптимизируя план выполнения, следуя которому запрос извлекает строки из базы данных, часто удается избавиться даже от обращений к памяти.
Поднявшись по стеку еще выше, можно обнаружить еще более про­стые пути достижения результата. Например, может выясниться, что данная пользовательская операция может выполняться реже или не выполняться вообще (возможно, ее удастся чем-нибудь заме­нить), и это никак не скажется на ценности системы для бизнеса.

 



jAntivirus