ReSQL.ru
     
powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема с substr?
25 сообщений из 51, страница 2 из 3
  2  все
Проблема с substr?
    #35590833
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
В принципе, я получил ответ на свой вопрос. Всем спасибо за помощь и пояснения.
...
Рейтинг: 0 / 0
13.10.2008, 11:41
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35590969
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Евгений ФадеевЖуравлев Денис2faceДо этого работал с ораклом и там все было нормально, даже при работе с таблицами с большим количеством записей.В этом месте информикс лучше оракла в несколько раз.Речь про форум или про большие таблицы?
Если первое - то не в несколько раз, а в принципе. Если про второе - спорно :))

Если Вас не устраивает функциональность substr или поиск по LIKE - тогда
можно использовать технологию DataBlade - IBM INFORMIX EXCALIBUR TEXT SEARCH DATABLADE MODULE
или бесплатный поисковый datablade для версии 11.x

С уважением,
Вадим
...
Рейтинг: 0 / 0
13.10.2008, 12:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591042
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Внимательно посмотрел (дошли руки)

1 запрос substr

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' )
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

2 запрос

(1) Index Keys: cmfo cacc currency dtend (Key-First) (Serial, fragments: ALL)
Lower Index Filter: (informix.payord.cacc[1,4] = '6010' AND informix.payord.cmfo = informix.config_getkey('MFO' ,'COMMON' ))
Index Key Filters: (informix.payord.dtend >= 01/03/2008 ) AND
(informix.payord.dtend <= 31/03/2008 )

имеем индекс --- cmfo cacc currency dtend безумие, предиката с currency вообще в запросе нет, значит сканируется часть индекса лишняя. Т.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
...
Рейтинг: 0 / 0
13.10.2008, 12:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591224
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Индексы в таблицах создала программерская контора, которая написала "замечательную" АБС Profix. Айтишники ничего исправлять или добавлять не будут.
...
Рейтинг: 0 / 0
13.10.2008, 13:57
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591295
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
2faceИндексы в таблицах создала программерская контора, которая написала "замечательную" АБС Profix. Айтишники ничего исправлять или добавлять не будут.а фиг ли вы тогда запросы сами пишите? Естественно они работают плохо.
...
Рейтинг: 0 / 0
13.10.2008, 14:22
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591865
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
База создана под банковскую систему профикс. Соответственно под их потребности, в плане построения отчетов и вывода информации. Но тех возможностей, которые предоставляет профикс, недостаточно. Вот и приходится мне писать различные выборки. До этого я работал с ораклом и там изначально была правильно спроектированная база. Вот поэтому я и задал вопрос, чтобы выяснить в чем проблема: информиксе или в структуре базы. Выяснилось, что в структуре.
...
Рейтинг: 0 / 0
13.10.2008, 17:21
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591875
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Они это пишут, поскольку им дали такую возможность. Ничего зазорного в этом нет, в крупнейшем мировом Банке (вернее в его маленькой украинской дочке) целая плеяда главбухов этим в Экселе балуется уже лет 10.

Кстати насчет совета по currency, рекомендую прислушаться и явно указать, поскольку по счетам доходов операций с валютой отличной от 980 все равно не происходит.
...
Рейтинг: 0 / 0
13.10.2008, 17:24
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591905
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Папрашу птичку, а именно структуру ProFIX/ODB не пенять. Пеняйте на свои запросы и не знание особенностей системы.

Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.
...
Рейтинг: 0 / 0
13.10.2008, 17:33
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591968
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Daugava Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.

substr(cacc,1,4) in (6010,6011,6012,6013,6014,6015,6016,6017,6018)

номер счета протаскивать в таблицу проводок я бы не стал (но я вообще суррогато-пурист), хотя так делают все, но гемора из-за этого ойёй, и задрали эти ограничения по балансовым группам захардкоженные в тысяче и одной мест.
...
Рейтинг: 0 / 0
13.10.2008, 17:52
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35591987
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
DaugavaПапрашу птичку, а именно структуру ProFIX/ODB не пенять. Пеняйте на свои запросы и не знание особенностей системы.

