Oracle Database 11g: головні нові можливості для DBA і розробників, Інші СУБД, Бази даних, статті

Завершуючи серію, в цій статті я розповім про деякі загальні можливості Oracle Database 11g, Які дуже вам сподобаються, коли ви про них дізнаєтеся.

Нові Процеси


Кожна нова версія Oracle Database приносить із собою новий набір процесів, нових їх абревіатур. Ось цей список для Oracle Database 11g Release 1:




















































Процес Ім’я Опис
ACMS Atomic Controlfile to Memory Server Застосуємо тільки для примірника RAC. Коли проводиться оновлення розподіленої SGA, процес ACMS гарантує, що це оновлення відбудеться на всіх примірниках. Якщо ж оновлення на одному з примірників не вдалося, процес забезпечує відкат на всіх примірниках. Процес ACMS можна представити як координатор двофазної фіксації (two-phase commit) для SGA в кластері RAC.
DBRM Database Resource Manager Менеджер Ресурсів Бази Даних реалізує ресурсні плани та інші завдання управління ресурсами.
DIA0 Diagnosibility process 0 Діагностують процесс0 виявляє зависання і взаємні блокування. З часом, можливо, таких процесів буде більше. Тому ім’я – dia0. Інші процеси, якщо вони з’являться в майбутньому, отримають назвнія dia1, dia2 і т.д.
DIAG Diagnosibility process Діагностують процес виконує діагностику, при необхідності скидає дані в трасові файли і виконує загальні команди утиліти oradebug.
FBDA Flashback Data Archiver Архіватор ретроспективних даних Oracle Database 11g містить нову функціональність “Flashback Archive” для запису змін, виконаних по відношенню до таблиці (див. статтю “Transactions Management” в цієї серії). Цей процес формує ретроспективні архіви.
GTX0 Global Transaction Process 0 Процес Глобальних Транзакцій0 – в кластері Oracle Database RAC надає поліпшену обробку XA-транзакцій. Він координує XA-транзакції. Якщо на базу даних зростає XA-навантаження, автоматично створюються додаткові процеси з іменами GTX1, GTX2, аж до GTXJ.
KATE Konductor (Conductor) of ASM Temporary Errands Провідник Тимчасових Завдань ASM Безсумнівно, краще ім’я з усіх нових процесів. Процес можна побачити тільки на ASM-примірниках, в базі даних його немає (зверніться до статті про ASM, і, зокрема, про нову функціональності Fast Disk Resync). Коли диск вимикається (offline), цей процес виконує посередницький I / O від імені диска в метафайл ASM.
MARK Mark AU for Resync Koordinator (coordinator) Зверніться до статті про ASM для отримання додаткової інформації про гнучкість дискових груп ASM. Якщо відбувається збій диска, він стає недоступним (offline), тим самим, запис стає неможливою. В цьому випадку процес MARK позначає одиниці простору ASM (AU) як неактуальні. Коли диск відновлює працездатність, неактуальні сегменти оновлюються.
SMCO Space Manager Менеджер Простору (SMCO) є головним процесом управління, який, динамічно додає і видаляє простір. Породжує дочірні процеси Wnnn для виконання завдань.
VKTM TiMe Virtual Keeper of TiMe process Віртуальний Зберігач Процесу надає собою еквівалент настінних годинників (з оновленням 1 раз в секунду). Працюючи з підвищеним пріоритетом, надає оновлення раз в 20 мілісекунд.
W000 Space Management Worker Processes Робочі Процеси Управління Простором – виконують інструкції, отриманий від SMCO. При необхідності породжується необхідну кількість процесів з іменами W000, W001 і т.д.


Підсвічений SQL


Ця нова можливість не розфарбовує SQL-пропозиції різними кольорами; навпаки, вона сортує і позначає їх по їх “важливості” (as “important”).


Уявімо ситуацію, що адміністратор досліджує проблему з продуктивністю і знаходить підозріле SQL-пропозиція, яка і є причиною проблеми. Тепер він хоче, щоб це SQL-пропозиція захоплювалося під час кожного знімка Automatic Workload Repository (AWR). Однак AWR-знімки не захоплюють все SQL-пропозиції підряд; тільки топові. Яким чином його примусити захопити конкретний SQL, незалежно, в топі він чи ні?


Процедура add_colored_sql () з пакету dbms_workload_repository позначає SQL, як “кольоровий” або достатньо важливий, щоб бути захопленим кожним AWR-знімком, незалежно, чи потрапляє цей запит в топ чи ні. Для початку, знайдемо SQL-пропозиція і отримаємо його SQL_ID. Для його маркування, використовуємо:

