Просто вопросы по Interbase 7.5
Просто вопросы по Interbase 7.5
Добрый день всем!
Поставил Interbase 7.5 на NT 4 SP6.
Сразу возникло несколько вопросов:
1. В списке процессов почему-то два гвардейца. Это зачем нужно?
2. При запуске консоли последняя сообщает, что сервер не запущен (на самом деле все ОК), запустить его для Вас? Если сказать нет, то нормально подключается и можно работать с БД. Если сказать да, то ругается, что другой гвардеец уже запущен, и что ничего сделать нельзя.
3. Не понятно, почему сервер не использует системные ресурсы хотя бы наполовину. Например, память: Total - 392624 K, Available - 263620 K, File Cache - 70360 K. При этом имеем около 15 активных пользователей. Что-то настроить надо?
4. Что-то не то стало с оптимизатором. План выполнения одной из моих процедур изменился коренным образом, причем в худшую сторону. Такое чувство, что оптимизатор берет индексы "от вольного", а некоторых совсем не видит (сравниваю с версией 6.5). Если указать план самому - все ОК.
Поставил Interbase 7.5 на NT 4 SP6.
Сразу возникло несколько вопросов:
1. В списке процессов почему-то два гвардейца. Это зачем нужно?
2. При запуске консоли последняя сообщает, что сервер не запущен (на самом деле все ОК), запустить его для Вас? Если сказать нет, то нормально подключается и можно работать с БД. Если сказать да, то ругается, что другой гвардеец уже запущен, и что ничего сделать нельзя.
3. Не понятно, почему сервер не использует системные ресурсы хотя бы наполовину. Например, память: Total - 392624 K, Available - 263620 K, File Cache - 70360 K. При этом имеем около 15 активных пользователей. Что-то настроить надо?
4. Что-то не то стало с оптимизатором. План выполнения одной из моих процедур изменился коренным образом, причем в худшую сторону. Такое чувство, что оптимизатор берет индексы "от вольного", а некоторых совсем не видит (сравниваю с версией 6.5). Если указать план самому - все ОК.
1. ты наверное поставил с возможностью multi-instance. отсюда 2 сервера
2. забей на консоль, это сторонний продукт, включенный в поставку. www.ibexpert.com
3. www.ibase.ru/devinfo/ibconfig.htm плюс opguide.pdf по новым параметрам конфига
4. все может быть. лучше пересобрать статистику по индексам.
надеюсь, ты пользуешься триалом с сайта, а не дистрибутивом из D2005.
2. забей на консоль, это сторонний продукт, включенный в поставку. www.ibexpert.com
3. www.ibase.ru/devinfo/ibconfig.htm плюс opguide.pdf по новым параметрам конфига
4. все может быть. лучше пересобрать статистику по индексам.
надеюсь, ты пользуешься триалом с сайта, а не дистрибутивом из D2005.
Нет, не ставил. Сказал, что эта фича мне не нужна. Причем у меня сервер один, а гвардейцев два.ты наверное поставил с возможностью multi-instance. отсюда 2 сервера
Давно забил! Просто впечатлениями делюсь. IBExpert - навсегда!забей на консоль, это сторонний продукт, включенный в поставку
А зачем? База свежевосстановленная. Я так понимаю, что и индексы свеженькие?все может быть. лучше пересобрать статистику по индексам
А фиг его знает! Скачал откуда-то, но не с Борланда. У них не получилось.надеюсь, ты пользуешься триалом с сайта, а не дистрибутивом из D2005
И вовсе это уже не триал
Будем смотреть. Просто на эксперименты времени нет, да и люди работают с базой.www.ibase.ru/devinfo/ibconfig.htm плюс opguide.pdf по новым параметрам конфига
значит до того уже был установлен 7.0/7.1, и 7.5 встал как доп. сервис. удалить можно только вручную (программой, которая может удалять сервисы по их имени). Либо это глюк инсталлятора, чего я пока не видел и не слышал.
при свежевосстановленной базе да, у индексов статистика свежая. значит увы, оптимизатор несколько окривел.
при свежевосстановленной базе да, у индексов статистика свежая. значит увы, оптимизатор несколько окривел.
Ничего подобного! До этого был 6.5, который был снесен и даже директория удалена.значит до того уже был установлен 7.0/7.1
Ничего себе окривел!!! Да он просто ох..л!!! Он не видит очевидных индексов. Есть нормальный индекс, почти уникальный, идет связь двух таблиц по полям из этого индекса, а он говорит NATURAL. Руками пишешь план - все ОК.оптимизатор несколько окривел
А вообще, 7.5 юзал кто серьезно? Или так, на уровне демо баз?
там не так сильно исправлен оптимизатор, чтобы окриветь совсем. у тебя просто частный случай. надо посмотреть, есть ли такое на qc.borland.com, или просто дать им пример запроса и нехорошего плана (с предыдущим хорошим планом). В FB тоже оптимизатор не сразу починили. Собственно, пока его и не дочинили, вообще то.
Выкладываю.
Запрос:
[/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)))
Запрос:
Код: Выделить всё
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
Структура таблиц:
/******************************************************************************/
/**** 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)))
так, еще я вижу в запросе вот что - вопиюще некорректное использование алиасов. алиас задан для 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 ...
если уж взялся алиасы писать, так к чему полные имена таблиц? Сделай
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 ...
-
- Сообщения: 31
- Зарегистрирован: 26 окт 2004, 15:18
У меня переход с 7.1 на 7.5 прошел относительно гладко - пользую 7.5 больше месяца на девелоперской машине. Были проблемы, когда одни старые отлаженные запросы стали выполняться медленне, а другие быстрее при переходе с 7.0 на 7.1(мною была пройдена последовательная смена версий, начиная с IB 4.2). Те которые стали медленнее, пришлость переписать манипулируя порядком join'ов и || "" и
+ 0. При переходе 7.1 -> 7.5 таких проблем пока не замечено. Автор же исходного сообщения переходил с версии 6.5.
+ 0. При переходе 7.1 -> 7.5 таких проблем пока не замечено. Автор же исходного сообщения переходил с версии 6.5.