:: Не фоксом единым
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Приветствую, о великие ГУРУ в оракле.
Меня кидают с одного проекта на другой, типа, для затыкания дыр.
Вот и вчера кинули на проблему по проекту.
Повисли как бы сессии.
Сделал AWR-ку.
И вижу перегруз:
[attachment 30736 01_1.png]

[attachment 30737 01_2.png]
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
[attachment 30738 01_3.png]

[attachment 30739 01_4.png]

Запрос:
SELECT TITLE_TYPE_ID AS titleTypeId,
NVL (BIV.QUARTER_NUMBER, 0) AS quarter,
NVL (SUM (BIV.VALUE), 0) AS VALUE
FROM (SELECT *
FROM title
WHERE state_id != 4
AND delete_date IS NULL
AND stage_id = :StageId
AND year = :AIPyear
AND id IN (SELECT ID
FROM TITLE_DETAIL
WHERE TITLE_DETAIL.ISACTIVE = 'Y')) title
INNER JOIN (SELECT *
FROM BUILD_INDICATOR
WHERE BUILD_INDICATOR_TYPE_ID = 3) BI
ON title.ID = BI.TITLE_ID
LEFT JOIN
(SELECT BUILD_INDICATOR_ID,
VALUE,
QUARTER_NUMBER,
YEAR
FROM BUILD_INDICATOR_VALUE
WHERE BUILD_INDICATOR_VALUE_TYPE_ID = 1 AND Year = :AIPyear) BIV
ON BI.ID = BIV.BUILD_INDICATOR_ID
GROUP BY TITLE_TYPE_ID, BIV.QUARTER_NUMBER
ORDER BY TITLE_TYPE_ID, BIV.QUARTER_NUMBER


План:
Plan hash value: 3608865921
---------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 15 | 300 | | 20734 (1)| 00:04:09 |
| 1 | SORT GROUP BY | | 15 | 300 | | 20734 (1)| 00:04:09 |
| 2 | VIEW | VM_NWVW_2 | 52 | 1040 | | 20734 (1)| 00:04:09 |
| 3 | HASH UNIQUE | | 52 | 5096 | | 20734 (1)| 00:04:09 |
| 4 | NESTED LOOPS OUTER | | 52 | 5096 | | 20733 (1)| 00:04:09 |
| 5 | NESTED LOOPS | | 43 | 3096 | | 20604 (1)| 00:04:08 |
|* 6 | FILTER | | | | | | |
|* 7 | HASH JOIN OUTER | | 23 | 1035 | | 20512 (1)| 00:04:07 |
|* 8 | TABLE ACCESS BY INDEX ROWID| TITLE | 23 | 828 | | 7 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | IDX_TITLE | 24 | | | 3 (0)| 00:00:01 |
| 10 | VIEW | | 5 | 45 | | 20505 (1)| 00:04:07 |
|* 11 | FILTER | | | | | | |
| 12 | HASH GROUP BY | | 5 | 340 | | 20505 (1)| 00:04:07 |
|* 13 | HASH JOIN | | 506K| 32M| 18M| 20491 (1)| 00:04:06 |
|* 14 | TABLE ACCESS FULL | TITLE | 506K| 12M| | 9120 (1)| 00:01:50 |
| 15 | TABLE ACCESS FULL | TITLE | 522K| 20M| | 9120 (1)| 00:01:50 |
|* 16 | TABLE ACCESS BY INDEX ROWID | BUILD_INDICATOR | 2 | 54 | | 4 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | IDX_BUILD_INDICATOR_TITLE_ID | 7 | | | 2 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | BUILD_INDICATOR_VALUE | 1 | 26 | | 3 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | IDX_BIV_ID__BI_ID | 10 | | | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - filter(CASE WHEN ("H"."ISACTIVE"=1 AND "DELETE_DATE" IS NULL) THEN 'Y' ELSE 'N' END ='Y')
7 - access("H"."ID"(+)="ID")
8 - filter("STATE_ID"<>4)
9 - access("DELETE_DATE" IS NULL AND "STAGE_ID"=TO_NUMBER(:STAGEID) AND "YEAR"=TO_NUMBER(:AIPYEAR))
filter("STAGE_ID"=TO_NUMBER(:STAGEID) AND "YEAR"=TO_NUMBER(:AIPYEAR))
11 - filter("T"."CREATE_DATE"=MAX("T"."CREATE_DATE"))
13 - access("T"."ENTITY_ID"="T"."ENTITY_ID" AND "T"."STAGE_ID"="T"."STAGE_ID" AND "T"."YEAR"="T"."YEAR")
14 - filter("T"."DELETE_DATE" IS NULL)
16 - filter("BUILD_INDICATOR_TYPE_ID"=3)
17 - access("TITLE"."ID"="BUILD_INDICATOR"."TITLE_ID")
18 - filter("BUILD_INDICATOR_VALUE_TYPE_ID"(+)=1 AND "YEAR"(+)=TO_NUMBER(:AIPYEAR))
19 - access("BUILD_INDICATOR"."ID"="BUILD_INDICATOR_ID"(+))



