[ОТВЕТИТЬ]
09.08.2006 15:21
OlegON
 
Собственно, почему не делаете? Проверил, у deucel тоже работает на ура, как я понял... Речь о Partitioning.
09.08.2006 17:54
AlexLog
 
И что, шибко толку много ? эт на каких размерчиках надо начинать ?
09.08.2006 17:59
OlegON
 
Думаю, при размере базы от 20Гб - самое оно...
24.08.2006 08:28
reddevil
 
to olegon
для FFMAPREP используем давным давно а к каким еще можно попробовать прикрутить?
24.08.2006 08:59
OlegON
 
По идее, к SMSPEC, например. На всех больших. Какой тип партиций на FFMAPREP использовали?
24.08.2006 09:16
reddevil
 
"by range" по SALEDATE, и subpartition по inlist saletype (товарные отчеты мухой вылетают), по SMSPEC на что попробовать? мои опыта особого прироста не дали по краней мере по чтению а модификацию большим количеством сессий на тестовой БД не протестишь(((
24.08.2006 10:18
OlegON
 
хм, особого прироста точно не будет, тоже пробовал... Тогда не знаю :) А SMCASHCHECKITEMS? Я по памяти, навскидку больше здоровых таблиц не вспомню, да и вообще, у меня-то тоже тестовые только базы...
24.08.2006 14:18
deucel
 
Не советую пробовать на FFSPEC, при переносе у меня ругнулся на
типа немогу восстановить секционированный индекс.
Секционировать имеет смысл только по range и list.
У меня например пока
FFMAPREP (range SALEDATE),
SMSPEC (list DOCTYPE),
SMSPECTAX (range DOCTYPE, но лучше list),
SPSALE (range SALETIME),
SMSPECSTAT (list DOCTYPE)
24.08.2006 14:21
OlegON
 
Цитата:
deucel Секционировать имеет смысл только по range и list.
hash не дает прироста производительности?
24.08.2006 14:32
deucel
 
Мне даже показалось что тормозит.
Хотя если разносить по разным табличным пространствам - может тогда имеет смысл (я пробовал в одном).
24.08.2006 14:38
reddevil
 
SMSPEC (list DOCTYPE),
SMSPECTAX (range DOCTYPE, но лучше list)

в чем конкретно выйгриш провляется?
24.08.2006 14:40
reddevil
 
и в догонку - количесво строк SMSPEC?
24.08.2006 17:08
deucel
 
Цитата:
reddevil в чем конкретно выйгриш провляется?
А какие еще предложения (не переходя на глобальные индексы)?

Кол-во строк 99`163`404 (периодически удаляю акты, инвентаризационные и сличительные).
28.12.2007 10:18
artyom
 
Подскажите пожалуйста, как на Oracle8i Enterprise Edition Release 8.1.6.3.0 подключить функционал Partitioning?
У меня при попытке сделать секции выходит ошибка:
"ORA-00439: Не задействована функциональная возможность: Partitioning"
В моей инсталяшке опции такой не нашел.
28.12.2007 11:48
OlegON
 
Я бы предложил перейти на 9i :) Радует, кстати...
28.12.2007 12:54
kadr
 
Цитата:
artyom Подскажите пожалуйста, как на Oracle8i Enterprise Edition Release 8.1.6.3.0 подключить функционал Partitioning?
У меня при попытке сделать секции выходит ошибка:
"ORA-00439: Не задействована функциональная возможность: Partitioning"
В моей инсталяшке опции такой не нашел.
Это вроде не в инсталяшке надо смотреть а dbca (config assistant) он и позволяет загрузить в базу те или иные опции. Хотя в 8-ой версии это не использовал, могу и ошибаться.
Олег правильно говорит, в 9-ке очень много было доработано в плане партицирования (вчера только препода мучил на эту тему).
28.12.2007 14:34
reddevil
 
Раз уж всплыла тема, то повторю свой вопрос: какие именно операции стали быстрее, после секционирования таблиц SMSPECXXX, и покрывают ли они накладные расходы на обслуживание секций и доп. индексов?

Так же если не сложно deucel, приведи план, результат и время для :

select sum(decode( d.doctype, 'CS', 1,-1)*s.totalprice), count( distinct d.rowid), count(s.rowid)
from smdocuments d
,smspec s
where d.doctype=s.doctype
and d.id=s.docid
and d.doctype in ('CS' ,'CR')
and d.createdat between '01.11.2007' and '30.11.2007';
28.12.2007 16:13
artyom
 
Цитата:
kadr Это вроде не в инсталяшке надо смотреть а dbca (config assistant) он и позволяет загрузить в базу те или иные опции. Хотя в 8-ой версии это не использовал, могу и ошибаться.
Олег правильно говорит, в 9-ке очень много было доработано в плане партицирования (вчера только препода мучил на эту тему).
В dbca такой опции тоже нет.
28.12.2007 16:18
artyom
 
Буду пробовать 9i.
28.12.2007 16:43
OlegON
 
Цитата:
SQL Statement from editor:


select sum(decode( d.doctype, 'CS', 1,-1)*s.totalprice), count( distinct d.rowid), count(s.rowid)
from smdocuments d
,smspec s
where d.doctype=s.doctype
and d.id=s.docid
and d.doctype in ('CS' ,'CR')
and d.createdat between '01.11.2007' and '30.11.2007'
------------------------------------------------------------

Statement Id=6 Type=TABLE ACCESS
Cost=357 TimeStamp=28-12-07::16::41:19

(1) SELECT STATEMENT CHOOSE
Est. Rows: 1 Cost: 361
(10) SORT GROUP BY
Est. Rows: 1
(9) FILTER
(8) TABLE ACCESS BY LOCAL INDEX ROWID SUPERMAG.SMSPEC [Analyzed]
Blocks: 64 824 Est. Rows: 35 of 31 243 755 Cost: 1
(7) NESTED LOOPS
Est. Rows: 2 825 Cost: 361
(4) INLIST ITERATOR
(3) TABLE ACCESS BY INDEX ROWID SUPERMAG.SMDOCUMENTS [Analyzed]
(3) Blocks: 1 152 Est. Rows: 82 of 358 465 Cost: 357
Tablespace: BIG_USERS
(2) UNIQUE INDEX RANGE SCAN SUPERMAG.SMCDOCUMENTS_PK [Analyzed]
Est. Rows: 32 689 Cost: 3
(6) PARTITION LIST INLIST
(5) UNIQUE INDEX RANGE SCAN SUPERMAG.SMCSPEC_PK [Analyzed]
Est. Rows: 2 Cost: 1
Elapsed: 00:00:10.04
29.12.2007 02:49
isi
 
SQL Statement from editor:

Код:
    
  select sum(decode( d.doctype, 'CS', 1,-1)*s.totalprice), count( distinct d.rowid), count(s.rowid)
  from smdocuments d
  ,smspec s
  where d.doctype=s.doctype
  and d.id=s.docid
  and d.doctype in ('CS' ,'CR')
  and d.createdat between '01.12.2007' and '30.12.2007'
  ------------------------------------------------------------
    
  Statement Id=6   Type=INDEX
  Cost=12  TimeStamp=29-12-07::07::49:11
  
       (1)  SELECT STATEMENT  CHOOSE 
     Est. Rows: 1  Cost: 230
       (8)  SORT GROUP BY 
     Est. Rows: 1
           (7)  FILTER
               (6)  TABLE ACCESS BY INDEX ROWID SUPERMAG.SMSPEC  [Analyzed] 
               (6)   Blocks: 520*363 Est. Rows: 3 of 64*542*693  Cost: 1 
                    Tablespace: USERS
                   (5)  NESTED LOOPS 
                        Est. Rows: 1*750  Cost: 230
                       (3)  TABLE ACCESS BY INDEX ROWID SUPERMAG.SMDOCUMENTS  [Analyzed] 
                       (3)   Blocks: 21*968 Est. Rows: 538 of 1*984*123  Cost: 69 
                            Tablespace: USERS
                           (2)  NON-UNIQUE INDEX RANGE SCAN SUPERMAG.SMDOCUMENTS_CREATEDAT  [Analyzed] 
                                Est. Rows: 5*381  Cost: 12
                       (4)  UNIQUE INDEX RANGE SCAN SUPERMAG.SMCSPEC_PK  [Analyzed] 
                            Est. Rows: 1  Cost: 1
29.12.2007 10:42
deucel
 
Цитата:
reddevil Так же если не сложно deucel, приведи план, результат и время для :
не сложно:

Код:
  SQL Statement from editor:
   
   
  SELECT SUM (DECODE (d.doctype, 'CS', 1, -1) * s.totalprice),
         COUNT (DISTINCT d.ROWID), COUNT (s.ROWID)
    FROM smdocuments d, smspec s
   WHERE d.doctype = s.doctype
     AND d.ID = s.docid
     AND d.doctype IN ('CS', 'CR')
     AND d.createdat BETWEEN TO_DATE ('01112007', 'DDMMYYYY')
                         AND TO_DATE ('30112007', 'DDMMYYYY')
  ------------------------------------------------------------
    
  Statement Id=7   Type=INDEX
  Cost=2  TimeStamp=29-12-07::10::26:33
  
       (1)  SELECT STATEMENT  CHOOSE 
     Est. Rows: 1  Cost: 1 858
       (8)  SORT GROUP BY 
     Est. Rows: 1
           (7)  TABLE ACCESS BY LOCAL INDEX ROWID SUPERMAG.SMSPEC  [Analyzed] 
                Blocks: 2 420 476 Est. Rows: 24 of 292 460 555  Cost: 2
               (6)  NESTED LOOPS 
                    Est. Rows: 286 913  Cost: 1 858
                   (3)  TABLE ACCESS BY INDEX ROWID SUPERMAG.SMDOCUMENTS  [Analyzed] 
                   (3)   Blocks: 94 588 Est. Rows: 11 839 of 7 551 318  Cost: 1 146 
                        Tablespace: USERS
                       (2)  NON-UNIQUE INDEX RANGE SCAN SUPERMAG.SMDOCUMENTS_CREATEDAT  [Analyzed] 
                            Est. Rows: 587 325  Cost: 1 605
                   (5)  PARTITION LIST INLIST
                       (4)  UNIQUE INDEX RANGE SCAN SUPERMAG.SMCSPEC_PK  [Analyzed] 
                            Est. Rows: 2  Cost: 2
Statement processed in 162,51 sec
первый запуск в SQL Navigator

Код:
SQL> SELECT SUM (DECODE (d.doctype, 'CS', 1, -1) * s.totalprice),
2         COUNT (DISTINCT d.ROWID), COUNT (s.ROWID)
3    FROM smdocuments d, smspec s
4   WHERE d.doctype = s.doctype
5     AND d.ID = s.docid
6     AND d.doctype IN ('CS', 'CR')
7     AND d.createdat BETWEEN TO_DATE ('01112007', 'DDMMYYYY')
8                         AND TO_DATE ('30112007', 'DDMMYYYY');

SUM(DECODE(D.DOCTYPE,'CS',1,-1)
*S.TOTALPRICE)        COUNT(DISTINCTD.ROWID)    COUNT(S.ROWID)
-------------- ----------------------------- -----------------
     531796183                          5787           7176119


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

План выполнения
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1858 Card=1 Bytes=61)
   1    0   SORT (GROUP BY)
   2    1     TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'SMSPEC' (Cost=2 Card=24 Bytes=744)

   3    2       NESTED LOOPS (Cost=1858 Card=286913 Bytes=17501693)
   4    3         TABLE ACCESS (BY INDEX ROWID) OF 'SMDOCUMENTS' (Cost=1146 Card=11839 Bytes=355170)

   5    4           INDEX (RANGE SCAN) OF 'SMDOCUMENTS_CREATEDAT' (NON-UNIQUE) (Cost=1605 Card=587325)

   6    3         PARTITION LIST (INLIST)
   7    6           INDEX (RANGE SCAN) OF 'SMCSPEC_PK' (UNIQUE) (Cost=2 Card=2)
