База данных interbase 75Мб, 22 таблицы, доступ одновременно до 60 пользователей
запрос на элементарную запись заказа выполняется от 1 до 5 минут, все остальные запросы выполняются тоже долго, простой переход в конец выполняется минуту 

Раньше занимался локальными таблицами Paradox и с помощью кэширования достигал хорошей скорости, как быть здесь?

спасибо
 

1. Индексы по нужным полям (по которым чаще всего ставятся условия поиска) есть?
2. 

А ты что, SQL не используешь? На последнюю запись переходишь простым перебором? 

1. 
 Вот пример таблицы заказов:
 


2. Пользуюсь по возможности только SQL
не считая навигаторов (tdbnavigator)

не использую first, last, next и др.

у меня "толстый клиент" все права доступа и личные настройки хранятся в приложении клиента

вроде 75Мб (только текстовые и числовые типы данных) это же не много?

должно же бысто работать? сервер позволяет   

Это сообщение отредактировал(а) samurai - 27.7.2006, 06:48

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

как скорость зависит от количества подключенных пользователей?
какая конфигурация компа на котором база?

но в принципе медленно работает - надо эксперементировать и искать в чем проблема 

to akella: таблиц 22, в каждой от 10000 до 60000 записей, не знаю как по количеству, но нормально работать это точно не даёт, какой то выход мне надо искать 
вот поиск производится очень быстро, а запись долго.

to superVad я не знаю влияет ли количество подключений на скорость запроса.
 комп такой: 
 4 процессора Xeon-A (4.5x400) по 1800 МГц
 4х512 Мб = 2047Мб оперативки
 2x16Гб винчестеры зеркальные
 сетевухи гигабитные, сетка на 3com (48 портов х 2) switch с усилением
 ну маленькое вроде такое, но шустренькое

я просто вообще не знаю с чего начать копать, 
хотел услышать стандартные ошибки в построении таблиц и запросов

спасибо 

если поиск производится очень быстро то проблемы скорей всего не с сеткой.
комп в принципе хороший

единственное что в голову приходит - если стоит сервер с архитектурой SuperServer то стоит поставить ClassicServer может быть. Он на многопроцесорных системах лучще работает 

ты хочешь сказать, что запрос
  insert into orders
  (...)
  values (...)
выполняется минуту??

Антивирь??? 

Все перебрали, кроме самого главного, текст вашего SQL, который якобы у вас там минуты выполняется можно увидеть?

Добавлено @ 07:14 

Интересно, а как без last вы попадаете на последнию запись?

Добавлено @ 07:21 

Стоп! А какой версией Interbase вы пользуетесь? 

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


Это сообщение отредактировал(а) DimW - 1.8.2006, 10:02

to jack128
ну не совсем, происходит ряд проверок
здесь же выполнение StoredProc (хранимые процедуры)
антивиря нет, доступ в онлайн запрещен

to Alex
next, last & etc стараюсь не использовать
но дбнавигатор использует именно их

Версия Interbase 6.5

Заметил следующее: с утра всё работает намного быстрее, мало клиентов, активность из 60 юзеров примерно 10, к обеду ситуация усложняется ввод заказа выполняется в несколько раз дольше, к вечеру у некоторых подвисают приложения-клиенты
Может проблемы с кэшью? где посмотреть?

to DimW
индексов от 1 до 6 на каждую таблицу, таблиц 22,
но в среднем получается 2-3 индекса на таблицу
это много?

спасибо всем кто помогает

samurai,  Клиентских приложений много ? 60 клиентов, а клиентская программа у них одна ? Хорошо бы пересмотреть запросы, которые эта программа посылает на сервер, раз тормоза начинаются во время интенсивной работы с БД.
Хотя сервер мощный, если запросы в БД от клиентов просты, то он должен справляться с обработкой. Есть какие-либо сложные выборки данных типа запросов в несколько таблиц с объединением, вложенными запросами и т.п.

http://ibase.ru/ibfaq.htm#proc
http://ibase.ru/ibfaq.htm#arch
http://ibase.ru/ibfaq.htm#que

таки попробуй поставить FB 1.5 ClassicServer

И получить 60 процессов, каждый будет требовать под себя свою память... ClassicServer является устаревшей технологией

Вы ни как не прочитаете самое главное, InterBase до версии 7.0 и FB до версии 2.0 не могут работать на многопроцессорной машине их нужно закруглять на один из процессоров
http://ibase.ru/devinfo/ht.htm

Это сообщение отредактировал(а) Alex - 3.8.2006, 09:45

вобще прежде чем понять много это или нет, нужно определиться какого типа у тебя БД, разлечают два основных типа БД - транзакционная и аналитическая. в транзакционных БД как правело минимум индексов, я бы даже сказал - только по ключам, т.к. при транзакциях нужно не только добавить, изменить или удалить данные, а еще и переписать индексы на эту таблицу, поэтому теряется производительность. В аналитических БД (БД которые содержат данные и  используются для отчетности, т.е. часто выполняются запросы на выбор данных) приветствуется использование индексов(но рациональное использование), т.к. индексы способствуют быстрой выборки данных. Так же существует третий тип - смешенный, где БД является как транзакционной так и аналитической, вот здесь нужен грамотный подход к построению индексов! это и опыт и эксперементы.  6 индексов это может и немного, если они действительно используются при выполнении селекта, но к примеру - если селект выберал данные из этой таблицы без инднксов достаточно быстро, то нафига их вобше создавать.
это конечно все в теории, есть одна аксиома, к каждой БД нужен индивидуальны подход, нет одинаково построенных БД!
удачи! 

to Fedia
Клиентское приложение у всех одинаковое, так называемый толстый клиент, т.е. различные права по отделам распределены прямо в клиентском приложении. Запросов много и много проверок между ними. пример одного из запросов (остальные имеют схожую структуру):


to superVad
У меня не столь крутые задачи, чтобы менять платформу, мне надо найти недочёты чтобы увеличить производительность, но всё равно спасибо!

to Alex
Факи прочитал, всё проверил, вроде явных ошибок у меня нет

DataBase Cach (pages) 2048
Client map size (bytes) 4096
как думаешь увеличить?
если да, то можно не останавливать работу, а прямо во время, ничего не случится?

to DimW
философия на тему типа БД мне не поможет
у меня очень конкретный вариант.
это похоже на выражени "Сколько людей - столько мнений" - выражение без смысла, т.к.
решение всё равно принимают общее, так вот мне нужно решение. Без обид!
Задача как у всех - склад + бухгалтерия.
спасибо

samurai, Есть возможность посмотреть загруженность процессора сервера БД и процент используемой ОЗУ во время интенсивной работы пользователей ? Если ресурсы используются по полной программе, то тут уже придется думать об оптимизации структуры БД и таблиц.
Не знаю, есть ли аналог MySql  функции explain для Interbase. Если есть, то все запросы к БД, по хорошему, нужно пересмотреть при помощи аналога explain.

и посмотреть, используются ли для обработки данного запроса индексы, количества строк, которые будут перебираться при формировании ответа на запрос, длину ключа и др. параметры. Ну а дальше действовать по обстоятельствам. Н-р: если не используется индекс и запрос выполняется долго, то можно либо создать необходимый для ускорения запроса индекс (пожертвовав местом на HDD сервера) или же изменить запрос, так, чтобы он использовал уже существующие индексы.
Это кропотливая работа, но ИМХО необходимая для оптимизации клиентских приложений в случае, если они сверх меры нагружают сервак   Бог в помощь.

еще раз процетирую:

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


а вот мне в свое время помогла, только не философия это а теория, а прежде чем приступить к практике теорию нужно знать.


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


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

DimW, 
Ходить на лекции, оно конечно хорошо. Только чудесатое разделение на 

я ни у одного из классиков типа Дейта, Бойса, Кодда, Ульмана не встречал. Так что это разделение - на совести лектора или твоей (последнее более правдоподобно). И нафиг оно никому не нужно. Поскольку СО ВСЕМИ СЕРВЕРАМИ РАБОТАЮТ ЧЕРЕЗ ТРАНЗАКЦИИ и никак иначе. Они по-другому просто не умеют. 
Вдогонку: не надо коверкать русский язык. Т.е. писать с грубыми ошибками - не уважать самого себя.

samurai, 
Сходи на www.ibase.ru и почитай про версионность. Судя по тому, что у тебя с начала работы в течение дня скорость падает - увеличивается количество версий записей, и соответственно все больше времени уходит на актуализацию. Т.е. слишком поздно делаешь commit.

Главное "заведи" сервер на один процессор, что бы он не шастал по всем у тебя 4-ем и размер кеша м кол-ва страниц можно увиличить.

PS:
Ваша задача это мелочь в принципе для IB

в этом все и дело что это классики, они описывают правельные БД - нормалезованные, и учат контролировать данные при помощи всевозможных констрейтов, тригеров и чем больше их тем лучше! Вот такие любители классической литературы напроектируют баз данных, а потом расхлебывай заними!  
Избыточность индексов - это одна из причин снижениея производительности сервера БД.


Вовсе нет, т.к. лекторы как и вы начитаются классиков и живут в розовом цвете...

так что в вашем понимании транзакция?! любое обрашение к БД? если так, то очень вас жаль!
Транзакцией называют любой sql-запрос который нацелен на модификацию как объектов БД, так и данных. Sql - запросы возвращающие наборы данных не являются транзакциями! а те транзакции которые вы имеете ввиду - называются сессиями БД!
ну так вот те БД которые используются для получения информации называются аналитическими(предпологается что данные накапливались в БД ранее, или транзакций на порядок меньше чем возврата данных).
   
SergeBS, вдогонку:  читайте дальше Дейта, Бойса, Кодда, Ульмана и будет вам счастье, во могу даже дать телефон моего бывшего лектора, вы с ним поладите!!!    

Это сообщение отредактировал(а) DimW - 6.8.2006, 10:38

Тихо, тихо какая там избыточность, что за необоснованные наезды на триггеры там у человека база по размерам просто смешная. Триггеры при грамотном их использовании это палочка выручалочка, да и работу с индерсами можно организовать так, что даже на больших БД при вставке все будет нормально.

Дайте нам не грамотным определение сессии БД

Ты сам говоришь, что нормализованные БД - правильные. И для подтверждения этого факта можно привести множество аргументов ! 


Зачем ты так пишешь? Принцип чем больше, тем лучше относиться к прибыли, но никак не к БД. Определение "нормализованная БД" совсем не подразумевает наличия в БД большого количества индексов и триггеров. Если ты об этом знаешь, то к чему такие высказывания ? Всего должно быть в меру, для обеспечения быстрого и надежного функционирования БД ! Классики бы на тебя затаили большую обиду 

я не говорю что вы не грамотные!
сессиея(соединение) - это период времени от подключения к БД до отключения.
в одной сессии может вызываться множество транзакций.

вобще я не понял что вас так задело?! что я не правельно написал?
 
samurai, спросил

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

я не говорю что у samurai в БД избыточность, я лишь предпологаю что может быть такое. 
Alex,  на счет тригеров я погорячился. сам их уважаю и использую, но в меру  .

Как же хочется отправить вас почитать литературу прежде чем высказываться... Запрос - это транзакция, ужас.



Да, что вы говорите, а про уровни изоляции транзакций, версиональность данных вы слышали?

не надо придераться к словам, вы же прекрасно поняли о чем я! sql - запрос т.е. sql - оператор, а транзакция считается завершенной если был commi или rollback. так же транзакция может состоять из нескольких sql - операторов. вот что я имел ввиду. но из песни слов не выкинешь.   
 вот про это нужно почитать.

с этим никто не спорит. просто в IB и его клонах любой запрос(в том числе и select) может выполняться только в контексте какой либо транзакции. Иначе говоря - не открыв транзакции ты не сможешь выполнить ни одного запроса. По причине версионности (в IB - параметры видимости - задаются при отрытии транзакции). В блокировочниках я так понимаю подобных проблем нету, поэтому для select'ов и не нужны отрытые транзакции.

Просто хочу уточнить. Что вкладывается в понятие блокировочник ? Ты имеешь в виду СУБД у которых бликирутся модифицируемые таблицы при внесении изменений в БД ?

да. 

jack128,  т.е. теоретически утверждение:

для СУБД MySql например не верно ? Там ведь при запросах в БД никакие транзакции не стартуют ?

