RBS и запросы : Oracle

Mihon · █ 26.06.2008 14:33

Написал запросик (кстати, разместил его в FAQ по СМ), однако слишком мало тестил (тесты на базах магазинов).
Тестил на базе давностью ~1 месяц - запрос работает ~4 минут, и все возвращает, как положено.
Тестил на базе давностью 1,5 года - вот тут уже сложности начались - сначало на тэйблспейс temp обругалось, потом на сегменты RBS. RBS увеличили, не помогло.
Собственно, вопрос:
Как выбрать оптимальное кол-во сегментов, их размер и размер тэйблспэйсов?
Не будет ли так, что запросик мой СЛИШКОМ громоздкий, и всех этих рбс-ов для него надо очень жирных и много. Если их сделать слишком много и слишком больших, не отразится ли это плохо на базе и на быстродействии?
размер базы - 11,5 гб
Oracle 8i
Сегментов RBS 24 шт. по 10 мб (optimal size) 4 мб (next size).
Тэйблспэйс RBS один на 2 гига
текст запроса:

Код:

SELECT 
  to_char(cc.printtime,'DD.MM.YYYY') "date", sp.article, sp.docid, 
max(
(to_number(to_char(cc.printtime,'hh24'))*60 +
 to_number(to_char(cc.printtime,'mi'))) -
(to_number(to_char(log.eventtime,'hh24'))*60 +
 to_number(to_char(log.eventtime,'mi')))
) "minutes", 
to_char(log.eventtime,'hh24:mi:ss') "change_price_time", to_char(cc.printtime,'hh24:mi:ss') "check_time", sp.itemprice "Price", cci.itemprice "check_price"

FROM 
  SUPERMAG.Smspec sp,
  SUPERMAG.Smdoclog log,
  SUPERMAG.Smcashchecks cc,
  SUPERMAG.Smcashcheckitems cci
where 
  log.doctype='AC' and
  log.oldstate=2 and
  log.newstate=3 and
  log.id=sp.docid and
  sp.article=cci.article and
  cc.desknum=cci.desknum and
  cc.znum=cci.znum and
  cc.checknum=cci.checknum and
  to_char(cc.printtime,'DD.MM.YYYY') =to_char(log.eventtime,'DD.MM.YYYY') and
  cci.itemprice<>sp.itemprice and
  cc.printtime-log.eventtime>0

group by 
sp.article, sp.docid, log.eventtime, cc.printtime, cci.itemprice, sp.itemprice

еще добавлял в where log.eventtime>='01.04.2008' - все равно обругалось.
а вот с '01.06.2008' получилось, хотя и ждал минут 20...

Mtirt · █ 26.06.2008 15:31

Вот это явно заведомо долго будет выполняться:
to_char(cc.printtime,'DD.MM.YYYY') =to_char(log.eventtime,'DD.MM.YYYY')
and cc.printtime-log.eventtime>0

Mihon · █ 26.06.2008 16:46

Цитата:

Mtirt ➤ Вот это явно заведомо долго будет выполняться:
to_char(cc.printtime,'DD.MM.YYYY') =to_char(log.eventtime,'DD.MM.YYYY')
and cc.printtime-log.eventtime>0

а чем можно заменить, что попроще?

Mtirt · █ 26.06.2008 17:23

В твоем случае - скорее всего ничем.

akonev · █ 26.06.2008 17:24

(cc.printtime - log.eventtime) < 1 and
cc.printtime>log.eventtime

Mtirt · █ 26.06.2008 17:32

Тут суть в том, что и в той и в другой таблице это неиндексируемое поле.
А обе таблички совсем немаленькие.
Как следствие - прямое чтение с диска больших объемов данных.
План запроса (последние три графы cost, cardinality, byte):

Код:

SELECT STATEMENT, GOAL = CHOOSE            297444    109    9047
 SORT GROUP BY            297444    109    9047
  HASH JOIN            297443    109    9047
   TABLE ACCESS FULL    SUPERMAG    SMCASHCHECKS    36    32645    489675
   HASH JOIN            297397    218582    14863576
    TABLE ACCESS FULL    SUPERMAG    SMCASHCHECKITEMS    41    32645    587610
    HASH JOIN            297321    884376    44218800
     TABLE ACCESS FULL    SUPERMAG    SMDOCLOG    27824    20131    523406
     TABLE ACCESS FULL    SUPERMAG    SMSPEC    262797    178869173    4292860152

Mtirt · █ 26.06.2008 17:42

Цитата:

Andrew_Konev ➤ (cc.printtime - log.eventtime) < 1 and
cc.printtime>log.eventtime

Судя по плану запроса на порядок лучше :)

Код:

 SELECT STATEMENT, GOAL = CHOOSE            27931    1    83
 SORT GROUP BY            27931    1    83
  TABLE ACCESS BY INDEX ROWID    SUPERMAG    SMSPEC    14    1    24
   NESTED LOOPS            27930    1    83
    HASH JOIN            27917    1    59
     MERGE JOIN            27874    1    41
      SORT JOIN            27830    20131    523406
       TABLE ACCESS FULL    SUPERMAG    SMDOCLOG    27824    20131    523406
      FILTER                    
       SORT JOIN                    
        TABLE ACCESS FULL    SUPERMAG    SMCASHCHECKS    36    32645    489675
     TABLE ACCESS FULL    SUPERMAG    SMCASHCHECKITEMS    41    32645    587610
    INDEX RANGE SCAN    SUPERMAG    SMSPEC_ART    13    1

Mihon · █ 27.06.2008 16:43

а что по поводу рбс-ов?

Mtirt · █ 27.06.2008 16:47

Если ты будешь запросом меньше грузить базу, тебе RBS настраивать не придется.

Mihon · █ 27.06.2008 16:56

Это я понял. А как можно оптимизировать запрос?