второй запуск в SQL Plus

ну и сам результат

но тут еще нужно учитывать параметры настроики.
09.01.2008 12:31
reddevil
 
Помогите, что делаю не так!
Создаю табло:
Код:
  create table smspec_part
tablespace ffdata
  PARTITION by list (doctype) 
  ( 
PARTITION  PRT_AC VALUES ('AC'),
PARTITION  PRT_AD VALUES ('AD'),
PARTITION  PRT_BI VALUES ('BI'),
PARTITION  PRT_CA VALUES ('CA'),
PARTITION  PRT_CC VALUES ('CC'),
PARTITION  PRT_CI VALUES ('CI'),
PARTITION  PRT_CN VALUES ('CN'),
PARTITION  PRT_CO VALUES ('CO'),
PARTITION  PRT_CR VALUES ('CR'),
PARTITION  PRT_CS VALUES ('CS'),
PARTITION  PRT_EO VALUES ('EO'),
PARTITION  PRT_FA VALUES ('FA'),
PARTITION  PRT_GT VALUES ('GT'),
PARTITION  PRT_IL VALUES ('IL'),
PARTITION  PRT_IW VALUES ('IW'),
PARTITION  PRT_LA VALUES ('LA'),
PARTITION  PRT_MA VALUES ('MA'),
PARTITION  PRT_ME VALUES ('ME'),
PARTITION  PRT_OC VALUES ('OC'),
PARTITION  PRT_OR VALUES ('OR'),
PARTITION  PRT_PD VALUES ('PD'),
PARTITION  PRT_PE VALUES ('PE'),
PARTITION  PRT_PL VALUES ('PL'),
PARTITION  PRT_PN VALUES ('PN'),
PARTITION  PRT_PO VALUES ('PO'),
PARTITION  PRT_RL VALUES ('RL'),
PARTITION  PRT_RO VALUES ('RO'),
PARTITION  PRT_RP VALUES ('RP'),
PARTITION  PRT_SL VALUES ('SL'),
PARTITION  PRT_SO VALUES ('SO'),
PARTITION  PRT_SR VALUES ('SR'),
PARTITION  PRT_WI VALUES ('WI'),
PARTITION  PRT_WO VALUES ('WO')
 )
 as select * from smspec