Исправлено 1 раз(а). Последнее : ВладимирС, 14.03.19 08:57
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
При большом количестве пользователей - зависание.
Хотя залочивания не было.
Память: 32 Gb.
Вот CPU всего 4.

Load – 13-15 при 4 CPU.

Отсюда вопрос:
В чем меряется параметр Load ?
Понятно, что запрос надо оптимизировать...

Но м.б. у заказчика теперь потребовать
Увеличение количества CPU ?

На всякий PGA SGA:

[attachment 30740 01_5.png]



Исправлено 4 раз(а). Последнее : ВладимирС, 14.03.19 09:13
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
pasha_usue

Сообщений: 3647
Откуда: Е-бург
Дата регистрации: 06.10.2006
Про load не скажу. Но на Title - факт не хватает эффективных индексов. Возможно year был бы эффективным, если там статистика за много лет уже.

Я в оракл-планах не силён. Но ведь факт, title выбирается 2 раза и сам с собой джойнится. Что это? Алиас подзрапроса "title" выбран неудачно?
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
pasha_usue
Про load не скажу. Но на Title - факт не хватает эффективных индексов. Возможно year был бы эффективным, если там статистика за много лет уже.
Я в оракл-планах не силён. Но ведь факт, title выбирается 2 раза и сам с собой джойнится. Что это? Алиас подзрапроса "title" выбран неудачно?
Соглашусь, что ЭФФЕКТИВНЫХ индексов у них мало:

[attachment 30741 01.png]

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



Исправлено 1 раз(а). Последнее : ВладимирС, 14.03.19 09:25
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
TITLE_DETAIL - какая то стрёмная вьюха, лучше или развернуть её минимально необходимую часть (то что определяет ISACTIVE = 'Y') в просто подзапрос - или может даже банально допусловие к основной части, или хотя-бы поменять способ связи с ней на inner join (если там id в результате уникально, то это эквивалентно исходному запросу будет) - возможно тогда хотя бы не с неё начнёт плясать, а с хорошо оптимизированной части где как раз работают условия идеально ложащиеся на IDX_TITLE, а эту (самую тяжёлую сейчас) хренотень через NESTED LOOPS подтянет.
Оракл вообще частенько начинает тупить когда в запросах представления встречаются - хотя судя по плану там и не должно было ничего "этакого" быть в запросе, но...

Из "тупых" советов - прежде всего пересобрать статистику, включая гистограммы (особенно если распределение значений сильно "перекошено" - ну типа в поле бывают значени 1,2,3, но 99.9% это 1, 0.1% это 2 и всего 1-2 раза 3-ка встречается).

Не очень понял зачем ты latch free подчеркнул - вроде как в нём нет проблем


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спасибо тебе большое.
Igor Korolyov
TITLE_DETAIL - какая то стрёмная вьюха, лучше или развернуть её минимально необходимую часть (то что определяет ISACTIVE = 'Y') в просто подзапрос - или может даже банально допусловие к основной части, или хотя-бы поменять способ связи с ней на inner join ...
Да, спасибо.
Как-то я им помогал в аналогичном запросе... тоже разворачивал код этой вьюхи для более лучшего плана. Но они все равно ее используют.

Igor Korolyov
Не очень понял зачем ты latch free подчеркнул - вроде как в нём нет проблем
Уже забыл... столько запросов для анализа делал.
Наверное тупанул.