Я ее (структуру) не видел лет так 6, но судя по вашим запросам она не сильно изменилась. Из всех банковских систем, которые я видел (включая с десяток западных и десятка два украинских) - лучшая.
Я сожалею, если это лучшая АБС, с которой Вы работали. Это самая убогая и ограниченная АБС. Правда я работал всего с 5 системами.
...
Рейтинг: 0 / 0
13.10.2008, 17:58
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35592349
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
Журавлев ДенисТ.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?
Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?
...
Рейтинг: 0 / 0
13.10.2008, 22:38
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35592697
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
2faceЯ сожалею, если это лучшая АБС, с которой Вы работали.
Я не говорил, что это лучшая АБС это был бы уже полный оффтоп, я сказал, что у нее лучшая структура БД :). Кроме того, я не говорил, что я с ней работал, просто по роду работ приходилось конвертировать данные в/из самые различные системы.
...
Рейтинг: 0 / 0
14.10.2008, 10:14
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35593016
2face
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
2face
Гость
Насчет структуры БД я бы тоже поспорил. Часть таблиц "перегружены" лишними полями, некоторые очевидные связи сделаны мягко говоря странно. Индексы в таблицах, возможно, были созданы только под нужды Профикса. А т.к. набор инструментов ограничен, то возникают проблемы со скоростью выборки. До этого я работал с ораклами 9 и 10 и мссервером. Там таких проблем не было, потому что были грамотно спроектированы БД.
...
Рейтинг: 0 / 0
14.10.2008, 12:03
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35593183
Фотография Daugava
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Daugava
Участник
Проектировать индексы под "другие задачи" - обязанность админа БД, а не разработчика. Да и вообще заниматься фрагментацией по условиям надо именно на конкретной инсталляции. Поскольку это все таки более менее коробочный продукт, заточенный под среднюю температуру по больнице и то, что будет хорошо Клиенту А, будет абсолютно не примлемо Клиентом Б.
Знаю я вашего "Оракла", выросшего из штанишек Интербейса, но справедливости ради его базу за вымя я не щупал, врать не буду. По "МСсерверу" - есть дельные вещи, но если бы не побег в Канаду-Штаты отцов основателей, я бы их уже задушил, как минимум за структуру ConnotationValues.
Кроме того, стоит учесть, что в отличие от приводимых вами двух основных конкурентов структура БД Профикса значительно старше и пережила изменение плана счетов в 98-году. Может я и ошибся в предположениях по конкретным разработчикам, но это врядли, поскольку узок круг широкораспространненых банковских АБС в Украине.
...
Рейтинг: 0 / 0
14.10.2008, 12:53
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594504
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
bk0010Журавлев ДенисТ.е. запрос потенциально можно ускорить еще и еще, если сделать "правильный" индекс или правильно фрагментировать существующий индескс.
Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?
Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?


Фрагментирование + PDQPRIORITY>=1 в 80% случаев будет быстрее.
...
Рейтинг: 0 / 0
14.10.2008, 20:42
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594518
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
onstatФрагментирование + PDQPRIORITY>=1 в 80% случаев будет быстрее.
Спасибо. А Mirroring тоже до сих пор актуален или лучше делать RAID 1?
...
Рейтинг: 0 / 0
14.10.2008, 21:00
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594596
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
bk0010Под "фрагментировать индекс" вы имеете в виду разнести части индекса по разным дискам?Что обычно выгоднее: собрать диски в raid 0 или фрагментировать самые затребованные таблицы?фрагментировать -- разбить на куски. Все валим на один рейд, никаких дисков.

Создаем табличку
create table test_entry(acc char(20), adate date, sum decimal(20,2)) in speedtest;

Наполняем
execute procedure fill_te(100000);

select count(*) from test_entry;
1311763

update statistics high for table test_entry;

Мучать будем запрос
Код: plaintext
1.
2.
select {+explain} count(*)
from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[ 1 , 4 ]='1111'

Создаю хороший индекс
create index ixte1 on test_entry(acc,adate) in speedtest;
Estimated Cost: 31
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:38:00)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 31
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

    (1) Index Keys: acc adate   (Key-Only)  (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 
        Index Key Filters:  (informix.test_entry.adate >= 01/01/2008 ) AND
                            (informix.test_entry.adate < 01/04/2008 )


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        663        00:00.01   31      

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.01


Создаем индекс фрагментированный c partition
create index ixte1 on test_entry(acc)
fragment by expression
partition p12007 adate >= '01.01.2007' and adate < '01.04.2007' in speedtest,
partition p22007 adate >= '01.04.2007' and adate < '01.07.2007' in speedtest,
partition p32007 adate >= '01.07.2007' and adate < '01.10.2007' in speedtest,
partition p42007 adate >= '01.10.2007' and adate < '01.01.2008' in speedtest,
partition p12008 adate >= '01.01.2008' and adate < '01.04.2008' in speedtest,
partition p22008 adate >= '01.04.2008' and adate < '01.07.2008' in speedtest,
partition p32008 adate >= '01.07.2008' and adate < '01.10.2008' in speedtest,
partition p42008 adate >= '01.10.2008' and adate < '01.01.2009' in speedtest;
Estimated Cost: 103
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:33:15)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 103
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

        Filters: (informix.test_entry.adate >= 01/01/2008 AND informix.test_entry.adate < 01/04/2008 ) 

    (1) Index Keys: acc   (Serial, fragments: 4)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         91        71         00:00.12   104     

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.12


create index ixte1 on test_entry(acc) in speedtest;
Estimated Cost: 645
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:35:42)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 645
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

        Filters: (informix.test_entry.adate >= 01/01/2008 AND informix.test_entry.adate < 01/04/2008 ) 

    (1) Index Keys: acc   (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         91        663        00:03.59   645     

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:03.59


без индекса
Estimated Cost: 51967
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:39:57)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 51967
Estimated # of Rows Returned: 1

  1) informix.test_entry: SEQUENTIAL SCAN

        Filters: ((informix.test_entry.acc[1,4] = '1111' AND informix.test_entry.adate >= 01/01/2008 ) AND informix.test_entry.adate < 01/04/2008 ) 


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        1311763    00:02.04   51968   

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:02.04


хреновый индекс
create index ixte1 on test_entry(acc, sum, adate) in speedtest;
Estimated Cost: 34
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
QUERY: (OPTIMIZATION TIMESTAMP: 10-14-2008 21:42:01)
------
select {+explain} count(*)

from test_entry where adate >= '01.01.2008' and adate < '01.04.2008' and acc[1,4]='1111'

DIRECTIVES FOLLOWED: 
EXPLAIN 
DIRECTIVES NOT FOLLOWED: 

Estimated Cost: 34
Estimated # of Rows Returned: 1

  1) informix.test_entry: INDEX PATH

    (1) Index Keys: acc sum adate   (Key-Only)  (Serial, fragments: ALL)
        Lower Index Filter: informix.test_entry.acc[1,4] = '1111' 
        Index Key Filters:  (informix.test_entry.adate >= 01/01/2008 ) AND
                            (informix.test_entry.adate < 01/04/2008 )


Query statistics:
-----------------

  Table map :
  ----------------------------
  Internal name     Table name
  ----------------------------
  t1                test_entry

  type     table  rows_prod  est_rows  rows_scan  time       est_cost
  -------------------------------------------------------------------
  scan     t1     71         90        663        00:00.02   34      

  type     rows_prod  est_rows  rows_cons  time
  -------------------------------------------------
  group    1          1         71         00:00.02


наполнял так:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
CREATE PROCEDURE fill_te(a int);
    define b int; 
    for b = 1 to a
       insert into test_entry values(sp_random()||'', '10.01.2007', 0);
       insert into test_entry values(sp_random()||'', '10.04.2007', 0);
       insert into test_entry values(sp_random()||'', '10.07.2007', 0);
       insert into test_entry values(sp_random()||'', '10.10.2007', 0);
       insert into test_entry values(sp_random()||'', '10.01.2008', 0);
       insert into test_entry values(sp_random()||'', '10.04.2008', 0);
       insert into test_entry values(sp_random()||'', '10.07.2008', 0);
       insert into test_entry values(sp_random()||'', '10.10.2008', 0);       
    end for
END PROCEDURE;


CREATE PROCEDURE sp_random( ) RETURNING INTEGER; 
    DEFINE GLOBAL seed DEC( 10 ) DEFAULT 1; 
    DEFINE d DEC( 20, 0 ); 
    LET d = seed * 1103515245 + 12345; 
    LET seed = d - 4294967296 * TRUNC( d / 4294967296 ); 
    RETURN MOD( seed , 4294967296/2 ); 
END PROCEDURE;


тест получился плохой, дата одинаковая, и работает похоже все несколько иначе. Т.е. при фрагментированном индексе почему-то нет KEY-ONLY , зачем-то ходит в таблицу
...
Рейтинг: 0 / 0
14.10.2008, 22:28
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594653
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Это батенька зря ...

Создаем индекс фрагментированный c partition
create index ixte1 on test_entry(acc)
fragment by expression
partition p12007 adate >= '01.01.2007' and adate < '01.04.2007' in speedtest,
partition p22007 adate >= '01.04.2007' and adate < '01.07.2007' in speedtest,
partition p32007 adate >= '01.07.2007' and adate < '01.10.2007' in speedtest,
partition p42007 adate >= '01.10.2007' and adate < '01.01.2008' in speedtest,
partition p12008 adate >= '01.01.2008' and adate < '01.04.2008' in speedtest,
partition p22008 adate >= '01.04.2008' and adate < '01.07.2008' in speedtest,
partition p32008 adate >= '01.07.2008' and adate < '01.10.2008' in speedtest,
partition p42008 adate >= '01.10.2008' and adate < '01.01.2009' in speedtest;

Попробуй фрагментировать индекс не для одного partition, а для нескольких db-пространств
(in speedtest1, in speedtest2, in speedtest3, in speedtest4 и т.д) !!!

С уважением,
Вадим.
...
Рейтинг: 0 / 0
14.10.2008, 23:39
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35594901
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
а теперь про умненького оракла который умеет substr



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> set autotrace on
SQL> select count(*)
  2  from absmain.acc_Entry
  3  where  substr(EN_CNT_NUM,1,4) = '3010' and en_vir_cnt='0000.00' and en_dt_buh >= '01.01.2001' and en_dt_buh  INDEX* (FAST FULL SCAN) OF 'EN_CNT_NUM_IDX' (NON-UNIQU :Q23000E) (Cost=31 Card=4 Bytes=136)

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         226  consistent gets 
          0  physical reads
          0  redo size
        407  bytes sent via SQL*Net to client
        499  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed





тупим однако, переписываю в like.




Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
SQL> select count(*)
  2  from absmain.acc_Entry
  3  where  EN_CNT_NUM like '3010%' and en_vir_cnt='0000.00' and en_dt_buh >= '01.01.2001' and en_dt_buh   INDEX (RANGE SCAN) OF 'EN_CNT_NUM_IDX' (NON-UNIQUE) (Cost=4 Card=2 Bytes=68)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          13  consistent gets 
          0  physical reads
          0  redo size
        407  bytes sent via SQL*Net to client
        499  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL> disc
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
...
Рейтинг: 0 / 0
15.10.2008, 09:23
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35596904
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
GVF112GVFЭто батенька зря ...
почему?

GVF112GVF
Попробуй фрагментировать индекс не для одного partition, а для нескольких db-пространств
(in speedtest1, in speedtest2, in speedtest3, in speedtest4 и т.д) !!!и зачем?
...
Рейтинг: 0 / 0
15.10.2008, 20:51
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597023
bk0010
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bk0010
Участник
Журавлев Дениси зачем?
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.
...
Рейтинг: 0 / 0
15.10.2008, 22:13
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597273
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
bk0010
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.бред какой-то, я показывал обратное, видимо никто не понимает что такое фрагментация и для чего ее применять. ртфм.
...
Рейтинг: 0 / 0
16.10.2008, 08:34
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597508
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
bk0010Журавлев Дениси зачем?
Возможно если заставить грузиться куски индекса с разных дисков одновременно, то это позволит улучшить те удручающие результаты, которые вы привели выше. Хотя, скорее всего, скорость выполнения увеличится только если саму таблицу разнести по дискам, но стоимость запроса при этом уменьшится вряд ли. То, что не стоит фрагментировать данные на RAIDе вы показали очень убедительно: никак не ожидал, что стоимость при этом вырастет не на проценты, а в разы.

Денис совсем о другом хотел сказать.
Вопрос заключается в том, что если есть однозначное попадание ключа индекса
в один фрагмент, значит должен читаться только один фрагмент, а не 4.
...
Рейтинг: 0 / 0
16.10.2008, 10:26
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597548
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Я хотел сказать что для таблицы с проводками, необходим индекс (счет,дата), но для квартальных отчетов при большом объеме таблицы (например от 500 млн записей), неплохо заиметь фрагментацию этого индекса (таблицу можно не фрагментировать, хотя при этом появляется опасность напороться на ограничения информикса).
В 2008 году -- диски шпинделя раиды роли не играют.

Еще можно заиметь таблицу счет, где балансовая группа -- отдельное индексированное поле тогда:

select dmfo, dacc, cmfo, cacc, amountuak
from vpayord, счет
where
счет.балансовая_группа in (6010,6011,6012,6013,6014,6015,6016,6017,6018)
and счет.id = vpayord.счетid
and cmfo=config_getkey('MFO','COMMON')
and dtend between MDY(3,1,2008) and MDY(3,31,2008)
...
Рейтинг: 0 / 0
16.10.2008, 10:36
| Ответить | Цитировать | Написать  
Проблема с substr?
    #35597639
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Журавлев ДенисЯ хотел сказать что для таблицы с проводками, необходим индекс (счет,дата), но для квартальных отчетов при большом объеме таблицы (например от 500 млн записей), неплохо заиметь фрагментацию этого индекса (таблицу можно не фрагментировать, хотя при этом появляется опасность напороться на ограничения информикса).
В 2008 году -- диски шпинделя раиды роли не играют.

Если обслуждать кулинарию приготовления отчетов, то индексов на все отчеты
ненапасешся,
Я считаю что таблицу нужно фрагментировать, а отчеты можно и фулсканом
прогнать, только следить за тем что бы база читала только один или нужный список фрагментов.

p.s. По поводу раидов и шпинделей не согласен, но спорить не буду ибо оффтопик относительно substr.
...
Рейтинг: 0 / 0
16.10.2008, 10:59
| Ответить | Цитировать | Написать  
25 сообщений из 51, страница 2 из 3
  2  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Проблема с substr?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=44&msg=35591905&tid=1607978]:
 0ms
get settings:
 8ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 75ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 67ms
get tp. blocked users:
 1ms
others: 325ms
total:  511ms
созд. / загр.: 511ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]