Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Добрый день. Используем двухузловую базу под Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit HP-UX.

Периодически возникают проблемы переключения арк-логов. Выглядит это так. В час наибольшей (а иногда и средней) нагрузки все логи переходят в статус ARC=NO. Все арк-процессы в представлении V$ARCHIVE_PROCESSES переходят в STAT=BUZY В этот момент пользователи не могут зайти в комплекс, жалуются на общие проблемы отклика (замирания отчётов) и т.п. Даже вход пользователя SYS затруднён.

В алертах при этом сообщения:

ORACLE Instance INECA5 - Can not allocate log, archival requred
...
ARC1: Switch failed
ARC1: Switch failed
ARC1: Switch failed
ARC2: Switch failed
ARC2: Switch failed
ARC2: Switch failed

Пытались добавлять новые редо-группы, увеличивать количество арк-процессов. Количество проблем немного снизилось но не исчезло.

Используем хранилище Clarion. Дисковые группы арк-логов стоят на SATA-дисках. Все остальные группы под SCSI.

1) Дайте совет, как можно мониторить узкое место в данном случае? Как узнать, чем занят процесс ARC(n) когда он в статусе BUSY ?

2) Какими UNIX-утилитами смотрят дисковые ожидания хранилища.

3) Дайте совет по выбору оптимального значения log_archive_max_processes. Читали здесь

http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams105.htm#REFRN10090
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/archredo.htm#sthref1057

но никакой конкретной формулы не нашли.


Вот текущее (нормальное) состояние.
SQL> show parameter log_archive_max_processes

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_max_processes            integer     4


SQL> select * from GV$ARCHIVE_PROCESSES where status='ACTIVE';

   INST_ID    PROCESS STATUS     LOG_SEQUENCE STAT
---------- ---------- ---------- ------------ ----
         5          0 ACTIVE                0 IDLE
         5          1 ACTIVE                0 IDLE
         5          2 ACTIVE                0 IDLE
         5          3 ACTIVE                0 IDLE
         1          0 ACTIVE                0 IDLE
         1          1 ACTIVE                0 IDLE
         1          2 ACTIVE                0 IDLE
         1          3 ACTIVE                0 IDLE

8 строк выбрано.

SQL> select * from v$log where thread# in (1,5) order by THREAD#;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS                  FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- -------------------- -------------------
         1          1      17518  268435456          1 YES INACTIVE                 467652256017 2009-08-12 12:25:51
        14          1      17519  268435456          1 YES INACTIVE                 467653553641 2009-08-12 13:37:40
        16          1      17520  268435456          1 NO  CURRENT                  467653840246 2009-08-12 14:03:36
        13          1      17517  268435456          1 YES INACTIVE                 467651001900 2009-08-12 12:17:41
        10          1      17516  268435456          1 YES INACTIVE                 467649777858 2009-08-12 12:09:22
        22          5      13327  268435456          1 YES INACTIVE                 467653663984 2009-08-12 13:47:40
        15          5      13325  268435456          1 YES INACTIVE                 467653063787 2009-08-12 12:31:16
        21          5      13324  268435456          1 YES INACTIVE                 467652659945 2009-08-12 12:28:31
        20          5      13330  268435456          1 NO  CURRENT                  467653957766 2009-08-12 14:12:22
        19          5      13328  268435456          1 YES INACTIVE                 467653766609 2009-08-12 13:57:46
         9          5      13329  268435456          1 YES INACTIVE                 467653840201 2009-08-12 14:03:36
         2          5      13326  268435456          1 YES INACTIVE                 467653553520 2009-08-12 13:37:39

12 строк выбрано.
12 авг 09, 15:54    [7528865]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Осенев
Member

Откуда: рай->bloody hell
Сообщений: 547
Вы можете пролиагностировать проблему временно перенеся арх-логи на локальные диски. Ситуация повторяется?
12 авг 09, 16:25    [7529124]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Осенев
Вы можете пролиагностировать проблему временно перенеся арх-логи на локальные диски. Ситуация повторяется?

Это очень сложно. На локальных блинах места мало и во время исполнения ночных пакетных заданий можно получить нехватку. Я-бы не рискнул такое делать.