begin
dbms_workload_repository.add_colored_sql(
sql_id => “ff15115dvgukr”
);
end;

Для того щоб знайти, який SQL був помічений, звернемося до AWR-таблиці WRM $ _COLORED_SQL:

SQL> SELECT * FROM wrm$_colored_sql;
DBID SQL_ID OWNER CREATE_TI
———- ————- ———- ———
2965581158 ff15115dvgukr 1 05-APR-08

Це показує, що SQL-речення з ID ff15115dvgukr буде захоплюватися кожним знімком, навіть якщо воно не в топі SQL-пропозицій (звичайно, щоб бути захопленим AWR-знімком, це SQL-пропозиція повинна бути в бібліотечному кеші).


Але що робити, якщо SQL перестає бути цінним, тобто більше немає необхідності в його захопленні? Його можна виключити, викликавши протилежну процедуру:

begin
dbms_workload_repository.remove_colored_sql(
sql_id => “ff15115dvgukr”
);
end;

Ця можливість є надзвичайно зручною, коли потрібно сфокусуватися на конкретному SQL під час завдань по налаштуванню.


Стиснення Таблиць в OLTP


З давніх пір в тій чи іншій формі стиск було реалізовано як можливість Oracle Database.


Стиснення – завдання, завжди вимагає ресурсів CPU і займає час. Зазвичай, якщо дані стислі, їх необхідно розтиснути, щоб ними скористатися. У той час як ця вимога прийнятно в системах зберігання даних, де SQL зазвичай оперує з великим набором рядків і досить довгі відповіді в основному влаштовують користувачів, в OLTP-середовищах це може бути неприйнятно.


Тепер, в Oracle Database 11g, Можна зробити ось що:


create table my_compressed_table (
col1 number(20),
col2 varchar2(300),

)
compress for all operations

Пропозиція “compress for all operations” включає стиск на все DML-пропозиції, такі як INSERT, UPDATE і т.д. Стиснення відбуватиметься на будь DML-активності, а не тільки на direct path вставках як в попередніх релізах.


Чи буде це уповільнювати виконання DML-пропозиції? Не обов’язково. Ось де нова можливість працює кращим чином. Стиск не відбувається в момент, коли рядок вставляється в таблицю; рядок вставляється незжатий і в звичайному порядку. Коли певну кількість рядків вставлено (або оновлено) в стислому вигляді, в справу вступає алгоритм стиснення і стискає все стиснені рядка в блоці. Іншими словами, стиснутий блок, а не рядок. Поріг, після якого відбувається стиснення, визначено всередині коду бази даних.


Механіка Стиснення


Візьмемо таблицю ACCOUNTS, що містить рядки:


Уявімо, що всередині бази даних всі ці рядки зберігаються в одному блоці даних.


Ось так виглядає незжатий блок даних: записи з усіма даними всіх полів (стовпців). При стисненні блоку база даних спочатку визначає всі повторювані значення, знайдені в рядках, переміщує їх з рядків і поміщає поруч із заголовком блоку даних. Ці повторювані значення в рядках замінюються на символ, унікально визначає кожне з таких значень. Цей алгоритм концептуально зображений на ілюстрації нижче – блок до і після стиснення:


Зверніть увагу, як значення вилучені з рядків і вставлені в спеціальну область вгорі, звану “Symbol Table” (Таблиця Символів). Кожному значенню в стовпцях присвоєно символ, який заміщає реальне значення в рядку. Так як символи за розміром менше реальних значень, розмір запису істотно менше оригінально розміру. Чим більше повторюваних значень у рядку, тим більш компактною виходить таблиця символів і, отже, блок даних.


У зв’язку з тим, що стиснення відбувається подієво, а не під час вставки рядка, вплив на продуктивність дорівнює нулю під час звичайної DML-операції. Звичайно, коли виникає подія стиснення, вимоги до CPU підвищуються, але все інше час вплив на CPU нульове, тим самим роблячи стиснення прийнятним для OLTP-додатків – це головний факт для компресії в Oracle Database 11g.


Іншими важливими властивостями стиснення, крім зменшення споживання дискового простору, є зменшення часу передачі даних по мережі, зменшення місця для резервних копій і можливість реально оперувати повними копіями промислової бази даних для QA та тестування.


COPY живий!


Всупереч чуткам, команда COPY все ще тут. І вона все ще є єдиною можливістю копіювати дані типу LONG. Однак у зв’язку з тим, що ця команда є застарілою, вона не встигає за новітніми розробками в Oracle Database.


Наприклад, вона не знає про існування нового типу даних, званого BFILE. Якщо спробувати скопіювати таблицю DOCS, що містить стовпець BFILE, вийде ось що:

SQL> copy to sh@oradba11 –
&lgt; replace docs_may08 –
> using select * from docs
> where creation_dt between “1-may-08” and “31-may-08”;
Enter TO password:

Array fetch/bind size is 15. (arraysize is 15)
Will commit when done. (copycommit is 0)
Maximum long size is 80. (long is 80)

CPY-0012: Datatype cannot be copied


Повідомлення про помилку говорить сама за себе: команда COPY не може скопіювати дані типу BFILE. Однак у випадку з таблицею, яка містить стовпець типу LONG, не можна використовувати оператори INSERT / * + APPEND * / і CREATE TABLE … NOLOGGING AS SELECT … Ось приклад, де ми спробуємо скопіювати декілька рядків з однієї таблиці в іншу і при цьому один із стовпців буде типу LONG:

SQL>create table mytab1 as select * from mytab where col1 = “A”;
create table mytab1 as select * from mytab
*
ERROR at line 1:
ORA-00997: illegal use of LONG datatype

SQL> insert /*+ APPEND */ into mytab
2> select * from mytab where col1 = “A”;
select * from mytab
*
ERROR at line 2:
ORA-00997: illegal use of LONG datatype


Таким чином, єдиним простим способом скопіювати великий обсяг даних без заповнення undo-сегментів, є використання команди COPY.


Експорт і Імпорт


Коли в Oracle Database 10g з’явився механізм Data Pump, поступове старіння традиційних утиліт Export і Import було очікувано. Однак, не поспішайте: в Oracle Database 11g ці старі утиліти дуже потрібні. Будучи “знятими з виробництва”, не отримуючи ніякого розвитку, проте вони далекі від марності.


За кількістю можливостей Data Pump у багато разів випереджає звичайний Export / Import, проте в одному простому прикладі останній дуже корисний: коли необхідно створити дамп-файл на стороні клієнта, а не сервера. Немає потреби створювати директорію перед виконанням цієї операції, тому в більшості випадків простий експорт даних простіше виконати за допомогою стандартного Export / Import.


Проте, нагадую ще раз – ці утиліти більше не розвиваються, тому, використовуючи їх, існує три ризику:



Таким чином, має сенс переписати існуючий код на використання Data Pump, особливо в нових розробках.


Інкрементального Оновлювана Глобальна Статистика


У будь секціонірованние таблиці по кожній секції може зібрати статистику оптимізатора. До того ж існує глобальна статистика на всю таблицю, і вона не залежить від секцій, наприклад, кількість унікальних значень у всій таблиці. По-замовчуванню глобальна статистика не збирається – тільки в разі, якщо це робиться навмисне за допомогою процедур dbms_stats.gather_ * _stats. Якщо параметр global_stats не вказаний, вона не збирається, і оптимізатор отримує її з статистик секцій. Звичайно, зібрана глобальна статистика завжди набагато точніше, ніж отримана із секцій, тому завжди переважніше збирати їх обидві.


Однак, є одна проблема: коли дані в одній із секцій змінюються і при цьому інші секції залишаються без змін, глобальна статистика стає застарілою. Тому, процес пересбора статистики повинен пройти по всій таблиці для збору глобальної статистики, навіть якщо зміни відбулися лише в одній секції.


Більше цього не буде. В Oracle Database 11g з’явилася можливість вказати оптимізатору зібрати глобальну статистику інкрементального, просканувавши тільки змінилася секцію, тим самим уникнувши повного табличного сканування. Досягається це шляхом вказівки параметра INCREMENTAL в значення TRUE для таблиці під час збору статистики:

begin
dbms_stats.set_table_prefs(
“SH”,”SALES”,”INCREMENTAL”,”TRUE”);
end;
/

Зберемо статистику по таблиці, а конкретно – по секції SALES_1995 із зазначенням параметра granularity (зернистість) рівним AUTO:

begin
dbms_stats.gather_table_stats (
ownname => “SH”,
tabname => “SALES”,
partname => “SALES_1995”,
granularity => “AUTO”
);
end;

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


DataPump Стає Краще


Як я вже показував вище, починаючи з попереднього релізу бази даних, Data Pump є кращим інструментом для переміщення великих обсягів даних або ефективного отримання “логічних” резервних копій даних. Аналогічно утилітам Export / Import, Data Pump платформо-незалежний (наприклад, можна експортувати дані на Linux і імпортувати їх в Solaris). В Oracle Database 11g він отримав кілька удосконалень.


Одна з серйозних проблем з використанням Data Pump – неможливість стискування одержуваних файлів під час їх створення. У тих же старих утилітах Export / Import це робилося просто. В Oracle Database 11g Data Pump вміє стискати файли дампів під час їх створення. Досягається це зазначенням параметра COMPRESSION в командному рядку expdp. Параметр має три опції:



Ось приклад того, як стиснути експорт таблиці UNITS_FACT:

$ expdp global/global directory=dump_dir tables=units_fact
dumpfile=units_fact_comp.dmp compression=all

Для порівняння, експортуємо ту ж таблицю, але без стиснення:

$ expdp global/global directory=dump_dir tables=units_fact
dumpfile=units_fact_uncomp.dmp

Тепер порівняємо отримані файли:

$ ls -l
-rw-r—– 1 oracle dba 2576384 Jul 6 22:39 units_fact_comp.dmp
-rw-r—– 1 oracle dba 15728640 Jul 6 22:36 units_fact_uncomp.dmp

Розрахунок ступеня стиснення: 100 * (15728640-2576384) / 15728640 або близько 83.61%! Це дійсно вражає: незжатий файл займає 15 Мб, в той час як стиснений – 1.5 Мб.


Якщо стиснути експортний файл за допомогою gzip:

$ gzip units_factl_uncomp.dmp
-rw-r—– 1 oracle dba 3337043 Jul 6 22:36 units_fact_uncomp.dmp.gz

Стиснутий файл займає близько 3.2 Мб, що в два рази більше стиснення, отриманого за допомогою Data Pump. Таким чином, на додаток до потенційно більш ефективному стисненню, розархівування дійсно має сенс. Під час імпорту файлу дампа, процесу імпорту не потрібно спочатку розархівувати файл – це відбувається у міру читання, роблячи процес дійсно швидким.


І ще два удосконалення в Data Pump:



Почитати про ці можливості можна в статті з безпеки.


Дієва оперативна перебудова індексів


Пам’ятайте пропозицію ONLINE для перебудови індексу?

alter index in_tab_01 rebuild online;

Цей оператор перебудує індекс, не зачіпаючи DML-команди, що використовують його. Досягається це відстеженням, які блоки індексу використовуються, і в кінці роботи по перебудові індексу ці блоки об’єднуються з тільки що побудованим індексом. Для завершення цього завдання операція по перебудові індексу повинна отримати ексклюзивну блокування в кінці роботи. Незважаючи на те що вона дуже коротка, проте її не уникнути і DML-оператори будуть чекати.


В Oracle Database 11g online перебудова індексів дійсно online: вона не ставить ексклюзивну блокування. DML-команди не зачіпаються.


Різні Табличні Простору для Тимчасових Таблиць


Створюючи глобальну тимчасову таблицю, де відбувається виділення необхідного простору? Воно береться з тимчасового табличного простору користувача. Звичайно це не є проблемою, проте в деяких випадках буває необхідно звільнити тимчасове табличне простір від потреб, для яких воно призначається (сортування в основному). Іноді потрібно створити тимчасову таблицю в іншому табличному просторі, на більш швидких і ефективних дисках для прискорення доступу до даних. Іншого виходу немає, окрім як призначити це табличне простір тимчасовим табличним простором користувача.


В Oracle Database 11g можна використовувати інше тимчасове табличне простір для глобальних тимчасових таблиць. Подивимося, як це робиться. Для початку створюємо ще одне тимчасове табличне простір:

SQL> create temporary tablespace etl_temp
2> tempfile “+DG1/etl_temp_01.dbf”
3> size 1G;

Tablespace created.


Тепер створюємо GTT із зазначенням нового табличного простору:

SQL> create global temporary table data_load (
2> input_line varchar2 (2000)
3> )
4> on commit preserve rows
5> tablespace etl_temp;
Table created.

Все, ця тимчасова таблиця створена в табличному просторі ETL_TEMP замість табличного простору TEMP, призначеного користувачеві за замовчуванням.


Запис Помилок в SQL * Plus


Припустимо, є SQL-скрипт з ім’ям myscript.sql:

set puase on
set lines 132 pages 0 trimsppol on
select * from nonexistent_table
/

Зверніть увагу, скрипт містить кілька помилок: помилка в першому рядку в написанні “pause”, у другій сходинці помилка в написанні “trimspool” і, нарешті, третя сходинка містить вираз SELECT з таблиці, якої зовсім не існує. Запускаючи такий скрипт через командний рядок SQL * Plus, якщо висновок (spool) не включений, виявити помилку після роботи скрипта неможливо. Навіть у випадку, якщо висновок все ж був, необхідний доступ до віддаленого сервера для аналізу spool-файла, що не завжди можливо.


Oracle Database 11g пропонує ідеальне рішення: тепер є можливість фіксувати помилки, що йдуть з SQL * Plus, в спеціальній таблиці. Для цього необхідно першою командою видати:

SQL> set errorlogging on

Тепер запускаємо скрипт:

SQL> @myscript

Виконання скрипта сформує ось таке повідомлення про помилку:

SP2-0158: unknown SET option “puase”
SP2-0158: unknown SET option “trimsppol”
select * from nonexistent_table
*
ERROR at line 1:
ORA-00942: table or view does not exist

яке можна побачити, а можна і не побачити, залежно від того, яким способом був запущений скрипт – з командного рядка SQL * Plus, або в фоні, як виклик скрипта. Після того як скрипт відпрацював, авторизувавшись в базі даних, слід перевірити таблицю SPERRORLOG:

sql> col timestamp format a15
sql> col username format a15
sql> col script format a10
sql> col identifier format a15
sql> col statement format a20
sql> col message format a20
sql> select timestamp, username, script, statement, message
2> from sperrorlog;

TIMESTAMP USERNAME SCRIPT STATEMENT MESSAGE
————— ————— ———- ——————– ——————–
05-JUL-08 06.08 SH myscript.s set puase on SP2-0158: unknown SE
.41.000000 PM ql T option “puase”

05-JUL-08 06.08 SH myscript.s set lines 132 pages SP2-0158: unknown SE
.41.000000 PM ql 0 trimsppol on T option “trimsppol”

05-JUL-08 06.08 SH myscript.s select * from nonexi ORA-00942: table or
.41.000000 PM ql stent_table view does not exist


Зверніть увагу, перевірка помилок була виконана з іншої сесії, а не тієї, в якій скрипт був виконаний. До того ж, скрипт відпрацював і сесія так і так припинила існування. Таким чином, з’являється потужний засіб для перевірки помилок після того, як вони виникли в сесіях SQL * Plus, що іншим способом було неможливо, або, принаймні, складно.


Таблиця SPERRORLOG є спеціальною таблицею, створеної тільки для описаних цілей. Можна також створити свою власну таблицю і наповнювати її помилками SQL * Plus. Таблиця повинна бути створена так:

SQL> create table my_sperror_log
2 (
3 username varchar2(256),
4 timestamp timestamp,
5 script varchar2(1024),
6 identifier varchar(256),
7 message clob,
8 statement clob
9 )
10 /

Table created.


Тепер, замість таблиці за замовчуванням, можна використовувати цю таблицю для фіксування помилок.

SQL> set errorlogging on table sh.my_sperror_log;
SQL> @myscript

Тепер таблиця MY_ERROR_LOG (а не SPERRORLOG) буде зберігати журнал помилок. Для усічення всіх рядків у таблиці, виконаємо команду:

SQL> set errorlogging on truncate

Є також додатковий оператор IDENTIFIER, що дозволяє відзначати помилки з певних сесій. Припустимо, видана команда:

SQL> set errorlogging on identifier MYSESSION1

Тепер, запустивши скрипт, записи будуть створюватися, заповнюючи стовпець IDENTIFIER значенням MYSESSION1. Отримати тільки ці записи можна ось таким запитом:

select timestamp, username, script, statement, message
from sperrorlog
where identifier = “MYSESSION1”;

Таким чином будуть відображені записи тільки з цієї сесії. Це дуже корисно, якщо необхідно ізолювати помилки в безлічі скриптів і сесій.


Стиснення Тимчасового табличного простору


Швидше за все вам відомо, тимчасові табличні простору особливі – звичайні правила управління простором для них можуть не підходити. Коли виділяється тимчасовий сегмент, надалі він не звільняється. Це не є проблемою, адже часові сегменти (для яких і використовуються тимчасові табличні простору) не є частиною схеми і не зберігаються між циклами бази даних. Місце використовується повторно для іншого користувача або іншого запиту. У будь-якому випадку, так як місце не звільняється, тимчасові табличні простору з часом збільшуються в розмірах. Що робити, якщо необхідно обрізати їх для звільнення місця під інші табличні простору?


До цих пір єдиною можливість було видалити і перестворювати табличний простір – в принципі тривіальна задача, практично завжди здійсненне на льоту. Тим не менш, є одне маленьке “але”: що робити, якщо потрібно 100% доступність системи і ніяк інакше? В Oracle Database 11g можна досягти цього просто зменшивши тимчасове табличне простір.


От яким чином стискується табличний простір TEMP1:

alter tablespace temp1 shrink space;

Цією дією звільняються всі незайняті сегменти з табличного простору і воно стискається. Після цієї операції можна подивитися уявлення DBA_TEMP_FREE_SPACE для перевірки, скільки вільного і зайнятого місця зараз є.

SQL> select * from dba_temp_free_space;

TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
—————————— ————— ————— ———-
TEMP 179306496 179306496 178257920


У досить спокійній базі даних операція стискування може зменшити тимчасове табличне простір практично до нуля. Однак, це дуже штучна ситуація, подальша активність розширить табличне простір, тому логічніше залишити якесь місце, наприклад 100 Мб. Ось як це зробити:

SQL> alter tablespace temp shrink space keep 100m;

Tablespace altered.

SQL> select * from dba_temp_free_space;

TABLESPACE_NAME TABLESPACE_SIZE ALLOCATED_SPACE FREE_SPACE
—————————— ————— ————— ———-
TEMP 105906176 1048576 104857600


Весь простір, за винятком 100 Мб, віддано. Так можна керувати обсягом різних табличних просторів. Тепер можна запозичити місце з тимчасового табличного простору і дати на час іншим табличним просторам (без жартів). Пізніше, коли місце більше не потрібно, його можна повернути в тимчасове табличне простір. Поєднуючи цю можливість з табличним простором для глобальних тимчасових таблиць, можна вирішувати безліч складних проблем з управлінням об’ємом тимчасових табличних просторів.


SQL * Plus показує BFILE


В Oracle Database тип даних BFILE зберігає покажчик на зовнішній файл, а не вміст самого файлу. Він виконує специфічну функцію: зберігається місце в базі даних, в той час як користувачі мають доступ до даних в файлах. Це зручно для деяких додатків, наприклад, використовують бази даних з мультимедійним вмістом.


Якщо в таблиці існує стовпець з типом даних BFILE, спроба вибрати з нього дані через SQL * Plus завершиться отриманням помилки. Однак, в Oracle Database 11g утиліта SQL * Plus як значення стовпця покаже шлях до файлів.


Подивимося приклад. Для початку необхідно створити об’єкт directory для розміщення BFILE.

SQL> create directory doc_dir as “/u01/oracle/docs”;
Directory created.
Тепер сама таблиця.
SQL> create table docs
2 (
3 doc_id number(20),
4 doc_file bfile,
5 doc_type varchar2(10)
6 );
Table created.
Створюємо рядок.
SQL> insert into docs values
2 (
3 1,
4 bfilename(“DOC_DIR”,”metric_daily_report.pdf”),
5 “PDF”
6 );

1 row created
Тепер, якщо вибрати цей рядок через SQL * Plus:
SQL> col doc_file format a50
SQL> select * from docs;

DOC_ID DOC_FILE DOC_TYPE
———- ————————————————– ———-
1 bfilename(“DOC_DIR”, “metric_daily_report.pdf”) PDF


Висновок в стовпці DOC_FILE, який є BFILE, показує місце розташування файлу, а не помилку.


Параметричні Файли в Пам’яті


Уявімо ситуацію: в процесі діагностики якої-небудь проблеми з базою даних, було модифіковано безліч параметрів, все в пам’яті. Пізніше можна забути, які саме параметри були змінені. Якщо забути записати ці параметри в файл параметрів (pfile або spfile), ці зміни будуть втрачені. Так як відбувалися експерименти зі значеннями, вони не були внесені в файл параметрів, адже було неясно, яке саме значення використовувати для того чи іншого параметра. Звичайно, можна пройти по журналу alert.log і витягнути все змінені значення, але ця процедура не тільки болюча, але і потенційно може містити помилки.


В Oracle Database 11g можна використовувати дуже просту команду для створення pfile або spfile на підставі значень параметрів в пам’яті.

SQL> create spfile from memory;
File created.

SQL> create pfile from memory;