Но меня заинтересовало, что они сдали проект без нагрузочного тестирования. При нем этот косяк вылез бы.
А теперь перед заказчиками как бы стыдно.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Тут навязывают курсы
Диагностика производительности по отчётам AWR и ASH
Мне это очень интересно.
Но меня скорее не отпустят.
Отсюда вопрос:
Где почитать про AWR и ASH ?
Хочу добиться хорошего их анализа.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Видимо только в официальной доке - но это, конечно, тяжелее и медленнее чем послушать объяснения на курсах


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Хм... Еще есть вопрос...
Вот если добавлять записи типа
INSERT INTO ...
SELECT ...FROM ...
То при большом количестве записей идет нагрузка на TABLESPACE UNDOTBS ну или кто как организует...
И начинаешь следить за этим UNDOTBS по заполненности... и при необходимости дробить количество записываемых данных.

Но, при организации EXTERNAL TABLE из файла и добавлять записи аналогично:
INSERT INTO ...
SELECT ...FROM ...
То не наблюдается нагрузки на TABLESPACE UNDOTBS. Вроде как сразу TABLESPACE в которой живет таблица.
Вопрос почему ? Как происходит вставка записей в этом случае ? Или я просто не успеваю увидеть явления.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Хм...
Тут начал анализировать один сервак. На котором оракл крутится. И заметил одно явление (может я что-то недопонимаю):
Память у сервера:
[root@localhost ~]# cat /proc/meminfo
MemTotal: 2195872 kB
MemFree: 43328 kB
...
Т.е. RAM 2Gb.
SGA PGA:
select name,value, display_value
from v$parameter
where name in ('db_cache_size','pga_aggregate_target','sga_max_size','sga_target','memory_target','memory_max_target');
NAME                VALUE     DISPLAY_VALUE
sga_max_size      901775360   860M
sga_target                0     0
memory_target     901775360   860M
memory_max_target 901775360   860M
db_cache_size             0     0
pga_aggregate_target      0     0
Т.е. SGA PGA 860Mb с автоматическим распределением памяти.
Вроде как все ОК.
Но, как мог максимальный PGA
SELECT ROUND(VALUE/1024/1024/1024,1) as MAX_PGA_GB FROM V$PGASTAT
WHERE name='maximum PGA allocated';
MAX_PGA_GB = 2.4 Gb

Но если доку посмотреть:
maximum PGA allocated             Maximum number of bytes of PGA memory allocated at one time since instance startup.
То все хранилось в памяти... Как так ?, если ее всего 860Mb. Выходит писалось на диск ?



Исправлено 1 раз(а). Последнее : ВладимирС, 05.07.19 13:36
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
А в чём проблема то? target значит цель - автоуправление памятью (надеюсь оно таки включено у тебя иначе эти настройки бессмысленны) будет стремиться такой объём поддерживать, но если надо больше, то куда ж ему деваться - будет жрать больше.
Естественно что если объём превысит размеры физической памяти то что-то запишется и в своп.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спасибо...
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Прошу совета...
В одном проекте. При загрузке данных заполняется Tablespace UNDO.

[attachment 31394 UNDO.jpg]

Проект чужой. Запускается только процедура из пакета. А там куча вызовов других процедур.
При 100% заполнении интересно оракл выдаст ошибку ?
В данном случае это был максимум заполненности UNDO. Я понимаю, что это динамическое место и освободится, когда нагрузка спадет.
Просто напрягает.
При заполненности 100%... интересно надо скорее всего пополнять Tablespace новым файлом ?
Что не хотелось бы.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
ВладимирС
Прошу совета...
В одном проекте. При загрузке данных заполняется Tablespace UNDO.
Это нормально. Чем больше объём изменений, и чем большее значение undo_retention, тем больший объём undo пространства требуется.

