Oracle mechanics

21.03.2018

ASH_IO_WAITSBY.SQL

Filed under: Oracle,Scripts — Игорь Усольцев @ 00:46
Tags: ,

По причине ошибки ORA-00600: Internal Error Code, Arguments: [qmxtcsxmlt:xmltype] (Doc ID 2079499.1), характерной для использования функции XMLAgg в бд состояния MOUNTED (standby or non-standby), переписал скрипт ASH_IO_WAITS.SQL для поиска наиболее активных в WAIT_CLASS-ах ‘User I/O‘ и ‘System I/O‘ процессов/запросов на STANDBY и прочих MOUNTED системах

Например, при замедлившемся накате standby (в отсутствии Read Only пользовательских запросов) можно было наблюдать аномально интенсивную IO активность пользовательских процессов RFS в части control file sequential read и RFS write:

SQL> @ash_io_waitsby blocks 10 "1 = 1"
 
INST SQL_PROCESS   SUM(WAIT_COUNT) waits%  SUM(REQUESTS) reqs%   SUM(BLOCKS) blocks% event(waits:requests:blocks)
---- ------------- --------------- ------- ------------- ------- ----------- ------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1 (USER)                 156134   73.56        156134   11.11     1269165   39.07 control file sequential read(11699:11699:1123994); RFS write(105538:105538:105538); RMAN backup & recovery I/O(29486:29486:29486); Data file init write(6877:6877:6877); control file parallel write(736:736:1472); Disk file operations I/O(1049:1049:1049); Disk file Mirror Read(641:641:641); Log archive I/O(108:108:108)
   1 (DBW.)                  14696    6.92       1207318   85.94     1207318   37.16 db file parallel write(14696:1207318:1207318)
   1 (PR..)                  17569    8.28         17569    1.25      523541   16.12 log file sequential read(3984:3984:506025); recovery read(13311:13311:13311); control file sequential read(120:120:4020); direct path write(91:91:91); control file parallel write(31:31:62); direct path read(31:31:31); Disk file operations I/O(1:1:1)
   1 (ARC.)                  16169    7.62         16169    1.15      234540    7.22 control file sequential read(8614:8614:226728); Log archive I/O(7104:7104:7104); control file parallel write(280:280:560); Disk file Mirror Read(106:106:106); Disk file operations I/O(40:40:40); log file sequential read(25:25:2)
   1 (CKPT)                   4624    2.18          4624    0.33        8932    0.27 control file parallel write(3301:3301:6602); control file sequential read(1007:1007:2014); Disk file Mirror Read(316:316:316)
   1 a5xcbum9zpyzn            1750    0.82          1750    0.12        2912    0.09 control file sequential read(1162:1162:2324); Disk file Mirror Read(588:588:588)
   1 6jaghrm3vy74f             769    0.36           769    0.05        1303    0.04 control file sequential read(534:534:1068); Disk file Mirror Read(235:235:235)
   1 89z2u0fdrdg66             397    0.19           397    0.03         761    0.02 control file sequential read(364:364:728); Disk file Mirror Read(33:33:33)
   1 (M...)                     50    0.02            50    0.00          92    0.00 control file sequential read(42:42:84); Disk file Mirror Read(8:8:8)
   1 7mgr3uwydqq8j              13    0.01            13    0.00          22    0.00 control file sequential read(9:9:18); Disk file Mirror Read(4:4:4)
 
10 rows selected

в сравнении с нормальным поведением, где RFS заметен лишь на 4-м месте с 5% прочитанных/записанных blocks: (more…)

Реклама

04.12.2014

ORA-8103 при использовании BCT на standby db

Filed under: Active Data Guard,bugs,Oracle — Игорь Усольцев @ 22:59
Tags: ,

После восстановления очередной тестовой бд с использованием инкрементальных бэкапов, сделанных с использованием Block Change Tracking (BCT) на standby версии 11.2.0.3 получили при попытке последовательно прочитать определённые блоки таблицы:

SQL> select/*+ full(t)*/ count(*) from U2.CALL_STAT t;
 
select/*+ full(t)*/ count(*) from U2.CALL_STAT t
 
ORA-08103: object no longer exists

SQL> analyze table U2.CALL_STAT validate structure;
 
analyze table U2.CALL_STAT validate structure
 
ORA-08103: object no longer exists

, при этом в трейсах можно видеть фактический источник ошибки: (more…)

10.06.2010

Oracle трейс утилит exp/imp и expdp/impdp

При выполнении еженощного экспорта некоторых важных схем бд (производимого на всякий случай, помимо штатного бэкапа средствами rman), периодически появляется ошибка EXP-00003: no storage definition found for segment(123, 345). В процессе работы над Service Request сотрудники техподдержки Oracle порекомендовали сделать datapump export с неописанным в документации параметром TRACE=480300

Для чего и как можно применить трейс утилит DataPump Export/Import (и устаревших Export/Import) ? (more…)

20.04.2009

Как открыть БД с повреждёнными (недоступными) log-файлами

Filed under: Backup and Recovery,Oracle — Игорь Усольцев @ 15:57
Tags: ,

Практический опыт восстановления базы данных

Oracle версии 9.2.0.6 в режиме NOARCHIVELOG, ~1.5 ТБ, после серьёзного сбоя файловой системы и «ручного» запуска утилиты fsck.ext2 файлы данных оказались в /lost+found поименоваными номерами inod’ов, controlfile отсутствуют (пропали при восстановлении — 3 штуки :), redolog-файлы, как выяснилось, повреждены. (more…)

26.01.2009

Standby для Oracle Standard Edition с использованием rman

Filed under: Backup and Recovery,Oracle — Игорь Усольцев @ 18:48
Tags: , ,

Практическая реализации рекомендаций документа 333749.1 Alternative for standby/dataguard in standard edition.

Основная БД Oracle Standard Edition 10.2.0.4, 2-node RAC, archivelog, Oracle Enterprise Linux 5.1 x86_64, ASM, SAN, резервная (standby) некластерная бд установлена на сервере с локальным расположение файлов (не-ASM).

Резервное копирование производится следующим образом:

  • ежененедельное резервное копирование файлов данных (full backup)
RMAN>backup full filesperset 4 format '/FULL_%d_%u/';
  • +ежедневное резервное копирование архивированных логов (archivelog backup) с последующим удалением
RMAN> backup filesperset 20 archivelog all delete all input;

Далее приводятся сценарии создания, инкрементального восстановления (наката лог-файлов) и активации резервной БД командами RMAN без использования recovery catalog. Oracle той же версии устанавливается на резервном сервере, без использования ASM, восстанавливать файлы данных планируется на файловую систему linux ext3.

(more…)

Создайте бесплатный сайт или блог на WordPress.com.