Первый запрос, выполняемый на большом наборе данных в базе данных Firebird после запуска нашего приложения, всегда очень медленный. Последующие обращения к одному и тому же запросу (это хранимая процедура) являются точными. Я предполагаю, что это связано с тем, что что-то загружается в память, но я мог бы сделать с объяснением, что и есть ли что-то, что можно сделать, чтобы обойти проблему.Первый запрос slow на Firebird
Возможно, речь идет не о запросе, но время соединения (задержка) длинное? Была такая проблема с [старыми] системами Firebird/Interbase.
Возможно, вы имеете в виду проблему, связанную с расширением файла .gdb является «системным специальным расширением» в xp (и, предположительно, более поздних версиях Windows), поэтому операционная система делает полную копию файла базы данных, когда движок сначала открыл его. AFAIK, проблема все еще присутствует и не связана с самим двигателем. Если вы все еще используете расширение .gdb для файла базы данных, первое соединение будет медленным, независимо от используемой версии firebird/interbase. – jachguate
Привет, спасибо за мысли. Мы используем Firebird v2.1 на Windws Server 2003, а расширение базы данных - .fdb. Размер db равен 5gb, поэтому, если бы была сделана полная копия, которая заняла бы время. Но учитывая, что расширение является fdb, не применимо ли это? – williamsdb
Проверка списка «контролируемых» Microsoft (http://msdn.microsoft.com/en-us/library/aa378870(VS.85).aspx) fdb не работает, поэтому, к сожалению, это не может быть причиной. – williamsdb
Если хранимая процедура в первом запросе компилирует хранимую процедуру, она также извлекает буферы и кэширует результат. По второму запросу процедура не скомпилирована (предварительно заблокирована), и результаты мгновенные (выборки также находятся в памяти для некоторых операционных систем, поэтому нет необходимости в диске io)
В одном из способов можно оптимизировать sp или таблицы Насколько они велики? (Количество записей для каждой таблицы)
один простой способ оптимизировать это поставить хроны сценарий, который будет выполняться один раз в день/час предварительного заполнения кэшей, так что вы будете быстро получить SP
Я действительно задавался вопросом об этом. Я знаю, что SQL Server компилирует и кэширует SP в памяти и поэтому может быть медленнее в первый раз. Я попробую предложение о планировании SP. Что касается количества записей, то есть два SP и две таблицы, каждая из которых содержит около 200 000 записей. Спасибо – williamsdb
Вы не сделали объясните, какую версию Firebird вы используете, но в версии 2.50 есть ошибка (CORE 3227 - медленная компиляция хранимых процедур), которая может быть причиной вашей проблемы. Подробнее: http://www.firebirdnews.org/?p=5282&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+FirebirdNews+%28Firebird+News%29
Привет спасибо за указатель. В настоящее время мы используем FB v2.1, поэтому, возможно, я не буду спешить с обновлением! – williamsdb
Каждый запрос, независимо от того, что запрос? Или конкретный запрос? Динамически создается SQL-запрос SQL? Является ли firebird db не запущенным до тех пор, пока вы не запустите клиентское приложение? Обычно приложение и db независимы друг от друга. – Tim
Чтобы ответить на вопросы: Нет, всего 1 запрос. Нет, он не динамически создает sql. Да, fb запускается и работает все время. Они независимы. Я бы опубликовал sp, но слишком длинный для количества символов, разрешенных здесь. – williamsdb
Вы можете разместить его, например, на http://pastebin.com/? – Harriv