Oracle
 sql >> база данни >  >> RDS >> Oracle

Идентифициране на съдържанието на ASH последователност в RAC

В глава 3 на настройката на производителността на Oracle RAC показах как неправилните стойности на CACHE за последователности могат да причинят лоша производителност в Oracle RAC. Показах също как да забележите спорове за последователност, когато разглеждате изчакващи събития на сесия.

Днес работех с разработчик, който създаваше нова последователност. Разработчикът имаше CACHE стойност от 100, което ме накара първоначално то е е твърде ниска стойност. Забелязах тази ниска настройка по време на преглед на кода. Разработчикът смята, че стойността на CACHE е добра, но аз не съм убеден. Ще тестваме това при натоварване, за да видим дали стойността на CACHE трябва да бъде коригирана.

Междувременно си мислех „ами ако пропусна това по време на прегледа на кода?“ И последващ въпрос, „какво, ако не забелязахме нищо по време на тестване на натоварване?“ Искам да мога да се върна и да определя кои последователности, ако има такива, биха били кандидати за неправилна настройка на КЕШ. Със сигурност бих могъл да проследя сесиите и да анализирам файловете за проследяване, но това би било твърде болезнено. Затова създадох скрипт, който мога да изпълня срещу активна история на сесиите, за да помогна за определянето на последователностите кандидати.

select sh.sql_id,to_char(st.sql_text),count(*)
from dba_hist_active_sess_history sh
join dba_hist_sqltext st
 on sh.sql_id=st.sql_id
where st.sql_text like '%NEXTVAL%'
 and (event='row cache lock' or event like 'gc current block %-way')
group by sh.sql_id,to_char(st.sql_text)
order by count(*) desc;

Това не е съвършена наука поради естеството на събирането на пепел. Сесията, в която възниква спорът, трябва да бъде уловена в точното време, за да бъде в таблицата DBA_HIST_ACTIVE_SESSION_HISTORY. Но изявлението на SQL по-горе ми дава някои кандидати за разглеждане. Не всяка последователност, достъпна в върнатите SQL изрази, трябва да има коригирани стойности на CACHE. Ще е необходим допълнителен анализ. Това обаче ми дава списък с тези, които трябва да обмисля. И може да помогне да отговоря на първоначалните ми въпроси. Ако съм пропуснал създаването на последователност по време на прегледа на кода, надявам се, че мога да го намеря по-късно, ако последователността е проблем за производителността на приложението.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. ORA-12560:TNS:грешка в адаптера на протокола

  2. Регулярни изрази на Oracle. Опасна гама

  3. как да промените размера на колона

  4. Голямо .patch_storage

  5. Използване на „колона с израз на случай“ в клауза where