Прежде всего я не парень AS 400 - вообще. Поэтому простите мне за выяснение у любых noobish вопросов здесь.
В основном я работаю над приложением .NET, которое должно получить доступ к AS400 для некоторых данных реального времени. Хотя у меня есть системная работа, я получаю совсем другие результаты проверки производительности между запросами. Как правило, когда я выполняю 1-й запрос против SPROC на AS400, я вижу ~ 14 секунд для получения полного набора данных. После того начального вызова любые последующие вызовы обычно только берут ~ 1 секунда для возврата. Это повышение производительности остается для ~ приблизительно 20 минутами, прежде чем потребуется 14 секунд снова.
Интересная часть с этим - то, что, если хранимая процедура выполняется непосредственно на iSeries Навигаторе, она всегда возвращается в миллисекундах (никакое изменение в ответ время).
Интересно, является ли это кэширование / проблема плана выполнения, но я могу только применить свою логику SQL-СЕРВЕРА к AS400, который является не всегда соответствием.
Какие-либо предложения на том, что я могу сделать для получения более последовательного времени отклика или просто понимания относительно того, почему AS400 действует этим способом, когда я использовал iSeries Поставщика данных для .NET? Существует ли лучший метод доступа, который я должен использовать?
На всякий случай вот код, который я использую для соединения с AS400
Dim Conn As New IBM.Data.DB2.iSeries.iDB2Connection(ConnectionString)
Dim Cmd As New IBM.Data.DB2.iSeries.iDB2Command("SPROC_NAME_HERE", Conn)
Cmd.CommandType = CommandType.StoredProcedure
Using Conn
Conn.Open()
Dim Reader = Cmd.ExecuteReader()
Using Reader
While Reader.Read()
'Do Something
End While
Reader.Close()
End Using
Conn.Close()
End Using
Править: после наведения справки немного по этой проблеме и использованию некоторых комментариев ниже, я начинаю задаваться вопросом, испытываю ли я это из-за усилений от организации пула подключений? Мысли?
Я нашел Redbook Интеграция DB2 Universal Database для iSeries с Microsoft ADO .NET полезным для диагностики подобных проблем.
Внимательно изучите трассировки на стороне клиента и сервера, чтобы выявить проблему. И не бойтесь звонить в службу поддержки программного обеспечения IBM. Они могут помочь вам настроить профилирование, чтобы разобраться в проблеме.
Я видел аналогичную производительность запросов iSeries SQL (ODBC) в течение нескольких лет. Я думаю, что это часть природы зверя - OS / 400 динамически перемещает данные с диска в память при доступе к ней.
FWIW, я также заметил, что iSeries больше похож на трактор, чем на гоночную машину. Он намного лучше справляется с большими нагрузками. В одном случае я объединил около дюжины коротких запросов в один чудовищный и сократил время выполнения с примерно 20 секунд до примерно 2 секунд.
В прошлом мне приходилось извлекать данные из AS/400, в основном мне помогла пара вещей:
1) Выгружать данные в таблицу SQL Server ночью, где я мог контролировать индексы, родной SqlClient побеждает IBM DB2 .NET Client каждый раз
.
2) Поговорите с одним из ваших программистов AS400 и убедитесь, что команда, которую вы используете, бьет по логическому файлу, а не по физическому (логический и физический в их мире сродни нашим таблицам и представлениям)
.
3) Создайте представления с помощью Linked Server на SQL-сервере и запросите ваши представления.
Вы можете попробовать другой драйвер для подключения к системе AS400-DB2. Я использовал 2 варианта.
Очевидно, что первый вариант будет медленнее из два, но это бесплатный способ делать что-то.
Попробуйте создать хранимую процедуру. Это создаст и кэширует ваш план доступа с хранимой процедурой, поэтому оптимизатору не придется искать в кэше SQL или повторно оптимизировать.