Базы данных Oracle - статьи
Миф о коэффициенте попаданий в библиотечный кеш
Низкие статистики (не превышающие 99%) коэффициентов попаданий в библиотечный кеш или кеш словаря данных являются симптомом плохой производительности при работе с областью разделяемого пула, которая может быть повышена путем увеличения размера разделяемого пула.
Факт
Хорошо, давайте сначала зададим вопрос: что заставляет вас думать, что с разделяемым пулом есть проблемы? "Откопали" вы какие-либо события ожидания, связанные с разделяемым пулом? Обнаружили вы какую-либо конкуренцию за различные защелки, используемые в библиотечном кеше? Просто увеличение размера разделяемого пула произвольным образом вряд ли разрешит какие-либо проблемы производительности, связанные с этим пулом. Заметим, что позитивный эффект большего размера разделяемого пула (сверх определенного размера, зависящего от приложений) будет заметен только на протяжении короткого периода после запуска экземпляра. Кроме этого, чем больше памяти вы выделите области разделяемого пула, тем больше вероятность увеличения потребления времени ЦП, затрачиваемого на управление этим кешем, и больше шансов, что процессы будут удерживать защелки более продолжительное время, создавая таким образом конкуренцию за доступ к разделяемому пулу. Если вы продолжите действовать в такой же манере, выделяя все больше и больше памяти, вы, в конечном счете, существенно подорвете производительность.
Как почти со всеми проблемами производительности, только выделение дополнительных ресурсов (в данном случае, дополнительной памяти для области разделяемого пула) дает немногим больше, чем откладывание решения проблемы на будущее. А в некоторых случаях добавление памяти может создать другие проблемы производительности, которые вы не предвидели. Вы должны понимать, что большинство проблем разделяемого пула связано с характером доступа к этой структуре памяти, кроме того, с отсутствием осмысленного и упреждающего сопровождения пространства в этой структуре.
Помимо всего прочего, важное значение имеют: устранение полных разборов (hard parses) - в Oracle 8.1.7 и выше рекомендуется устанавливать CURSOR_SHARING = FORCE, уменьшение количества частичных разборов (soft parses) соответствующей установкой параметра SESSION_CACHED_CURSORS, разделение больших и маленьких операторов SQL с использованием резервной области разделяемого пула, идентификация часто используемого хранимого SQL (пакеты, процедуры, функции). В равной степени критично выделение адекватного пространства для области большого пула, используемой для обеспечения работы Recovery Manager (RMAN), Parallel Query, Java и Oracle multithreaded server (MTS). В число лучших методов организации сопровождения этой структуры памяти входят: увеличение повторного использования операторов SQL, уменьшение количества полных разборов, уменьшение количества частичных разборов (путем кеширования курсоров в сеансах), сопровождение пространства различных пулов (shared (разделяемого), large (большого), java). Все это поможет снизить конкуренцию и обеспечить соответствующую производительность.
