Медленно читается 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! Вот еще один раз попросили написать консольное приложение и псмотреть, че к чему. Давай, показывай результаты =))

Новые блоги и статьи Все статьи Все блоги /
Свет в конце тоннеля kumehtar 16.06.2026 Поймал себя на одной мысли. Раньше мне всегда казалось неправильным жить без чёткого понимания, куда всё идёт. Будто я иду по дороге судьбы, но не знаю, куда она ведёт. А раз не знаю — значит,. . .	[golang] Реализация стека с поддержкой получения минимального элемента за O(1) alhaos 16.06.2026 155. Min Stack Задача: Реализовать стек который поддерживает push, pop, top и получение минимального элемента за O(1). Методы: NewMinStack() *MinStack — инициализация Push(val int) —. . .	[golang] Конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. alhaos 10.06.2026 Задача Реализовать конкурентный fetcher с ограничением максимального количества одновременных HTTP запросов. Сигнатура func Fetch(urls string, maxConcurrent int) Result Пример urls :=. . .	[golang] Состояние гонки (race condition) alhaos 10.06.2026 Состояние гонки (race condition) Состояние гонки (Race Condition) — это ошибка, возникающая при одновременном доступе нескольких горутин к одним и тем же данным без должной синхронизации. При этом. . .
Взрослые отношения, и почему они не получаются kumehtar 09.06.2026 Когда в детстве ребёнок не получает от родителей чего-то важного, он лишается не просто приятных переживаний, а основы для формирования определённых внутренних качеств и навыков. Если ребёнок не. . .	[golang] Worker Pool alhaos 09.06.2026 Worker Pool Worker Pool — паттерн конкурентной обработки задач в Go. Суть: фиксированное количество горутин-воркеров читают задачи из общего канала и пишут результаты в общий канал результатов. . . .	[golang] Pipeline alhaos 08.06.2026 Pipeline Pipeline — паттерн конкурентной обработки данных в Go. Суть: данные проходят через цепочку независимых стадий, каждая из которых работает в своей горутине и общается с соседями через. . .	Свет внутри себя kumehtar 07.06.2026 Пусть это будет здесь lIs4oanZS9Y

@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