Change Transaction-Log-size of sapinst ?

[Former Member]

Hello,

is it possible to change the default transaction-Log-size of sapinst ?

I know, that there is a 'advanced database configuration' checkbox for other databases, but on DB2 we can't find it...

Are the default values stored in a file so we can change them ? Or is there a option when we execute sapinst to enable the advanced-checkbox ?

[hans-juergen_zeltwanger]

Hello Christoph,

as far as I know there is no option in SWPM (sapinst) to do so.

May I ask for the background of your question?

The number and size of log files should be sufficient to run a fresh installation.

If you experienced issues in this area, it is worth to open an incident, because this should not happen.

For R3load based system copies this can be different, depending on your specific case. However, if it is a huge system combined with a challenging offline time you may want to leave SWPM and run the migration monitor manually. I this case you probably also have to manually adapt the log files.

DB2 at this point in time (fresh installation or R3load based system copy) is anyhow configured in circular logging mode, which means that available log files are constantly re-used.

(And therefore please ignore the comment on infinite secondary logs from the other posts, LOGSECOND=-1 does not work for circular logging)

While circular logging is fine for the installation phase, it is not recommended for later production use.

Saying this: One has to change the logging configuration from circular logging  to log archiving after the installation or system copy. And one could change the size / number of log files as part of this step. The log files need to be re-created anyhow when you switch from circular to archiving.

Hans-Jürgen

[Former Member]

Hi Hans-Jürgen,

thank you for your answer.

We try to do a unicode-conversion,

but the transaction-log is running full.

If i understand your info correctly, the DB2-Transaction-Log should be overwritten in circles while working ?

That means, It shouldn't be too small and our problem is located somewhere else ?

[Frank-Martin]

Hi Christoph,

yes, this is somewhat strange. SWPM uses LOAD instead of INSERT for most tables. LOAD only logs extent allocation. So this should not require large log volumes.

For indexes the LOGINDEXBUILD parameter is switched off on DB level. So index creation should not require large log volumes too. Please check the LOGINDEXBUILD parameter.

Do you use anything special during system copy? E.g. Splitted export ... For such tables SWPM would use INSERT instead of LOAD as a default. However since R3load with INSERT commits regularly I still do not understand why you get log full situations.

If the problem persists it may be good to take some database and application snapshots. The database snapshots will show the application holding the oldest transaction and the application snapshots will show what this application is doing.

Regards

               Frank

[Former Member]

Hi Frank,

yes, we use splitted tables while conversion/copy.

While working the Export/Import stops and the Transaction-Log was full.

We will check the Parameter and try again.

Maybe we come back to you soon.

thank you for the suggestions...

Kind regards

Christoph

[hans-juergen_zeltwanger]

Hi Frank,

Hi Christoph,

maybe Index build before load is configured?

If I recall correctly: Even if the index build is not consuming much log space, it still holds an early entry in the logs. All subsequent log space may be eaten up by the INSERTS for splitted tables then.

As Frank mentioned, the snapshots should reveal the application holding the oldest transaction.

@ Christoph, can you check the index creation strategy? Typically to be found in DDLDB6.TPL.

And to answer your question: Yes, with circular logging the log files will be overwritten. Which basically means that there is no archiving of this log files taking place.

However, the amount of available log space still is limited: If some very long running transaction (or a transaction that "forgets" to commit) holds a log entry, the corresponding log file will not be available for re-use. And as soon as the "overwrite cycle" reaches this log file, you will see the log full situation.

Hans-Jürgen

[Former Member]

Hello Hans-Jürgen,

thank you again for the info.

Know we know how to stop the sapinst at a special point of execution (before Export/Import),

and we will have a closer look to the database condition at this point.

I'll come back to you with the results...

Kind regards

Christoph

[former_member182505]

Hello Christoph

I agree with ventat Points, there is no option in sapinst,

you can use secondary log as suggested ,

Thanks

Sadiq

[former_member213250]

Dear Chris

As far as I am aware , there shouldn't be any specific Transaction log space specific to SAPINST. T-Log space is at DB level and all the DB activities will be logged in here.

If you have any concern regards to transaction log space during upgrade or installation, you can consider to set No.of log files to maximum allowed values (0-255) and increase fize of each log file size.

In exterme cases if you hit repeated log full cases at the time of installation or upgrade you can consider to set LOG_SECONDARY value to " infinite " . Please be aware this "INFINITE" value is recommended for well monitored systems.

Regards
Venkat.