Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Выбор сервера БД? [D6, D7, IB4.x, MySQL]

Страницы: 1 2 >
sw © (2004-10-24 18:51:00)
Есть программа для работы c Interbase базой,
на данный момент в ней уже порядка 5000-6000 тыс. записей.
На одном компьютере оставлена база, остальные (еще 5 комп-ров) обращаются как к сетевому.
В последнее отчеты (QR 1-2 страница) генерируются вообще по минут 5-6, а так как объем базы
в будующем будет нарастать возникли вопросы:
Какие коренные изменения можно(нужно) сделать чтобы как то повлиять на эту ситуацию.
Может быть бросить IB и пока не поздно переписать под MySQL или еще что-нибудь(измениться ли что-то от этого?)
Очень хочеться услышать советы от тех кто разрабатывал подобные проекты.

Danilka (2004-11-02 09:42:00) [1]
[23] sw (29.10.04 13:55)
> > А B/R нормально?
> не совсем понимаю о чем идет речь ?

B/R = Backup/Restore
только, восстанавливай, на всякий случай, в другое место, бывают такие базы, бакап с которых - нерабочий.

Johnmen (2004-11-02 09:16:00) [2]
>sw (01.11.04 19:06) [29]

См.полный синтаксис SELECT.

sw (2004-11-01 19:06:00) [3]
и все таки как "внести план в SQL" ?

sw (2004-10-31 15:06:00) [4]
так все таки есть еще какие то мнения ?

}|{yk (2004-10-29 18:36:00) [5]
Слушай, да??? В IBExpert есть утилита генерации набора данных. Я специально генерировал по 10000 тыс в главной, 20000 в подчиненной, и по 200 в 4 иерархических справочниках. Консолидация осуществлялась за 1,5 с. Но пока добился этого, поменял полностью архитектуру подсчета. Кроме того, для отчётов я бы лучше использовал ХП, быстрее будет.

Johnmen (2004-10-29 16:36:00) [6]
>То что INNER JOIN - тормоз написано еще у М.Грабера

Можно привести выдержку ?

Zacho (2004-10-29 16:25:00) [7]

> То что INNER JOIN - тормоз написано еще у М.Грабера

Чушь. Так можно сказать, что любой JOIN - тормоз, давайте делать БД в одной таблице.

2 sw : Почитай статьи на http://www.ibase.ru/develop.htm

AZDesign (2004-10-29 14:28:00) [8]
Начни с мелочей:
Установи файловую систему NTFS, а то на FAT32 удивительно что ты не потерял всю БД, да еще после выключения питания.
И на сервак нужно поставить нормальный UPS, чтобы аккуратно остановить.

Проводи переодически дефрагментацию - судя по твоим словам, систему поставил по умолчанию и не задумываясь. Посмотри в diskeepere как выглядит диск после установки системы - мрак

Конечно 5-6 тысяч записей - это мелочи,
Но все-таки посмотри структуру таблиц, а после запросов, при правильной структуре таблиц и запросы простые, и выполняются быстро. У тебя много сравнений по текстовым полям

То что INNER JOIN - тормоз написано еще у М.Грабера

sw (2004-10-29 13:55:00) [9]

> А B/R нормально?

не совсем понимаю о чем идет речь ?

Запустили вышеуказанный отчет с параметрами из IBExpert с сетового комп-ра: получена 21 запись:

Plan
PLAN SORT (MERGE (SORT (SPES_KORPUS NATURAL),SORT (JOIN (TOTALDISCIPL INDEX (TOTALDISCIPL_IDX1),VEDOMOST INDEX (VEDOMOST_IDX1,RDB$FOREIGN27),TEACHERS INDEX (RDB$PRIMARY4),ZAYAVKIKAZ_CHOISE INDEX (RDB$FOREIGN48),STUDENTS INDEX (RDB$PRIMARY13),SPESIALNOSTI INDEX (RDB$PRIMARY6),CHOISEDISCIPL INDEX (RDB$FOREIGN21),REGISTER_COURSES_1 INDEX (RDB$FOREIGN24)))))

Adapted Plan
PLAN SORT (MERGE (SORT (SPES_KORPUS NATURAL),SORT (JOIN (TOTALDISCIPL INDEX (TOTALDISCIPL_IDX1),VEDOMOST INDEX (VEDOMOST_IDX1,FK_VEDOMOST),TEACHERS INDEX (PK_TEACHERS),ZAYAVKIKAZ_CHOISE INDEX (FK_ZAYAVKIKAZ_CHOISE),STUDENTS INDEX (PK_STUDENTS),SPESIALNOSTI INDEX (PK_SPESIALNOSTI),CHOISEDISCIPL INDEX (FK_CHOISEDISCIPL1),REGISTER_COURSES_1 INDEX (FK_REGISTER_COURSES)))))

------ Performance info ------
Prepare time = 16ms
Execute time = 1s 546ms
Avg fetch time = 73,62 ms
Current memory = 1 436 348
Max memory = 1 879 972
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 51 959

самая большая таблица здесь это REGISTER_COURSES_1, остальные на порядок меньше.

> вылечилось внесением плана в SQL.

никогда с этим не сталкивались, как это сделать?

vv_fran (2004-10-28 14:23:00) [10]
Базу полечить, сделать bacup-restore.
Переписать запрос без INNER JOIN , от него и от DISTINCT - основные тормоза. Проверить план. Он может сначала выбирать из самой большой таблицы, а потом из мелких - сделать наоборот. У меня была такая проблема, вылечилось внесением плана в SQL.

Zacho (2004-10-28 11:03:00) [11]
Змена TIBTable на TIBDataSet - вполне возможно, повлияет. Переход с IBX на FIBPlus сам по себе большого "ускорения" не даст.
И всё-таки, ответь на вопрос Sergey13 © (27.10.04 16:24) [18]

sw (2004-10-28 08:13:00) [12]

> IBTable нахрен выкинуть, переходи на компоненты FIB.

это повлияет на ситуацию?

Erik1 (2004-10-27 17:31:00) [13]
IBTable нахрен выкинуть, переходи на компоненты FIB.

Sergey13 (2004-10-27 16:24:00) [14]
2[17] sw (27.10.04 16:16)
>После того, как раза два рубанули свет, вот и пошло
А B/R нормально?

>ну а вот этот отчет (писали не сами (SQL Builder))
И что показывает план?

sw (2004-10-27 16:16:00) [15]

> А как вообще-то сама сеть ?

сеть правда 10Мбит/с(именно 10 а не 100).

> Какие винды стоят ?

Win XP Proff. RUS учетная запись у всех одинаковая admin (права администратора) Доступ к дисками открыт.

> Кстати, если сервер ХР или 2003, то расширение файла БД
> надо бы поменять на fdb. Дело в том, что gdb эти системы
> считают защищаемым файлом, и при каждом изменении копируют.
> Поэтому так долго соединяется обычно :)

Попробовали так сделать. Изменили расширение, снова прописали в IBExpert, в программе изменили сервер на remote(localhost). Реакции ноль, соединяется также долго.
По началу когда IBExpert только поставили мгновенно открывал.
После того, как раза два рубанули свет, вот и пошло. Хотя при запуске только связь с базой данных (Connect & Open ) и запуск транзакции (программно).

В базе используется 19 таблиц между ними установлены связи "Главный- подчиненный" проиндексированны соответственно по первичным и вторичным ключам. В программе при построении запросов используются компоненты IBQUERY (есть ли какая-нибудь альтернатива?) Все компоненты (IBTable(19 шт. ) и IBQuery ( в кол-ве 20 шт.) и т.д.) помещены в DataModile(модуль данных).

ну а вот этот отчет (писали не сами (SQL Builder))

