db2 log files

[jackhu]

Sorry to trouble you guys but I believe you can give me a hand since you are the expertise of db2. I have a java program which insert more than 1 million records into database. The program is it always generates db2 log files that eventually make disk full. I am just wondering how I could check these log file? Is there any way to solve this disk full problem?

Thanks a lot.

 

[MarcLodge]

I think that if you issue a COMMIT (if it is possible to do this, from a business point of view), the log file should start again from the commit point.
Marc

 

[gregsimpson]

Are you sure it's the disk and not the log files that are full up. Log files can be 32GB in version 7.1.

If this is a one off load to the table you could always use the "not logged initially option".

This option exists for the CREATE TABLE and ALTER TABLE statements. When the option is used, no loggable activity within the unit of work that creates or alters the table or activates this option at a later time is logged. This is an advantage when inserting or updating a large amount of data into a table for the first time. This option is also suitable for work tables where data can be easily recreated. The advantage is the improvement of performance due to the absence of the logging overhead, the disadvantage is the recoverability of the unit of work.

I also strongly agree with Marc above, which may be all you need to do. Issuing a COMMIT will free up the log files and place the data from the log file into the table, effectively starting the log file again. Are you issuing COMMITS, if so how often?

If you are issuing a COMMIT and still have problems I think you hould read up on LOGBUFSZ, DBHEAP and also logging to raw devices.

Cheers
Greg

 

[jackhu]

Thanks guys. By using circular logging instead of archival logging, the problem is fixed.
Greg,
I have another question. My application reads a file and inserts a hugh chunk of data into database. Every time when it runs against an empty and just created database it is slow. The problem remains until I restart the machine. I just can't figure it out why.

Jack

 

[gregsimpson]

jackhu,

perhaps you have a memory leak. Clearly rebooting the machine won't physically change how the data is stored, so I'm wondering whether something is going wrong in the memory management when you insert the huge chunk of data.

Greg

 

[jackhu]

Greg,

Currently my problem can only be solved by reboot the machine. If it is a memeory leaking problem I think restart the application can help. But it actually it does't.

Jack

 

[gregsimpson]

Jackhu,

in which case not sure. Bit more on JAVA memory leaks below, just in case. JAVA HEAP size could have an effect.

Thanks
Greg

It is almost impossible to improve the performance of your code if your application is impacted by memory leaks. Memory leaks can be in either Java or native code. In native code, memory leaks are caused by the programmer forgetting to free a memory block. Java memory leaks are often caused by saving an object reference in a class level collection and forgetting to remove it at the proper time. There are also other kinds of problems with managing resources that impact performance, such as not closing JDBC Statements/ResultSets in a finally block (many JDBC drivers store a Statement reference in the Connection object). Fixing memory/resource leaks in the application not only has a great impact on performance but also system stability, as you will consume fewer resources.


There are some great tools in the marketplace that make it easy to find Java memory leaks. There are also tools for finding native memory leaks, but you shouldn’t need them unless your company is writing native code. It should suffice to monitor the memory used at the operating system level over a period of time while the client load test is running. In theory, if the application is repeating the same operations, total process memory should not creep up over time (it should level off). If the total memory of the Java process increases each time the client load test is run, then you probably have a memory leak to track down.

To determine if the memory leak is caused by a Java memory leak, you should monitor the Java memory used. The following code can be used for this purpose in the application:

System.out.println(“Java memory in use = “ + Runtime.getRuntime().totalMemory() –
Runtime.getRuntime().freeMemory());

You would want to view this information after running the client test load. If the Java memory is increasing in proportion to the total process memory increase, then you are probably leaking Java memory. If the Java memory is stabilized but the total process memory is increasing, you are probably leaking native memory. You have to make a judgment call on whether this technique applies to your application. If the application is designed to consume additional memory after each client request, then this technique will not help you determine if you have a memory leak. You will have to use commercially available Java/native memory leak finding tools instead.