Засоби діагностики і утиліти налагодження в oracle - все про it і програмуванні

ЗМІСТ

Трасувальні файли Oracle

Головним є файл журналу повідомлень (alert.log), який містить найважливішу інформацію про роботу БД, в ході діагностики його слід перевіряти в першу чергу.

На початку роботи БД в alert.log заносяться всі параметри файлу init.ora і повідомлення про запуск фонових процесів. Реєструється також використовується цим екземпляром потік і послідовний номер журналу, в який проводить запис процес LGWR.

У загальному випадку заноситься також інформація про запуски і остановах БД, створення табличних просторів і сегментів відкоту, деяких операціях alter. перемиканнях журналів і повідомлення про помилки.

Крім alert.log Oracle автоматично генерує два файли трасування. Один з них - фоновий файл трасування, створюється фоновими процесами DBWR і LGWR. Ці файли трасування можуть і не створюватися при запуску системи, в залежності від наявності інформації для запису.

Файл трасування другого типу створюється з'єднанням користувача з БД і називається призначеним для користувача файлом трасування.

Такий файл з'являється, тільки якщо сеанс користувача наштовхується на помилку.

Імена файлів трасування мають стандартний формат і залежать від використовуваної ОС. У середовищі UNIX фоновий файл трасування виглядає як ORA_PID_PROCESS.trc, а призначений для користувача файл - PROCESS_ID.trc. При цьому ORA_PID представляє ідентифікатор процесу Oracle, а PROCESS_ID - системного процесу, який створив файл трасування.

Для налагодження підтримуються різні засоби діагностики. Для вивантаження в файли трасування діагностичної інформації можна підключити певні події. Для діагностики пошкоджень диска і пам'яті застосовуються деякі спеціальні параметриinit.ora. Ці параметри не задаються при нормальній роботі БД, тому що вони знижують її продуктивність.

Завдання подій трасування

Наведемо способи завдання подій трасування:

-вивантажити стан системи для діагностики проблем, пов'язаних з зависанням

-вивантажити стек помилки і процесу (напр. помилка ORA-00604)

При завданні подій за допомогою init.ora використовуються наступні рядки:

EVENT = "604 TRACE NAME ERRORSTACK FOREVER" - вивантажується стек помилок кожен раз, коли процес зустрічає помилку ORA-00604;

EVENT = "10210 TRACE NAME CONTEXT FOREVER, LEVEL 10" - контролюється цілісність кожного блоку при читанні з диска в кеш.

Найбільш поширені коди подій:

10013 і 10015 - застосовуються при діагностиці проблем, пов'язаних з пошкодженням сегментів відкоту.

event = "10015 trace name context forever"

10029 і 10030 - інформація про початки і зупинках сеансів.

10210 і 10211 - перевіряються блоки даних, що зчитуються в область SGA

event = "10210 trace name context forever, level 10"

10231 і 10232 - пропустити пошкоджені блоки в ході сканування таблиці і вивантажити їх у файл трасування

alter session set events '10231 trace name context off';

event = "10231 trace name context forever, level 10"

Перший оператор відключає перевірку блоків для даного сеансу. Другий включає перевірку всіх блоків БД, зчитувальних будь-яким процесом в область SGA.

Аналіз журналу за допомогою LogMiner

Архівні файли журналів повторів дуже важливі, особливо для відновлення БД. Для того, щоб прочитати внесені в БД зміни, які містяться в архівному файлі журналу повторів, необхідно відкрити вказаний файл і вивчити його вміст.

Для цього існує спеціальний інструмент під назвою LogMiner.

Для роботи з цим інструментом необхідно:

1. Встановити utl_file_dir в init.ora

2. Запустити $ ORACLE_HOME / rdbms / admin / dbmslogmnrd.sql

3. SQL> EXECUTE dbms_logmnr_d.build ( 'dictionary.ora', '');

4. SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE (LogFileName => '/oradata/test/arc/test454.arc', Options => dbms_logmnr.NEW);

для кожного додається до списку файлу журналу видалити

