Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Erkesh
Member

Откуда: Астана
Сообщений: 92
Здравствуйте.
Сообщите, пожалуйста, если не сложно, какая у кого скорость обработки архивных логов logminer-ом, когда он используется процессом захвата изменений.
У меня - около 35 мегабайт в минуту. Этот вывод я делаю на основе анализа "streams healh check" отчетов (streams-hc-10GR2.sql), деля "bytes of redo processed" из раздела "logminer statistics" на общее время работы capture процесса из раздела "capture statistics".
2 гигабайта в час - очень медленно. Это только у меня так или это нормальное явление?
20 апр 12, 09:21    [12443479]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Не понятна методика измерений, т.к. по ней получается, что чем меньше redo, тем ниже скорость.
20 апр 12, 09:32    [12443510]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
Erkesh
Здравствуйте.
Сообщите, пожалуйста, если не сложно, какая у кого скорость обработки архивных логов logminer-ом, когда он используется процессом захвата изменений.
У меня - около 35 мегабайт в минуту. Этот вывод я делаю на основе анализа "streams healh check" отчетов (streams-hc-10GR2.sql), деля "bytes of redo processed" из раздела "logminer statistics" на общее время работы capture процесса из раздела "capture statistics".
2 гигабайта в час - очень медленно. Это только у меня так или это нормальное явление?
Скорость обработки логов зависит от скорости процессора, параллелизма, правильности настройки SGA.
2 Гб/час это очень мало - я по Streams не могу привести статистику, но по GoldenGate это 60 Гб/час на 1 ядро Xeon.
20 апр 12, 09:35    [12443521]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
wurdu
Не понятна методика измерений, т.к. по ней получается, что чем меньше redo, тем ниже скорость.
Скорее всего у автора Capture уже пытается нагонять и не успевает.
Иначе согласен с wurdu - для измерения скорости нужно, чтобы Capture было доступно достаточное кол-во логов.
Можно остановить Capture, нагенерить изменений, а потом опять запустить Capture
20 апр 12, 09:38    [12443533]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Erkesh
Member

Откуда: Астана
Сообщений: 92
Alexander Ryndin
Erkesh
Здравствуйте.
Сообщите, пожалуйста, если не сложно, какая у кого скорость обработки архивных логов logminer-ом, когда он используется процессом захвата изменений.
У меня - около 35 мегабайт в минуту. Этот вывод я делаю на основе анализа "streams healh check" отчетов (streams-hc-10GR2.sql), деля "bytes of redo processed" из раздела "logminer statistics" на общее время работы capture процесса из раздела "capture statistics".
2 гигабайта в час - очень медленно. Это только у меня так или это нормальное явление?
Скорость обработки логов зависит от скорости процессора, параллелизма, правильности настройки SGA.
2 Гб/час это очень мало - я по Streams не могу привести статистику, но по GoldenGate это 60 Гб/час на 1 ядро Xeon.


Александр, "параллелизма" чего именно?

Люди. В различных нотах на металинк, связанных со стримами, рекомендуют для 10g выставлять параметр parallelism процесса захвата изменений в 1. Можно ли изменить этот параметр в большую сторону? На что он влияет? Будет ли процесс захвата изменений захватывать изменения "правильно" (т.е. по сути, как я понимаю, последовательно), если этот параметр изменить в большую сторону?
20 апр 12, 09:47    [12443587]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Erkesh
Member

Откуда: Астана
Сообщений: 92
Alexander Ryndin
wurdu
Не понятна методика измерений, т.к. по ней получается, что чем меньше redo, тем ниже скорость.
Скорее всего у автора Capture уже пытается нагонять и не успевает.
Иначе согласен с wurdu - для измерения скорости нужно, чтобы Capture было доступно достаточное кол-во логов.
Можно остановить Capture, нагенерить изменений, а потом опять запустить Capture


Совершенно верно. Захват обрабатывает архивные логи за вчерашнее утро, хотя его я практически не останавливал, а только иногда (два-три раза) перезапускал, пытаясь "ускорить" его работу, меняя параметры streams-pool-size и -sga-size (простите, но "подчеркушка" не работает).
20 апр 12, 09:51    [12443601]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Для начала надо понять, тормозит capture или apply (или вообще propagation, если есть). Собственно смотрим v$streams_capture, v$streams_appy_server. Если убеждаемся что действительно capture - смотрим события ожидания сессий capture. По скорости - без проблем майнит по 40-60 Gb в час.
20 апр 12, 10:01    [12443643]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
Erkesh
Member

Откуда: Астана
Сообщений: 92
wurdu,
подскажите, пожалуйста, если не трудно, можно ли сделать на основе следующего v$streams-capture, что "тормозит" захват?
SID 1799
SERIAL# 12286
CAPTURE# 1
CAPTURE_NAME CAPTURE_STREAM
LOGMINER_ID 41
STARTUP_TIME 20.04.2012 11:11:17
STATE CAPTURING CHANGES
TOTAL_PREFILTER_DISCARDED 5376434
TOTAL_PREFILTER_KEPT 0
TOTAL_PREFILTER_EVALUATIONS 5376557
TOTAL_MESSAGES_CAPTURED 289116
CAPTURE_TIME 20.04.2012 12:18:37
CAPTURE_MESSAGE_NUMBER 97461402311
CAPTURE_MESSAGE_CREATE_TIME 19.04.2012 9:24:28
TOTAL_MESSAGES_CREATED 289627
TOTAL_FULL_EVALUATIONS 386
TOTAL_MESSAGES_ENQUEUED 118
ENQUEUE_TIME 20.04.2012 12:15:31
ENQUEUE_MESSAGE_NUMBER 97461359332
ENQUEUE_MESSAGE_CREATE_TIME 19.04.2012 9:23:39
AVAILABLE_MESSAGE_NUMBER 97566045722
AVAILABLE_MESSAGE_CREATE_TIME 20.04.2012 12:18:40
ELAPSED_CAPTURE_TIME 393317
ELAPSED_RULE_TIME 57
ELAPSED_ENQUEUE_TIME 73
ELAPSED_LCR_TIME 468
ELAPSED_REDO_WAIT_TIME 0
ELAPSED_PAUSE_TIME 0
STATE_CHANGED_TIME 20.04.2012 12:18:37

Как посмотреть статистику работы не захвата, а самого логмайнер?
20 апр 12, 10:32    [12443818]     Ответить | Цитировать Сообщить модератору
 Re: Скорость обработки логов Logminer-ом, используемым Capture Streams  [new]
dimacrat
Member

Откуда: Москва
Сообщений: 305
Скорость сильно зависит от правил Capture.
У нас после добавления одной часто изменяемой таблицы скорость резко упала - на пару порядков, т.е. совсем все легло.
Пришлось удалять это правило.
20 апр 12, 11:45    [12444408]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить