Чистим-чистим арклоги в FRA ASM Standby

Automatic Storage Management на стендбай сервере ругается, что Disk Group FRA is 90.358% used ?
Давайте почистим Fast Recovery Area.

Немного подхачим гуляющий по интернету скрипт и получим готовую к выполнению в RMAN команду для удаления применённых арклогов с учётом тредов. Минус 2 от максимального, т.к. бывали случаи, что стендбай ломался и требовал пару уже применённых логов. Выполнять строго на Standby:

select 'DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE '|| (max(sequence#)-2)||' THREAD '||THREAD# ||';'
from v$archived_log
where applied = 'YES'
AND  RESETLOGS_TIME = (select MAX(RESETLOGS_TIME) from V$DATABASE_INCARNATION)
group by THREAD#;---

Чтобы быть уверенным, что особого отставания нет и адских гепов, посмотрим на PRIMARY

select max(SEQUENCE#),THREAD# from v$archived_log
where RESETLOGS_TIME = (select MAX(RESETLOGS_TIME) from V$DATABASE_INCARNATION)
group by THREAD#;

Получим что-то вроде этого:

DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 3786 THREAD 1;
DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE 3571 THREAD 2;

Возможно, будет хорошим решением будет включение опции автоматического удаления накатившихся арклогов:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

Ожидания и реальность в статспэке. Statspack Idle Events

Если у вас нет Enterprise Edition с Diagnostic Pack, то юзать AWR у вас не получится, а вот Statspack поставить не только можно, но и нужно. Да, он всё ещё присутствует, но к сожалению, практически не развивается. Одна из самых важных секций ‘Top 5 Timed Events’ показывают только события переднего плана (foreground events), по крайней мере, должен показывать. Когда пользовательский процесс ожидает фоновый процесс (background) эта секция должна учитывать только фоновое ожидание, а не активность фоновых процессов, иначе мы получим удвоенный учёт. Фоновая активность включена в события ‘Idle’ (простаивание) чтобы быть исключенной из секции «топ 5». К сожалению, новые версии Oracle DB выпускаются с новыми типами ожидания, которые вы не найдёте в списке событий простоя StatsPack’а.

Например, вот ‘Top 5 Timed Events’ в период с 22:00 по 23:00 без активности приложения:

Top 5 Timed Events                                                    Avg %Total
~~~~~~~~~~~~~~~~~~                                                   wait   Call
Event                                            Waits    Time (s)   (ms)   Time
----------------------------------------- ------------ ----------- ------ ------
LGWR worker group idle                               6      22,049 ######   65.2
AQPC idle                                          120       3,602  30014   10.7
heartbeat redo informer                          3,568       3,601   1009   10.7
lreg timer                                       1,195       3,598   3011   10.6
direct path read                                31,221         466     15    1.4
-------------------------------------------------------------

Простой и таймеры занимают первые позиции. Прямое чтение с диска кажется минимальным. А использование ЦПУ вообще нет. Очевидно, что здесь, что-то не так.
Читать далее «Ожидания и реальность в статспэке. Statspack Idle Events»

QUICK KILL USER SESSION

Просто замените username на те, что нужны.
Just change username in section…

SELECT 'KILLING SESSION of LOUISE' FROM DUAL;
BEGIN
FOR r IN (select sid,serial# from v$session where username in ('LOUISE','MAM','PBB') )
LOOP
EXECUTE IMMEDIATE 'alter system kill session ''' || r.sid
|| ',' || r.serial# || '''';
END LOOP;
END;
/

Don’t forget to use upper case : UPPER(‘username’)

01555 и BLOB

Задача: полный экспорт БД.

Ну вот те раз!
"Job "SYSTEM"."SYS_EXPORT_FULL_01" completed with 1 error(s)
at Fri Nov 3 00:20:04 2017 elapsed 0 00:30:22"

Ar-r-r-r-r!!!

ORA-31693: Table data object "ARDOME"."XFER_HISTORY" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old

Странно, не указана ссылка на табличное пространство UNDO, столкнулся с этим первый раз. Прошёлся по стандартной схеме:
0) Увеличение объёма UNDO и длительности UNDO_RETENTION

ORA-22924 — сигнализирует о проблемах с LOB

Вот что было предпринято, но не помогло:
1) alter table ARDOME.XFER_HISTORY modify lob (XFH_PAYLOAD) (pctversion 100);
2) alter table ARDOME.XFER_HISTORY modify lob(XFH_PAYLOAD) (retention);

Не помогло…

Есть вероятность того, что повреждены BLOB в этой таблице, для того, чтобы определить какие именно:

1) Создадим пустышку для хранения ROWID и кода ошибки ERR_NUM
SQL> create table corrupt_lobs (corrupt_rowid rowid, err_num number);