5. EXECUTE DBMS_LOGMNR.START_LOGMNR (DictFileName =>

6. select scn, log_id, username, sql_redo, sql_undo from v $ logmnr_contents where username = 'SCOTT';

список всіх змін, виконаних користувачем SCOTT

7. SQL> EXEC DBMS_LOGMNR.END_LOGMNR;

Пошук і виправлення пошкоджених блоків даних за допомогою модуля DBMS_REPAIR

Для усунення пошкоджень в блоках, таблицях і індексах Oracle пропонує інструмент DBMS_REPAIR.

Цей модуль дозволяє:

- м'яко пошкоджувати блоки, щоб показати, що вони пошкоджені;

- пропускати пошкоджені блоки в ході повного сканування таблиці або індексу;

- обслуговувати стали непотрібними рядки індексу, які вказують на пошкоджені блоки даних;

- перебудовувати списки вільної пам'яті для зазначеної таблиці або індексу.

Створення таблиць адміністрування модуля DBMS_REPAIR

1. sqlplus "/ as sysdba"

2. Створити (за бажанням) табличний простір.

3. SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ( 'REPAIR_ADMIN', 1, 1, 'REPAIR_TS');

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ( 'ORPHAN_ADMIN'. 2, 1, 'REPAIR_TS');

Якщо потрібно видалити таблицю:

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ( 'ORPHAN_ADMIN'. 2, 3, NULL);

Щоб очистити таблицю (видаливши всі її рядки):

SQL> EXEC DBMS_REPAIR.ADMIN_TABLES ( 'ORPHAN_ADMIN'. 2, 2, NULL);

Сканування конкретної таблиці або індексу за допомогою процедури DBMS_REPAIR.CHECK_OBJE

Перевіримо на пошкодження таблицю data схеми prod. Припустимо, що в схемі sys була створена таблиця repair_admin

1. sqlplus "/ as sysdba"

SQL> VARIABLE A NUMBER;

2. SQL> EXEC DBMS_REPAIR.CHECK_OBJECT ( 'PROD', 'DATA', NULL, 1,

'REPAIR_ADMIN'. NULL, NULL, NULL, NULL. A);

4. SELECT RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Виправлення пошкоджених блоків за допомогою процедури DBMS_REPAIR.FIX_CORRUPT_BLOCKS

1. VARIABLE A NUMBER;

2. EXEC DBMS_REPAIR.FIX_CORRUPT_BLOCKS ( 'PROD', 'DATA', NULL, 1, 'REPAIR_ADMIN', NULL. A);

3. Перевіримо позначені чи елементи блоку, як програмно пошкоджені:

SELECT RELATIVE_FILE_ID FILE,

MARKED_CORRUPT MARKED FROM REPAIR_ADMIN;

Пропуск пошкоджених блоків за допомогою процедури DBMS_REPAIR.SKIP_CORRUPT_BLOCKS

EXEC DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ( 'PROD', 'DATA', 1,1);

EXEC DBMS_REPAIR.DUMP_ORPHAN_KEYS ( 'PROD', 'SNO_IDX', NULL, 2, 'REPAIR_ADMIN',

'ORPHAN_ADMIN', NULL. A);

SELECT SCHEMA_NAME, INDEX_NAME, INDEX_ID, TABLE_NAME, KEYROWID, KEY,

DUMP_TIME FROM ORPHAN_ADMIN;

Щоб перебудувати список вільної пам'яті таблиці DATA:

EXEC DBMS_REPAIR.REBUILD_FREELISTS ( 'PROD', 'DATA', NULL, 1);

Утиліта oradebug надає доступ до структур пам'яті процесів Oracle, стека і т.д. З його допомогою можна генерувати дамп стану процесу, а також вивантажувати структури області SGA. Крім того, для вже працюючого процесу можна активізувати будь-яку подію.

процес менеджера прикріплюється до процесу Oracle під Unix номером 9431.

приклад виходу: Oracle pid: 12, unix process pid: 9431, image: oraclevk803

розмір файлу трасування встановлюється в unlimited

активізується подія трасування SQL

скидаємо трасування інформацію на диск не можна так робити для фонових ораклових процесів - може статися зупинка бази

Слід розуміти, що фрагментація таблиць відмінна від файлової фрагментації. Коли виконується серія операцій DML над таблицею, таблиця фрагментируется, тому що DML не звільняє вільний простір до HWM.HWM - це індикатор використання блоків (USED BLOCKS) в базі даних. Блоки йдуть до чи.

Default Permanent Tablespace Перейменування табличного пространстваТаблічное простір SYSAUX Складений табличний простір TempDefault Permanent TablespaceOracle 9i ввів поняття тимчасового табличного простору за замовчуванням (default temporary tablespace), що дозволило запобігти випадковим.

ALTER TABLE table_name READ ONLY; ALTER TABLE table_name READ WRITE; Наступний скрипт створює таблицю, додає в неї кілька рядків, потім переключається у режим регулювання таблицю в режим "тільки для читання" .CREATE TABLE ro_tab (id NUMBER); INSERT INTO ro_tab VALUES (1); INSERT INTO ro_tab VALUES (2).

Процедура створення практично не відрізняється від попередніх версій - 9i і 10g. У створюваній базі даних будемо використовувати такі опції: OMF (Oracle Managed File) для файлів даних, файлів журналів повторного виконання і керуючих файлів. FRA (Flash Recovery Area) для архівних журналів або резе.

Неможливість гарантувати, що всі зміни плану завжди будуть в кращу сторону, привела деяких замовників до того, щоб закріпити свої плани виконання (збережені плани) або блокувати статистику оптимізатора. Однак, якщо діяти таким чином, ми позбавляємо себе можливості коли-небудь вико.