File created.


Цією командою буде створений pfile або spfile зі значеннями з пам’яті. У самому верху pfile буде розташована рядок, подібна цієї:

# Oracle init.ora parameter file generated by instance ODEL11 on 08/28/2007 14:52:14

Цей метод позбавляє від зусиль і ризику під час пошуку параметрів, змінених в пам’яті. Також ця можливість дозволяє створити pfile з іншим ім’ям і потім порівняти поточний pfile з тільки що згенерували на предмет виявлення параметрів, які змінені.

SQL> create pfile=”/tmp/a” from memory;

Ця команда створить pfile в вигляді / tmp / a. Тепер в Unix проста команда diff покаже відмінності в цих двох файлах.


Скидання з оглядкою


Під час процесу настройки продуктивності проводиться аналіз впливу деяких динамічних параметрів ініціалізації, і значення змінюються відразу в spfile. До нещастя, адміністратор забув, що саме і на що він міняв. Так як зміни були внесені відразу в spfile, на підставі його вже не можна сказати, що саме було змінено.


І ось тут з’являється кавалерія: команда ALTER SYSTEM RESET скидає значення на значення за замовчуванням, не дивлячись на те, що використовується spfile.

alter system reset license_max_sessions;

У попередніх релізах ця команда також була доступна, але з одним великим відмінністю: потрібно вказувати SID при використанні в конфігурації RAC. Якщо було необхідно скинути параметр на всіх примірниках, вказувалося SID = “*”. В Oracle Database 11g конструкція SID є необов’язковою і значенням по-замовчуванню є всі екземпляри. Таким чином, якщо забути вказати цю конструкцію, раніше команда завершувалася з помилкою; тепер вона виконається, але ефект може бути не тим, який від неї чекають. Будьте уважні.


Моніторинг SQL в реальному часі


З цією можливістю діагностика продуктивності отримала величезний стрибок. Уявімо: хтось запустив набір SQL-запитів (можливо, всередині блоку PL / SQL). Яким чином дізнатися, скільки ресурсів (CPU, I / O і т.д.) споживає кожен крок на шляху доступу? Можна трасувати сесію або аналізувати трасовий файл за допомогою Trace Analyzer або старого tkprof, але все це вже буде після того, що сталося. Було б непогано мати можливість заглянути, що саме зараз відбувається в сесії, чи не так?


В Oracle Database 11g нова можливість, Real Time SQL Monitoring, робить саме те, що сказано в її назві: дозволяє бачити різні метрики виконуваного SQL в реальному часі. Статистики стають доступними через динамічне представлення продуктивності V $ SQL_MONITOR, яке оновлюється раз на секунду.


Для демонстрації запустимо великий запит і будемо спостерігати за статистиками в реальному часі. Ми знаємо, що SID запущеної сесії дорівнює 103. Для запиту з уявлення я використовував знаменитий інструмент Томаса Кайта print_table, що дозволяє бачити результат у вертикальному форматі для кращої сприйнятливості.

SQL> exec print.tbl(“select * from v$sql_monitor where sid = 103”)
KEY : 476741369968
STATUS : EXECUTING
FIRST_REFRESH_TIME : 07-jul-2008 14:13:38
LAST_REFRESH_TIME : 07-jul-2008 14:26:27
REFRESH_COUNT : 48043
SID : 103
PROCESS_NAME : ora
SQL_ID : 2xj1nram1k1x0
SQL_EXEC_START : 07-jul-2008 14:13:31
SQL_EXEC_ID : 16777216
SQL_PLAN_HASH_VALUE : 1759042790
SQL_CHILD_ADDRESS : 38837734
SESSION_SERIAL# : 32668
PX_SERVER# :
PX_SERVER_GROUP :
PX_SERVER_SET :
PX_QCINST_ID :
PX_QCSID :
ELAPSED_TIME : 42638722
CPU_TIME : 9199624
FETCHES : 48032
BUFFER_GETS : 3238
DISK_READS : 12096
DIRECT_WRITES : 13419
APPLICATION_WAIT_TIME : 0
CONCURRENCY_WAIT_TIME : 134534
CLUSTER_WAIT_TIME : 0
USER_IO_WAIT_TIME : 148436
PLSQL_EXEC_TIME : 0
JAVA_EXEC_TIME : 0
—————–

Назви більшості стовпців говорять самі за себе: SQL_ID – sql_id виконуваного SQL користувачем SID; STATUS – статус SQL прямо зараз, показує, що SQL виконується прямо зараз; SQL_EXEC_START – час початку, і т.д. стовпці типу CPU_TIME, DISK_READS і DIRECT_WRITES відображають однойменні метрики. Якщо продовжити виконання запиту буде видно, як ці метрики оновлюються.


Ще одне подання, V $ SQL_PLAN_MONITOR, показує оновлюваний в реальному часі план виконання запускаються SQL запитів. От яким чином можна використовувати це подання, щоб побачити всілякі кроки в плані і пов’язану статистику в реальному часі.

select plan_line_id,
plan_operation,
plan_options,
output_rows
from v$sql_plan_monitor
where sid = 103
order by plan_line_id;
PLAN_LINE_ID PLAN_OPERATION PLAN_OPTIONS OUTPUT_ROWS
———— —————————— —————————— ———–
0 SELECT STATEMENT 809994
1 HASH GROUP BY 809994
2 HASH JOIN 918845
3 PART JOIN FILTER CREATE 1826
4 TABLE ACCESS FULL 1826
5 HASH JOIN 918845
6 TABLE ACCESS FULL 503
7 HASH JOIN 918845
8 TABLE ACCESS FULL 72
9 HASH JOIN 918845
10 TABLE ACCESS FULL 5
11 HASH JOIN 918845
12 TABLE ACCESS FULL 55500
13 PARTITION RANGE JOIN-FILTER 918845
14 TABLE ACCESS FULL 918845

Аналогічно попередньому поданням, якщо перезапустити запит буде видно, як оновлюються метрики. Ці два подання дозволяють заглибитися в обробку SQL в реальному часі.


Інший корисною частиною моніторингу SQL в реальному часі є SQL Monitor Report. Використовуючи цей інструмент можна отримати візуальний звіт про різні метриках SQL і кроків плану. Звіт генерується як висновок типу CLOB з функції REPORT_SQL_MONITOR з пакету DBMS_SQLTUNE. Ось як викликати цю функцію:

SQL> set long 99999 lines 3000 pages 0 trimspool on
SQL> select dbms_sqltune.report_sql_monitor (
2 event_detail => “YES”,
3 report_level => “ALL”,
4 type => “HTML”
5 )
6 from dual;

Направимо висновок в файл rep1.html і запустимо SQL. Через якийсь час виконаємо цей SQL ще раз, направивши висновок в новий файл – re2.html. І в кінці, після того як запит відпрацював, запустимо ще раз, направивши висновок в rep3.html. Кожен звіт є знімком метрик SQL в реальному часі за звітний період. Створюючи звіт у трьох різних моментах часу дозволяє відстежити зміни. Відкривши один з звітів в Web браузері, буде видно звіт, схожий на цей:


На ньому відображено SQL-пропозиція разом з метриками. У лівому верхньому кутку розташовані метадані про це SQL – час запуску, останнього оновлення і т.д. Правіше розташовані кілька кольорових графіків, відображають різні метрики. При наведенні курсору миші на ці графіки, буде показано їх опис разом зі значеннями, які вони ілюструють.


Нижня містить план оптимізатора для цього запиту разом з часом, що витрачається на кожен крок і розбитим по таким категоріям, як Активність CPU, Очікування (Waits) і т.д. Кольорові графіки показують відносні значення для кожної метрики. При наведенні курсору миші над цими графіками, будуть показані значення та інтервали часу для кожної метрики.


Цей звіт є не більше ніж знімком розглянутого раніше подання Монітору SQL в реальному часі, показаного в графічному вигляді. Представлені в графічному вигляді дані допомагають зрозуміти складові частини запиту і виміряти час, проведений в кожній з цих частин, тим самим роблячи діагностику продуктивності простіше.


Заключна Замітка


Цим завершується 20-тижневий ураганний тур по новим можливостям, представленим в Oracle Database 11g. Як і будь-який автор, я намагався зберегти делікатний баланс між глибиною і шириною. У минулій серії статей про Oracle Database 10g Rel 1 і Rel 2, відгуки читачів були гучними і ясними: вам подобається стиль викладу заснований на прикладах, тому я не відійшов від такого формату і в цій серії.


Мої щирі подяки йдуть рецензентам, які стверджували цю серію. Я не можу не подякувати Джастіна Кестеліна (Justin Kestelyn) за підтримку і допомогу в приведенні цього проекту до успіху. І спасибі тобі, дорогий читачу, за надання сенсу всьому цьому.

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


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

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

Ваш отзыв

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

*

*