Но вы мне подкинули мысль. Я подумаю над тем, чтобы log_archive_dest_1 перенести на SCSI группу.
12 авг 09, 16:31    [7529194]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
Хорошо бы изобразить размер реду-логов и частоту их переключения, напрмер так
автор
SELECT TRUNC(first_time) "Date",
TO_CHAR(first_time, 'Dy') "Day",
COUNT(1) "Total",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'00',1,0)) "h0",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'01',1,0)) "h1",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'02',1,0)) "h2",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'03',1,0)) "h3",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'04',1,0)) "h4",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'05',1,0)) "h5",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'06',1,0)) "h6",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'07',1,0)) "h7",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'08',1,0)) "h8",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'09',1,0)) "h9",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'10',1,0)) "h10",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'11',1,0)) "h11",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'12',1,0)) "h12",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'13',1,0)) "h13",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'14',1,0)) "h14",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'15',1,0)) "h15",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'16',1,0)) "h16",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'17',1,0)) "h17",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'18',1,0)) "h18",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'19',1,0)) "h19",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'20',1,0)) "h20",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'21',1,0)) "h21",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'22',1,0)) "h22",
SUM(DECODE(TO_CHAR(first_time, 'hh24'),'23',1,0)) "h23"
FROM V$log_history
GROUP BY TRUNC(first_time), TO_CHAR(first_time, 'Dy')
ORDER BY 1
12 авг 09, 16:45    [7529326]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Отчёт получился слишком широкий в ширину. Прикрепляю в виде html.

К сообщению приложен файл (rep.html - 27Kb) cкачать
12 авг 09, 17:39    [7529726]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Думаю, надо добавить фильтрацию инстанций

....
FROM V$log_history
where thread#=5
GROUP BY TRUNC(first_time), TO_CHAR(first_time, 'Dy')
ORDER BY 1
Щас сформирую два отчёта по двум узлам отдельно.
12 авг 09, 18:42    [7530032]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745


К сообщению приложен файл (instance1.zip - 1Kb) cкачать
12 авг 09, 18:49    [7530051]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745

Who is Sokolovskaya ? (c) Thomas Kyte
12 авг 09, 18:49    [7530053]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745


К сообщению приложен файл (instance5.zip - 1Kb) cкачать
12 авг 09, 18:49    [7530054]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Vertigo
Member

Откуда:
Сообщений: 610
mayton,
для начала iostat`ом смотрите загрузку дисков, на которых лежат архивлоги. busy=100% обычно соответствует действительности и означает, что диски не справляются. Кроме этого, нужно смотреть еще длину очереди запросов на в/в - чем больше, тем хуже. Статистика по лунам с массива тоже поможет.
Если не можете уйти с сата-дисков (а fc-диски в 5 или 50 рейде будут гораздо лучше), то увеличивайте количество групп так, чтобы они не успевали полностью заполниться в часы пик
12 авг 09, 19:43    [7530192]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Vertigo
mayton,
для начала iostat`ом смотрите загрузку дисков, на которых лежат архивлоги. busy=100% обычно соответствует действительности и означает, что диски не справляются. Кроме этого, нужно смотреть еще длину очереди запросов на в/в - чем больше, тем хуже. Статистика по лунам с массива тоже поможет.

Unix-оиды предлагают использовать утилиту sar. В принципе, она выдаёт нужную информацию, но формат её представления очень сырой и требует переработки. Кроме того мне еще надо разобраться, откуда она снимает статистику. Если с текущей ноды, то придётся объединять срезы счётчиков по 6 нодам (6-узловой кластер). Надо повозиться со скриптами и придумать.


Если не можете уйти с сата-дисков (а fc-диски в 5 или 50 рейде будут гораздо лучше), то увеличивайте количество групп так, чтобы они не успевали полностью заполниться в часы пик

Группы я уже увеличивал, но возникает здравый вопрос - а насколько собственно их увеличить? Сколько гиг надо впихнуть в этот буфер чтобы он выдержал шквал транзакций, особенно когда будет закрытие периода или не дай бог перестройка индексов разработчиком? На этот вопрос я ответить не могу.

По поводу SATA-дисков мы уже думали. Есть неплохой вариант - докупить дисков (если будет финансирование) и добавить их в группу. Очень надеюсь, что ASM-овское распыление экстентов поможет разбалансировать нагрузку.

Насчёт того, чтобы класть архи на SCSI группы - пока ответить не могу. Надо оценить место. Можем элементарно пролететь.
12 авг 09, 21:57    [7530569]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Vertigo
Member

Откуда:
Сообщений: 610
mayton

Unix-оиды предлагают использовать утилиту sar.

Так Вы не админ? Ну и не делайте за админов их работу - неблагодарное это дело. Пусть сами разбираются, что им использовать - просто спросите у них, не сдыхали ли диски под таким-то томом в такой-то период времени


Группы я уже увеличивал, но возникает здравый вопрос - а насколько собственно их увеличить?

посмотрите сколько логов переключилось за ваш усредненный час пик - можете стремиться к такому числу групп.
перестройка индексов разработчиком?

от всех дураков заранее не подстрахуешься. В былые лихие времени я на таких натравлял oradebug suspend, пока база не приходила в себя. Ну а по-правильному только руки отрывать таким

ASM-овское распыление экстентов

оно вам надо? обычный 50 рэйд здесь рулит
13 авг 09, 00:34    [7530893]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
ua2
Guest
mayton,

Може у Вас ще-й стендбай е?
13 авг 09, 03:09    [7531008]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Vertigo
Так Вы не админ? Ну и не делайте за админов их работу - неблагодарное это дело. Пусть сами разбираются, что им использовать - просто спросите у них, не сдыхали ли диски под таким-то томом в такой-то период времени

Unix-админы у нас - молодые и зелёные. И когда им говоришь-де SATA-группа сдохла - удивлённо хлопают глазами. Потом отпираются-де "типовая конфигурация, Не может этого быть.". Приходится доказывать.

посмотрите сколько логов переключилось за ваш усредненный час пик - можете стремиться к такому числу групп.

Я не слыхал о такой формуле. По моим отчётам из календаря переключений получается, что я должен создать порядка 25 логов объёмом 256Мб. Это получается где-то 6 Гигабайт редо-пространства.
13 авг 09, 09:12    [7531288]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
onstat-
Member

Откуда:
Сообщений: 6941
mayton
Vertigo
Так Вы не админ? Ну и не делайте за админов их работу - неблагодарное это дело. Пусть сами разбираются, что им использовать - просто спросите у них, не сдыхали ли диски под таким-то томом в такой-то период времени

Unix-админы у нас - молодые и зелёные. И когда им говоришь-де SATA-группа сдохла - удивлённо хлопают глазами. Потом отпираются-де "типовая конфигурация, Не может этого быть.". Приходится доказывать.

посмотрите сколько логов переключилось за ваш усредненный час пик - можете стремиться к такому числу групп.

Я не слыхал о такой формуле. По моим отчётам из календаря переключений получается, что я должен создать порядка 25 логов объёмом 256Мб. Это получается где-то 6 Гигабайт редо-пространства.


Увеличивайте размер редо логов .

Частое переключение редологов вносит дополнительные накладные расходы по записи грязных блоков в датафайлы, которые без переключения туда не писались бы , а записались бы позже, за это время в этих блоках могут еще какие либо изменения произойти, и они опять будут писаться.

Посмотрите, что там у хранилища с кешем на запись, если хранилище используется только под Вас, попробуйте вырубить кеш на чтение , оставьте только на запись.
Если есть возможности делить приоритет использования кеша по томам ,
добавьте томам с логами приоритета.
13 авг 09, 10:34    [7531697]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
onstat-

Увеличивайте размер редо логов .

Частое переключение редологов вносит дополнительные накладные расходы по записи грязных блоков в датафайлы, которые без переключения туда не писались бы , а записались бы позже, за это время в этих блоках могут еще какие либо изменения произойти, и они опять будут писаться.
.

это вам кажеться ))
13 авг 09, 10:37    [7531712]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
onstat-
Посмотрите, что там у хранилища с кешем на запись, если хранилище используется только под Вас, попробуйте вырубить кеш на чтение , оставьте только на запись.
Если есть возможности делить приоритет использования кеша по томам ,
добавьте томам с логами приоритета.
Спасибо. Это интересное предложение. Надо поискать информацию по нашему Clarion-у.
13 авг 09, 10:45    [7531756]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
onstat-
Member

Откуда:
Сообщений: 6941
pravednik



это вам кажеться ))


возможно.

Я в своих словах(логике) исходил из

http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10752/build_db.htm#19559

Sizing Redo Log Files

The size of the redo log files can influence performance, because the behavior of the database writer and archiver processes depend on the redo log sizes. Generally, larger redo log files provide better performance. Undersized log files increase checkpoint activity and reduce performance.

Although the size of the redo log files does not affect LGWR performance, it can affect DBWR and checkpoint behavior. Checkpoint frequency is affected by several factors, including log file size and the setting of the FAST_START_MTTR_TARGET initialization parameter. If the FAST_START_MTTR_TARGET parameter is set to limit the instance recovery time, Oracle automatically tries to checkpoint as frequently as necessary. Under this condition, the size of the log files should be large enough to avoid additional checkpointing due to under sized log files. The optimal size can be obtained by querying the OPTIMAL_LOGFILE_SIZE column from the V$INSTANCE_RECOVERY view. You can also obtain sizing advice on the Redo Log Groups page of Oracle Enterprise Manager Database Control.

It may not always be possible to provide a specific size recommendation for redo log files, but redo log files in the range of a hundred megabytes to a few gigabytes are considered reasonable. Size your online redo log files according to the amount of redo your system generates. A rough guide is to switch logs at most once every twenty minutes.


Если я не прав, покажите как все происходит на самом деле.
13 авг 09, 10:57    [7531854]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
pravednik
Member

Откуда: Jacksonville, FL
Сообщений: 16268
onstat-

Если я не прав, покажите как все происходит на самом деле.

