Основні напрями налаштування: що є критичним для електронного бізнесу, HTML, XML, DHTML, Інтернет-технології, статті

Якщо Ви рухаєтеся у бік інтерактивного бізнесу, постійно Вашої уваги повинні бути ці найбільш загальні напрямки настройки.


У традиційній архітектурі клієнт / сервер на погано налаштованої базі даних прикладні програми можуть виконуватися повільно, але в середовищі Web ці ж програми можуть не виконуватися зовсім. Уявіть, наприклад, що ви дозволили замовникам або клієнтам робити запити до бази даних через ваш Web-сайт. Додаток, який раніше було доступно лише небагатьом користувачам вашої установи, тепер раптово стало доступно, скажімо, тисячам ваших замовників. Тим не менше, коли ви переводите ваші ділові дії на Web, основні принципи настроювання бази даних залишаються тими ж самими, незалежно від того, як буде зростати кількість запитів до вашої базі даних (нехай навіть по експоненті). Природно, багато пов'язаних з ефективністю проблем є характерними тільки для кожної конкретної системи, але я виявив, що якщо при налаштуванні постійно мати на увазі такі чотири напрями, це допоможе швидко і просто поліпшити продуктивність системи:



У цій статті будуть обговорюватися перші три напрями. Налаштування проблемних запитів – це окрема тема, і про неї піде мова в следующейs статті.


Правило 1. Виділення примірнику Oracle достатнього обсягу оперативної пам'яті


Виділення примірнику Oracle достатнього обсягу пам'яті є досить критичним. Необхідно мати достатню кількість пам'яті, щоб через її нестачі не доводилося очищати буферний кеш від використовуваних даних, але все-таки не настільки багато, щоб це знижувало загальну продуктивність системи. У файлі init.ora є багато параметрів, деякі з яких можна використовувати для розподілу пам'яті вашої базі даних. Нижче наведені найбільш важливі для управління розподілом пам'яті параметри:

 DB_BLOCK_BUFFERS і DB_BLOCK_SIZE
SHARED_POOL_SIZE
SORT_AREA_SIZE

Використовуйте наведений в лістингу 1 запит, щоб знайти поточні значення цих параметрів. Побачити значення цих параметрів ви можете також, використовуючи для цього кошти Oracle Enterprise Manager (OEM).


Лістинг 1. Знаходження встановлених значень основних параметрів настройки

select name, value from v$parameter

where name in (“db_block_buffers”, “db_block_size”,

“shared_pool_size”, “sort_area_size”);

NAME VALUE

——————————————————-

db_block_buffers 4000

db_block_size 4096

shared_pool_size 7000000

sort_area_size 262144


DB_BLOCK_BUFFERS і DB_BLOCK_SIZE


Параметр DB_BLOCK_BUFFERS управляє системної глобальної областю (SGA), яку сервер бази даних Oracle використовує для зберігання та обробки даних у пам'яті. Коли споживачі запитують дані, сервер поміщає їх у пам'ять, так, щоб при наступних запитах користувача (або користувача процесу) забезпечити швидший доступ до них. Якщо значення параметра DB_BLOCK_BUFFERS занадто мало, то сервер занадто рано скине на диск найстаріші з наявних в пам'яті даних. А це означає, що коли ці дані будуть потрібні в наступний раз, серверу доведеться зчитувати їх з диска, а не брати в оперативній пам'яті. Якщо ж значення параметра DB_BLOCK_BUFFERS занадто велике, вашій системі може не вистачити пам'яті для ефективного функціонування.


Ви можете з'ясувати, наскільки ефективна настройка параметра DB_BLOCK_BUFFERS, вимірюючи коефіцієнт попадань (hit ratio), значення якого говорить вам, яка частина даних, до яких здійснюють доступ споживачі, знаходиться в пам'яті. Щоб знайти його, ви можете використовувати запит, наведений у лістингу 2. (Для графічного представлення цих даних, ви можете використовувати модуль OEM Performance Manager.)


Лістинг 2. Знаходження коефіцієнта попадання з читання (read hit ratio).


select 1-(sum(decode(name, “physical reads”, value,0))/

(sum(decode(name, “db block gets”, value,0)) +

(Sum (decode (name, "consistent gets", value, 0 ))))) * 100 "Read Hit Ratio"

from v$sysstat;

Read Hit Ratio

————–

98.415926


Я вважаю, що для коефіцієнта влучень цілком прийнятно значення 95 відсотків або вище. Якщо вийшло у вас значення нижче, ніж 95 відсотків, вам варто скорегувати значення DB_BLOCK_BUFFERS. Гарне емпіричне правило для визначення цього значення – призначити для DB_BLOCK_BUFFERS 25 відсотків доступної оперативної пам'яті, хоча конкретний вибір може залежати від розміру вашої системи, обсягу доступної пам'яті і числа споживачів.


На додаток до коректування числа блоків даних, які сервер зберігає в пам'яті, ви можете змінити розмір цих блоків, регулюючи налаштування параметра DB_BLOCK_SIZE. Цей параметр керує кількістю даних, які база даних може вважати в пам'ять протягом однієї транзакції введення / виводу. При роботі з Oracle8, ви можете встановити це значення рівним 32Кбайт (в попередніх версіях Oracle тільки 16Кбайтам), але ви повинні реорганізувати базу даних, щоб значення параметра було змінено. Перш, ніж змінити цей параметр, загляньте в керівництва по налаштуванню і адмініструванню бази даних Oracle.


[Прим. редактора: Зверніть особливу увагу, що автор все ж говорить про необхідність реорганізувати базу даних, якщо Ви захочете змінити параметр DB_BLOCK_SIZE.]


SHARED_POOL_SIZE


Параметр SHARED_POOL_ SIZE управляє обсягом пам'яті, розподіленим для кешування бібліотеки і словника даних. Ви можете з'ясувати, наскільки ефективна настройка цього параметра, таким же чином, як і для параметра DB_BLOCK_BUFFER_SIZE – вимірюючи коефіцієнт попадань. Коефіцієнт влучень можна вимірювати окремо для бібліотеки та для словника даних.


Коефіцієнт влучень для бібліотеки вказує, який відсоток пам'яті сервер використовує для операторів і об'єктів PL / SQL, наприклад, процедур, пакетів, і тригерів. На додаток до обчислення відсотка удач (Див. Листинг 2), Ви повинні також дослідити значення стовпець RELOAD в поданні v $ librarycache.


Перезавантаженнями називаються оператори, які були розміщені в пам'яті, але які довелося перезавантажити після того, як сервер видалив їх звідти. Якщо у вас коефіцієнт попадань менше, ніж 95 відсотків, або число перезавантажень більше нуля, вам слід збільшити значення SHARED_POOL_SIZE.


Коефіцієнт влучень для словника даних вказує на розподіл пам'яті для словника даних Oracle. Природно, повний словник не може постійно знаходитися в пам'яті, але розмір словникового кешу важливий, тому що база даних багаторазово звертається до словника під час обробки операторів SQL. Щоб знайти відсоток удач для словника, ви можете використовувати наступний запит:

   select (1-(sum(getmisses)/sum(gets))) * 100 “Hit Ratio”
from v$rowcache;

коефіцієнт попадань ———- 95.40%


Нагадаю ще раз: добре, якщо отримане значення 95 або вище. Якщо отримане вами значення менше 95 відсотків, варто подумати про збільшення значення SHARED_POOL_SIZE.


Ви можете використовувати наведений в лістингу 1 запит, щоб з'ясувати, скільки вільної пам'яті стає доступною для використовуваного значення SHARED_POOL_SIZE. Кількість вільної пам'яті – ще один індикатор того, чи є значення SHARED_POOL_SIZE оптимальним.


SORT_AREA_SIZE