ну если в MySQL они не стартуют, то какие могут быть сомнения? 
ЗЫ а что, в мускуле вообще нету транзакций или они не обязательны к использованию?

Они вроде поддерживаются в дополнении к MySql Inno DB, а в самой СУБД их нет. Хотя возможно в 5-й версии уже появились.

мне кажеться проблема гдето здесь

2ALL
Спокойнее, спокойнее, горячие финские парни...
А теперь я по вредности своей начну свое задвигать, благо чуток времени выпал 

Fedia, 

Воообще-то MySQL тем и уникален в своем роде, что поддерживает несколько разных способов хранения данных. Из док:

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

Насчет блокировочников и версионников - из распространенных:
Версионники: InterBase (IB), FireBird(FB), Oracle
Блокировочники: MS SQL, MySQL, Informix, MS Jet(Access)
Ну кого забыл - извиняйте, я не со всеми дела имел, а лазить по описаниям - лениво.
В двух словах разница.
Версионники хранят несколько версий записи, и при чтении по хитромудрым правилам подсовывают версии записи, так что одна запись может иметь кучу версий и блокировок при попытке чтения записи, которую другая транзакция изменяет, но еще не откоммитила, так сказать, не происходит. Но потом зато происходит т.н. "кооперативная сборка мусора" - уборка "лишних" версий. И она может изрядно  сожрать, если не думать. Подробнее - в доках. Есть еще на эту тему на ibase.ru статья Кузьменко, признанного "гуру" по IB/FB. Полезно, по делу, кратко. РУЛЕЗЗ!
У блокировочников - по-другому. Транзакция блокирует запись, которую изменяет, от чтения/редактирования другими транзакциями. Отсюда и название. Можно управлять мощностью блокировки.
Естественно есть способы в обоих случаях (версионность/блокировочность) поведением рулить.

DimW, 


1. Не зная достижений предшественников, новое создать невозможно - это не я, это перефразированный Ньютон и куча прочих. 
2. Вам никогда не приходилось за кем-то расхлебывать. Поскольку для этого нужно понимать что к чему, а у Вас в голове - "каша" из обрывков популярных книжек типа "Изучи Oracle за 24 дня". Именно публика, которая не понимает смысла нормализации,  плодит всякие ублюдочные варианты, которые потом просто идут "в печку". С соответствующими эпитетами в адрес автора.


Рекомендую ознакомиться:
1. С принципом ("бритвой") Оккама.
2. С книжкой любого классика по СУБД (раз уж лекции просачковал). Хотя бы классификацию и решаемую задачу. Дабы не изобретать велосипеда с квадратными колесами и не морочить им всем горовы. Свои доморощенные термины и теории оставьте при себе. 
Здесь в основном практики общаются.


Уже читал. И поэтому я могу ОБОСНОВАТЬ заказчику, почему у меня в базе 62 таблицы, например, а не 50 и т.п. Вам такое не грозит. 
Заодно с отказом от нормальных форм можете отказаться от таблицы умножения (от грамматики уже отказались).   

Более корректно:

В общем почти разобрался:

1. с моими объёмами 100Мб таблиц даже с плохими индексами можно работать быстро
2. моя проблема была в том что клиентские приложения не все обновлялись вовремя и в некоторых
    оставались транзакции с параметрами по умолчанию, в то время как в основных транзакциях параметры такие
    
    умолчательные транзакции конфликтуют с моими, после прогона IBAnalyst, выяснилось что
    некоторые транзакции живут уже 80 дней, тормоза были страшенные.
    Когда все транзакции привёл к одному виду всё заработало более или менее прилично
3. В данный момент потеря скорости обусловленна ещё тем, что чистка мусора имеет тот же приоритет что и основная транзакция,
    я это сделал только для стабильности, чтобы в исключительных ситуациях мусор не накапливался в прогрессии,
    т.к. я начинающий и не уверен в правильности своих действий    

    Всем спасибо 

Как увидел проблему, хотел сказать за уровни изолированности транзакций. Была у меня такая проблема. Еще советую использовать 2 сессии - одну для чтения, вторую для модификации данных. Гораздо жизнь упрощается