Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Посоветуйте что-нибудь получше V$OBJECT_USAGE / 25 сообщений из 25, страница 1 из 1
08.02.2017, 17:45
    #39401155
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Накопилось достаточно легаси индексов, и нужно выяснить, какие из них нужны, а какие не очень.
V$OBJECT_USAGE показывает только YES/NO, а хотелось бы знать насколько ЧАСТО/РЕДКО или время последнего доступа.
Спасибо.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.02.2017, 18:09
    #39401166
Добрый Э - Эх
Добрый Э - Эх
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

V$SEGMENT_STATISTICS
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
08.02.2017, 19:15
    #39401209
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Добрый Э - Эх,

Спасибо
Похоже, DBA_HIST_SEG_STAT содержит более полную информацию.
Только какую метрику лучше смотреть для определения частоты использования индекса?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 04:50
    #39401344
Добрый Э - Эх
Добрый Э - Эх
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

ну, как бы, логично - V$SEGMENT_STATISTICS содержит статистические данные по сегментам от момента сбора по ним статистики, до следующего такого момента. А DBA_HIST_SEG_STAT - хранит историю, и при сборе статистики не сбрасывается.

А смотреть нужно не на абсолютные значения чисел, а на их относительность друг друга. Как там Том писал - ориентироваться нужно на соотношения кол-ва чтений и записей по индексу. Если чтений сильно больше чем записей, значит индекс используется в Select-ах. Если их соотношение примерно равно или записей по индексу больше, чем чтений - значит индекс "мертвый" и читается только DML-операторами для последующей модификации. Соответственно, подобрав приемлемое соотношение между этими значениями можно выбрать индексы - кандидаты на удаление ввиду их неиспользуемости в селектах...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 06:49
    #39401349
AlexAA
AlexAA
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Посмотрите здесь https://jonathanlewis.wordpress.com/2015/09/01/index-usage-3/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 11:52
    #39401493
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Добрый Э - Эхориентироваться нужно на соотношения кол-ва чтений и записей по индексувы имеете в виду "logical reads" и "db block changes"?
там просто много всяких reads/writes..
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 12:24
    #39401515
Добрый Э - Эх
Добрый Э - Эх
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

ну да. Льюис, в частности, именно этими значениями и оперирует.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 17:35
    #39401798
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Добрый Э - Эх,

как каков по-вашему критерий полезности индекса?
вот в статье, которую любезно предоставил AlexAA, если "db block changes" > "logical reads"/3, то такой индекс считается бесполезным и кандидатом на удаление
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.02.2017, 20:37
    #39401899
Takurava
Takurava
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--, отсортируй по "logical reads" / "db block changes" и начни удалять с начала.
Остановишься, когда заметишь пользу :)
Можно ещё связать v$sql_plan, с v$sql и с dba_indexes и посмотреть кол-во выполнений.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 07:30
    #39401974
AlexAA
AlexAA
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

Небольшое уточнение
--Eugene--...если "db block changes" > "logical reads"/3, то такой индекс считается бесполезным и кандидатом на удаление
Льюис пишет, что это при level = 3, т.е. чтобы изменить один блок индекса - надо выполнить 3 чтения для поиска этого блока.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 09:49
    #39402035
pihel
pihel
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

можно еще заодно проверить по ash, но там не будет мелких запросов:
 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
select /*+ parallel(8) */ i.index_name, i.TABLE_NAME, round( i.NUM_ROWS / 1000 / 1000, 2) as rows_m, 
  ROUND( (NVL(m.INSERTS,0) + nvl(m.UPDATES,0) + nvl(m.DELETES,0)) / 1000 / 1000, 2) as dml_m --число dml
  , t.LAST_ANALYZED
FROM (
  select index_name from dba_indexes where owner = 'SAPSR3'
  minus
  select DISTINCT p.OBJECT_NAME
  from dba_hist_active_sess_history h
  join SYS.DBA_HIST_SQL_PLAN p on h.sql_id = p.sql_id and P.PLAN_HASH_VALUE = h.SQL_PLAN_HASH_VALUE and h.SQL_PLAN_LINE_ID = p.id
  where h.sample_time >= to_date('01.12.2016', 'dd.mm.yyyy')
  and p.OBJECT_TYPE = 'INDEX'
) o
join dba_indexes i on i.index_name = o.index_name and i.owner = 'SAPSR3'
left join dba_tables t on t.owner = 'SAPSR3' AND t.table_name = i.TABLE_NAME
left join dba_tab_modifications m on m.table_owner = 'SAPSR3' AND m.table_name = i.TABLE_NAME
order by i.NUM_ROWS desc nulls last;


...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 10:12
    #39402048
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Я как-то такое рисовал
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
with v$plan as (select object_name, operation, options
	from v$sql_plan where sql_id not in (
		select sql_id from v$sql
		where sql_text like '%/*+ % dbms_stats % */%'
	)
)
select index_name, operation, options, count(operation)
from v$plan p, all_indexes i
where table_name='&table_name'
and object_name(+)=index_name
group by index_name, operation, options
order by 1, 2
/
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 10:55
    #39402085
fortnet
fortnet
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
--Eugene--,

Если индекс используется редко или даже очень редко , это не значит, что он не очень нужен. Вы же не выбрасываете вещь, которой пользуетесь раз-два в году.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 11:04
    #39402093
fortnet
fortnet
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
По поводу частоты использования можно включать и выключать мониторинг индексов раз в день, час ...
v$object_usage будет отражать информацию за этот период.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 11:18
    #39402111
n0rd1c.c0ld
n0rd1c.c0ld
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
fortnetЕсли индекс используется редко или даже очень редко , это не значит, что он не очень нужен. Вы же не выбрасываете вещь, которой пользуетесь раз-два в году.
А может быть, в таком случае, нужно рассматривать возможность управления статусом (части)индекса?

Если продолжать Ваш пример, обычно не хранят вещи, которыми пользуются раз в год, вместе/рядом с вещами для ежедневного пользования.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 11:33
    #39402131
fortnet
fortnet
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
n0rd1c.c0ldfortnetЕсли индекс используется редко или даже очень редко , это не значит, что он не очень нужен. Вы же не выбрасываете вещь, которой пользуетесь раз-два в году.
А может быть, в таком случае, нужно рассматривать возможность управления статусом (части)индекса?


Статусом - перевод в UNUSABLE ?

n0rd1c.c0ldЕсли продолжать Ваш пример, обычно не хранят вещи, которыми пользуются раз в год, вместе/рядом с вещами для ежедневного пользования.

Ну именно этот вопрос (именно об индексах) в БД слишком тонкая материя.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 12:34
    #39402225
n0rd1c.c0ld
n0rd1c.c0ld
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
fortnetn0rd1c.c0ldА может быть, в таком случае, нужно рассматривать возможность управления статусом (части)индекса?

Статусом - перевод в UNUSABLE ?
да + invisible(в случае полного индекса)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 12:47
    #39402243
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
А что, INVISIBLE индекс не обновляется?
А перевод в UNUSABLE индекса поддерживающего уникальный/первичный ключ -- это чтоб сделать табличку READ ONLY?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 13:02
    #39402254
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
fortnetn0rd1c.c0ldfortnetЕсли индекс используется редко или даже очень редко , это не значит, что он не очень нужен. Вы же не выбрасываете вещь, которой пользуетесь раз-два в году.... статусом ..?... перевод в UNUSABLE ?А смысл держать его в базе в состоянии зомби?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 13:06
    #39402258
n0rd1c.c0ld
n0rd1c.c0ld
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Вячеслав ЛюбомудровА что, INVISIBLE индекс не обновляется?
А что, мною где-то такое написано?

Вячеслав ЛюбомудровА перевод в UNUSABLE индекса поддерживающего уникальный/первичный ключ -- это чтоб сделать табличку READ ONLY?
n0rd1c.c0ldА может быть, в таком случае, нужно рассматривать возможность управления статусом (части)индекса?
Как видится, императив о переводе в статус UNUSABLE, отсутствует. Или это был не вопрос?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 13:09
    #39402261
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Ты вообще топик не читаешь, даже свои посты?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 13:37
    #39402279
--Eugene--
--Eugene--
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Вячеслав Любомудров,

ну, в принципе, про "часть индекса", возможно идея неплоха.
тут наверно можно использовать PARTIAL (если индекс секционированный, ессно).
поправьте, если жестко туплю
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.02.2017, 14:42
    #39402310
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Тут, мне кажется, надо исходить из цели -- чего ты добиваешься
-- "лишние" индексы занимают место
-- "лишние" индексы обновляются при DML
-- "лишние" индексы могут быть причиной неоптимальных планов

С другой стороны, индексы, поддерживающие PK/UK как не вертись нужны, и, как правило, планы они не портят. Перевод их в UNUSABLE запрещает изменять/добавлять данные в этих ключах в таблице.

Индексы, поддерживающие внешние ключи в дочерних таблицах -- тут засада. Как правило, они нужны только в случае если в родительской таблице удаляются/изменяются ссылочные ключи. Если такой деятельности нет -- их легко можно и удалить. С другой стороны, если они таки нужны по каким-то причинам, они часто (ну или я предвзят) портят план, чтоб это не происходило их можно перевести в INVISIBLE -- от этого они не перестанут потреблять место и снижать производительность DML, но хоть не будут учитываться оптимизатором при составлении плана.

Перевод в UNUSABLE части (PARTITION) локального индекса не вижу смысла -- если он для поддержки PK/UK -- так и переводи его в Read Only вместе с секцией таблицы (правда место он будет занимать). Если он поддерживает FK -- см.выше, хотя если соответствующая секция таблицы в RO, то можно и в UNUSABLE, освободить место (много ли?). Опять же, иногда требуется возвращать секцию обратно RO -> RW. Что же, перестраивать все эти секции индексов обратно?

Что касается не локально-секционированных, то тут вообще трудно выбрать какой-то критерий

Если индекс юзается раз-два в год, на мой взгляд, проще его построить перед и убить после использования, чем весь год терпеть небольшое, но таки влияние на производительность (да и место в бэкапе занимает). Ну или да, если он не используется для поддержки PK/UK -- может и есть смысл перевести его в UNUSABLE, чтоб не забыть DDL создания, но терпеть в БД полгода объекты со статусом UNUSABLE мне как-то не нравится
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
11.02.2017, 09:30
    #39402572
Вячеслав Любомудров
Вячеслав Любомудров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
И, кстати, индексы для поддержки FK, как правило, очень хорошие кандидаты для сжатия
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.02.2017, 06:45
    #39403185
Начинучка
Начинучка
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Посоветуйте что-нибудь получше V$OBJECT_USAGE
Читаю в доке описание к DBA_HIST_SEG_STAT. Информации с гулькин нос, и непонятны следующие моменты:

1) This view captures the top segments based on a set of criteria and captures information from V$SEGSTAT.
Где посмотреть и можно ли изменить эти самые критерии попадания статистик по сегментам в ТОП?

2) The total value is the value of the statistics since instance startup.
Если данные в этом представлении накопительные с момента запуска инстанса, то почему у меня по многим сегментам наблюдаются скачки вниз значений *_TOTAL? С дельтой понятно - она пляшет вашим-нашим и зависит от "плотности нагрузки" между двумя соседними моментами SNAP_ID, но *_TOTAL же должен быть нарастающий?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Посоветуйте что-нибудь получше V$OBJECT_USAGE / 25 сообщений из 25, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 501ms
Закрыть
start [/forum/topic.php?fid=52&mobile=1&tid=1886456]:
 0ms
get settings:
 6ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 169ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 74ms
get tp. blocked users:
 2ms
others: 216ms
total:  501ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]