[ОТВЕТИТЬ]
27.07.2006 16:27
deucel
 
У меня сложилось такое ощущение, что аналитика не использует индексы
для примера суммарные значения:

Datafile_____Total read time__% I/O load__Phisical reads__Avg read time (ms)

INDX_FF___________342,12_________54_______523527__________7,09
USERS_FF________26856,72_________42_____13798973_________21,55

INDX_SMSPEC_____5753,83__________7______2008043_________17,93
USERS_SMSPEC___17156,79_________29______4337809_________11,87
27.07.2006 16:44
Mtirt
 
А какие отчеты формировались за день? Может индекс не используется конкретным отчетом?
27.07.2006 17:00
OlegON
 
Кроме того, необходимо уточнить, что индекс тем и крут, что его полное последовательное чтение не обязательно, соответственно, объем чтений юзерса всегда будет больше.
27.07.2006 17:11
deucel
 
Цитата:
olegon , объем чтений юзерса всегда будет больше.
Но не настолько, это больше похоже на фулскан таблиц (даже визуально по загрузке винтов).
Большинство отчетов не используются так как долго делаются, и если при этом идет чтение индекса а потом фулскан таблицы это на порядок дольше (индексы 20Гб)
27.07.2006 17:16
deucel
 
Собственно это возникло не внезапно, просто решил озвучить.
Если сравнивать со всей базой то оснавная нагрузка на винты с аналитикой (на отдельных винтах), остальные используются кратковременно и или неактивно.
27.07.2006 17:19
OlegON
 
А ты бы не на визуальность опирался, а постарался поймать запрос, который фулсканит, или несколько их, просто ловить долгие запросы, а потом смотреть их план. Разберем - лучше будет.
27.07.2006 17:21
Mtirt
 
Почему интересно у меня иначе?
Сегодня разбирались, аналитические таблицы выделены в отдельное табличное пространство.
Смотрели нагрузку - в основном зщадействован Users.
Что мы делаем не так.
Отчеты формируем, и часто.
Пользователей почти 50?

Может все-таки удастся выяснить, какие отчеты запускаются?
31.07.2006 11:48
deucel
 
Цитата:
olegon А ты бы не на визуальность опирался, а постарался поймать запрос, который фулсканит.
Посмотрел один из отчетов (Товарные - Оборотная ведомость) и наткнулся на интересную подсказку:
__________/*+ ORDERED USE_NL(A) FULL(A) FULL(M.U_MapRep.FFMapRep) */
без этой подсказки стоимость уменьшается в четыре раза *04
Это конечно можно вылечить outline, но думаю это далеко не единственный такой запрос.
*08
Изображения
Тип файла: jpg Graphic1.jpg (30.4 Кб, 575 просмотров)
Тип файла: jpg Graphic1.jpg (30.4 Кб, 575 просмотров)
11.12.2006 12:28
kadr
 
deucel, сегодня тоже начал разбираться с медленным формированием некоторых отчётов и тоже наткнулся на такую ситуацию, когда при такой же подсказке стоимость выполнения выше в 4 раза.
Вот думаю что делать-то
11.12.2006 15:40
slava
 
Цитата:
kadr deucel, стоимость выполнения выше в 4 раза.
Вот думаю что делать-то
А чем в данном случае критична стоимость? Может всетаки на быстродействие смотреть надо?
11.12.2006 15:52
kadr
 
slava, так потому и смотрю на стоимость, что время выполнение выросло очень сильно, было 1 час, сейчас уже больше 9-ти часов считается.
вот этот запрос:
Код:
INSERT INTO TTRemains ( StoreLoc, Article, Quantity, Forced, CP_NoVat, CP_Full )( SELECT  Location, Article, SUM(Quantity) Quantity, Forced, SUM(CP_NoVat) CP_NoVat, SUM(CP_Full) CP_Full
from ( SELECT /*+ ORDERED USE_NL(A) FULL(A) FULL(M.U_MapRep.FFMapRep) */ L.Id Location, M.Article, SUM(DECODE(L.Id,M.SaleLocationTo,1,M.SaleLocationFrom,-1,0)*M.Quantity) Quantity, DECODE(nvl(A.PrimeAlg,0),0,ForcedMapping,PrimeCostForced) Forced, nvl(SUM(DECODE(L.Id,M.SaleLocationTo,1,M.SaleLocationFrom,-1,0)*DECODE(nvl(A.PrimeAlg,0),0,DECODE(M.IncomeQ,0,0,M.IncomeNoVat*M.Quantity/M.IncomeQ),nvl(PrimeCostNoVAT,0))),0) CP_NoVat, nvl(SUM(DECODE(L.Id,M.SaleLocationTo,1,M.SaleLocationFrom,-1,0)*DECODE(nvl(A.PrimeAlg,0),0,DECODE(M.IncomeQ,0,0,M.IncomeSum*M.Quantity/M.IncomeQ),nvl(PrimeCost,0))),0) CP_Full
FROM FVMapRep M, SMStoreLocations L, TTStoreCfg A
WHERE L.Id in (M.SaleLocationTo, M.SaleLocationFrom) and L.Id = A.StoreLoc(+) and M.SaleDate between :i_Start and :i_Stop and M.Article  in (select FData
from TTFilterStr
where FType=1)
GROUP BY L.Id, M.Article, DECODE(nvl(A.PrimeAlg,0),0,ForcedMapping,PrimeCostForced) )
group by Location, Article, Forced having ROUND(SUM(Quantity),3) <> 0 or ROUND(SUM(CP_NoVat),4) <> 0 or ROUND(SUM(CP_Full),4) <> 0 )
события ожидания db file scattered read на таблице FFMAPREP

Может посоветуешь в другое место посмотреть?
11.12.2006 16:19
slava
 
Глянь сюда

Запусти под sys
select Segment_name,Segment_type, Count(*) from dba_extents t
Where owner = 'SUPERMAG' and
Segment_name like 'FF%'
Group by Segment_name,Segment_type
Having Count(*) > 5
Order by Segment_name,Segment_type
11.12.2006 16:48
kadr
 
slava, а пояснить не хочешь, для чего всё это? определить уровень дефрагментации?
и зачем обязательно под sys? думаешь никто больше не имеет прав на dba_extents?
11.12.2006 18:09
OlegON
 
А что со стоимостью, если без Insert сделать? Компрессия включена?
11.12.2006 18:14
kadr
 
olegon, планы оцениваю только по селекту, компрессия не включена.
11.12.2006 19:24
OlegON
 
А multiblock_read_count сколько? Я по памяти, может как-то схоже параметр зовется.
11.12.2006 19:34
Mtirt
 
db_file_multiblock_read_count = 32
11.12.2006 20:12
OlegON
 
А размер блока базы? Я, к сожалению, пока не вижу возможности обойти подсказку, да и хорошей базы для прогона теста у меня пока нет под рукой, просто идея в удешевлении стоимости сканирования по индексу, 9 часов это слишком круто. Мучаюсь склерозом, TTRemains мне уже попадалась и, как мне кажется, чем-то я ее поборол. Как я понимаю, это про 9ку речь? Просто, смутные подозрения, что в моем случае косяк был вовсе не в стоимости скана по подсказке, а в одной из параллельных, неаналитической таблице. Вспомню - скажу. Кстати, раз уж мы выкручиваем index_cost_adj, не хотите ли попробовать поднять db_file_multiblock_read_count ? Таблицы у вас здоровые, а блок базы, поди, маленький...
12.12.2006 06:37
slava
 
Цитата:
kadr slava, а пояснить не хочешь, для чего всё это? определить уровень дефрагментации?
и зачем обязательно под sys? думаешь никто больше не имеет прав на dba_extents?
Определить уровень дефрагментации.
Ты селект запустил? Экстентов сколько?
На счет прав сам решай.
12.12.2006 15:03
kadr
 
Oracle 9.2.0.8

Цитата:
9 часов это слишком круто.
устаревшая информация, пользователь пришёл сегодня утром и не дождавшись оборвал выполнение отчёта на 24 часу его работы.

Цитата:
аз уж мы выкручиваем index_cost_adj
не выкручивал, да и не трогал я эти параметры

Цитата:
не хотите ли попробовать поднять db_file_multiblock_read_count
Нет, не хочу.

db_blok_size=8192

slava, У меня аналитика лежит в отдельном ТС на разных дисках и при расчёте товародвижения ТС пререписывается на 80%

и вообще у меня складывается что всё это из-за битого индекса FFMAPREP_DOC - обнаружил не так давно.
Так что пересоздам сейчас его и посмотрим, что мы получим в итоге.
12.12.2006 16:01
slava
 
Цитата:
kadr У меня аналитика лежит в отдельном ТС на разных дисках и при расчёте товародвижения ТС пререписывается на 80%

и вообще у меня складывается что всё это из-за битого индекса FFMAPREP_DOC - обнаружил не так давно.
Так что пересоздам сейчас его и посмотрим, что мы получим в итоге.
Я не знаю как на твоей версии СМ2000, а мы когда-то сталкивались с тем, что при расчете ТД вместо Delete или Truncate С+ использовал Drop Table с последующим ее созданием. При чем все storage при создании таблицы по default из табличного пространства.
12.12.2006 16:07
inna
 
kadr, это нормально, что аналитика лежит в другом ТП? А то у меня в разных, но собираюсь перенести в одно, так как Олег сказал что СМ настроен на USERS. На разных дисках с USERS? А индексы отдельно лежат от других индексов?
12.12.2006 16:08
kadr
 
slava, я этого не наблюдал, похоже это было давно

inna, отдельно выделено ТС для данных аналитики и отдельно для индексов аналитики. Это связано с поведением СМ при расчёте ТД. Если всё держать в одном ТС, то уровень дефрагментации будет достаточно высоким.
По дискам разнесено таким образом, что либо опер данные пересекаются с аналит. индексами, либо аналит данные - с опер. индексами.
А если СМ действительно настроен на USERS, то это недоработка СМ.
12.12.2006 16:31
Mtirt
 
Скорее не СМ2000 настроен на USERS, а оптимайзер на него настроен.
Он об этом честно предупреждает при запуске.
А СМ2000 по большому счету все равно, как называется (называются) табличные пространства...
12.12.2006 16:41
inna
 
Да нет, оптимайзеру тоже все равно. Спасибо за совет - попробую так и сделать.
12.12.2006 17:22
OlegON
 
Когда говорилось о том, что СМ настроен на USERS, хотя фраза немного другая была, шла речь о том, что, например, при заведении нового пользователя, в качестве пространства по умолчанию предлагается именно USERS, независимо от его существования. Это одно из видимых. У вас не так? Что касается реорганизации с выносом аналитики - согласен, НО, именно выносом, т.е. чтобы вся оперативная часть была в TS, названном USERS, чтобы это TS обязательно было. Просто рекомендация.
13.12.2006 09:12
kadr
 
Цитата:
т.е. чтобы вся оперативная часть была в TS, названном USERS, чтобы это TS обязательно было.
На чём основана эта рекомендация? Может мне стоит вернуть переименовать USERS1 в USERS *13 ?
И зачем вся оперативная часть? я хочу разделить опер. на несколько ТС (вынести smspec и несколько др. таблиц), чем мне может это грозить?
13.12.2006 09:25
OlegON
 
Цитата:
чтобы это TS обязательно было
вот, я ж уже сказал. Основное. Если дальше делить будешь - ничем тебе это не грозит.
13.12.2006 09:49
kadr
 
Цитата:
чтобы это TS обязательно было
т.е. главное его наличие? сделать 10 метров и пусть себе лежит в уголке?

или оно должно быть основным, и что понимать под словом основное? прописано по умолчанию пользователю supermag (а если пользователю прописано др. ТС?) или там должны лежать определённые объекты?
13.12.2006 10:15
OlegON
 
"Основное" я имел ввиду, что цитируемое было сутью высказывания. Лучше по умолчанию для пользователя supermag и отсюда - не 10 метров, поскольку еще наверняка есть пользователи, для которых оно - по умолчанию. Все это потому, что в интерфейсе СМ оно забивается, как ТП по умолчанию. И в один прекрасный момент кто-нибудь забудет его поменять.


Опции темы


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

 

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