параметр db_file_multiblock_read_count не нужно менять
в 10 он на откупе у ORACLE - так рекомендует ORACLE
а ведь точно
alter system reset db_file_multiblock_read_count ...
Болел наверное когда тему проходили
To prog
А в ОЕМ Performance Analysis никаких рекомендаций не дает?
Определяет размер памяти, выделяемый каждому пользовательскому процессу на сортировку (UGA; может быть в расположена в SGA или PGA; используется, например, при обработке DISTINCT или ORDER BY). Если памяти не хватает, будет использоваться дисковое пространство – хороший способ "подсадить" работу системы. Увеличение параметра сократит число "дисковых" сортировок; в то же время объемных сортировок диска все равно не избежать. По окончанию сортировки память полностью возвращается в "кучу" UGA, то есть неприятными с точки зрения расходования памяти являются только одновременно выполняемые несколькими процессами сортировки.
SORT_AREA_RETAINED_SIZE
Задает максимальный размер памяти, динамически запрашиваемой у UGA на завершающую фазу процедуры сортировки, выполняемой с привлечением дисковой памяти. По завершению процедуры сортировки эта память возвращается, однако в завершающей стадии сортировки она может расходоваться в течение некоторого времени процессом в дополнение к "основной" памяти, регулируемой параметром SORT_AREA_SIZE. (В это время общая оперативная память, расходуемая процессом на сортировку, может достичь SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)
но так или иначе все равно надо смотреть на запросы пользователей, определить, чем забивается память. Кстати. а ibso патч то какой? Цфт начал (неудачное слово) менять оптимизацию представлений под 10 только в 8,8. Вобщем, смотреть надо со всех сторон, возможно и решение будет комплексным. Например, в ОЕМ увидел , что очень большую загрузку дает проверка документов по финмониторингу.
А однажды, после установки какого то из патчей тормоза жуткие были, пришлось индексы большие пересобрать.
Doc ID: 377037.1
Selects Against ALL_SYNONYMS Perform Badly on 10g Release 10.2
Медленное выполнение запросов с участием не оптимального представления ALL_SYNONYMS - кстати говоря оно в пакетах Т.Я. используется , так что рекомендую всем а особенно тем кто использует станцию сканирования FineReader Bank + ODBC и так - solution:
Код:
connect / as sysdba
create or replace view SYS.ALL_SYNONYMS_920X
(OWNER, SYNONYM_NAME, TABLE_OWNER, TABLE_NAME, DB_LINK)
as
select u.name, o.name, s.owner, s.name, s.node
from sys.user$ u, sys.syn$ s, sys.obj$ o
where o.obj# = s.obj#
and o.type# = 5
and o.owner# = u.user#
and (
o.owner# in (USERENV('SCHEMAID'), 1 /* PUBLIC */) /* user's private, any public */
or /* user has any privs on base object */
exists
(select null from sys.objauth$ ba, sys.obj$ bo, sys.user$ bu
where bu.name = s.owner
and bo.name = s.name
and bu.user# = bo.owner#
and ba.obj# = bo.obj#
and ( ba.grantee# in (select kzsrorol from x$kzsro)
or ba.grantor# = USERENV('SCHEMAID')
)
)
or /* user has system privileges */
exists (select null from v$enabledprivs
where priv_number in (-45 /* LOCK ANY TABLE */,
-47 /* SELECT ANY TABLE */,
-48 /* INSERT ANY TABLE */,
-49 /* UPDATE ANY TABLE */,
-50 /* DELETE ANY TABLE */)
)
)
/
2.
CREATE SYNONYM IBS.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_920X
3. Grant ALL on IBS.ALL_SYNONYMS to IBS;
4. @?/rdbms/admin/utlrp
- скорость выполнения некоторых запросов с использованием вьюхи существенно увеличивается, конкретно для сканирования документов у себя получили увлечение скорости валидации и экспорта платежки в 3 раза.
Определяет размер памяти, выделяемый каждому пользовательскому процессу на сортировку (UGA; может быть в расположена в SGA или PGA; используется, например, при обработке DISTINCT или ORDER BY). Если памяти не хватает, будет использоваться дисковое пространство – хороший способ "подсадить" работу системы. Увеличение параметра сократит число "дисковых" сортировок; в то же время объемных сортировок диска все равно не избежать. По окончанию сортировки память полностью возвращается в "кучу" UGA, то есть неприятными с точки зрения расходования памяти являются только одновременно выполняемые несколькими процессами сортировки.
SORT_AREA_RETAINED_SIZE
Задает максимальный размер памяти, динамически запрашиваемой у UGA на завершающую фазу процедуры сортировки, выполняемой с привлечением дисковой памяти. По завершению процедуры сортировки эта память возвращается, однако в завершающей стадии сортировки она может расходоваться в течение некоторого времени процессом в дополнение к "основной" памяти, регулируемой параметром SORT_AREA_SIZE. (В это время общая оперативная память, расходуемая процессом на сортировку, может достичь SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)
- PGA_AGREGATE_TARGET - рулил, рулит и будет рулить кстати Оракел не рекомендует использовать больше sort_area....
Насчет "не рекомендует" - к примеру, для анализа (сбора статистики) может потребоваться полный просмотр таблиц, индексов, у что соотно потребует бОльший обьем памяти. Цитиирую-
Цитата:
...необходимо непосредственно перед выполнением анализа изменить установки сеанса. По окнчании анализа нужно либо завершить сеанс, либо восстановить действовавшие до анализа установки сеанса.Изменению подлежат следующие установки сеанса:
SORT_AREA_SIZE и DB_FILE_MULTIBLOCKk_READ_COUNT.
Чем больше размер области сортировки, тем меньше вероятность того, что для сегментов сортировки потребуется использовать временнон табличное пространство. Чем выше значение счетчика многоблочного чтения , тем большее число блоков может быть считано за одну операцию физичесого считывания...
можно было в двух словах , но хотел именно процитировать(источник, вроде , серьезный ORACLE PRESS "ORACLE 10G Настольная книга администратора баз данных").
Из чего делаю вывод, использовать можно -НО остроожно.
Мы ведь хотим найти источник проблем(ы)
Цитата:
После перевода базы ибсо на 10 оракл сервер стал периодически падать:
сервер начинает жутко свопиться, работа замедляется, потом вообще перестает отвечать на любые запросы (oracle, ssh).
Помогает только перезагрузка.
В результате мониторинга удалось выяснить, что у некоторых сессий PGA вырастает в разы, достигая 1,5Гб
а потом уже найти решение, так ?
Ну и по ходу пополнить свои знания
To prog -кстати, насчет статистики , запущени ли AWR(STATISTICS_LEVEL= TYPICAL или ALL) ?
Насчет "не рекомендует" - к примеру, для анализа (сбора статистики) может потребоваться полный просмотр таблиц, индексов, у что соотно потребует бОльший обьем памяти. Цитиирую-
Цитата:
...необходимо непосредственно перед выполнением анализа изменить установки сеанса. По окнчании анализа нужно либо завершить сеанс, либо восстановить действовавшие до анализа установки сеанса.Изменению подлежат следующие установки сеанса:
?
- ключевое слово СЕАНСА и потом ранее были рекомендации к ручному выделению памяти серверному процессу, но со временем Oracle отказался от этого, лично я в документации Oracle после 2007 года не видел что рекомендуется использовать ручные параметры для области сортировки.
Васильев Николай пишет:
SORT_AREA_SIZE и DB_FILE_MULTIBLOCKk_READ_COUNT.
Чем больше размер области сортировки, тем меньше вероятность того, что для сегментов сортировки потребуется использовать временнон табличное пространство. Чем выше значение счетчика многоблочного чтения , тем большее число блоков может быть считано за одну операцию физичесого считывания...
? - что не всегда может полезно, СВО использует dbmrc для расчета метода доступа к объекту, любое "нажатие " на СВО - вы берете ответственность на себя - со своей стороны не буду более разубеждать, у себя не пользуюсь не sort_area ни dbmrc , на 8-ке активно использовал на 9-ке после экспериментов отказался от sort_area и на 10-ке выкинул совсем dbmrc - http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2006-04-20.2949600305/view?searchterm=db_file_multiblock_read_count, вот у Криса Фута например, там же по поиску послушайте его мнение, мои эксперименты покрайняк его не опровергают, а только подтверждают dbmrc - mus die forever!
Насчет "не рекомендует" - к примеру, для анализа (сбора статистики) может потребоваться полный просмотр таблиц, индексов, у что соотно потребует бОльший обьем памяти. Цитиирую-
Цитата:
...необходимо непосредственно перед выполнением анализа изменить установки сеанса. По окнчании анализа нужно либо завершить сеанс, либо восстановить действовавшие до анализа установки сеанса.Изменению подлежат следующие установки сеанса:
?
- ключевое слово СЕАНСА и потом ранее были рекомендации к ручному выделению памяти серверному процессу, но со временем Oracle отказался от этого, лично я в документации Oracle после 2007 года не видел что рекомендуется использовать ручные параметры для области сортировки.
Васильев Николай пишет:
SORT_AREA_SIZE и DB_FILE_MULTIBLOCKk_READ_COUNT.
Чем больше размер области сортировки, тем меньше вероятность того, что для сегментов сортировки потребуется использовать временнон табличное пространство. Чем выше значение счетчика многоблочного чтения , тем большее число блоков может быть считано за одну операцию физичесого считывания...
? - что не всегда может полезно, СВО использует dbmrc для расчета метода доступа к объекту, любое "нажатие " на СВО - вы берете ответственность на себя - со своей стороны не буду более разубеждать, у себя не пользуюсь не sort_area ни dbmrc , на 8-ке активно использовал на 9-ке после экспериментов отказался от sort_area и на 10-ке выкинул совсем dbmrc - http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2006-04-20.2949600305/view?searchterm=db_file_multiblock_read_count, вот у Криса Фута например, там же по поиску послушайте его мнение, мои эксперименты покрайняк его не опровергают, а только подтверждают dbmrc - mus die forever!
Обязательно почитаю.
Я ж специально прооцитировал, чтобы подчернуть именно конкретный случай (сеанс), когда изменение параметров может быть полезно.
Насчет PGA_AGGREGATE_TARGET полностью согласен (да и вообще тоже ). Собсно (но для 9), мож кому то будет полезно.
Цитата:
PGA_AGGREGATE_TARGET
Начиная с ORACLE9i, появился параметр PGA_AGGREGATE_TARGET (суммарная память PGA). В связи с этим ORACLE не рекомендует использовать параметры SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE, если ваша база данных сконфигурирована на режим DEDICATED. Теперь можно, включив автоматическое управление (workarea_size_policy=auto) доверить управление PGA самому ораклу. Все прочие параметры (*_area_size) управляющие размерами рабочих областей игнорируются. Корпорация Oracle рекомендует устанавливать значение параметра pga_aggregate_target, равное объему памяти, оставшейся свободной в сервере UNIX после запуска экземпляра (минус 20% на другие задачи ОС UNIX).
Сервер базы данных автоматически некоторым интеллектуальным способом распределяет эту память между различными активными запросами так, чтобы обеспечить максимальную производительность и наиболее эффективно использовать память. Кроме того, СУБД Oracle9i может сама адаптироваться к изменению рабочей нагрузки, таким образом, ресурсы используются эффективно независимо от нагрузки на систему. Объем памяти PGA, доступной экземпляру, можно изменять динамически, изменяя значение параметра PGA_AGGREGATE_TARGET. Работу по настройке параметра PGA_AGGREGATE_TARGET значительно упрощает представление – предсказатель V$PGA_TARGET_ADVICE.
Для баз данных, работающих в режиме разделяемых (shared) соединений по-прежнему действуют параметры sort_area_size, sort_area_retained_size и др., а pga_aggregate_target игнорируется.
Рекомендации по изменению значения pga_aggregate_target
Выполним запрос
Код:
select name, value from v$sysstat where name like 'workarea executions %'
Имеет смысл изменять значение параметра при условии:
увеличить значение pga_aggregate_target можно, если значение статистики “workarea executions – multipass” (количество операций обработки в многопроходном режиме) превышает 1%,
уменьшить значение pga_aggregate_target можно, если значение статистики “workarea executions – optimal” (количество операций обработки в оптимальном режиме) всегда равно 100%.
WORKAREA_SIZE_POLICY
Это параметр задает способ управления размерами рабочих областей. Может принимать значения AUTO или MANUAL. Если задан параметр PGA_AGGREGATE_TARGET, то WORKAREA_SIZE_POLICY по умолчанию принимает значение AUTO, в противном случае значение по умолчанию - MANUAL.
Если параметр установлен в AUTO, то размеры рабочих областей определяются автоматически (по какому-то внутреннему оракловскому алгоритму используя собранные статистические данные об использовании памяти экземпляром) исходя из значения PGA_AGGREGATE_TARGET, учитывая потребность конкретной операции. Очевидно, что AUTO возможно лишь при определении параметра PGA_AGGREGATE_TARGET.
Если параметр установлен в MANUAL, то рабочие области нужно определять вручную с помощью параметров *_area_size (SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE, CREATE_BITMAP_AREA_SIZE и т.д.)
А вообще , мож проблема уже решена? А то как в анекдоте про партизан . Автор что то молчит
параметр db_file_multiblock_read_count не нужно менять
в 10 он на откупе у ORACLE - так рекомендует ORACLE
а ведь точно
alter system reset db_file_multiblock_read_count ...
Болел наверное когда тему проходили
To prog
А в ОЕМ Performance Analysis никаких рекомендаций не дает?
А я так просто в диком восторге от ОЕМ! Давно таких продуктов не встречал. Как перешли на 10 , админ дал доступ, теперь мониторим на пару- эффект взаимодействия админа и разработчега поразительный!
Фтыкаю с удовольствием ! теперь никто ни накого зря не наезжает по поводу кривых запросов или настроек. При моем мизерном опыте AS DBA инструмент просто чудесный (IMHO!). Кстати, посмотрел на свой параметр query_rewrite_enabled, установлен в FALSE. Вобщем, рекомендую, весч!
To Serj
В ОЕМ есть рекомендация
Цитата:
Oracle recommends installing JAccelerator(NCOMP) which typically contains Natively compiled (NCOMP) classes for improved Java Virtual Machine performance. Please refer to the Post-installation Tasks section in the Database Install Guide for instructions on how to install JAccelerator.
Стоит ли это делать?
и еще ругается
Цитата:
Avoid use of non-standard initialization parameters. 1 Parameter Name_resource_manager_always_on
В init параметрах я его не вижу. Остался после экспорта импорта видимо?
Надо ли с этим что делать?
Oracle recommends installing JAccelerator(NCOMP) which typically contains Natively compiled (NCOMP) classes for improved Java Virtual Machine performance. Please refer to the Post-installation Tasks section in the Database Install Guide for instructions on how to install JAccelerator.
Стоит ли это делать?
- Стоит одназначно - это компилированые библиотеки Java ускоряют хранимый Java код - EM будет шустрить.
Васильев Николай пишет:
и еще ругается
Цитата:
Avoid use of non-standard initialization parameters. 1 Parameter Name_resource_manager_always_on
В init параметрах я его не вижу. Остался после экспорта импорта видимо?
Надо ли с этим что делать?
- _resource_manager_always_on - появился в 10.2 является скрытым в default-e выставлен в TRUE руками трогать сильно не рекомендуют. Ничего делать очевидно ненужно.
Сам ЕМ не очень пользуюсь, поковырял немного, посмотрел ну неплохо, но не больше - привычка работать в консоли делает свое черное дело.
после перехода на oracle10
в алерт логе сыпятся сообщения
ALTER SESSION SET optimizer_max_permutations specifies an obsolete parameter
Кто сталкивался?
В АРМе доступа в параметре ALTER SESSION необходимо убрать изменение optimizer_max_permutations. Параметр в 10-ке не работает
Да уж. Сам все перерыл на предмет причины появления этого сообщения про optimizer_max_permutations,
пока не догадался глянуть в upgr6612.zip (Обновление технологического ядра до версии 6.6.1.2)
А там конкретно:
prompt ALTER_SESSION for DEFAULT profile
insert into profiles(profile,resource_name,value,description) values('DEFAULT','ALTER_SESSION',
'optimizer_max_permutations=100 optimizer_index_cost_adj=3',
'Параметры пользовательских сессий с профайлом DEFAULT');
И даже если ничего не делать, то job'ы не спят и лепят в alert.log с частотой в 1 минуту много-много таких записей.
Кстати, а ИБСО не поплохеет от отсутствия управлеия оптимизатором?
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB