If you are using circular logging (the default) then you need to increase the nu mber of secondary logs

to about 200, and increase the logfilesz to about 20000 p ages. These changes will probably solve your problem. If you are using recovery logging (sometimes known a log retain), then you need to make the same changes as above, plus you need to archive the logs (LOGARCHMET H1), and also periodically prune (delete) the older logs on the log archive path . All these changes are set up with the "db2 update db cfg for db-name using XXXXX XXX XX" command, and then terminate all connections for them to take effect. Tranaction log full error pops up when the DML transactions are not commited fre quently. Use COMMITS frequently, say for every 1000 records. If you want to delete huge data from the tables, better drop them and recreate b efore inserting the data.

**** The circular logs can be reused after all transactions have committed. If the am ount of logging in a unit of work of an SQL statement (commit scope) is too larg e for the log size you specified, you will get the error you received. You need to increase the number of logs (I would double them), and the size of each log ( I would increase the size by a factor of 10). That would make each log file 40 M B, which is not much disk space.

***** I would suggest you to go for infinite logging where in you set logsecond = -1 a nd it allows you to use as much active log space as you want provided you have e nough filesystem space for the logpath and the overflow logpath. This cannot be accomplished by turning off logarchmeth1. Don't forget the fact that rollback and crashrecovery will be pretty slow by ena bling infinite logging. *************** Tuning DB2 transaction log size The space required by DB2 transaction log is specified by the following DB2 param eters: * LOGFILSIZ * LOGPRIMARY * LOGSECOND

* NEWLOGPATH To view the DB2 parameters associated with DB2 transaction log and their values, run the following command: db2 get database configuration for ldapdb2 \ egrep 'LOGFILSIZ LOGPRIMARY LOGSECOND NEWLOGPATH Path to log f iles' Log file size (4KB) (LOGFILSIZ) = 2000 Number of primary log files (LOGPRIMARY) = 8 Number of secondary log files (LOGSECOND) = 3 Changed path to log files (NEWLOGPATH) = Tivoli Directory Server uses transaction log disk space for storing uncommitted D B2 transactions from directory update operations. The transaction log parameters must be tuned to allow the transaction logs to grow to their maximum required s ize. The transaction log size is limited by the values of DB2 parameters LOGFILS IZ, LOGPRIMARY, and LOGSECOND, and also by the available disk space in the direc tory specified by the NEWLOGPATH DB2 parameter. If the transaction logs exceeds the limit due to the settings of the DB2 size parameter, then the transaction is backed out using the information in the transaction logs and the transaction fa ils. If the transaction logs exceed the limit due to a lack of available disk sp ace, the database becomes corrupted and goes into an unusable state. If the data base becomes corrupted in this way, it is possible to issue DB2 commands to reco ver the database. Alternatively, the database can be restored from a backup or r eloaded. If the database becomes corrupted, often the recovery commands can be f ound in the sqllib/db2dump/db2diag.log file, which is located in the DB2 instanc e owner's home directory. By default the DB2 transaction log file size (LOGFILSI Z) is defined to be 2000 blocks of 4 KB in size or 8000 KB per log file. The num ber of primary logs files (LOGPRIMARY) is defined as 8 and the number of seconda ry log files (LOGSECOND) is 3. In order to increase the DB2 transaction log limi ts to allow for millions of users, it is necessary to increase the size of the t ransaction logs (LOGFILSIZ) and increase the number of secondary files (LOGSECON D). It is better to increase the number of secondary files rather than the numbe r of primary files, because the secondary files periodically get deleted when no t in use. The transaction log requirements are small for a Tivoli Directory Server running with a normal workload. It is observed that runtime directory operations will i ncrease the transaction log requirements for a short period of time. * The ldapadd or ldapmodify commands use some amount of transaction log spac e as the number of multi-valued attributes added to a single LDAP entry in a sin gle command grows. For example, when loading many members into a group. * An ACL placed on a suffix object can result in that ACL propagating to eve ry entry under that suffix. The Tivoli Directory Server performs ACL propagation as one single committed DB2 transaction. **************** I hope you got your doubt cleared by now, if not the reason people suggest to in crease the logfilesz or number of log files is to increase the "space allocated for the db2 transaction logs" rather than the "log File system space". Your Avai lable or the Maximum Transaction log space is different from the Available or th e Maximum File system space allocated for db2 logs. For example, If your Log fil e system space is 10GB, it does not mean that your db2 transactions can use all of that 10GB, instead db2 transaction log space is given by your "logfilesz * (l ogprimary logsecondary) * 4" KB, if your logfilesz = 2000, and logprimary is 50 and logsecondary is 200, then The Maximum Db2 Transaction log file space availab le for applications is 2000 * (50 200) *4 KB, which is around 1.9 GB only. So, e

ven though your log file system space in this case is 10GB, there is every possi bility that you encounter Transaction log full errors once your 1.9GB is utilize d by the applications. That is the exact reason, why people increase their log f ile size or number of primary or secondary log files, so that they increase the total Transaction log file space available (which you can increase until you ext inguish your LOG FILE system space or utilize around 80% of your Log file system space, then its the concern of your OS administrator to increase the file syste m space). **************** It's always advised to use frequent commit logic. COMMITCOUNT is a way to make s ure of it. Another way would be break down the query based on some column values . However, we can do an estimation whether the log space available on database i s going to be enough for our transaction using the below method LOGSPACE_AVAILABLE = (LOGFILSIZ*(LOGPRIMARY LOGSECONDARY))*4 KB LOGSPACE_REQUIRED = TABLE_ROW_SIZE * NUMBER_OF_ROWS_TO_BE_DELETED * PAGE_SIZE KB TABLE_ROW_SIZE can be bet estimated using the AVGROWSIZE column value from sysca t.tables (from v9.1 onwards). Select avgrowsize from syscat.tables where tabname='TABNAME' and tabschema='TABS CHEMA'; We can compare LOGSPACE_AVAILABLE and LOGSPACE_REQUIRED to predict whether the d elete operation would be successful. This method also helps us to determine and set COMMITCOUNT value in the import s tatement. Say, for e.g. we have 1000KB LOGSPACE_AVAILABLE on the db. To be on a safer side let us allow the transaction to use only 800 KB log space , i.e. LOGS PACE_REQUIRED value would be 800. Thus, 800 = TABLE_ROW_SIZE * value_commitcount * PAGE_SIZE => value_commitcount = 800/(TABLE_ROW_SIZE * PAGE_SIZE) This is what I use to predict the status of DML operations. Any thoughts or a be tter suggestion is most welcome. *************************** TABLESPACE select substr(tbsp_name,1,10) "Name", tbsp_utilization_percent "Used%", tbsp_fre e_pages "FreePages", tbsp_usable_Pages "UsablePages", tbsp_used_pages "UsedPages", tbsp_page_t op "HWM", tbsp_auto_resize_Enabled "AutoResize 1=Yes", tbsp_max_size "MaxSizeBytes -1=ulimited", tbsp_last_resize_failed "ResizeFailed 1=Yes", tbsp_page_size "PgSize Bytes" from SYSIBMADM.TBSP_UTILIZATION where tbsp_type = 'DMS';

db2pd

db <db_name> -tablespaces .

DATABASE STATISTICS select stats_time, rtrim(tabname) Table from syscat.tables where type = 'T' order by stats_time desc;

select stats_time, rtrim(tabname) Table, rtrim(indname) Index from syscat.indexes order by stats_time desc; *** autoconfigure using mem_percent 85

workload_type simple num_stmts tpm 20 300

admin_priority performance is_populated yes num_local_apps 0 num_remote_apps 500 isolation cs

bp_resizeable yes apply none; *** Adequate Indexing db2advis -d <db_name> -g *** DB2 calculate your package cache hit ratio in a v9.x database. For older versions y ou can perform a database snapshot and use a similar calculation to find it: m I -o advisfile.txt

select rtrim(db_name) Database, rtrim(char((1-(pkg_cache_inserts/pkg_cache_lookups))*100)) CacheHitRatio from sysibmadm.snapdb; **** ALTER TABLE x ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE; OR set logsecond to -1. or increase your logfilsiz/logprimary or load from null or other truncate tricks OR **** in 9.7 you can also use truncate table command. db2 "truncate table tablename IGNORE DELETE TRIGGERS drop storage immediate" Reply With Quote *** db2 connect to <database> echo echo TRANSACTION LOG UTILISATION REPORT echo echo sysibmadm.LOG_UTILIZATION '%' Package