2) Найдём имя столбца который содержит LOB данные:
SQL> DESC ARDOME.XFER_HISTORY
———-
XFH_ID      NOT NULL NUMBER(10
XFH_PAYLOAD      BLOB
 

3) Выполним следующий блок:

declare
error_1578 exception;
error_1555 exception;
error_22922 exception;
pragma exception_init(error_1578,-1578);
pragma exception_init(error_1555,-1555);
pragma exception_init(error_22922,-22922);
num number;
begin
for cursor_lob in (select rowid r, &&lob_column from &table_owner..&table_with_lob) loop
begin
num := dbms_lob.instr (cursor_lob.&&lob_column, hextoraw ('889911')) ;
exception
when error_1578 then
insert into corrupt_lobs values (cursor_lob.r, 1578);
commit;
when error_1555 then
insert into corrupt_lobs values (cursor_lob.r, 1555);
commit;
when error_22922 then
insert into corrupt_lobs values (cursor_lob.r, 22922);
commit;
end;
end loop;
end;
/

Он у нас запросит и мы введём (имя столбца, имя владельца и имя таблицы):

Enter value for lob_column: XFH_PAYLOAD
Enter value for table_owner: ARDOME
Enter value for table_with_lob: XFER_HISTORY

4) После выполнения вышеописанной процедуры в созданной табличке мы можем найти (или не найти) ROWID повреждённых лоб:
select * from corrupted_lob_data;

У меня оказалось 3 строки:
corrupt_rowid     err_num
——————————-
AAAXd7AAKAAK5+oAAU    1555
AAAXd7AAKAAK5+oAAV    1555
AAAXd7AAKAAK5+oAAW   1555

В этой ситуации можно:
-восстановить эти LOB сегменты из физического бекапа;

-почистить (обнулить) повреждённые LOBы используя UPDATE:
update <owner>.<tablename>
set    <lob column> = empty_blob()
where  rowid in (select corrupted_rowid from   corrupted_lob_data);
commit;

В моей ситуации обошёлся тем, что выгрузил дамп БД без повреждённых строк:
expdp \"/as sysdba\" parfile=export_options.par

Содержимое export_options.par:
directory=DUMP_EXP
dumpfile=mamdb01_full.dmp
logfile=mamdb01_full.exp.log
full=y
query="where rowid not in ('AAAXd7AAKAAK5+oAAU', 'AAAXd7AAKAAK5+oAAV', 'AAAXd7AAKAAK5+oAAW')"

Высокое ожидание resmgr:cpu quantum с отключенным Resource Manager.

Дано:
Product Oracle Database — Standard Edition
Product Version 12.1.0.2
Operating System Microsoft Windows x64 (64-bit)
OS Version 2012 R2

По ссылке к описанию этого ожидания увидим, что оно относится только к Менеджеру Ресурсов:
«This event occurs when the resource manager is enabled and is throttling CPU consumption.» [«Это событие происходит тогда, когда менеджер ресурсов включен и он ограничивает потребление CPU»]

Но странность в том, что у нас Standard Edition и Resource Manager не должен быть активен, даже по определению:
«Resource Manager is a database feature that was introduced in Oracle 8i. It is only available with
Enterprise Edition.» [«Менеджер ресурсов это функционал БД который был представлен в Oracle 8i. Он доступен только в Корпоративной версии (Enterprise Edition)»] (Using Oracle Database Resource Manager)

