Медленно читается TIMESTAMP из базы данных

@Neznajka111 · Регистрация: 22.07.2010

Студворк — интернет-сервис помощи студентам

Здравствуйте уважаемая аудитория! Имеется проблемка!
Опишу конкретно!
Вот кусок вырезанной программы!

Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
  for (int s=7;s<=11;s++)
   {
         Rst1 = stmt1.executeQuery (SQL[s]);
 
         //Отладочная выдача
//   System.out.println("SQL"+s+" was done.");
         //ЧИТАЕМ СОДЕРЖИМОЕ ТАБЛИЦЫ
         number_of_records[rez_col] = 1;  //Это - число строк в таблице
                              
           while (Rst1.next())
           {
    try
    {
     REZ[number_of_records[rez_col]][rez_col] = Rst1.getString(1).trim().toLowerCase();
     //System.out.println(REZ[number_of_records[rez_col]][rez_col]);
     
    }
    catch (NullPointerException np)
    {
    }
      number_of_records[rez_col]++;
            }
  rez_col++;
 
      }

Вот собственно сами SQL-и.

Java
1
2
3
4
5
6
SQL[7]="select DATA_SOZD from "+Qualifier_OTT+".Z_SPIS_Z order by DATA_SOZD with ur";
    SQL[8]="select DATA_PRIEMA from "+Qualifier_OTT+".Z_SPIS_Z order by DATA_PRIEMA with ur";
    SQL[9]="select DATA_ISP from "+Qualifier_OTT+".Z_SPIS_Z order by DATA_ISP with ur";
    SQL[10]="select DATA_REAL from "+Qualifier_OTT+".Z_SPIS_Z order by DATA_REAL with ur";
    SQL[11]="select DISTINCT PRIORIT from "+Qualifier_OTT+".Z_SPIS_Z order by PRIORIT with ur";
    SQL[12]="select ID_STATUS,NAME_STATUS from "+Qualifier_OTT+".Z_NSI_STATUS_Z with ur";

SQL 7,8,9,10 РАБОТАЮТ ОЧЕНЬ МЕДЛЕННО!
11 и 12 вылетают как из пулемёта! Но это и ясно!

Там нету почти ничего.
Дело не в 11 и 12.
COUNT(*) Каждого из этих SQL-ей(7,8,9 и 10) примерно 3500 записей. Получается в сумме 3500*4 =14000 записей!
А на самой деле 14000 значений TIMESTAMP! Так как поля DATA_SOZD, DATA_PRIEMA, DATA_ISP и DATA_REAL имеют тип данных TIMESTAMP.
Так вот по этому кусочку программы видно что эти значения я запихиваю в String-овский массив( REZ[number_of_records[rez_col]][rez_col] ).
Используется метод getString.
Вывод:
Время работы каждого из этих SQL-ей(7,8,9 и 10) примерно 4-5 секунд. В сумме получается более 20 секунд!
То есть каждый for (int s=7;s<=11;s++) для s=7? 8? 9 или 10 ВЫПОЛНЯЕТСЯ ОЧЕНЬ ДОЛГО!
Вопросы: Это нормальное время или я что-то криво делаю! Может что-то криво пишу или не тем мотодом(getString) считываю?
P.S.
1. СУБД DB2 под OS-390
2. Это вырезка из jsp-ки, которая работает под Web-серверов Apache Tomcat 4.1.29
То есть клиентское Web приложение, работающее с БД IBM DB2 под мэйнфреймом.
И ещё очень интересная вещь!
Для примера,
в БД TIMESTAMP содержится вот в таком виде: 2005-07-05-10.36.00.000001
После вот этого
REZ[number_of_records[rez_col]][rez_col] = Rst1.getString(1).trim().toLowerCase();

в переменной REZ[number_of_records[rez_col]][rez_col] он искажается вот в такое
2005-07-05 10:36:00.000001
Сравним???
2005-07-05-10.36.00.000001
2005-07-05 10:36:00.000001
Из-за чего произошёл такой произвол?
С уважением Владимир!

@Danissimo · 30.08.2006, 20:12

Эээ, boombastik, я бы не был столь категоричен по поводу драйвера. Почему? Потому что вспоминается мне опыт, когда пришлоcь декомпилировать оракловый драйвер. И вот что там было обнарудено: если тип данных в БД INT, и доступ к полю происходит через getInt(), то драйвер использовал один алгоритм преобразования к числу. Если же тип данных -- NUMBER, то применялся какой-то ужасный алгоритм строковых преобразований с генерацией просто мегатонн короткоживущего мусора, что в конечном итоге приводило опять же к тому же int на выходе.

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

Теперь по сути вопроса.

1) 0.2-0.3 км -- это о4 близко, => влияние latency отметаем.

2) Возможно boombastik прав, и DB2 и/или OS-390 просто долго выдает данные. Как проверить? (1) Выполнить этот самый "медленный" запрос с командной строки на OS-390. (2) Выполнить его же на каком-нть другом боксе, напрмер, там, где крутится томкат. Если мне не изменяет память, то для DB2 на unix это делается примерно так:

<pre>db2 "select..."</pre>

3) Уже третий раз просим, ну пожааалуйста, проверь, как getTimestamp() работает.

4) Раз сужение снижает время, то, скорее всего, проблема в подготовке данных СУБД/передаче их по сети. Возможно, если увеличить буфер приема на стороне клиента, то это сможет помочь. НО!!! Вожможно, это просто отсрочит проблему, так как она не будет проявляться, пока объем возвращаемых данных не превысит объема буфера.

5) Интересно, может ли uncommitted read влиять на время, которое требуется СУБД, чтобы по строчкам открытого на стороне сервера баз данных курсора бегать?

6) Можно ещещодим способом проверить, скока же времени программа в драйвере проводит. Там же можно увидеть, скока времени ожидался ввод/вывод. Если ожиданий практически нету, то это означает, что данные сервером отдаются сразу. Профилировщик -- хорошая штука. Второй раз рекомендую, попробуй. Он встроен в JVM.

@boombastik · 30.08.2006, 22:28

Эээ, Danissimo, ты все мои сообщения читал?

Как ты думаешь, для чего я просил выполнить запросы: SELECT date_field и SELECT CHAR(date_field)? Именно для того, чтобы избавить JDBC драйвер от нагрузки преобразования Date -> String и заставить DB2 выполнять эту операцию.

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

Кстати, возможно имеет смысл написать маленькое консольное приложение и тестировать производительность драйвера и запросов через него, а то неизвестно какими дополнительными Wrapper'ами обвешано соединение к БД вызываемое из JSP-страницы.

С уважением,

Владимир

@Danissimo · 30.08.2006, 23:24

О, Neznajka111! Вот еще один раз попросили написать консольное приложение и псмотреть, че к чему. Давай, показывай результаты =))

Новые блоги и статьи Все статьи Все блоги /
Загрузка PNG-файла с альфа-каналом с помощью библиотеки SDL3_image на Android 8Observer8 27.01.2026 Содержание блога SDL3_image - это библиотека для загрузки и работы с изображениями. Эта пошаговая инструкция покажет, как загрузить и вывести на экран смартфона картинку с альфа-каналом, то есть с. . .	влияние грибов на сукцессию anaschu 26.01.2026 Бифуркационные изменения массы гриба происходят тогда, когда мы уменьшаем массу компоста в 10 раз, а скорость прироста биомассы уменьшаем в три раза. Скорость прироста биомассы может уменьшаться за. . .	Воспроизведение звукового файла с помощью SDL3_mixer при касании экрана Android 8Observer8 26.01.2026 Содержание блога SDL3_mixer - это библиотека я для воспроизведения аудио. В отличие от инструкции по добавлению текста код по проигрыванию звука уже содержится в шаблоне примера. Нужно только. . .	Установка Android SDK, NDK, JDK, CMake и т.д. 8Observer8 25.01.2026 Содержание блога Перейдите по ссылке: https:/ / developer. android. com/ studio и в самом низу страницы кликните по архиву "commandlinetools-win-xxxxxx_latest. zip" Извлеките архив и вы увидите. . .
Вывод текста со шрифтом TTF на Android с помощью библиотеки SDL3_ttf 8Observer8 25.01.2026 Содержание блога Если у вас не установлены Android SDK, NDK, JDK, и т. д. то сделайте это по следующей инструкции: Установка Android SDK, NDK, JDK, CMake и т. д. Сборка примера Скачайте. . .	Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	30.08.2006, 20:12
	Эээ, boombastik, я бы не был столь категоричен по поводу драйвера. Почему? Потому что вспоминается мне опыт, когда пришлоcь декомпилировать оракловый драйвер. И вот что там было обнарудено: если тип данных в БД INT, и доступ к полю происходит через getInt(), то драйвер использовал один алгоритм преобразования к числу. Если же тип данных -- NUMBER, то применялся какой-то ужасный алгоритм строковых преобразований с генерацией просто мегатонн короткоживущего мусора, что в конечном итоге приводило опять же к тому же int на выходе. Мораль: JDBC драйверы обычно очень и очень кривые. И это подтверждает мой опыт с тремя СУБД. Нет-нет, да и выскочит какой-нть глюк. Этим грешать все производители СУБД. Видимо именно поэтому существуют и платные JDBC драйверы для разных СУБД, а также драйверы, входящие в Weblogic, к примеру. Теперь по сути вопроса. 1) 0.2-0.3 км -- это о4 близко, => влияние latency отметаем. 2) Возможно boombastik прав, и DB2 и/или OS-390 просто долго выдает данные. Как проверить? (1) Выполнить этот самый "медленный" запрос с командной строки на OS-390. (2) Выполнить его же на каком-нть другом боксе, напрмер, там, где крутится томкат. Если мне не изменяет память, то для DB2 на unix это делается примерно так: <pre>db2 "select..."</pre> 3) Уже третий раз просим, ну пожааалуйста, проверь, как getTimestamp() работает. 4) Раз сужение снижает время, то, скорее всего, проблема в подготовке данных СУБД/передаче их по сети. Возможно, если увеличить буфер приема на стороне клиента, то это сможет помочь. НО!!! Вожможно, это просто отсрочит проблему, так как она не будет проявляться, пока объем возвращаемых данных не превысит объема буфера. 5) Интересно, может ли uncommitted read влиять на время, которое требуется СУБД, чтобы по строчкам открытого на стороне сервера баз данных курсора бегать? 6) Можно ещещодим способом проверить, скока же времени программа в драйвере проводит. Там же можно увидеть, скока времени ожидался ввод/вывод. Если ожиданий практически нету, то это означает, что данные сервером отдаются сразу. Профилировщик -- хорошая штука. Второй раз рекомендую, попробуй. Он встроен в JVM. 0

@boombastik 7 / 7 / 12 Регистрация: 13.02.2007 Сообщений: 1,255
	30.08.2006, 22:28
	Эээ, Danissimo, ты все мои сообщения читал? Как ты думаешь, для чего я просил выполнить запросы: SELECT date_field и SELECT CHAR(date_field)? Именно для того, чтобы избавить JDBC драйвер от нагрузки преобразования Date -> String и заставить DB2 выполнять эту операцию. Согласен, проблемы могут быть все еще в JDBC, единственное что могу предложить, чтобы по быстрому проверить насколько сильно влияет JDBC драйвер на производительность в данном случае - это попробовать различные альтернативные JDBC драйвера для DB2 и померять производительность. Кстати, возможно имеет смысл написать маленькое консольное приложение и тестировать производительность драйвера и запросов через него, а то неизвестно какими дополнительными Wrapper'ами обвешано соединение к БД вызываемое из JSP-страницы. С уважением, Владимир 0

@Danissimo 4 / 4 / 4 Регистрация: 28.08.2008 Сообщений: 611
	30.08.2006, 23:24
	О, Neznajka111! Вот еще один раз попросили написать консольное приложение и псмотреть, че к чему. Давай, показывай результаты =)) 0