SELECT DISTINCT Students.SURNAME, Students.NAMESTUD, Vedomost.KOMPONENTA1, Vedomost.KOMPONENTA2, Vedomost.KOMPONENTA3, Vedomost.KOMPONENTA4, Vedomost.KOMPONENTA5, Vedomost.KOMPONENTA6, Vedomost.KOMPONENTA7, Vedomost.SUMBAL, Students.SHIFRSP, Vedomost.MAXBAL
FROM TEACHERS Teachers
INNER JOIN VEDOMOST Vedomost
ON (Teachers.PAROLTEACH = Vedomost.PAROLTEACH)
INNER JOIN ZAYAVKIKAZ_CHOISE ZayavkiRUS_CHOISE
ON (ZayavkiKAZ_CHOISE.PAROLTEACH = Teachers.PAROLTEACH)
INNER JOIN TOTALDISCIPL Totaldiscipl
ON (Vedomost.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN STUDENTS Students
ON (Students.PAROLSTUD = Vedomost.PAROLSTUD)
INNER JOIN REGISTER_COURSES Register_courses_1
ON (Register_courses_1.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN ChoiseDiscipl choiseDiscipl
ON (choiseDiscipl.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN SPESIALNOSTI Spesialnosti
ON (Spesialnosti.SHIFRSP = Students.SHIFRSP)
INNER JOIN SPES_KORPUS Spes_korpus
ON (Spes_korpus.SHIFRSPES = Spesialnosti.SHIFRSP)
WHERE (Teachers.FAMILIA = :prmFamTeach)
AND (Teachers.NAME = :prmNameTeach)
AND (Totaldiscipl.NAMEDISRUS = :prmNameD)
AND (Students.LANGUAGE = :prmLang)
AND (Vedomost.NBLOCK = :prmNBlock)
AND (Vedomost.SEMESTR = :prmSem)
AND (ZayavkiKAZ_CHOISE.KORPUS =:prmKorpus)
AND (Spes_korpus.KORPUS =:prmKorpusS)

Romkin (2004-10-26 18:03:00) [16]
Это какой же должен быть запрос, чтобы так долго выполняться?
Кстати, если сервер ХР или 2003, то расширение файла БД надо бы поменять на fdb. Дело в том, что gdb эти системы считают защищаемым файлом, и при каждом изменении копируют. Поэтому так долго соединяется обычно :)
Примечание: у меня тяжелейщий отчет, который крутит несколько раз выборку из таблиц по полтора миллиона записей, выполняется за несколько секунд на PIII-600 :)

Sergey13 (2004-10-26 13:34:00) [17]
2sw (24.10.04 18:51)
>В последнее отчеты (QR 1-2 страница) генерируются вообще по минут 5-6
Может все таки последует описание хотя бы одного такого отчета.

msguns (2004-10-26 13:08:00) [18]
А как вообще-то сама сеть ? Простое копирование идет нормально по скорсти ? Какие винды стоят ? Если старше 98, то правильно ли прописаны учетные записи и т.д.

DSKalugin (2004-10-26 12:56:00) [19]
2 DrPass
Здравствуй дорогой земляк, Женя :-)))
Согласен вполне с твоим замечанием. Но с "каким бы сложным не был запрос" позволь не согласиться. Если делать внешние объединения, а тем более full outer join то они тормознут любую машину. У меня кстати тоже П4 2,8

DrPass (2004-10-25 21:44:00) [20]

> 0-отсутствие индексов
> 1-если они есть - Разбаллансировка индексов
> 2-поломалась сама БД

0 и 1 - исключено. 5-6 тыс. записей - это ничтожное количество. На P4-2.8 они будут без единого индекса обрабатываться за доли секунды, каким бы сложным не был запрос.
2 - тоже маловероятно, и трудно не заметить. Зато вполне вероятен вариант, что человек использует в своей программе IBTable да еще в связках мастер-деталь, и таким образом при каждом подключении гоняет всю базу взад-вперед по сети

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »