Извиняюсь, что вопрос уж очень по-ламерски звучит ... Декорация: бардак полный, кто чем занимается я понятия не имею.... Итак, во время экскрементов юных дбшников, наблюдаю во множестве подобные сообщения:
Code
DSNT501I -DB9G DSNILMCL RESOURCE UNAVAILABLE 238 CORRELATION-ID=db2jcc_appli CONNECTION-ID=SERVER LUW-ID=NF000001.G80C.110207133622=20833 REASON 00C9008E TYPE 00000302 NAME DSNDB06 .SYSOBJ .X'0000C3' DSNT376I -DB9G PLAN=DISTSERV WITH 239 CORRELATION-ID=db2bp.exe CONNECTION-ID=SERVER LUW-ID=D90F12C3.A64B.C74C4216CCFF=22212 THREAD-INFO=IBMUSER:DB2ESE:ibmuser:db2bp.exe IS TIMED OUT. ONE HOLDER OF THE RESOURCE IS PLAN=DISTSERV WITH CORRELATION-ID=db2jcc_appli CONNECTION-ID=SERVER LUW-ID=NF000001.G553.110207132733=20771 THREAD-INFO=IBMUSER:4-111-2-15:ibmuser:db2jcc_application ON MEMBER DB9G
Хочется выяснить следующие вещи: 1. О каком ресурсе базар ? 2. Кто конкретно этот ресурс "держит" ? 3. К кому из экскрементаторов относятся эти сообщения ? Т.е. IP и порт запускальщика. (В z/OS никто лазать не умеет, все запросы приходят из линуха или виндов)
В ISPF я нашел место где могу посмотреть информацию о тредах DB2 ... Ну и смотрю на табличку как баран - не знаю что делать дальше. В OMVS к моей великой радости обнаружилась работающая команда netstat Но она показывает мне десяток установленных соединений к DB2, "угадать" среди них виновников не представляется возможным...
Вообще, есть ли возможность "подсмотреть" кто какие запросы слал ?
Сообщение отредактировал sl - Вт, 08.02.2011, 15:53
О странице DSNDB06 .SYSOBJ .X'0000C3'. Если интересует какая таблица, то её название можно узнать распечатав табличное пространство с помощью DSN1PRNT. Только вряд ли это нужно. Возможно, проблема в клинете DB2.
3. К кому из экскрементаторов относятся эти сообщения ? Т.е. IP и порт запускальщика. (В z/OS никто лазать не умеет, все запросы приходят из линуха или виндов)
Как переводить LUWID в IP-адрес описано здесь: http://www-01.ibm.com/support/docview.wss?uid=swg21055269
Но в вашем случае это не подходит, т.к. первый символ LUW-ID должен был в интервале от 'G' до 'P'. LUW-ID=NF000001 - возможно это localhost. Но это только предположение.
При возникновении подобной ситуации для обеих нитей посмотрите вывод команды
Code
-DB9G DIS THD(*) LUWID(xxxxx) det
где xxxxx берется из
Code
LUW-ID=D90F12C3.A64B.C74C4216CCFF=xxxxx
Quote
Вообще, есть ли возможность "подсмотреть" кто какие запросы слал ?
Есть несколько вариантов: 1. Запустить трассировку и преобразовать её в отчет, но это не тривиально. 2. Посмотреть кэш запросов, например, с помощью IBM Data Studio (самый простой вариант). 3. Использовать инструменты DB2 for z/OS, например DB2 Query Monitor for z/OS.
Но в вашем случае это не подходит, т.к. первый символ LUW-ID должен был в интервале от 'G' до 'P'. LUW-ID=NF000001 - возможно это localhost. Но это только предположение.
Почему же не подходит ? N вообще-то в этом диапазоне и как раз равен 7, т.е. 7f 00 00 01 - таки да... Но я этого не понимаю, т.к. в z/OS НИКТО не работает, мамой клянусь... Еще раз пардон за глупость: может быть такое, что этот запрос с localhost'а явился следствием какого-то запроса извне ? Такое бывает в природе ?
Я в задачу стараюсь не вникать, потому что структура базы и логика работы перетянута из оракла, а там оно было спроектировано а) каким-то шизофреником, б) для совершенно другой задачи , в общем - бред на бреде сидит и бредом погоняет. А шиза - она заразна, как известно, так что я просто боюсь за свои мозги Но знаю, что все делается на хранимых процедурах, которые многократно друг друга вызывают. А поскольку это разработка, то вполне себе рядовая ситуация что кто-то один дал запрос на какое-то длинное изменение в базе, или выборку, а кто-то другой в этот момент перетранслирует одну из процедур, вызываемых при обработке этого запроса. Но это не объясняет откуда может взяться запрос с localhost'а....
Когда говорил, что не подходит, то имел ввиду LUW-ID=D90F12C3. Другой даже не подумал переводить.
А это просто IP, без изменений. Задача как стоит - чтоб начиналось с буквы ? Ну вот, A-F отображаются как есть, а 0-9 преобразуются в G-P. IBM-овский стиль трудно с чем-нибудь спутать
Quote
У вас Java хранимые процедуры?
Вроде бы нет, насколько мне известно. Но поручиться не могу. Кто-то с явой играется как-то, подробности не знаю.
Добавлено (11.02.2011, 03:01) --------------------------------------------- Прикол: в какой-то момент увидел LUW-ID, который "расшифровал" как 10.0.2.15 . Приторчал. Вроде не было у них там такой сетки. (А даже если б была - какого черта местному басурману понадобилось в НАШЕЙ DB2 ? ) Тут же попробовал пингануть этот адрес. Естественно , не пингуется. netstat -r про такую сетку ничего не знает. Из детства вспоминается - вроде бы slirp любил такой адрес выдавать... И кто-то еще, кажется, из эмулятров, стянувших к себе соотв.кусок кода... Но какое отношение это имеет к DB2 под z/OS - фантазия буксует.
А на самой системе нет интерфейса с таким адресам? D TCPIP,,N,HOME не покажет такой адрес в списке "домашних"? Ну плюс еще может где-то NAT-преобразование есть?
Могу дать еще одно предположение, более "изощренное". Если в z/OS стоит пакет OpenSSH и пользователи имеют право туда ходить, то можно через SSH-соединение форварднуть порт. В таком случае диагностика может "валять дурака". Т.е. сэмулировать подключение с адреса 127.0.01 можно "на раз".
А на самой системе нет интерфейса с таким адресам? D TCPIP,,N,HOME не покажет такой адрес в списке "домашних"?
Code
EZZ2500I NETSTAT CS V1R11 TCPIP 024 HOME ADDRESS LIST: ADDRESS LINK FLG 192.86.32.76 OSDL P 127.0.0.1 LOOPBACK 2 OF 2 RECORDS DISPLAYED END OF THE REPORT
Буржуи, блин - им не впадлу было туда повесить ЧЕСТНЫЙ ipшник, без всяких натов и пробросов.
Quote
Если в z/OS стоит пакет OpenSSH и пользователи имеют право туда ходить, то можно через SSH-соединение форварднуть порт. В таком случае диагностика может "валять дурака". Т.е. сэмулировать подключение с адреса 127.0.01 можно "на раз".
ssh есть. Но хожу на него я один.
Quote (Gregory)
а с WebShere никто не играется? если да, то запрос с 127.0.0.1 не удивителен...
Ошметки от нее в фс видны. Но из наших никто не играется точно, а у IBMовцев для поиграцца есть более подходящие места, чем сдаваемая в аренду "юзерская" виртуальная машинка.
Ну тогда проверить все jar-архивы хранимых процедур и функций на предмет строки jdbc:db2:// Для этого нужно выгрузить все архивы из таблицы SYSIBM.SYSJAROBJECTS и провести текстовый поиск по файлам классов. Пример java-класса, который умеет вытаскивать jar-ы из архивов:
Code
import java.sql.*; import java.io.*;
class db2_get_jars { public static void main(String args[]) throws Exception { if (args.length != 2) { System.out.println("Usage: get_jars <JDBC URL> <output dir>"); return; } System.out.println("Loading DB2 Driver 'com.ibm.db2.jcc.DB2Driver'"); Class.forName("com.ibm.db2.jcc.DB2Driver"); System.out.println("Connecting to database."); Connection con = DriverManager.getConnection(args[0]); Statement stmt = con.createStatement(); System.out.println("Executing request to SYSIBM.SYSJAROBJECTS"); ResultSet rs = stmt.executeQuery("SELECT STRIP(JARSCHEMA) CONCAT '_' CONCAT STRIP(JAR_ID) as NAME, JAR_DATA as JAR from SYSIBM.SYSJAROBJECTS"); String filename = ""; while ( rs.next() ) { filename = args[1]+System.getProperty("file.separator")+rs.getString("NAME")+".jar"; System.out.println("Writing : "+filename); FileOutputStream fout = new FileOutputStream(filename); fout.write(rs.getBytes("JAR")); fout.close();
} rs.close(); stmt.close(); System.out.println("Disconnecting from database."); con.close(); System.out.println("Done."); } }
Но она показывает мне десяток установленных соединений к DB2, "угадать" среди них виновников не представляется возможным... 