Попытки принудительно его отключить, сообщают нам, что мы ничего не поделаем =(

SQL> alter system set resource_manager_plan='' scope=both;
alter system set resource_manager_plan='' scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00439: feature not enabled: Database resource manager

Потому, MOS посоветовал диссоциировать менеджер ресурсов от всех окон Oracle Scheduler. Читать далее «Высокое ожидание resmgr:cpu quantum с отключенным Resource Manager.»

Vim for beginners

Изучение Vim — это инвестирование.

Редакторы командной строки могут быть страшной вещью для обучения и использования новичками и Vim возможно найстрашнейший из них– хотя на самом деле не должен. В нём много чего скрыто (гораздо больше, чем будет сказано в этом руководстве) и здесь рассмотрим основы настолько, что мы могли бы по крайней мере удобно редактировать файлы. Читать далее «Vim for beginners»

Трассировка определённого SQL. Tracing for a specific SQL.

Event 10046 — это событие является стандартным методом сбора расширенной sql_trace информации для Oraclовых сессий.
Для вопросов связанных с производительностью запросов (Query Performance) обычные требования — это записать информацию об ожиданиях и биндах переменных. Эта задача выполняется при использовании 10046 с уровнем 12 или 4 (level 12/level 4).

Для методов которые требуют уровня трассировки действительны следующие значения:
0 — Нет трейса. Как если sql_trace off.
2 — Эквивалент обычного sql_trace;
4 — То же, что и 2, но дополняется значениями забинженых переменных;
8 — То же, что и 2, но дополняется событиями ожидания;
12 — То же, что и 2, но с доп. значениями забинженых переменных и событиями ожидания (как у уровней 4 и 8, собственно 4+8=12).

В конкретном случае мне требуется узнать значение переменной B1 у запроса  10q4ut6chvak6 (выпадает ORA-00600: internal error code, arguments: [kdsgrp1] при определённых значениях):

--- Current SQL Statement for this session (sql_id=10q4ut6chvak6) ---
SELECT R.*, C.CCN_ID, C.CCN_TITLE FROM ARDOME.RUNDOWN_ROW R
LEFT OUTER JOIN ARDOME.COLLECTION C ON R.RDR_SITE_ID_STR=C.CCN_SITE_ID_STR AND C.CCN_TYPE='program' WHERE RDR_ID=:B1

Включить:
alter system set events 'sql_trace[sql: 10q4ut6chvak6] level=12';

Найти трейс можно по запросу:
SELECT VALUE FROM V$DIAG_INFO WHERE NAME = 'Default Trace File';

Через некоторое время в трейсе можно обнаружить то, что требовалось найти:
PARSING IN CURSOR #140038752954880 len=177 dep=1 uid=103 oct=3 lid=103 tim=1494421918938952 hv=2567809606 ad='41f2229a0' sqlid='10q4ut6chvak6'
SELECT R.*, C.CCN_ID, C.CCN_TITLE FROM ARDOME.RUNDOWN_ROW R LEFT OUTER JOIN ARDOME.COLLECTION C ON R.RDR_SITE_ID_STR=C.CCN_SITE_ID_STR AND C.CCN_TYPE='program' WHERE RDR_ID=:B1
END OF STMT
BINDS #140038752954880:
Bind#0
oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1206001 frm=00 csi=00 siz=24 off=0
kxsbbbfp=7f5d50211b40 bln=22 avl=11 flg=05
value=2101705100110951942

Выключить:
alter system set events 'sql_trace[sql: 10q4ut6chvak6] off';

Отследить отслеживаемые запросы можно через oradebug
SQL> oradebug setmypid
Statement processed.
SQL> oradebug eventdump session
sql_trace[sql: 10q4ut6chvak6] level=12

 

N.B. Будьте бдительны, в моём случае я поймал то, что искал:
EXEC #140534692422696:c=0,e=303,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=2,plh=2289027174,tim=1494423351664104
* kdsgrp1-1: *************************************************
row 0x02cbbaca.7 continuation at
0x02cbbaca.7 file# 11 block# 768714 slot 7 not found

и далее +72Мб дополнительной информации. При многократном получении ошибки можно быстро забить файловую систему.