Хотел секционировать что нибудь :) но что-то наша 8-ка, хотя и называла себя Enterprise, в partitioning было false и что странно,
в инсталляторе эта опция отсутствовала.
Поэтому вдруг, не подготовившись вообще *194 , переехал на 9,
ну и заслуженно огреб по полной программе *192
(полдня операторы курили, пока индексы/статистика не ожили)
Подобные вещи на форуме почитал, но всеж напишу свое.
P4 2-х ядерный, 4Гб, база 80Гб (дамп 14Гб) на 3-х raid1
Win2003, Oracle 9.2.0.8
Cначала по мелочи - старая проблема еще с 8-ки
Все дольше, часами принимаются Z-отчеты,
там многократно повторяется этот запрос:
Код:
delete FROM supermag.smcashdisc d
WHERE EXISTS (SELECT 1
FROM supermag.smcashchecks c
WHERE c.locid = d.locid
AND c.desknum = d.desknum
AND c.znum = d.znum
AND c.checknum = d.checknum
AND c.opcode = 3)
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=CHOOSE 7 24102
HASH JOIN SEMI 7 238 24102
TABLE ACCESS FULL SUPERMAG.SMCASHDISC 27 M 582 M 7607
TABLE ACCESS FULL SUPERMAG.SMCASHCHECKS 2 M 23 M 1398 Чем лечить ?
Также еле ворочаются отчеты по аналитике (всяческие ffmaprep+ffmaprep_ table access full)
Например, один из таких запросов для оборачиваемости по поставщикам
Код:
INSERT INTO supermag.ttturnoversupp1
(suppid, locid, article, summa)
(SELECT t.suppid, t.locid, t.article, round(sum(t.summa * nvl(p.price1, 0)),
2)
FROM (SELECT /*+ ORDERED USE_HASH (m l spl) */
m.incomeclientindex suppid, l.id locid, m.article article,
sum(decode(l.id, m.salelocationfrom, -m.quantity,
m.quantity)) summa
FROM supermag.smstorelocations l, supermag.fvmaprep m
WHERE m.saledate <= to_date('31.07.2007', 'DD.MM.YYYY')
AND m.incometype = 'WI'
AND m.forcedmapping = 0
AND l.id IN (m.salelocationto, m.salelocationfrom)
AND l.id IN (SELECT id
FROM supermag.ttloclist)
AND m.incomeclientindex IN (SELECT id
FROM supermag.ttsuppllist)
AND m.article IN (SELECT crd.article
FROM supermag.smcard crd
WHERE crd.datatype != 4
AND crd.article IN (SELECT article
FROM supermag.ttidgroup))
GROUP BY m.incomeclientindex, l.id, m.article) t,
supermag.ttgoodsnotsale1 p
WHERE t.locid = p.locid (+)
AND t.article = p.article (+)
GROUP BY t.suppid, t.locid, t.article)
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
INSERT STATEMENT Optimizer Mode=CHOOSE 1 16321
SORT GROUP BY 1 109 16321
NESTED LOOPS OUTER 3 327 16318
VIEW 1 56 16317
SORT GROUP BY 1 160 16317
SORT GROUP BY 1 160 16317
HASH JOIN 589 K 89 M 14051
VIEW 86 K 7 M 4289
UNION-ALL
TABLE ACCESS FULL SUPERMAG.FFMAPREP 48 K 1 M 2402
TABLE ACCESS FULL SUPERMAG.FFMAPREP_ 38 K 1 M 1887
HASH JOIN 1 G 65G 9762
INDEX FULL SCAN SUPERMAG.SMCSTORELOCATIONS_PK 27 81 1
MERGE JOIN CARTESIAN 1 G 62G 188
MERGE JOIN CARTESIAN 53 M 2G 187
HASH JOIN 6 K 229 K 186
INDEX FULL SCAN SUPERMAG.TTCIDGROUP_PK 8 K 215 K
TABLE ACCESS FULL SUPERMAG.SMCARD 93 K 819 K 173
BUFFER SORT 8 K 103 K 14
INDEX FULL SCAN SUPERMAG.TTCSUPPLLIST_PK 8 K 103 K
BUFFER SORT 20 260 187
INDEX FULL SCAN SUPERMAG.TTCLOCLIST_PK 20 260
TABLE ACCESS BY INDEX ROWID SUPERMAG.TTGOODSNOTSALE1 3 159 1
INDEX UNIQUE SCAN SUPERMAG.TTCGOODSNOTSALE1_PK 1 Попробую все же порезать ffmap на секции - есть смысл, например для запроса выше?
От fullscan в данном случае уйдем или не ?
Compress где имеет смысл - на всех больших таблицах или где-то не нужно?
И что совсем плохо - перемещения встали, смена статуса с черновика до зеленой - до 25 мин, буду ловить, отпишусь, *23