Просто вопросы по Interbase 7.5

Access Violation, некорректное выполнение запросов или вызовов API, ошибки утилит командной строки, в общем все, что вам мешает работать

Модераторы: kdv, dimitr

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Просто вопросы по Interbase 7.5

Сообщение Дмитрий » 12 янв 2005, 12:51

Добрый день всем!
Поставил Interbase 7.5 на NT 4 SP6.
Сразу возникло несколько вопросов:
1. В списке процессов почему-то два гвардейца. Это зачем нужно?
2. При запуске консоли последняя сообщает, что сервер не запущен (на самом деле все ОК), запустить его для Вас? Если сказать нет, то нормально подключается и можно работать с БД. Если сказать да, то ругается, что другой гвардеец уже запущен, и что ничего сделать нельзя.
3. Не понятно, почему сервер не использует системные ресурсы хотя бы наполовину. Например, память: Total - 392624 K, Available - 263620 K, File Cache - 70360 K. При этом имеем около 15 активных пользователей. Что-то настроить надо?
4. Что-то не то стало с оптимизатором. План выполнения одной из моих процедур изменился коренным образом, причем в худшую сторону. Такое чувство, что оптимизатор берет индексы "от вольного", а некоторых совсем не видит (сравниваю с версией 6.5). Если указать план самому - все ОК.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 12 янв 2005, 15:06

1. ты наверное поставил с возможностью multi-instance. отсюда 2 сервера

2. забей на консоль, это сторонний продукт, включенный в поставку. www.ibexpert.com

3. www.ibase.ru/devinfo/ibconfig.htm плюс opguide.pdf по новым параметрам конфига

4. все может быть. лучше пересобрать статистику по индексам.

надеюсь, ты пользуешься триалом с сайта, а не дистрибутивом из D2005.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 12 янв 2005, 15:35

ты наверное поставил с возможностью multi-instance. отсюда 2 сервера
Нет, не ставил. Сказал, что эта фича мне не нужна. Причем у меня сервер один, а гвардейцев два.
забей на консоль, это сторонний продукт, включенный в поставку
Давно забил! Просто впечатлениями делюсь. IBExpert - навсегда!
все может быть. лучше пересобрать статистику по индексам
А зачем? База свежевосстановленная. Я так понимаю, что и индексы свеженькие?
надеюсь, ты пользуешься триалом с сайта, а не дистрибутивом из D2005
А фиг его знает! Скачал откуда-то, но не с Борланда. У них не получилось.
И вовсе это уже не триал :lol:
www.ibase.ru/devinfo/ibconfig.htm плюс opguide.pdf по новым параметрам конфига
Будем смотреть. Просто на эксперименты времени нет, да и люди работают с базой.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 12 янв 2005, 17:02

значит до того уже был установлен 7.0/7.1, и 7.5 встал как доп. сервис. удалить можно только вручную (программой, которая может удалять сервисы по их имени). Либо это глюк инсталлятора, чего я пока не видел и не слышал.

при свежевосстановленной базе да, у индексов статистика свежая. значит увы, оптимизатор несколько окривел.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 12 янв 2005, 17:42

значит до того уже был установлен 7.0/7.1
Ничего подобного! До этого был 6.5, который был снесен и даже директория удалена.
оптимизатор несколько окривел
Ничего себе окривел!!! Да он просто ох..л!!! Он не видит очевидных индексов. Есть нормальный индекс, почти уникальный, идет связь двух таблиц по полям из этого индекса, а он говорит NATURAL. Руками пишешь план - все ОК.
А вообще, 7.5 юзал кто серьезно? Или так, на уровне демо баз?

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 12 янв 2005, 18:13

там не так сильно исправлен оптимизатор, чтобы окриветь совсем. у тебя просто частный случай. надо посмотреть, есть ли такое на qc.borland.com, или просто дать им пример запроса и нехорошего плана (с предыдущим хорошим планом). В FB тоже оптимизатор не сразу починили. Собственно, пока его и не дочинили, вообще то.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 12 янв 2005, 18:36

Дык я могу сюда выложить структуру таблиц, индексов и два разных плана. Не хочу с Борландом связываться! :cry:

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 12 янв 2005, 18:48

