[ТЕМА ЗАКРЫТА]
13.10.2011 10:34
idus_
 
Добрый день!

Помогите, пожалуйста, начинающему..

У нас в базе быстро разрастаются индексное пространство. Приблизительно раз в месяц добавляем в него новый файл. Сейчас на одной базе уже семь файлов заполненных полностью (32Гб). А свободного места на диске остается все меньше...
Подскажите, пожалуйста, что можно сделать с этими индексами. Может просто часть их удалить? Или перестроить? поможет ли это и не повредит ли базе...

oracle 10.2.0.4
13.10.2011 10:36
OlegON
 
Оптимайзер можете поставить? Сколько занято в users? Вообще база Супермага или какая-то самостоятельная? Optimizer3 не использовали? В нем был такой недочет, а некоторые упрямо его используют.
13.10.2011 10:47
idus_
 
Нет, база не Супермага. Optimizer3 не использовали..Установить не разрешат ((
пространство useкtbsp - size 100mb used - 0.1 mb
У нас здесь два основных табличных пространства: emc_ind и emc_tab
Первое под индексы, второе под данный..
Пространство данных растет относительно медленно, а вот индексы наоборот..
13.10.2011 10:54
OlegON
 
Тогда предлагаю посмотреть количество таблиц в dba_tables и количество индексов в dba_indexes, по основному юзеру. Потом в dba_segments посмотреть, кто растет быстрее всего. Если индексов по 20 на каждой табличке, то ее прирост дает нехилый прирост на индексы. Но, предлагаю сделать вышеперечисленное и отписаться тут.
13.10.2011 11:29
idus_
 
Количество таблиц - 1795
Количество индексов - 1533

Извините за глупый вопрос, а как проанализировать в dba_segments кто растет быстрее всего?
13.10.2011 12:14
akonev
 
можно без затей: с интервалом в несколько дней поснимать размеры индексов, посравнивать.

поштучно:
Код:
select t.owner, t.segment_name, sum(t.bytes)
from dba_segments t
where t.segment_type='INDEX'
group by t.owner, t.segment_name, t.partition_name
order by sum(t.bytes) desc
суммарно индексы по таблицам:
Код:
select s.owner, sum(s.bytes), i.table_name
from dba_segments s, dba_indexes i
where s.owner=i.owner and s.segment_name=i.index_name
  and s.segment_type='INDEX'
group by s.owner, i.table_name
order by sum(s.bytes) desc
13.10.2011 12:19
akonev
 
всего индексов у вас сильно меньше таблиц. есть какие-то сильно-сильно индексированные?
Код:
select t.table_owner, t.table_name, count(t.index_name)
from dba_indexes t
where UPPER(t.tablespace_name)='EMC_IND'
group by t.table_owner, t.table_name
having count(t.index_name)>1
order by count(t.index_name) desc
13.10.2011 16:13
idus_
 
Вот такое выдал запрос:

15:05:37 EMCOS@EMCOR >select t.table_owner, t.table_name, count(t.index_name)
15:05:44 2 from dba_indexes t
15:05:44 3 where UPPER(t.tablespace_name)='EMCOS_IND'
15:05:44 4 group by t.table_owner, t.table_name
15:05:44 5 having count(t.index_name)>1
15:05:44 6 order by count(t.index_name) desc;

TABLE_OWNER TABLE_NAME COUNT(T.INDEX_NAME)
EMCOS EV 12
EMCOS ML 11
EMCOS RODO 9 EMCOS RP_LOG 8 EMCOS SAMU 8 EMCOS MT 7
EMCOS AUD_DATA_KEYS 7
EMCOS DI 7
EMCOS GRC_DATA 7 EMCOS SRC 7 EMCOS ECP_DATA 7 ...................................................
................................................... EMCOS RMDR_GR 2 EMCOS EU_MAP 2 EMCOS EVA_TYPE 2EMCOS SE_LPTY 2 EMCOS SP_LPTY 2 EMCOS XA 2
EMCOS XO_TYPE 2EMCOS STA_PRQ_DATA 2

272 строк выбрано.
13.10.2011 16:22
OlegON
 
теп ерь нео
бх о дим о в но рм
ал ь ном ф ор м ат
и
ро ва н ии вы д ать
раз м е
р
эт их та бли ч
еки их п рир ост
13.10.2011 16:29
akonev
 
Цитата:
idus_ Вот такое выдал запрос:


TABLE_OWNER TABLE_NAME COUNT(T.INDEX_NAME)
EMCOS EV 12
EMCOS ML 11
EMCOS RODO 9
ты эта... к Олегу прислушайся насчет форматирования :)

размер индексов суммарно по табличкам теперь вытяни.

и задумайся:

у меня база не сильно крупная.
самая большая таблица - около 2 гиг. по ней 2 индекса. занимают на 10% больше, чем таблица.

следующая по размеру чуть меньше, но тоже около 2 гиг. по ней 4 индекса. занимают на 50 процентов больше, чем таблица.

если предположить, что больше всего индексов у вас привинчено на самые навороченные таблицы - табличное под индексы просто обязано расти сильно быстрее, чем табличное под таблицы. еще и вставки должны нехило подтормаживать.
13.10.2011 16:29
idus_
 
А вот, что я увидел на другой нашей базе с такой же проблемой:

15:20:11 SYS@EMCOR1 in ODU>select s.owner, sum(s.bytes)/1024/1024/1024, i.table_name
15:20:14 2 from dba_segments s, dba_indexes i
15:20:14 3 where s.owner=i.owner and s.segment_name=i.index_name
15:20:14 4 and s.segment_type='INDEX'
15:20:14 5 group by s.owner, i.table_name
15:20:14 6 order by sum(s.bytes) desc
15:20:15 7 ;

OWNER SUM(S.BYTES)/1024/1024/1024 TABLE_NAME
------------------------------ --------------------------- ------------------------------
EMCOS 23,119812 RODO
EMCOS 6,27331543 EV
EMCOS 6,2333374 STA_PRQ
EMCOS 2,91369629 AUD_DATA
EMCOS 2,80895996 STA_PH_DATA
EMCOS 2,17614746 STA_PRQ_DATA
EMCOS 1,6942749 PLUP
EMCOS 1,58197021 PLEP
EMCOS ,770690918 AUD_DATA_PARAM
EMCOS ,502197266 AUD_DATA_KEYS
EMCOS ,50189209 STA_GRQ_DATA
EMCOS ,218139648 AUD_SE
SYS ,1953125 WRI$_OPTSTAT_HISTGRM_HISTORY
EMCOS ,177490234 CP_DATA
EMCOS ,164367676 XFE_PL_DATA
EMCOS ,142028809 QUEST_PPCM_TIME_SNAP
EMCOS ,123168945 AUD_SEP
EMCOS ,092773438 AUD_SEP_RC
EMCOS ,078857422 QUEST_PPCM_ADVISORY_SNAP
EMCOS ,052185059 AUD_DI
..........................................................................................
..........................................................................................

YSMAN ,000061035 MGMT_USER_TARGETS
SYSMAN ,000061035 MGMT_CONTAINER_CREDENTIALS
SYSMAN ,000061035 MGMT_HC_HARDWARE_MASTER

1526 строк выбрано.

Затрач.время: 00:00:01.71

Это означает, что какой-то индекс занимает 23Гб??
Посоветуйте, пожалуйста, что можно сделать для уменьшения занимаемого пространства?
13.10.2011 16:38
akonev
 
Цитата:
idus_
Это означает, что какой-то индекс занимает 23Гб??
Посоветуйте, пожалуйста, что можно сделать для уменьшения занимаемого пространства?
нет. это все индексы по таблице занимают 23Гб. по RODO их у тебя 9 штук значится.

что делать? задуматься крепко: надо ли их там столько, индексов этих?
13.10.2011 16:42
akonev
 
Индексы по RODO
Код:
select s.owner, i.index_name, sum(s.bytes)/1024/1024/1024
from dba_segments s, dba_indexes i
where s.owner=i.owner and s.segment_name=i.index_name
  and s.segment_type='INDEX'
  and i.table_name='RODO'
group by s.owner, i.index_name
order by sum(s.bytes) desc
;
13.10.2011 16:50
OlegON
 
Это табличка занимает 23Гб, индексы на ней может и больше. Сделай запросик на индексы, посмотрим их размеры.
Если занимаемое пространство - единственное, что тебя беспокоит, то
alter table EMCOS.RODO move compress;
на всех больших индексах
alter index .... rebuild compress;
если кардинальность подходит, то можно из обычного индекса сделать bitmap.
13.10.2011 16:56
akonev
 
Цитата:
OlegON Это табличка занимает 23Гб, индексы на ней может и больше...
не-не-не... это индексы по ней.

а так-то да. ребилдить сначала и смотреть, чего получилось.
13.10.2011 17:40
idus_
 
Сделал для индекса
alter index RODO_USER_I rebuild compress;
он был 3,03 Гб, стал 2,49. Результат есть...
а не повредит ли такое ужатие базе?
13.10.2011 18:09
OlegON
 
Данные будут в целости и сохранности так же, как и без сжатия.
14.10.2011 07:21
Mtirt
 
А скорость работы?
14.10.2011 07:27
OlegON
 
Если винты раньше проседали, то может и увеличиться... Его же это не интересует. Там главное - место сэкономить.
14.10.2011 08:56
AlexeyF
 
вопрос про прочитанное, для расширения кругозора...
compress индексы и таблицы - уменьшился размер под эти таблицы и индексы, быстрее чтение с диска. Получается нагрузка на проц. должна увеличиться ? Скорость записи должна уменьшиться ?
Опции темы


Часовой пояс GMT +3, время: 09:00.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.