Professional Web Applications Themes

JDBC type 4 and a growing SQL.LOG - IBM DB2

Hi, I'm using a IBM JDBC type 4 driver to connect to a 8.2 DB2 database (on a Windows client). While running the application I saw that there is created a logfile in the root of the startingdrive (Z:\). This is called SQL.LOG. It's growing with several MB's per second. I don't have unlimited drive space and I think it slows down the application. So I like the get rid of that logfile. It contains information like shown at the end of this message. I tried to start the JDBC connection using ....traceFile=c:\traceConnect2db2.log;traceLevel= " + (com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE) + ";" Now there's ...

  1. #1

    Default JDBC type 4 and a growing SQL.LOG

    Hi,

    I'm using a IBM JDBC type 4 driver to connect to a 8.2 DB2 database
    (on a Windows client).
    While running the application I saw that there is created a logfile in
    the root of the startingdrive (Z:\). This is called SQL.LOG. It's
    growing with several MB's per second. I don't have unlimited drive
    space and I think it slows down the application. So I like the get rid
    of that logfile. It contains information like shown at the end of this
    message.

    I tried to start the JDBC connection using
    ....traceFile=c:\\traceConnect2db2.log;traceLevel= " +
    (com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE) + ";"
    Now there's an empty file traceConnect2db2.log in the root of C:\. But
    the file SQL.LOG on the starting drive (Z:\) keeps existing and
    growing.

    Has anybody had the same problem and a sollution to get rid of it???

    Thanx in advance,
    Marcel Rokers

    Some lines in SQL.LOG

    db2jcc_license_ ***-*** ENTER SQLGetData

    HSTMT 0B3F22F8

    UWORD 2

    SWORD 8 <SQL_C_DOUBLE>

    PTR <unknown type>

    SQLLEN 8

    SQLLEN * 0x0B36FAC0



    db2jcc_license_ ***-*** EXIT SQLGetData with return code 0
    (SQL_SUCCESS)

    HSTMT 0B3F22F8

    UWORD 2

    SWORD 8 <SQL_C_DOUBLE>

    PTR <unknown type>

    SQLLEN 8

    SQLLEN * 0x0B36FAC0 (8)



    db2jcc_license_ ***-*** ENTER SQLFetch

    HSTMT 0B3F22F8



    db2jcc_license_ ***-*** EXIT SQLFetch with return code 0
    (SQL_SUCCESS)

    HSTMT 0B3F22F8



    db2jcc_license_ ***-*** ENTER SQLNumResultCols

    HSTMT 0B3F22F8

    SWORD * 0x0B36FAA8



    db2jcc_license_ ***-*** EXIT SQLNumResultCols with return code 0
    (SQL_SUCCESS)

    HSTMT 0B3F22F8

    SWORD * 0x0B36FAA8 (3)
    Marcel Guest

  2. #2

    Default Re: JDBC type 4 and a growing SQL.LOG

    Did you notice a speed increase switching to the Type 4 driver?

    "Marcel" <mrvgelder.com> wrote in message
    news:e7cc35f1.0307030606.afd433bposting.google.co m...
    > Hi,
    >
    > I'm using a IBM JDBC type 4 driver to connect to a 8.2 DB2 database
    > (on a Windows client).
    > While running the application I saw that there is created a logfile in
    > the root of the startingdrive (Z:\). This is called SQL.LOG. It's
    > growing with several MB's per second. I don't have unlimited drive
    > space and I think it slows down the application. So I like the get rid
    > of that logfile. It contains information like shown at the end of this
    > message.
    >
    > I tried to start the JDBC connection using
    > ...traceFile=c:\\traceConnect2db2.log;traceLevel=" +
    > (com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE) + ";"
    > Now there's an empty file traceConnect2db2.log in the root of C:\. But
    > the file SQL.LOG on the starting drive (Z:\) keeps existing and
    > growing.
    >
    > Has anybody had the same problem and a sollution to get rid of it???
    >
    > Thanx in advance,
    > Marcel Rokers
    >
    > Some lines in SQL.LOG
    >
    > db2jcc_license_ ***-*** ENTER SQLGetData
    >
    > HSTMT 0B3F22F8
    >
    > UWORD 2
    >
    > SWORD 8 <SQL_C_DOUBLE>
    >
    > PTR <unknown type>
    >
    > SQLLEN 8
    >
    > SQLLEN * 0x0B36FAC0
    >
    >
    >
    > db2jcc_license_ ***-*** EXIT SQLGetData with return code 0
    > (SQL_SUCCESS)
    >
    > HSTMT 0B3F22F8
    >
    > UWORD 2
    >
    > SWORD 8 <SQL_C_DOUBLE>
    >
    > PTR <unknown type>
    >
    > SQLLEN 8
    >
    > SQLLEN * 0x0B36FAC0 (8)
    >
    >
    >
    > db2jcc_license_ ***-*** ENTER SQLFetch
    >
    > HSTMT 0B3F22F8
    >
    >
    >
    > db2jcc_license_ ***-*** EXIT SQLFetch with return code 0
    > (SQL_SUCCESS)
    >
    > HSTMT 0B3F22F8
    >
    >
    >
    > db2jcc_license_ ***-*** ENTER SQLNumResultCols
    >
    > HSTMT 0B3F22F8
    >
    > SWORD * 0x0B36FAA8
    >
    >
    >
    > db2jcc_license_ ***-*** EXIT SQLNumResultCols with return code 0
    > (SQL_SUCCESS)
    >
    > HSTMT 0B3F22F8
    >
    > SWORD * 0x0B36FAA8 (3)

    Brien Schultz Guest

  3. #3

    Default Re: JDBC type 4 and a growing SQL.LOG

    No, because I didn't use a type 3 driver before.
    Do you mean that type 4 is faster than type 3?

    Haven't you seen the effect I mean?

    Thanx

    Brien Schultz wrote:
    > Did you notice a speed increase switching to the Type 4 driver?
    >
    > "Marcel" <mrvgelder.com> wrote in message
    > news:e7cc35f1.0307030606.afd433bposting.google.co m...
    >
    >>Hi,
    >>
    >>I'm using a IBM JDBC type 4 driver to connect to a 8.2 DB2 database
    >>(on a Windows client).
    >>While running the application I saw that there is created a logfile in
    >>the root of the startingdrive (Z:\). This is called SQL.LOG. It's
    >>growing with several MB's per second. I don't have unlimited drive
    >>space and I think it slows down the application. So I like the get rid
    >>of that logfile. It contains information like shown at the end of this
    >>message.
    >>
    >>I tried to start the JDBC connection using
    >>...traceFile=c:\\traceConnect2db2.log;traceLevel =" +
    >>(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE) + ";"
    >>Now there's an empty file traceConnect2db2.log in the root of C:\. But
    >>the file SQL.LOG on the starting drive (Z:\) keeps existing and
    >>growing.
    >>
    >>Has anybody had the same problem and a sollution to get rid of it???
    >>
    >>Thanx in advance,
    >>Marcel Rokers
    >>
    >>Some lines in SQL.LOG
    >>
    >>db2jcc_license_ ***-*** ENTER SQLGetData
    >>
    >>HSTMT 0B3F22F8
    >>
    >>UWORD 2
    >>
    >>SWORD 8 <SQL_C_DOUBLE>
    >>
    >>PTR <unknown type>
    >>
    >>SQLLEN 8
    >>
    >>SQLLEN * 0x0B36FAC0
    >>
    >>
    >>
    >>db2jcc_license_ ***-*** EXIT SQLGetData with return code 0
    >>(SQL_SUCCESS)
    >>
    >>HSTMT 0B3F22F8
    >>
    >>UWORD 2
    >>
    >>SWORD 8 <SQL_C_DOUBLE>
    >>
    >>PTR <unknown type>
    >>
    >>SQLLEN 8
    >>
    >>SQLLEN * 0x0B36FAC0 (8)
    >>
    >>
    >>
    >>db2jcc_license_ ***-*** ENTER SQLFetch
    >>
    >>HSTMT 0B3F22F8
    >>
    >>
    >>
    >>db2jcc_license_ ***-*** EXIT SQLFetch with return code 0
    >>(SQL_SUCCESS)
    >>
    >>HSTMT 0B3F22F8
    >>
    >>
    >>
    >>db2jcc_license_ ***-*** ENTER SQLNumResultCols
    >>
    >>HSTMT 0B3F22F8
    >>
    >>SWORD * 0x0B36FAA8
    >>
    >>
    >>
    >>db2jcc_license_ ***-*** EXIT SQLNumResultCols with return code 0
    >>(SQL_SUCCESS)
    >>
    >>HSTMT 0B3F22F8
    >>
    >>SWORD * 0x0B36FAA8 (3)
    >
    >
    >
    Marcel Guest

  4. #4

    Default Re: JDBC type 4 and a growing SQL.LOG

    This doesn't sound like a JDBC driver log. As you saw, when you used
    TRACE_NONE you saw where the output would have gone if it were a T4 driver
    trace. This sounds more like an application's log.
    --
    Larry Menard
    IBM Workstation Database (DB2) Performance Team
    Defender of Geese and of All Things Natural


    "Marcel" <mr_nospamvgelder.com> wrote in message
    news:3f091f3a$0$28905$1b62eedfnews.euronet.nl...
    > No, because I didn't use a type 3 driver before.
    > Do you mean that type 4 is faster than type 3?
    >
    > Haven't you seen the effect I mean?
    >
    > Thanx
    >
    > Brien Schultz wrote:
    > > Did you notice a speed increase switching to the Type 4 driver?
    > >
    > > "Marcel" <mrvgelder.com> wrote in message
    > > news:e7cc35f1.0307030606.afd433bposting.google.co m...
    > >
    > >>Hi,
    > >>
    > >>I'm using a IBM JDBC type 4 driver to connect to a 8.2 DB2 database
    > >>(on a Windows client).
    > >>While running the application I saw that there is created a logfile in
    > >>the root of the startingdrive (Z:\). This is called SQL.LOG. It's
    > >>growing with several MB's per second. I don't have unlimited drive
    > >>space and I think it slows down the application. So I like the get rid
    > >>of that logfile. It contains information like shown at the end of this
    > >>message.
    > >>
    > >>I tried to start the JDBC connection using
    > >>...traceFile=c:\\traceConnect2db2.log;traceLevel =" +
    > >>(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE) + ";"
    > >>Now there's an empty file traceConnect2db2.log in the root of C:\. But
    > >>the file SQL.LOG on the starting drive (Z:\) keeps existing and
    > >>growing.
    > >>
    > >>Has anybody had the same problem and a sollution to get rid of it???
    > >>
    > >>Thanx in advance,
    > >>Marcel Rokers
    > >>
    > >>Some lines in SQL.LOG
    > >>
    > >>db2jcc_license_ ***-*** ENTER SQLGetData
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>UWORD 2
    > >>
    > >>SWORD 8 <SQL_C_DOUBLE>
    > >>
    > >>PTR <unknown type>
    > >>
    > >>SQLLEN 8
    > >>
    > >>SQLLEN * 0x0B36FAC0
    > >>
    > >>
    > >>
    > >>db2jcc_license_ ***-*** EXIT SQLGetData with return code 0
    > >>(SQL_SUCCESS)
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>UWORD 2
    > >>
    > >>SWORD 8 <SQL_C_DOUBLE>
    > >>
    > >>PTR <unknown type>
    > >>
    > >>SQLLEN 8
    > >>
    > >>SQLLEN * 0x0B36FAC0 (8)
    > >>
    > >>
    > >>
    > >>db2jcc_license_ ***-*** ENTER SQLFetch
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>
    > >>
    > >>db2jcc_license_ ***-*** EXIT SQLFetch with return code 0
    > >>(SQL_SUCCESS)
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>
    > >>
    > >>db2jcc_license_ ***-*** ENTER SQLNumResultCols
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>SWORD * 0x0B36FAA8
    > >>
    > >>
    > >>
    > >>db2jcc_license_ ***-*** EXIT SQLNumResultCols with return code 0
    > >>(SQL_SUCCESS)
    > >>
    > >>HSTMT 0B3F22F8
    > >>
    > >>SWORD * 0x0B36FAA8 (3)
    > >
    > >
    > >
    >

    Larry Menard Guest

  5. #5

    Default Re: JDBC type 4 and a growing SQL.LOG

    Larry Menard wrote:
    > This doesn't sound like a JDBC driver log. As you saw, when you used
    > TRACE_NONE you saw where the output would have gone if it were a T4 driver
    > trace. This sounds more like an application's log.
    I think you mean by application's log, the database application / client
    application that's using the JDBC driver to access the DB2 database.
    The application is written in Java and written by me and a colleague.
    We're sure we ourselves haven't given a command to log to SQL.LOG and so
    much. So thats why we thougth it is part of the T4 driver.

    Is it a configuration option of the DB2 database? That's on another
    machine, so it's strange if that machine is the reason of the logging.

    I tried it with a T3 driver, but it has almost the same effect
    (so indeed I would say it's part of the application, but how do I quit
    logging???):


    db2java.zip" co 584-87c ENTER SQLFetch
    HSTMT 193522F8

    db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    HSTMT 193522F8

    db2java.zip" co 584-87c ENTER SQLNumResultCols
    HSTMT 193522F8
    [mrsantiago mr]$ head -n 100 SQL.LOG


    db2java.zip" co 584-87c ENTER SQLFetch
    HSTMT 193522F8

    db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    HSTMT 193522F8

    db2java.zip" co 584-87c ENTER SQLNumResultCols
    HSTMT 193522F8
    SWORD * 0x192BF960

    db2java.zip" co 584-87c EXIT SQLNumResultCols with return code 0
    (SQL_SUCCESS)
    HSTMT 193522F8
    SWORD * 0x192BF960 (3)

    db2java.zip" co 584-87c ENTER SQLGetData
    HSTMT 193522F8
    UWORD 1
    SWORD 11 <SQL_C_TIMESTAMP>
    PTR <unknown type>
    SQLLEN 16
    SQLLEN * 0x192BF97C

    db2java.zip" co 584-87c EXIT SQLGetData with return code 0 (SQL_SUCCESS)
    HSTMT 193522F8
    UWORD 1
    SWORD 11 <SQL_C_TIMESTAMP>
    PTR <unknown type>
    SQLLEN 16
    SQLLEN * 0x192BF97C (16)

    db2java.zip" co 584-87c ENTER SQLFetch
    HSTMT 193522F8

    db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    HSTMT 193522F8

    db2java.zip" co 584-87c ENTER SQLNumResultCols
    HSTMT 193522F8
    SWORD * 0x192BF960

    Marcel Guest

  6. #6

    Default Re: JDBC type 4 and a growing SQL.LOG

    Are you using any middleware like WebSphere?
    --
    Larry Menard
    IBM Workstation Database (DB2) Performance Team
    Defender of Geese and of All Things Natural


    "Marcel" <mr_nospamvgelder.com> wrote in message
    news:3f098237$0$28891$1b62eedfnews.euronet.nl...
    > Larry Menard wrote:
    > > This doesn't sound like a JDBC driver log. As you saw, when you used
    > > TRACE_NONE you saw where the output would have gone if it were a T4
    driver
    > > trace. This sounds more like an application's log.
    >
    > I think you mean by application's log, the database application / client
    > application that's using the JDBC driver to access the DB2 database.
    > The application is written in Java and written by me and a colleague.
    > We're sure we ourselves haven't given a command to log to SQL.LOG and so
    > much. So thats why we thougth it is part of the T4 driver.
    >
    > Is it a configuration option of the DB2 database? That's on another
    > machine, so it's strange if that machine is the reason of the logging.
    >
    > I tried it with a T3 driver, but it has almost the same effect
    > (so indeed I would say it's part of the application, but how do I quit
    > logging???):
    >
    >
    > db2java.zip" co 584-87c ENTER SQLFetch
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c ENTER SQLNumResultCols
    > HSTMT 193522F8
    > [mrsantiago mr]$ head -n 100 SQL.LOG
    >
    >
    > db2java.zip" co 584-87c ENTER SQLFetch
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c ENTER SQLNumResultCols
    > HSTMT 193522F8
    > SWORD * 0x192BF960
    >
    > db2java.zip" co 584-87c EXIT SQLNumResultCols with return code 0
    > (SQL_SUCCESS)
    > HSTMT 193522F8
    > SWORD * 0x192BF960 (3)
    >
    > db2java.zip" co 584-87c ENTER SQLGetData
    > HSTMT 193522F8
    > UWORD 1
    > SWORD 11 <SQL_C_TIMESTAMP>
    > PTR <unknown type>
    > SQLLEN 16
    > SQLLEN * 0x192BF97C
    >
    > db2java.zip" co 584-87c EXIT SQLGetData with return code 0 (SQL_SUCCESS)
    > HSTMT 193522F8
    > UWORD 1
    > SWORD 11 <SQL_C_TIMESTAMP>
    > PTR <unknown type>
    > SQLLEN 16
    > SQLLEN * 0x192BF97C (16)
    >
    > db2java.zip" co 584-87c ENTER SQLFetch
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c EXIT SQLFetch with return code 0 (SQL_SUCCESS)
    > HSTMT 193522F8
    >
    > db2java.zip" co 584-87c ENTER SQLNumResultCols
    > HSTMT 193522F8
    > SWORD * 0x192BF960
    >

    Larry Menard Guest

  7. #7

    Default Re: JDBC type 4 and a growing SQL.LOG

    Larry Menard wrote:
    > Are you using any middleware like WebSphere?
    I'm using Apache Tomcat 4.1.24. The client application is a servlet in
    the tomcat server. Is that creating and filling the logfile?

    Marcel Guest

  8. #8

    Default Re: JDBC type 4 and a growing SQL.LOG

    Actually, you said you get the same behaviour from the Type 3 driver, so
    it can't be a Type 4 driver problem, so I'm not going to talk to development
    about this. The verbose classloading suggestion still stands though.

    --
    Larry Menard
    IBM Workstation Database (DB2) Performance Team
    Defender of Geese and of All Things Natural


    "Larry Menard" <lmenardca.ibm.com> wrote in message
    news:bec6f7$ig$1hanover.torolab.ibm.com...
    > I don't know, I was just wondering what else it *could* be.
    >
    > I'll send a note to the Type 4 driver developers to verify that this is
    > not a driver trace of some sort.
    >
    > Another idea might be if you enabled verbose classloading very briefly,
    > just long enough to hopefully see who is printing to that log file.
    >
    > Other than that I'm out of ideas.
    > --
    > Larry Menard
    > IBM Workstation Database (DB2) Performance Team
    > Defender of Geese and of All Things Natural
    >
    >
    > "Marcel" <mr_nospamvgelder.com> wrote in message
    > news:3f098e4a$0$28912$1b62eedfnews.euronet.nl...
    > > Larry Menard wrote:
    > >
    > > > Are you using any middleware like WebSphere?
    > >
    > > I'm using Apache Tomcat 4.1.24. The client application is a servlet in
    > > the tomcat server. Is that creating and filling the logfile?
    > >
    >
    >

    Larry Menard Guest

  9. #9

    Default Re: JDBC type 4 and a growing SQL.LOG

    Larry Menard wrote:
    > Marcel,
    >
    > One of the JDBC folks here offers this suggestion:
    >
    >
    >>SQL.LOG is normally the ODBC trace, check in Control Panel ->
    >
    > Administrative -> ODBC Manager -> Tracing(tab) -> click on Stop Tracing
    >
    >
    Wow, that helps, the problem is solved. The logging stopped and the
    program runs much, much faster.
    The program also connects to a Sybase database via ODBC. So the
    Sybasedriver (via the JDBCODBC bridge) was the probably the problem.

    The strange thing is that all logging started with db2jcc (T4) or
    db2java.zip (T3). So that's why I thought that it was the DB2 JDBC
    driver. Can you explain why this behaviour happened? Does Microsoft also
    log JDBC calls or is it a bug in the Microsoft software and was it a
    mistake to call it a DB2 JDBC log. Or meaby it's a bug in the JDK (the
    db2 driver is loaded first), saying the wrong driver name.

    Looking at all those megabytes of loginfo I now see a SELECT statement
    to the Sybase database. The line starts with db2java.zip....

    Before the Sybase part of the program (select) took 95% of the the time.
    Now the DB2 part (insert) of the program takes about 70% of the time.

    Thanx a lot for all your help and suggestions,
    Marcel Rokers
    NL

    Marcel Guest

Similar Threads

  1. Replies: 4
    Last Post: August 25th, 06:33 PM
  2. Growing
    By Rick Brandt in forum Microsoft Access
    Replies: 1
    Last Post: July 21st, 06:12 PM
  3. JDBC Type 4 and DB2 ?!?
    By swap in forum IBM DB2
    Replies: 1
    Last Post: July 7th, 07:57 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139