Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Приветствую, о великие ГУРУ в оракле.
Меня кидают с одного проекта на другой, типа, для затыкания дыр. Вот и вчера кинули на проблему по проекту. Повисли как бы сессии. Сделал AWR-ку. И вижу перегруз: [attachment 30736 01_1.png] [attachment 30737 01_2.png] |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
[attachment 30738 01_3.png]
[attachment 30739 01_4.png] Запрос:
План:
Исправлено 1 раз(а). Последнее : ВладимирС, 14.03.19 08:57 |
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 |
Re: Oracle. Администрирование. | |
---|---|
pasha_usue Сообщений: 3647 Откуда: Е-бург Дата регистрации: 06.10.2006 |
Про load не скажу. Но на Title - факт не хватает эффективных индексов. Возможно year был бы эффективным, если там статистика за много лет уже.
Я в оракл-планах не силён. Но ведь факт, title выбирается 2 раза и сам с собой джойнится. Что это? Алиас подзрапроса "title" выбран неудачно? |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Соглашусь, что ЭФФЕКТИВНЫХ индексов у них мало: [attachment 30741 01.png] Надо им предложить поменять последовательность полей для одного индекса. С другой стороны часто используют поле TITLE_NUMBER. Исправлено 1 раз(а). Последнее : ВладимирС, 14.03.19 09:25 |
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 |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо тебе большое.
Да, спасибо. Как-то я им помогал в аналогичном запросе... тоже разворачивал код этой вьюхи для более лучшего плана. Но они все равно ее используют. Уже забыл... столько запросов для анализа делал. Наверное тупанул. Но меня заинтересовало, что они сдали проект без нагрузочного тестирования. При нем этот косяк вылез бы. А теперь перед заказчиками как бы стыдно. |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Тут навязывают курсы
Диагностика производительности по отчётам AWR и ASH Мне это очень интересно. Но меня скорее не отпустят. Отсюда вопрос: Где почитать про AWR и ASH ? Хочу добиться хорошего их анализа. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Видимо только в официальной доке - но это, конечно, тяжелее и медленнее чем послушать объяснения на курсах
------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Хм... Еще есть вопрос...
Вот если добавлять записи типа
И начинаешь следить за этим UNDOTBS по заполненности... и при необходимости дробить количество записываемых данных. Но, при организации EXTERNAL TABLE из файла и добавлять записи аналогично:
Вопрос почему ? Как происходит вставка записей в этом случае ? Или я просто не успеваю увидеть явления. |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Хм...
Тут начал анализировать один сервак. На котором оракл крутится. И заметил одно явление (может я что-то недопонимаю): Память у сервера:
SGA PGA:
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
Но если доку посмотреть: maximum PGA allocated Maximum number of bytes of PGA memory allocated at one time since instance startup.То все хранилось в памяти... Как так ?, если ее всего 860Mb. Выходит писалось на диск ? Исправлено 1 раз(а). Последнее : ВладимирС, 05.07.19 13:36 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
А в чём проблема то? target значит цель - автоуправление памятью (надеюсь оно таки включено у тебя иначе эти настройки бессмысленны) будет стремиться такой объём поддерживать, но если надо больше, то куда ж ему деваться - будет жрать больше.
Естественно что если объём превысит размеры физической памяти то что-то запишется и в своп. ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо...
|
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Прошу совета...
В одном проекте. При загрузке данных заполняется Tablespace UNDO. [attachment 31394 UNDO.jpg] Проект чужой. Запускается только процедура из пакета. А там куча вызовов других процедур. При 100% заполнении интересно оракл выдаст ошибку ? В данном случае это был максимум заполненности UNDO. Я понимаю, что это динамическое место и освободится, когда нагрузка спадет. Просто напрягает. При заполненности 100%... интересно надо скорее всего пополнять Tablespace новым файлом ? Что не хотелось бы. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Это нормально. Чем больше объём изменений, и чем большее значение undo_retention, тем больший объём undo пространства требуется. Для транзакции вносящей изменений - нет, не будет ошибок. Для транзакций читающих данные из меняющихся таблиц (данные, которые изменены но ещё не закоммичены, или же если читающая транзакция сама по себе очень долгоиграющая) - да, может возникнуть ошибка ORA-01555 Snapshot Too Old. Посколькоу именно undo блоки используются для обеспечения согласованного чтения. Более глубоко - для восстановления (временного - только для читающей транзакции) состояния блока изменённого другой транзакцией. Место в undo пространстве освободится (для использования новыми транзакциями), но его размер (физическое место на диске) - нет. Он как был раздут до 32Гб, таким и останется. В очень старых версиях - да, новые файлы добавлять. Но уже в 10-ке есть BigFile Tablespace - где с отдельными файлами не надо заморачиваться, т.к. они могут быть до 32Тб в размере (для "штатного" размера блока в 8К) - ну, конечно, надо учитывать и ограничения используемой файловой системы Вообще такой большой undo нужен по сути лишь для устранения ошибок Snapshot Too Old, если нельзя изменить саму логику как модификации, так и чтения данных (в разных транзакциях). Ну и в случае использования flashback (ретроспективных) запросов - это запросы с опцией "данные по состоянию на X часов назад". ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Просто давненько встретился с такой проблемой (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. Что не хочется. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Я ж говорю - заполнение undo не критично. Запускай "загрузки" по ночам, никто и не заметит.
------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Как не критично ? Переживаю, что оракл остановится. Другие работы это в основном запросы и отчеты. Перед запуском процедуры, UNDO порядка 4% заполнено. А там процедура через JOB (ручной) запускается. При работе в лог работы скорее всего отразится ошибка. Но потом все заново трудно откатить. Все чужое. Конечно при возникновении ошибки придется анализировать все процедуры в какие таблицы произошла запись данных. И потом (т.к. возможно расчет не закончится удачно) 1. удалять записи из таблиц. 2. добавить все таки в UNDO еще один файл. 3. заново произвести расчет. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Не остановится. Пострадать могут лишь долгоиграющие транзакции в других сессиях - малореальный сценарий - ну разве что параллельно с заливкой ты запустишь создание дампа в консистентном режиме - вот тогда это долгое чтение сломается с ошибкой Snapshot Too Old.
Транзакционная целостность так же гарантируется - скорее всего там одна транзакция на весь процесс (на вызовы всей кучи ХП), и потому в случае сбоя система сама всё вернёт в исходное состояние, это не фокс, и не надо руками что-то чинить после полу-проведенного расчёта. Конечно, если разработчики идиоты, то всякое возможно - может они напихали коммитов абы куда и возможно "логическое" повреждение данных - ну когда часть работы закоммичена а другая часть - нет. Но это вообще никак не связано с размером undo и никакие "наращивания" места при этом не помогут. ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Игорь,
БОЛЬШОЕ СПАСИБО за разъяснения... |
© 2000-2024 Fox Club  |