потом индексы
Код:
alter table smspec_part add constraint smspec_part_pk  primary key  (doctype, docid, specitem)
using index tablespace ffdata
Код:
create index  smspec_part_pid  on smspec_part  (doctype, docid)
  tablespace ffdata
а в плане все равно ботва какая то:

Код:

--------------------------------------------------------------------------------
| Id  | Operation                           |  Name                  | Rows  | B
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                        |     1 |  
|   1 |  SORT GROUP BY                      |                        |     1 |  
|   2 |   TABLE ACCESS BY GLOBAL INDEX ROWID| SMSPEC_PART            |     4 |  
|   3 |    NESTED LOOPS                     |                        |  9333 |  
|   4 |     TABLE ACCESS BY INDEX ROWID     | SMDOCUMENTS            |  2491 | 7
|   5 |      INDEX RANGE SCAN               | SMDOCUMENTS_CREATEDAT  | 18681 |  
|   6 |     INDEX RANGE SCAN                | SMSPEC_PART_PID        |     1 |  
--------------------------------------------------------------------------------
Ткните пожалуйста, что не так делаю.
09.01.2008 12:35
OlegON
 
Цитата:
reddevil Ткните пожалуйста, что не так делаю.
Если ты про разницу с нашими планами, то она в глобальном и локальном индексе.
09.01.2008 12:37
reddevil
 
Цитата:
OlegON Если ты про разницу с нашими планами, то она в глобальном и локальном индексе.
Блин точна, вот оно как говориться "бревно в глазу". Спасибо.
09.01.2008 14:33
reddevil
 
Пробовал всякие разные запросы..... Со скидкой на погрешность получается одинаково, что секционированная, что нет. Все таки на каких операциях заметен выигрыш?
09.01.2008 20:35
OlegON
 
На любых, где идет отбор по типу документа в данном случае. Ты статистику-то собрал? У меня общее быстродействие по интерсфейсному отклику увеличилось со слов работающих.
15.02.2008 08:05
kadr
 
Цитата:
OlegON hash не дает прироста производительности?
Цитата:
deucel Мне даже показалось что тормозит.
Хотя если разносить по разным табличным пространствам - может тогда имеет смысл (я пробовал в одном).
По идее хэш-секционирование для того и задумывалось, чтобы разделить таблицу на равные части и разложить по разным дискам, тогда должон быть заметен рост
20.03.2008 11:44
mighty
 
Подскажите плз, никак не могу врубиться, сама технология паритиционирования таблиц какая?
1) создаю партиционированную таблицу
2) создаю для неё индексы
3)?? дальше что? надо удалить старую таблицу? вместо неё создать новую на основе партиционированной что ли?

на основе FFMAPREP как пример?
20.03.2008 12:08
OlegON
 
А ты сумел две таблицы с одним именем в схеме создать? Вместо обычной должен сделать партиционированную.


Опции темы


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

 

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