ВладимирС
Проект чужой. Запускается только процедура из пакета. А там куча вызовов других процедур.
При 100% заполнении интересно оракл выдаст ошибку ?
Для транзакции вносящей изменений - нет, не будет ошибок. Для транзакций читающих данные из меняющихся таблиц (данные, которые изменены но ещё не закоммичены, или же если читающая транзакция сама по себе очень долгоиграющая) - да, может возникнуть ошибка ORA-01555 Snapshot Too Old.
Посколькоу именно undo блоки используются для обеспечения согласованного чтения. Более глубоко - для восстановления (временного - только для читающей транзакции) состояния блока изменённого другой транзакцией.

ВладимирС
В данном случае это был максимум заполненности UNDO. Я понимаю, что это динамическое место и освободится, когда нагрузка спадет.
Место в undo пространстве освободится (для использования новыми транзакциями), но его размер (физическое место на диске) - нет. Он как был раздут до 32Гб, таким и останется.

ВладимирС
При заполненности 100%... интересно надо скорее всего пополнять Tablespace новым файлом ?
Что не хотелось бы.
В очень старых версиях - да, новые файлы добавлять. Но уже в 10-ке есть BigFile Tablespace - где с отдельными файлами не надо заморачиваться, т.к. они могут быть до 32Тб в размере (для "штатного" размера блока в 8К) - ну, конечно, надо учитывать и ограничения используемой файловой системы

Вообще такой большой undo нужен по сути лишь для устранения ошибок Snapshot Too Old, если нельзя изменить саму логику как модификации, так и чтения данных (в разных транзакциях). Ну и в случае использования flashback (ретроспективных) запросов - это запросы с опцией "данные по состоянию на X часов назад".


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
В очень старых версиях - да, новые файлы добавлять. Но уже в 10-ке есть BigFile Tablespace - где с отдельными файлами не надо заморачиваться, т.к. они могут быть до 32Тб в размере (для "штатного" размера блока в 8К) - ну, конечно, надо учитывать и ограничения используемой файловой системы
Просто давненько встретился с такой проблемой (oracle 11.1.0.6) я у заказчика делал добавление и обновление данных. Получилось 100% заполнение UNDO. Пришлось звонить DBA. Он очень сильно ругался, но добавил файл в Tablespace. Работы завершились нормально. Я уехал. Но в памяти отразилось заполнение UNDO.
Вот теперь вижу, что напорюсь на эту проблему.
В этом проекте Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production.
undo_retention = 900 (стандарт)...
И я писал заказчику о прибавлении места в u01, для расширения других Tablespace. Добавили всего 200Gb. Места немного.
Скорее всего придется добавлять файл при заполнении UNDO. Что не хочется.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Я ж говорю - заполнение undo не критично. Запускай "загрузки" по ночам, никто и не заметит.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Я ж говорю - заполнение undo не критично. Запускай "загрузки" по ночам, никто и не заметит.
Как не критично ? Переживаю, что оракл остановится.
Другие работы это в основном запросы и отчеты. Перед запуском процедуры, UNDO порядка 4% заполнено.

А там процедура через JOB (ручной) запускается. При работе в лог работы скорее всего отразится ошибка. Но потом все заново трудно откатить. Все чужое. Конечно при возникновении ошибки придется анализировать все процедуры в какие таблицы произошла запись данных.
И потом (т.к. возможно расчет не закончится удачно)
1. удалять записи из таблиц.
2. добавить все таки в UNDO еще один файл.
3. заново произвести расчет.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Не остановится. Пострадать могут лишь долгоиграющие транзакции в других сессиях - малореальный сценарий - ну разве что параллельно с заливкой ты запустишь создание дампа в консистентном режиме - вот тогда это долгое чтение сломается с ошибкой Snapshot Too Old.

Транзакционная целостность так же гарантируется - скорее всего там одна транзакция на весь процесс (на вызовы всей кучи ХП), и потому в случае сбоя система сама всё вернёт в исходное состояние, это не фокс, и не надо руками что-то чинить после полу-проведенного расчёта. Конечно, если разработчики идиоты, то всякое возможно - может они напихали коммитов абы куда и возможно "логическое" повреждение данных - ну когда часть работы закоммичена а другая часть - нет. Но это вообще никак не связано с размером undo и никакие "наращивания" места при этом не помогут.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Игорь,
БОЛЬШОЕ СПАСИБО за разъяснения...
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 4 (Гостей: 4)

© 2000-2024 Fox Club 
Яндекс.Метрика