приложение зависает при обращении к Firebird. что делать помогите

← →
Tepex © (2008-11-06 14:59) [40]

Да вроде все понятно. Ничего нового не нашел.

← →
sniknik © (2008-11-06 15:01) [41]

> Ну так где копать надо начинать Уважаемые?
исправить уже найденные ошибки, почитать документацию, и пересмотреть весь код ещё раз.

← →
Сергей М. © (2008-11-06 15:13) [42]

> Ничего нового не нашел

Неужели ?!

← →
Tepex © (2008-11-06 15:20) [43]

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

← →
Сергей М. © (2008-11-06 15:30) [44]

А какие м.б. предложения ?
Сетевые условия взаимодействия с IB-сервером и с хостом, на котором он размещен, ты так и не детализировал ..
А от них многое зависит ..

← →
Сергей М. © (2008-11-06 15:37) [45]

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

← →
Tepex © (2008-11-06 15:42) [46]

[44] да соединение с сервером FB происходит через TCP/IP протокол, настройки самого FB по умолчанию. Машина на которой расположен сервер FB Intel Xeon 3.20 GHz, подключатся одновременно могут 10 клиентов. Вот такое взаимодействие с сервером FB.

← →
Сергей М. © (2008-11-06 15:45) [47]

> Tepex © (06.11.08 15:42) [46]

Этих сведений не достаточно для принятия решения о применении того или иного типа курсора. И в статье на это сделан довольно внятный акцент.

← →
Сергей М. © (2008-11-06 15:47) [48]

Неизвестно также в каком режиме работает IB-сервер - CS или SS..

← →
Tepex © (2008-11-06 16:00) [49]

[48] не могу посмотреть в данный момент в каком режиме работает. Насчет IN. что предлагаешь использовать в замен этой статьи?

← →
Сергей М. © (2008-11-06 16:15) [50]

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

← →
Сергей М. © (2008-11-06 16:30) [51]

Другие (кроме вставки) модификации таблицы, к которой ты выполняешь запрос, осуществляются ?
Подозрения на попадание твоей транзакции на сборку мусора пока еще не сняты ..

[51] Да вот я только что проанализировал свою базу при помощи утилиты IBAnalyst и она показала что плохо проиндексирована база данных и много мусора. Скорее всего ваши подозрения верны(про мусор). Потому что приложение написанное на Делфи так же при работе с базой данных тормозит. В базу данных fb ничего не вставляется только читается.

> она показала что плохо проиндексирована база

Что значит "плохо" ?
Подробней..
Конкретно про все имеющиеся индексы, касающиеся поля orders.agreementno ..

> много мусора

> В базу данных fb ничего не вставляется

Откуда же там взялись данные, если ничего не вставляется ?

И откуда взялся мусор, если кроме вставок никаки модификации не осуществляются (да и модифицировать-то собственно нечего, раз ничего не вставляется) ?

Речь идет об операциях с базой со стороны каждого из клиентов, а не только клиента в контексте твоего 1С-приложения !

> Tepex

http://www.ibase.ru/devinfo/garbage.htm

> Речь идет об операциях с базой со стороны каждого из клиентов,
> а не только клиента в контексте твоего 1С-приложения !

Ну так бы и сразу. Дело в том как я писал раннее я не могу знать при помощи каких механизмов происходит вставка данных в базу потому что они вставляются при помощи приложения написанного на Делфи, а исходников нет у меня.
> > В базу данных fb ничего не вставляется
>
>
> Откуда же там взялись данные, если ничего не вставляется
> ?

я имел ввиду что со стороны 1С ничего не вставляется.
> > она показала что плохо проиндексирована база
>
>
> Что значит "плохо" ?
> Подробней..
> Конкретно про все имеющиеся индексы, касающиеся поля orders.
> agreementno ..

Плохих индексов: 40.
Под `плохими` мы имеем в виду индексы с большим числом повторяющихся
ключей (90% от всех ключей) и большими группами одинаковых ключей
(30% от всех ключей). Большие группы одинаковых ключей замедляют
сборку мусора - MaxEquals здесь это % самой большой группы ключей с
одинаковыми значениями. Поиск по таким индексам является
неэффективным. Вы можете удалить такие индексы (если это не индекс по
Foreign Key).

Некоторые транзакции активны слишком долгое время. Самая старая
транзакция Oldest active стартовала 9060 транзакций назад, в то время
как среднее число транзакций в день примерно равно 13370.
Это может быть сигналом, что имеет смысл проверить текущую схему
обработки транзакций в ваших приложениях. Убедитесь, что транзакции
завершаются commit/rollback после использования, и не находятся в
активном состоянии долгое время без необходимости. Не стартуйте много
ненужных транзакций. Также имеет смысл посмотреть на динамику
количества транзакций в зависимости от активности клиентских
приложений. Одной из причин большого числа активных транзакций может
быть потеря transacton handle в коде приложения. То есть, приложение
стартует транзакцию, но не завершает ее по commit/rollback.
Другой причиной может быть использование BDE при отсутствии явного
управления транзакциями, и параметр алиаса SQLPASSTHROUGH = SHARED
NOAUTOCOMMIT.

Текущий размер страницы базы данных = 4096 байт.

Бесполезных индексов: 16.
Бесполезные индексы имеют только одно значение ключа. То есть,
столбец, по которому создан индекс, содержит одно единственное
значение во всех строках таблицы. Поэтому, использование индекса в
таких случаях приводит только к лишнему чтению страниц индекса с
диска. Вы можете удалить такие индексы (если это не индекс по Foreign
Key).

Ну вообщем вот такие вот рекомендации да IBAnalyst

[54] Спасибо! Но я уже это прочитал завтра буду экспериментировать.

приложение зависает при обращении к Firebird. что делать помогите Найти похожие ветки