то есть я должен все это оформить, и послать туда? однако. я, конечно, могу, но удивляет вот это "не хочу связваться". Точно так же многие не хотят "связываться" с FB, а потом на разных форумах пишут, что мол, баги не исправляют. Я не тыкаю пальцем, а ворчу в потолок, риторически ...

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 09:23

Хорошо, скажу иначе. Не сильно я волоку в англицком, что бы борландам описать проблему. Из-за этого и предлагаю здесь обсудить. Может кто у себя попробует. Легче же с братьями россиянами работать, чем с буржуями. :)

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 13 янв 2005, 09:49

давай. только желательно структуры таблиц предварительно сократить до минимума и убрать все домены. в общем, сделать минимальный пример. запрос и планы запросов приводи реальные.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 10:42

Выкладываю.
Запрос:

Код: Выделить всё

SELECT MIN(DIV_99.RD_NUM) AS RD_NUM, MIN(C.SCH_DEP) AS SCH_DEP, MAX(C.OPER_DATE) AS OPER_DATE,
       MIN(C.PAY_KOD) AS PAY_KOD, MAX(C.PAY_SUM) AS PAY_SUM,
       MAX(C.RET_SUM) AS RET_SUM, MAX(C.PAY_CODE) AS PAY_CODE,
       MAX(C.REP_RAO_NUM) AS REP_RAO_NUM, MAX(COUNTERS.REAL_YEAR) AS REAL_YAER,
       MAX(DIV_99.OWN_NAM) AS OWN_NAM, MAX(DIV_99.OWN_TYP) AS OWN_TYP,
       MAX(DIV_99.DOC_TYP) AS REZID, MAX(DIV_99.DVD_NCH) DVD_NCH,
       MAX(DIV_99.DVD_NAL1) AS DVD_NAL1, MAX(DIV_99.DVD_NAL2) AS DVD_NAL2,
       MAX(DIV_99.DVD_SUM) AS DVD_SUM
FROM DIV_99
 INNER JOIN PAY_HISTORY C ON (DIV_99.SCH_DEP = PAY_HISTORY.SCH_DEP AND
                              DIV_99.YEAR_VIP = PAY_HISTORY.YEAR_VIP)
 INNER JOIN COUNTERS ON (DIV_99.YEAR_VIP = COUNTERS.YEAR_VIP)
WHERE (C.REP_RAO_NUM BETWEEN :REP1 AND :REP2) AND (C.REP_RAO_NUM =
                                                                  (SELECT MAX(REP_RAO_NUM)
                                                                   FROM PAY_HISTORY
                                                                   WHERE (REP_RAO_NUM BETWEEN :REP1 AND :REP2) AND
                                                                         (SCH_DEP = C.SCH_DEP) AND (YEAR_VIP = C.YEAR_VIP)
                                                                  )
                                                  ) AND
      (C.PAY_KOD <> '_ВЦ')
GROUP BY C.SCH_DEP, C.YEAR_VIP
[/color][/size]

Структура таблиц:
/******************************************************************************/
/**** Tables ****/
/******************************************************************************/



CREATE TABLE COUNTERS (
YEAR_VIP VARCHAR(6),
REAL_YEAR VARCHAR(15)
);

CREATE TABLE DIV_99 (
RD_NUM VARCHAR(3) NOT NULL,
SCH_DEP VARCHAR(20) NOT NULL,
OWN_TYP SMALLINT,
OWN_NAM VARCHAR(128),
DOC_TYP SMALLINT,
DVD_NCH NUMERIC(15,2),
DVD_NAL1 NUMERIC(15,2),
DVD_NAL2 NUMERIC(15,2),
DVD_SUM NUMERIC(15,2),
YEAR_VIP VARCHAR(6) NOT NULL
);

CREATE TABLE PAY_HISTORY (
REC_NO INTEGER NOT NULL,
SCH_DEP VARCHAR(20),
PAY_SUM NUMERIC(15,2),
RET_SUM NUMERIC(15,2),
DOCUMENT VARCHAR(20),
OPER_DATE DATE,
PAY_CODE VARCHAR(17),
PAY_KOD VARCHAR(3),
REP_RAO_NUM SMALLINT,
PH_NOTE VARCHAR(255),
REPORT_DATE DATE,
PDOC_SUM NUMERIC(15,2) DEFAULT 0,
DOC_ID INTEGER,
YEAR_VIP VARCHAR(6)
);


/******************************************************************************/
/**** Indices ****/
/******************************************************************************/

CREATE UNIQUE INDEX CNT_1 ON COUNTERS (YEAR_VIP);
CREATE INDEX DV99_2 ON DIV_99 (SCH_DEP, YEAR_VIP);
CREATE INDEX DV99_7 ON DIV_99 (YEAR_VIP, RD_NUM);
CREATE INDEX PH_1 ON PAY_HISTORY (SCH_DEP, YEAR_VIP);
CREATE INDEX PH_4 ON PAY_HISTORY (REP_RAO_NUM);

План в 6.5:
PLAN JOIN (C ORDER PH_1,COUNTERS INDEX (CNT_1),DIV_99 INDEX (DV99_2)) PLAN (PAY_HISTORY INDEX (PH_1,PH_4))
План в 7.5:
PLAN (PAY_HISTORY INDEX (PH_1,PH_4)) PLAN SORT (JOIN (COUNTERS NATURAL,DIV_99 INDEX (DV99_7),C INDEX (PH_1,PH_4)))

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 13 янв 2005, 10:53

еще укажи примерное число записей в таблицах, и селективность индексов (rdb$indices.rdb$statistics) было бы очень здорово.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 11:39

Записи:
COUNTERS - 10
PAY_HISTORY - 7424990
DIV_99 - 6698014


Индексы:
CNT_1 - 0.1....
DV99_2 - 0.0000001....
DV99_7 - 0.0017....
PH_1 - 0.0000002....
PH_4 - 0.0042.....

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 13 янв 2005, 11:46

так, еще я вижу в запросе вот что - вопиюще некорректное использование алиасов. алиас задан для history как c, дальше по тексту history используется как сама, так и как c. Так делать не рекомендуется.

если уж взялся алиасы писать, так к чему полные имена таблиц? Сделай
FROM DIV_99 D
INNER JOIN PAY_HISTORY PH ON (D.SCH_DEP = PH.SCH_DEP AND
D.YEAR_VIP = PH.YEAR_VIP)
INNER JOIN COUNTERS C ...

и запрос будет лучше читаться. Соответственно везде надо будет имена таблиц заменить на их алиасы.
Кроме того, что будет если убрать явный join, и просто написать

FROM DIV_99 D, PAY_HISTORY PH, COUNTERS C
where D.SCH_DEP = PH.SCH_DEP AND
D.YEAR_VIP = PH.YEAR_VIP and ...

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 12:03

Сейчас в 7.5 уберу джоины и посмотрю, как план будет меняться. Потом сообщю результат.
ЗЫ: Вариант предыдущего запроса работает уже 32 часа.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 14:11

Переписал запрос. План выполнения не изменился.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 13 янв 2005, 15:16

вообще это мазохизм. тебе прямая дорога на хранение промежуточных агрегатов, в данном случае max. Считать это все по таблицам с миллионами записей - несерьезно при любом сервере.

Дмитрий
Сообщения: 127
Зарегистрирован: 26 окт 2004, 11:05

Сообщение Дмитрий » 13 янв 2005, 16:06

Да мне только один агрегат нужен, а из-за гроуп бай приходится все указывать. И тем более, там же условия есть, которые индексы используют.
А что с оптимизатором? Улучшили они его в 7.5? :lol:

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 13 янв 2005, 17:58

ну вообще судя по статистике индексов - улучшили. вот только plan sort все дело портит.

Anton Glasunov
Сообщения: 31
Зарегистрирован: 26 окт 2004, 15:18

Сообщение Anton Glasunov » 31 янв 2005, 12:39

У меня переход с 7.1 на 7.5 прошел относительно гладко - пользую 7.5 больше месяца на девелоперской машине. Были проблемы, когда одни старые отлаженные запросы стали выполняться медленне, а другие быстрее при переходе с 7.0 на 7.1(мною была пройдена последовательная смена версий, начиная с IB 4.2). Те которые стали медленнее, пришлость переписать манипулируя порядком join'ов и || "" и
+ 0. При переходе 7.1 -> 7.5 таких проблем пока не замечено. Автор же исходного сообщения переходил с версии 6.5.

Ответить