У меня пара замечаний по сабжу:
1. Для решения этой проблемы есть Adaptive cursor sharing, и он делает именно то, что нужно: на основе гистограмм создает подходящие дочерние курсоры. Если у них это не работало, значит надо было разбираться с причиной почему ACS не работал. Игорь Усольцев делал отличную подробную презентацию в российской юзергруппе оракл (RuOUG). Вообще, советую посещать наши мероприятия.
2. Раз на базе стоит cursor_sharing=force, то можно было просто создать профиль с одним единственным хинтом BIND_AWARE на любом из этих запросов, с указанием параметра force_match=>true.
3. Насчет динамики:
Понятно, что исправление приложения и использование параметров как литералов в запросе – это самый подходящий способ решения проблемы, но он ведет к динамическому SQL с его известными недостатками.
Я еще на 10-ке использовал несколько разных вариантов в зависимости от условий:
3.1 Если был возможен PL/SQL то просто разбивал через IF на пару разных вариантов, грубо говоря: IF cardinality>N then query1 else query2
A cardinality получал одним из быстрых способов.
3.2. Разбиение на union all с доп.подзапросом, например:
select/*+ index(t1 (a,b)) */ *
from t1
where ...
and (select count(*) from t1 where ... and rownum<=X)<X
union all
select/*+ full(t1) или index_ffs(t1) */ *
from t1
where ...
and (select count(*) from t1 where ... and rownum<=X)=X
И если данные уже промаркированы как в статье(отдельная таблица где помечены «большие/средние/маленькие»), то этот вариант был бы намного проще
4. Здесь неверно:
Другой путь – отключение запроса связанных переменных (ALTER SESSION SET "_OPTIM_PEEK_USER_BINDS" = FALSE) или удаление гистограмм (ссылка).
Это решение абсолютно для противоположной цели: отключение _OPTIM_PEEK_USER_BINDS и удаление гистограм делают в случае, если оракл плодит разные планы, а хочется строго одного и того же для любых биндов.
5. Существует и еще один подход: секционирование с учетом data skew. Тут вариантов много, одним из простейших является интервальное секционирование по «перекошенному» столбцу основного ACCESS предиката. А для статьи из примера удобно было бы секционировать как раз по SMALL/MIDDLE/LARGE, то есть три разные секции, каждая со своей статистикой(причем заработает даже без гистограмм, т.к. достаточно (num_rows-num_nulls)/num_distinct статистик по секции), что дает оптимизатору легко понять селективность столбца в данной секции.
ЗЫ. Надо было Виктору ко мне обратиться, вместе бы посмотрели почему ACS у них не работал.
Я давно написал и выделил, что речь именно о key entry.
продолжая утверждать, что key entry это ключ, и в который раз споря с моим «но никак не key», втыкая «key entry»?..
театр абсурда:
— это ключ
— это не ключ, не key
— нет, это ключ, так как "...key entry..."
— key entry != key
— да key entry!=key, но все равно entry = key
wtf?! Вы до сих пор так и не поняли, что ключ индекса — это index key? и что index key!=index entry? a index entry==entry==index key entry==key entry?
Перечитайте внимательно по своим же ссылкам у Кайта и ту же доку, если лень, то хотя бы п.7, который я вам специально процитировал даже.
Вернемся к самому началу:
In a bitmap index, you have:
a) a key value
b) a low-rowid value
c) a high-rowid value
d) a bit map that indicates for each rowid in that range whether the row that rowid points to has that value or not.
Suppose you have the EMP table and you create bitmap index bm on emp(deptno);
So, in the bitmap index, you might have key values like:
И вы предлагаете называть каждую такую запись ключом битмап индекса?! А что такое тогда deptno? бурлесоновщина в чистом виде…
зы. Про «что они ошиблись так же как и вы», я просто в первый раз доверился вам и не посмотрел внимательно, но оказалось, что у них все так же, как я и говорил. Не вырывайте из контекста.
ззы. раньше, кстати, там тоже ошибочно было упрощено как и в этой статье(показывали, что все для каждого значения ключа свой один bitmap, и каждый из них содержит все ROWIDs, что в корне неверно), что и породило миф о блокировке всех строк для изменяемого значения. И этот ответ на асктоме лишь от 2007 года, а Джулиан Дайк эту свою презентацию в первый раз прочитал еще в 2003. Так что я рад, что добавили деталей в 11.2, но спорить о существовании этого мифа довольно глупо.
ну и, пожалуй, самое интересное, если вы якобы знали то, о чем я говорил, то почему не заметили в этой статье несоответствие в описании структуры? Оно же гораздо важнее и идет в самом начале, в отличие от сентенции про ресурсы (про что тоже можно поспорить, т.к. изменение bitmap индекса более ресурсоемко)
мило, таки прочитал определение в первом же пункте из того документа, что такое index key и index key entry? :D Понаписал столько воды, вместо того, чтобы просто признать с самого начала, что это разные вещи. Ну хоть признал, и то хлеб…
Вы меня расстраиваете… Я понимаю, что можно плохо знать английский, можно не пройти теорию реляционных баз в универе, но не осилить пару предложений? Что вам в выделенном непонятно? Как это противоречит сказанному мной? Оно же и так чрезмерно упрощенное… Замечаете, что в первом из них «index key entry»?
index key != index key entry
Ну а пройтись хотя бы поиском по страничке на фразу «index key», как я уже подсказывал?
1
Keys and Columns
A key is a set of columns or expressions on which you can build an index. Although the terms are often used interchangeably, indexes and keys are different. Indexes are structures stored in the database that users manage using SQL statements. Keys are strictly a logical concept.
The following statement creates an index on the customer_id column of the sample table oe.orders:
CREATE INDEX ord_customer_ix ON orders (customer_id);
In the preceding statement, the customer_id column is the index key. The index itself is named ord_customer_ix.
2
For a nonunique index, the rowid is included in the key in sorted order, so nonunique indexes are sorted by the index key and rowid (ascending).
3
Reverse key indexes
In this type of index, the bytes of the index key are reversed, for example, 103 is stored as 301.
4
The database could use a range scan because the last_name column is specified in the predicate and multiples rowids are possible for each index key.
5
In a bitmap index, the database stores a bitmap for each index key.
6
CREATE BITMAP INDEX employees_bm_idx
ON employees (jobs.job_title)
FROM employees, jobs
WHERE employees.job_id = jobs.job_id;
As illustrated in Figure 3-2, the index keyis jobs.job_title and the indexed table is employees.
7. ну уж их этого-то куска невозможно не понять...
Bitmap Storage Structure
Oracle Database uses a B-tree index structure to store bitmaps for each indexed key. For example, if jobs.job_title is the key column of a bitmap index, then the index data is stored in one B-tree. The individual bitmaps are stored in the leaf blocks.
Assume that the jobs.job_title column has unique values Shipping Clerk, Stock Clerk, and several others. A bitmap index entry for this index has the following components:
The job title as the index key
A low rowid and high rowid for a range of rowids
A bitmap for specific rowids in the range
Conceptually, an index leaf block in this index could contain entries as follows:
Shipping Clerk,AAAPzRAAFAAAABSABQ,AAAPzRAAFAAAABSABZ,0010000100
Shipping Clerk,AAAPzRAAFAAAABSABa,AAAPzRAAFAAAABSABh,010010
Stock Clerk,AAAPzRAAFAAAABSAAa,AAAPzRAAFAAAABSAAc,1001001100
Stock Clerk,AAAPzRAAFAAAABSAAd,AAAPzRAAFAAAABSAAt,0101001001
Stock Clerk,AAAPzRAAFAAAABSAAu,AAAPzRAAFAAAABSABz,100001
.
.
. The same job title appears in multiple entries because the rowid range differs.
Assume that a session updates the job ID of one employee from Shipping Clerk to Stock Clerk. In this case, the session requires exclusive access to the index key entry for the old value (Shipping Clerk) and the new value (Stock Clerk). Oracle Database locks the rows pointed to by these two entries—but not the rows pointed to by Accountant or any other key—until the UPDATE commits.
зы. если уж пытаетесь свалить на незнание английского, то попробуйте тогда найти определение на ключ индекса на русском…
А если внимательно прочтете этот же кусок, который привели(особое внимание на пример в скобках) и, собственно, посмотрите в других местах, что они имеют ввиду под этим, то поймёте, что они ошиблись так же как и вы, но они не так категоричны: typically locks all these rows, что им позволит сказать, что, мол, мы и не говорили, что прямо всегда и все строки
Да нет, я прочитал все верно, поэтому если вы и хотели написать то же, что и я, то вы выражаетесь не общей терминологией, в которой (как у Кайта, так и у любых других авторов) «Ключ индекса» — это key value/values, а реально блокируются только записи в изменяемой битовой карте(bitmap, bitmap piece, index entry, но никак не key)
В принципе, это не мое дело, но дабы уберечь хоть кого-нибудь от бесполезной траты времени на чтение его бреда, я думаю, что надо перечислить как минимум главное «чем он плох»:
1. Введение в заблуждение:
В первую очередь, тем, что хоть и неосознанно, но постоянно вводит огромное число людей в заблуждение, т.к. алгоритмы Google не учитывают ценность и точность информации, его сайт и форум имеют слишком широкую аудиторию.
2. Недостаток знаний:
Вообще же корень проблемы в том, что в заблуждение он вводит из-за того, что он очень поверхностно знает Oracle. В то время как профессионалы докапываются до реальных причин и детально изучают Oracle internals, он постоянно делает поверхностные поспешные выводы, да еще и на основе однократных событий: увидел А и B вместе, и сразу делает вывод, что A привело к B, да еще и если еще раз увидит B, то сразу скажет что виноват А… (кстати, почитайте еще про BAAG)
3. Уверенность в своих заблуждениях:
Чисто для сравнения: многие оракловые специалисты прямо в аннотации пишут, что не нужно слепо доверять написанному и предоставляют тест-кейсы, чтобы вы могли сами проверить и изучить все данные утверждения. Что же любит Дон Бурлесон? А он просто удаляет и банит людей за посты, в которых лишь высказывается сомнение в тех или иных его утверждениях. Мы все, конечно, бредем по кривой Даннинга-Крюгера, но ему много лет, а он где-то подзастрял и до долины отчаяния не дошел…
накладывается блокировка на изменение всех(!) строк таблицы, содержащихся в этом ключе битмап индекса.
Как я уже ниже советовал, почитайте Ричарда Фута!
Вообще это один из известных мифов, и является полуправдой:
1. с одной стороны, действительно многие записи с таким же значением будут заблокированы, но
2. на самом деле, заблокированы будут только те записи, которые находятся в том же куске со списком ROWIDs, что и изменяемая запись, тк при большом кол-ве записей они не хранятся единым куском. (про реальное строение читайте у Р.Фута или просто проанализируйте дамп индекса)
Проверяется очень легко:
1. создайте таблицу с битмап индексом, в которой значение только одно:
SQL> create table tbitmap as select level id, 1 a from dual connect by level<=1e6;
Table created.
SQL> create bitmap index ix_bitmap on tbitmap(a);
Index created.
2. Измените значение индексного поля на 2 в строке с id=1:
SQL> update tbitmap set a=2 where id=1;
1 row updated.
3. В другой сессии вы можете спокойно изменить множество строк, кроме тех которые находятся в других блоках битмап карты:
SQL> update tbitmap set a=3 where id=1e6;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-100;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-1000;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-10000;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-100000;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-500000;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-800000;
1 row updated.
SQL> update tbitmap set a=3 where id=1e6-900000;
1 row updated.
4. Но если вы попытаетесь проапдейтить строку из того же куска, то тут же нарветесь на блокировку:
SQL> update tbitmap set a=3 where id=1024;
-- и висим...
О, прямо моя давняя мечта! Мне даже все равно что: трекболл, трекпойнт, тачпэд, лишь бы было именно на нормальной удобной эргономической клавиатуре с удобными F-клавишами. Удивительно даже, что за столько лет такое большое кол-во производителей не могут додуматься до таких простых, казалось бы, вещей.
Думаю, я далеко не один такой кто сидит часто развалившись в кресле с клавиатурой на коленях и закинув ноги на стол и печатает вслепую. При этом крайне лениво тянуться рукой к мышке на столе.
Ах, да, ещё забыл написать, что вместо plsql функции лучше бы сделали виртуальный столбец с case when… then...else… end и уже его бы индексировали, а если версия слишком старая и не поддерживает виртуальные колонки, то просто функциональный индекс по выражению (тому же case), это позволило бы избежать ненужных переключений контекста sql-pl/sql
Вообще, я не считаю оптимизацию топ-запросов именно проактивной оптимизацией. Я, конечно, понимаю, что это сейчас слишком обширное понятие, но все же, как мне кажется, под по-настоящему проактивной оптимизацией должен подразумеваться более глобальный подход с анализом трендов в различных разрезах и оптимизацией на опережение, а не постфактум, когда какой-то новый запрос вылех в топ. Обычно при долгой работе и на больших базах(если это, конечно, не специфические dwh и прочий постоянно меняющийся data mining), то топы запросов достаточно стабильны и остаются одними и теми же. Примитивный пример: топовый запрос жрет 5% — даже если его вообще убрать, то мы выиграем лишь 5%, в то время как часто оказывается, что проанализировав архитектуру чуть более детально и сделав, к примеру, какую-нибудь одну маленькую денормализацию, то можем выиграть 15%, но на сотнях мелких быстрых запросов.
Очень рад, что с такими темами начинают выступать и кто-то, как и я, тоже занимается чисто производительностью БД! У самого куча наработок, например, по этой статье у меня есть заготовка презентации «Performance tuning and troubleshooting баз данных в наши дни», в которой я как раз говорю о том, что, к сожалению, никто не держит инженеров по производительности баз данных и обращаются за помощью либо слишком поздно, собственно тогда, когда нужен уже troubleshooting, либо вообще не обращаются, а сразу закупают еще более и более мощное железо… Жаль только времени все время не хватает на презенташки. Был бы кто-нибудь кто б выступил с ними :D
По теме же, проактивности из своего опыта я бы посоветовал кое-что улучшить и автоматизировать:
1. На предыдущей работе я автоматизировал поиск запросов из AWR, которые стали выполняться медленнее. Сейчас это искать лень, но можете глянуть эту «рыбу», которую я сейчас набросал: gist.github.com/xtender/ade3d05eba1011f173d6deec81560093
2. При постоянном анализе производительности, создание AWR-отчета слишком медленное, поэтому для просмотра топа запросов я использую такой скрипт: github.com/xtender/xt_scripts/blob/master/awr/top_sql.sql
3. При добавлении очередной базы для анализа, я обычно сразу меняю настройку AWR на минимум 35 дней хранения(чтобы можно было глянуть эту же дату за предыдущий месяц), Top N SQL увеличию до 100, а интервал оставляю прежним — 1 час. В случае же, если есть проблемы с местом под AWR, то сохраняю бейслайны за пиковые часы. Мой скрипт для изменения настроек: github.com/xtender/xt_scripts/blob/master/awr/settings_modify.sql
4. Чтобы узнать пиковые дни/часы я использую такие скрипты:
по CPU: github.com/xtender/xt_scripts/blob/master/awr/db_cpu_by_days_hours.sql
целиком по DB Time: github.com/xtender/xt_scripts/blob/master/awr/db_time_by_days_hours.sql
5. для более онлайнового и детального мониторинга желательно настроить мониторинг и уведомления о:
5.1 долгих запросах: select * from v$sql_monitor r where elapsed_time>…
5.2 топe row-sources из ASH: gist.github.com/xtender/710b210bc455617cfd9531524ac3a1c6
5.3 оттуда же о новых фулсканах, например: gist.github.com/xtender/e771daf5581a12db15e3708c54678f5b
5.4 если же нет DIAG+TUNING и не стоит альтернативных ASH, то хотя бы о долгих операциях (v$session_longops)
6. Для более качественной информации о производительности, еще желательно логически разделить нагрузки по разным сервисам(v$services) и соответственно разрулить клиентов по ним и уже будет удобнее анализировать в разрезе сервисов, например в v$servicemetric, а если есть и свои разработчики, то разделить и бизнес-логику по module/action/client_id
В принципе, при работе с одними и теми же базами этого будет достаточно для начала, но в случае, если база еще и неизвестная, то там уже нужен полноценный performance data mining: анализ нагрузки и производительности уже с учетом архитектуры, связей про предикатам, горячим/холодным данным, и тд и тп, но это вообще огромная тема, тут одним комментарием не отделаться…
Ну самое главное, что я не получаю там детализированную информацию:
1. сколько процентов получает, скажем больше 315тр
2. Как рапределены по областям эти специалисты в процентах
Я не хочу только внутри своей области
Сделайте, пожалуйста, еще возможность просмотра статистики относительно своей или просто выбранной зарплаты: сколько процентов получает больше меня, в каких областях, с гистограммами.
1. Для решения этой проблемы есть Adaptive cursor sharing, и он делает именно то, что нужно: на основе гистограмм создает подходящие дочерние курсоры. Если у них это не работало, значит надо было разбираться с причиной почему ACS не работал. Игорь Усольцев делал отличную подробную презентацию в российской юзергруппе оракл (RuOUG). Вообще, советую посещать наши мероприятия.
2. Раз на базе стоит cursor_sharing=force, то можно было просто создать профиль с одним единственным хинтом BIND_AWARE на любом из этих запросов, с указанием параметра force_match=>true.
3. Насчет динамики:
Я еще на 10-ке использовал несколько разных вариантов в зависимости от условий:
3.1 Если был возможен PL/SQL то просто разбивал через IF на пару разных вариантов, грубо говоря: IF cardinality>N then query1 else query2
A cardinality получал одним из быстрых способов.
3.2. Разбиение на union all с доп.подзапросом, например:
И если данные уже промаркированы как в статье(отдельная таблица где помечены «большие/средние/маленькие»), то этот вариант был бы намного проще
4. Здесь неверно:
Это решение абсолютно для противоположной цели: отключение _OPTIM_PEEK_USER_BINDS и удаление гистограм делают в случае, если оракл плодит разные планы, а хочется строго одного и того же для любых биндов.
5. Существует и еще один подход: секционирование с учетом data skew. Тут вариантов много, одним из простейших является интервальное секционирование по «перекошенному» столбцу основного ACCESS предиката. А для статьи из примера удобно было бы секционировать как раз по SMALL/MIDDLE/LARGE, то есть три разные секции, каждая со своей статистикой(причем заработает даже без гистограмм, т.к. достаточно (num_rows-num_nulls)/num_distinct статистик по секции), что дает оптимизатору легко понять селективность столбца в данной секции.
ЗЫ. Надо было Виктору ко мне обратиться, вместе бы посмотрели почему ACS у них не работал.
театр абсурда:
— это ключ
— это не ключ, не key
— нет, это ключ, так как "...key entry..."
— key entry != key
— да key entry!=key, но все равно entry = key
WTF?!
Перечитайте внимательно по своим же ссылкам у Кайта и ту же доку, если лень, то хотя бы п.7, который я вам специально процитировал даже.
Вернемся к самому началу:
И вы предлагаете называть каждую такую запись ключом битмап индекса?! А что такое тогда deptno? бурлесоновщина в чистом виде…
зы. Про «что они ошиблись так же как и вы», я просто в первый раз доверился вам и не посмотрел внимательно, но оказалось, что у них все так же, как я и говорил. Не вырывайте из контекста.
ззы. раньше, кстати, там тоже ошибочно было упрощено как и в этой статье(показывали, что все для каждого значения ключа свой один bitmap, и каждый из них содержит все ROWIDs, что в корне неверно), что и породило миф о блокировке всех строк для изменяемого значения. И этот ответ на асктоме лишь от 2007 года, а Джулиан Дайк эту свою презентацию в первый раз прочитал еще в 2003. Так что я рад, что добавили деталей в 11.2, но спорить о существовании этого мифа довольно глупо.
index key != index key entry
Ну а пройтись хотя бы поиском по страничке на фразу «index key», как я уже подсказывал?
зы. если уж пытаетесь свалить на незнание английского, то попробуйте тогда найти определение на ключ индекса на русском…
Вообще даже странно как-то объяснять такую банальность как, что такое index keys…
А если внимательно прочтете этот же кусок, который привели(особое внимание на пример в скобках) и, собственно, посмотрите в других местах, что они имеют ввиду под этим, то поймёте, что они ошиблись так же как и вы, но они не так категоричны: typically locks all these rows, что им позволит сказать, что, мол, мы и не говорили, что прямо всегда и все строки
В принципе, это не мое дело, но дабы уберечь хоть кого-нибудь от бесполезной траты времени на чтение его бреда, я думаю, что надо перечислить как минимум главное «чем он плох»:
1. Введение в заблуждение:
В первую очередь, тем, что хоть и неосознанно, но постоянно вводит огромное число людей в заблуждение, т.к. алгоритмы Google не учитывают ценность и точность информации, его сайт и форум имеют слишком широкую аудиторию.
2. Недостаток знаний:
Вообще же корень проблемы в том, что в заблуждение он вводит из-за того, что он очень поверхностно знает Oracle. В то время как профессионалы докапываются до реальных причин и детально изучают Oracle internals, он постоянно делает поверхностные поспешные выводы, да еще и на основе однократных событий: увидел А и B вместе, и сразу делает вывод, что A привело к B, да еще и если еще раз увидит B, то сразу скажет что виноват А… (кстати, почитайте еще про BAAG)
3. Уверенность в своих заблуждениях:
Чисто для сравнения: многие оракловые специалисты прямо в аннотации пишут, что не нужно слепо доверять написанному и предоставляют тест-кейсы, чтобы вы могли сами проверить и изучить все данные утверждения. Что же любит Дон Бурлесон? А он просто удаляет и банит людей за посты, в которых лишь высказывается сомнение в тех или иных его утверждениях. Мы все, конечно, бредем по кривой Даннинга-Крюгера, но ему много лет, а он где-то подзастрял и до долины отчаяния не дошел…
Вообще забавный человек :) Вам стоит почитать о нем побольше, чисто навскидку:
1. oracledoug.com/serendipity/index.php?/archives/1303-Why-you-cant-just-say-Stop-feeding-the-troll-....html
2. oraclesponge.wordpress.com/2005/04/11/banned-by-burleson
3. jonathanlewis.wordpress.com/2007/07/14/analysing-statspack-6
4. jonathanlewis.wordpress.com/2011/02/14/burleson-buys-bmc
5. www.rittmanmead.com/blog/2004/08/don-burleson-busting-the-oracle-myth-busters
Вообще это один из известных мифов, и является полуправдой:
1. с одной стороны, действительно многие записи с таким же значением будут заблокированы, но
2. на самом деле, заблокированы будут только те записи, которые находятся в том же куске со списком ROWIDs, что и изменяемая запись, тк при большом кол-ве записей они не хранятся единым куском. (про реальное строение читайте у Р.Фута или просто проанализируйте дамп индекса)
Проверяется очень легко:
1. создайте таблицу с битмап индексом, в которой значение только одно:
2. Измените значение индексного поля на 2 в строке с id=1:
3. В другой сессии вы можете спокойно изменить множество строк, кроме тех которые находятся в других блоках битмап карты:
4. Но если вы попытаетесь проапдейтить строку из того же куска, то тут же нарветесь на блокировку:
Например: richardfoote.wordpress.com/2010/03/03/1196
А еще лучше всего его посты про них:
richardfoote.wordpress.com/category/bitmap-indexes
Думаю, я далеко не один такой кто сидит часто развалившись в кресле с клавиатурой на коленях и закинув ноги на стол и печатает вслепую. При этом крайне лениво тянуться рукой к мышке на столе.
Ах, да, ещё забыл написать, что вместо plsql функции лучше бы сделали виртуальный столбец с case when… then...else… end и уже его бы индексировали, а если версия слишком старая и не поддерживает виртуальные колонки, то просто функциональный индекс по выражению (тому же case), это позволило бы избежать ненужных переключений контекста sql-pl/sql
По теме же, проактивности из своего опыта я бы посоветовал кое-что улучшить и автоматизировать:
1. На предыдущей работе я автоматизировал поиск запросов из AWR, которые стали выполняться медленнее. Сейчас это искать лень, но можете глянуть эту «рыбу», которую я сейчас набросал: gist.github.com/xtender/ade3d05eba1011f173d6deec81560093
2. При постоянном анализе производительности, создание AWR-отчета слишком медленное, поэтому для просмотра топа запросов я использую такой скрипт: github.com/xtender/xt_scripts/blob/master/awr/top_sql.sql
3. При добавлении очередной базы для анализа, я обычно сразу меняю настройку AWR на минимум 35 дней хранения(чтобы можно было глянуть эту же дату за предыдущий месяц), Top N SQL увеличию до 100, а интервал оставляю прежним — 1 час. В случае же, если есть проблемы с местом под AWR, то сохраняю бейслайны за пиковые часы. Мой скрипт для изменения настроек: github.com/xtender/xt_scripts/blob/master/awr/settings_modify.sql
4. Чтобы узнать пиковые дни/часы я использую такие скрипты:
по CPU: github.com/xtender/xt_scripts/blob/master/awr/db_cpu_by_days_hours.sql
целиком по DB Time: github.com/xtender/xt_scripts/blob/master/awr/db_time_by_days_hours.sql
5. для более онлайнового и детального мониторинга желательно настроить мониторинг и уведомления о:
5.1 долгих запросах: select * from v$sql_monitor r where elapsed_time>…
5.2 топe row-sources из ASH: gist.github.com/xtender/710b210bc455617cfd9531524ac3a1c6
5.3 оттуда же о новых фулсканах, например: gist.github.com/xtender/e771daf5581a12db15e3708c54678f5b
5.4 если же нет DIAG+TUNING и не стоит альтернативных ASH, то хотя бы о долгих операциях (v$session_longops)
6. Для более качественной информации о производительности, еще желательно логически разделить нагрузки по разным сервисам(v$services) и соответственно разрулить клиентов по ним и уже будет удобнее анализировать в разрезе сервисов, например в v$servicemetric, а если есть и свои разработчики, то разделить и бизнес-логику по module/action/client_id
В принципе, при работе с одними и теми же базами этого будет достаточно для начала, но в случае, если база еще и неизвестная, то там уже нужен полноценный performance data mining: анализ нагрузки и производительности уже с учетом архитектуры, связей про предикатам, горячим/холодным данным, и тд и тп, но это вообще огромная тема, тут одним комментарием не отделаться…
1. сколько процентов получает, скажем больше 315тр
2. Как рапределены по областям эти специалисты в процентах
Я не хочу только внутри своей области