Параметр SORT_AREA_SIZE розподіляє пам'ять для сортування. Число байтів, яке ви розподіляєте для цього параметра, управляє обсягом пам'яті, виділеної для сортування кожному користувачеві. Якщо сервер не може виконати сортування в пам'яті, він розподіляє на диску тимчасові сегменти для зберігання проміжних результатів виконання, що збільшує число операцій введення / виводу. Ви повинні встановити досить високе значення цього параметра, щоб запобігти постійне породження тимчасових сегментів, і в той же самий час залишити достатньо пам'яті для інших процесів.


У поданні V $ systat містяться відомості про відсоток сортувань, які виконуються сервером в оперативній пам'яті і з використанням дискової пам'яті. Щоб знайти відсоток сортувань, які виконуються в пам'яті, я використовую запит з лістингу 2. Якщо цей відсоток менше, ніж 90, ви повинні розглянути питання про збільшення значення SORT_AREA_SIZE.


Правило 2. Зберігання в оперативній пам'яті потрібних даних


Після того, як ви розподілили примірнику сервера Oracle оптимальний обсяг пам'яті, ви повинні бути впевнені, що найбільш важливі дані залишаються в пам'яті. Ви можете "закріпити" в пам'яті (pin) основні таблиці, об'єкти PL / SQL і пакети, щоб уникнути скидання їх сервером на диск.


Закріплення таблиць


Якщо ви послідовно виконайте один і той самий запит два або більше разів, ви зверніть увагу, що другий (і подальші) запити виконуються швидше, ніж перший. Справа в тому, що початковий запит переміщує дані таблиці в буфера даних в пам'яті, де вони залишаються, поки не будуть виштовхнуті іншими даними з інших таблиць, використовуваних для відповіді на інші запити. Щоб зберегти конкретну таблицю в пам'яті, ви повинні закріпити її в кеші. Це варто робити лише з малими таблицями, які знаходяться в постійному використанні.


Якщо ви виявили, що сервер виштовхує основні таблиці з пам'яті, ви можете закріпити їх у пам'яті, використовуючи параметр CACHE оператора CREATE / ALTER TABLE:

ALTER TABLE [TABLENAME] CACHE;
Table altered.

Цей параметр гарантує, що дані з таблиці після повного її сканування знаходяться в списку найбільш недавно використаних (most recently used – MRU) даних, а не в списку найбільш давно використаних (Least recently used – LRU) даних, в результаті чого вони будуть збережені в пам'яті для подальшого використання. При створенні таблиці значення параметра за замовчуванням – NOCACHE. Тому для того, щоб кешувати таблицю при першому ж до неї доступ, потрібно використовувати наступний синтаксис:

   CREATE TABLE TEST_TAB (COL1 NUMBER)
TABLESPACE USERS
CACHE;

Можете також використовувати в запиті підказку CACHE, щоб закріпити таблицю і зберігати її в кеші, починаючи з першого її використання, а саме:

   SELECT /*+ CACHE(CUST) */ ENAME, JOB
FROM CUST
WHERE TABLE_NAME = “EMP”;

Перед закріпленням таблиць в пам'яті слід з'ясувати, скільки пам'яті все ще залишається вільною, щоб можна було врахувати непередбачені запити. Корисно проводити перевірку того, чи достатньо пам'яті розподілено для даних після того, як система опрацює більшу частину дня. Щоб з'ясовувати, скільки пам'яті доступно для даних у будь-який момент часу, виконайте наступний запит до таблиці x $ bh (щоб мати можливість звернутися до таблиць x $, ви повинні увійти в систему як SYS, або створити представлення таблиць, а потім створити привілеї для цих уявлень):


select decode(state,0, “FREE”, 1, decode
(lrba_seq,0,”AVAILABLE”,”BEING USED”),
3, “BEING USED”, state) “BLOCK STATUS”,
count (*)
from x$bh
group by decode(state,0,”FREE”,1, decode
(lrba_seq,0,”AVAILABLE”,”BEING USED”),
3, “BEING USED”, state);
select decode(state,0, “FREE”, 1, decode
(lrba_seq,0,”AVAILABLE”,”BEING USED”),
3, “BEING USED”, state) “BLOCK STATUS”,
count (*)
from x$bh
group by decode(state,0,”FREE”,1, decode
(lrba_seq,0,”AVAILABLE”,”BEING USED”),
3, “BEING USED”, state);

Якщо в перші 30 хвилин після запуску системи виявиться, що немає вільних буферів, вам, можливо, доведеться повернутися до першого правилом і збільшити значення DB_BLOCK_BUFFERS.


Закріплення в пам'яті об'єктів та пакетів


Якщо Ви не можете підтримувати задовільну настройку для SHARED_POOL_SIZE, може виявитися важливо зберігати закріпленими в пам'яті найбільш часто використовувані об'єкти. Ви можете закріплювати оператори об'єкта PL / SQL в пам'яті, використовуючи процедуру DBMS_SHARED_POOL.KEEP, наприклад, наступним чином:


BEGIN
DBMS_SHARED_POOL.KEEP(“PROCESS_DATE”,”P”);
END;

Ви можете також закріпити деякі або всі пакети, використовуючи деякі вбудовані пакети Oracle типу STANDARD, DBMS_STANDARD і DIUTIL.


Щоб закріпити всі пакунки вашої системи, ви можете використовувати скрипт з лістингу 3.


Лістинг 3. Закріплення всіх пакетів в кеші.

declare 

own varchar2(100);

nam varchar2(100);

cursor pkgs is

select owner, object_name

from dba_objects

where object_type = “PACKAGE”;

begin

open pkgs;

loop

fetch pkgs into own, nam;

exit when pkgs%notfound;

dbms_shared_pool.keep(own // “.” // nam, “P”);

end loop;

end;


Правило 3. Знаходження проблемних запитів


Один-єдиний індекс або запит можуть загальмувати або навіть зовсім припинити роботу всієї системи. Запитуючи v $ sqlarea, ви можете виявити запити, які створюють проблеми для системи. Проблемні запити – Це такі запити, для яких потрібно найбільша кількість фізичних або логічних операцій читання з диска.


Виявлення запитів, для яких потрібно найбільша кількість фізичних операцій читання з диска


В лістингу 4 наводиться запит для виявлення таких запитів, для виконання яких потрібно більше 10000 операцій читання з диска. Для систем більшого розміру вам може знадобитися збільшити цей поріг.


Лістинг 4. Пошук запитів, які вииполняют більше 10,000 дискових читань.

select disk_reads, sql_text

from v$sqlarea

where disk_reads > 10000

order by disk_reads desc;

DISK_READS SQL_TEXT

———- ——————————

12987 select order#,columns,types from orders

where substr(orderid,1,2)=:1

11131 select custid, city from customer

where city = “CHICAGO”

Вихідні дані прикладу вказують на те, що велика кількість операцій читання з диска викликають два запити. Проблема з першим запитом полягає в тому, що індекс за стовпцем orderid пригнічений функцією SUBSTR. Проблема з другим запитом – відсутність індексу для стовпця city.


Виявлення запитів, для яких потрібно найбільшу кількість логічних операцій читання з диска


В лістингу 5 наводиться запит для виявлення таких запитів, для виконання яких потрібно більше 200000 операцій читання в оперативній пам'яті. І знову, якщо ваша система велика, вам може знадобитися збільшити цей поріг.


Лістинг 5. Пошук запитів, які виконають більш ніж 200,000 логічних читань.

select buffer_gets, sql_text

from v$sqlarea

where buffer_gets > 200000

order by buffer_gets desc;

BUFFER_GETS SQL_TEXT

——————————————–

300219 select order#,cust_no, from orders

where division = “1”


Вихідні дані прикладу вказують на те, що проблему створює індекс за стовпцем division, коли в компанії є тільки два відділи. Щоб покращити продуктивність, потрібно або відмовитися від цього індексу, або створити його, як двійковий (bitmap) – це повинно допомогти.


Зауважте, що подання v $ sqltext відображає тільки обмежену частину SQL_TEXT. У разі прикладів в лістингах 4 і

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Метки: , , , , , ,
Рубрики: DHTML, HTML, XML

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*