вы не правы в утверждении, что если не переключаются, то и не пишуться...
при переключении срабатывает низко приоритетная нормальная контрольная точка, которая "растягивается" по времени..то есть лог может и не переключаться, а дбвр будет писать...
+ ко всему есть и инкрементальный чекпоинт, который зависит от LOG_CHECKPOINT_TIMEOUT, LOG_CHECKPOINT_INTERVAL, FAST_START_MTTR_TARGET, FAST_START_IO_TARGET
13 авг 09, 11:10    [7531942]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
onstat-
Member

Откуда:
Сообщений: 6941
pravednik
onstat-

Если я не прав, покажите как все происходит на самом деле.

вы не правы в утверждении, что если не переключаются, то и не пишуться...
при переключении срабатывает низко приоритетная нормальная контрольная точка, которая "растягивается" по времени..то есть лог может и не переключаться, а дбвр будет писать...
+ ко всему есть и инкрементальный чекпоинт, который зависит от LOG_CHECKPOINT_TIMEOUT, LOG_CHECKPOINT_INTERVAL, FAST_START_MTTR_TARGET, FAST_START_IO_TARGET


onstat-
а записались бы позже,


Когда позже я не описывал,
Это позже определяется параметрами приведенными Вами.
или вы хотите что бы по любому вопросу расписывал всю теорию от и до,

тут что все так делают ?

Давайте не будем придираться к словам.

Я не совсем понял что мне кажется, расшифруйте пожалуйста .
13 авг 09, 11:20    [7532023]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Vertigo
Member

Откуда:
Сообщений: 610
По поводу слишком маленького размера редологов - смотрите WRITES_LOGFILE_SIZE в V$INSTANCE_RECOVERY
13 авг 09, 15:07    [7534006]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Я считаю, что размер редо-логов нормальный. По тем отчётам из v$log_history, что я приводил выше:

(за понедельник, вторник, среду и четверг)
99+65+52+30(переключений) / 4(суток) = 246 / 96(часов) = 2.5 переключения/час

Итого 2.5 переключения в час. В среднем - очень нормальная цифра (по моему мнению). Другое дело, что с 10 до 11 часов у нас происходит какой-то поток пишуших транзакций. И арк затыкается. Это да...
13 авг 09, 15:27    [7534175]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Предлагая увеличить Редо я исходил из:
mayton


посмотрите сколько логов переключилось за ваш усредненный час пик - можете стремиться к такому числу групп.

Я не слыхал о такой формуле. По моим отчётам из календаря переключений получается, что я должен создать порядка 25 логов объёмом 256Мб. Это получается где-то 6 Гигабайт редо-пространства.


ИМХО лучше иметь 5 групп по Гигу чем 25 по 256 М .


Вот нагуглил интересную перезнташку
страницы 18 и 19.
13 авг 09, 16:23    [7534715]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
Vertigo
Member

Откуда:
Сообщений: 610
mayton
Я не слыхал о такой формуле.

о какой формуле идет речь? Это простая логика. Если у Вас лог архивируется дольше, чем заполняется, то как Вы еще сможете спастись от ситуации, когда заполняться все группу редо, кроме как держать необходимый объем в группах и архивировать его уже потихоньку потом, после того как нагрузка спадет?
Посмотрите, сколько времени архивируется лог:
select to_char(NEXT_TIME,'HH24:mi:ss'),to_char(COMPLETION_TIME,'HH24:mi:ss'),STANDBY_DEST 
from v$archived_log where SEQUENCE#=68921;

TO_CHAR( TO_CHAR( STA
-------- -------- ---
19:50:11 19:50:23 NO
и посмотрите, через сколько минут переключаются группы, и Вам будет что предъявить админам, несмотря на "типовую конфигурацию"

onstat-
ИМХО лучше иметь 5 групп по Гигу чем 25 по 256 М .
все зависит от ситуации, иногда и хуже, например, когда я не хочу, чтобы стендбай со сконфигуренным arch-транспортом потерял при актуализации в четыре раза больше последних редо-данных.
13 авг 09, 20:33    [7535989]     Ответить | Цитировать Сообщить модератору
 Re: Затруднения при переключении арк-логов  [new]
mayton
Member

Откуда: loopback
Сообщений: 49745
Vertigo
о какой формуле идет речь? Это простая логика. Если у Вас лог архивируется дольше, чем заполняется, то как Вы еще сможете спастись от ситуации, когда заполняться все группу редо, кроме как держать необходимый объем в группах и архивировать его уже потихоньку потом, после того как нагрузка спадет?

Да это всё понятно. Буферная зона и т.д. Мне нужно до сути докопать. Почему арк-процесс задумывается на 10-15 минут? Узкое место - канал между Raid10 (redo) и SATA (log_archive_dest) ? Тогда это проблема не только этой базы. В этом хранилище висит еще десяток баз.
13 авг 09, 20:42    [7536013]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Oracle Ответить