! needs attention ! log devspace gets filled up...

[Former Member]

Hello,

we're in a serious situation where the log-space get filled up, even if autolog-parameter is set to "on".

Probably maxdb has a problem while writing the log to disk..?!?!

What can we do to "empty" the log space........currently we are at level 72%, rapidly increasing..

any help appreciated.....GERD....

The message in knldiag.err looks like:

2009-03-18 10:44:17 5670 ERR 20021 Data Requested permanent data page 16777414 of root 16777414 is greater than the upper limit of 5597888.

2009-03-18 10:44:17 5670 ERR 11599 BTRACE -

---

> Emergency Stack Back Trace <----

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (0):0xabc2fe

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (1):0xabb27d

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (2):0xabb364

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (3):0xabb299

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (4):0x852d88

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (5):0x850767

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (6):0x8a40c7

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (7):0x8ab2da

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (8):0x8a5eb2

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (9):0x8a5897

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (10):0x847967

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (11):0x812d9f

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (12):0x7cc57b

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (13):0x80fc54

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (14):0x80f687

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (15):0x810514

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (16):0x81044e

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (17):0x54d1ec

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (18):0x54d4c6

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (19):0x901706

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (20):0x54d460

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (21):0xaf99aa

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (22):0xaf97f6

2009-03-18 10:44:17 5670 ERR 11599 BTRACE (23):0x2ae4a42897d0

2009-03-18 10:44:17 5670 ERR 11599 BTRACE -

---

> Module List <----

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |.text Start |.text End | Module File Name

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x0000000000400000|0x0000000000b88000| /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002aaaaaab6000|0x00002aaaaaabd000| /lib64/libnss_compat-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002aaaaacbe000|0x00002aaaaacd2000| /lib64/libnsl-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002aaaaaedf000|0x00002aaaaaee9000| /lib64/libnss_nis-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002aaaab0ea000|0x00002aaaab0f4000| /lib64/libnss_files-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002aaab074c000|0x00002aaab07fa000| /opt/sdb/7500/lib/liboms.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a32c0000|0x00002ae4a32dc000| /lib64/ld-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a34de000|0x00002ae4a34f4000| /lib64/libpthread-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a36f9000|0x00002ae4a36fb000| /lib64/libdl-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a38fd000|0x00002ae4a3905000| /lib64/librt-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a3b07000|0x00002ae4a3bca000| /usr/lib64/libstdc++.so.5.0.7

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a3dc9000|0x00002ae4a3dca000| /usr/lib64/libstdc++.so.5.0.7

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a3de4000|0x00002ae4a3e39000| /lib64/libm-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a403a000|0x00002ae4a4047000| /lib64/libgcc_s.so.1

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a4249000|0x00002ae4a4382000| /lib64/libc-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE |0x00002ae4a4581000|0x00002ae4a4584000| /lib64/libc-2.5.so

2009-03-18 10:44:17 5670 ERR 11599 BTRACE

2009-03-18 10:44:17 5670 ERR 11599 BTRACE -

---

> Symbolic Stack Back Trace <----

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 0: 0x0000000000abc40f eo670_UnixTraceStack +0x02ed

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 1: 0x0000000000abb27d eo670_CTraceContextStackOCB +0x0009

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 2: 0x0000000000abb364 eo670_CTraceStackOCB +0x003d

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 3: 0x0000000000abb299 eo670_CTraceStack +0x0017

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 4: 0x0000000000852d88 Z26bd13IllegalPageNoHandlingR18tgg00_TransContextRK12tgg00_FileIdi10tsp00_EnumI23tbd02_R

2009-03-18 10:44:17 5670 ERR 11599 BTRACE ecoveryMode_EnumLi3EhE +0x0238

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 5: 0x0000000000850767 bd13GetNode +0x0447

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 6: 0x00000000008a40c7 ZN24cbd300InvSubTreeCurrent15bd300SetSubRootER24cbd450_InvListRefSubTreeb +0x0083

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 7: 0x00000000008ab2da ZN24cbd300InvSubTreeCurrentC1ER22cbd300_InvCurrentBasisRK10tsp00_EnumI21tbd_node_request

2009-03-18 10:44:17 5670 ERR 11599 BTRACE EnumLi2EhER24cbd450InvListRefSubTreeb +0x00f0

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 8: 0x00000000008a5eb2 Z20bd400DeleteSubTreesR17cbd300_InvCurrentR11cbd600_Node +0x0144

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 9: 0x00000000008a5897 Z16bd400DropInvTreeR17cbd300InvCurrent +0x0261

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 10: 0x0000000000847967 bd03ReleaseInvTree +0x0101

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 11: 0x0000000000812d9f b01prefix_destroy_files +0x022e

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 12: 0x00000000007cc57b k53server_drop_aux_files +0x003e

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 13: 0x000000000080fc54 kb90child_prefix_destroy_files +0x00e1

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 14: 0x000000000080f687 k90sreceive_server +0x00fa

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 15: 0x0000000000810514 kb92_server +0x00bb

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 16: 0x000000000081044e k92server_process +0x01ee

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 17: 0x000000000054d1ec ak91run_non_user_process +0x023d

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 18: 0x000000000054d4c6 a91mainprogam_with_allocator +0x004f

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 19: 0x0000000000901706 gg941CreateAllocatorAndCallMainprog +0x01a4

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 20: 0x000000000054d460 a91mainprogram +0x0036

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 21: 0x0000000000af99aa Z23en88CallKernelTaskMainP9TASK_TYPE +0x01ae

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE 22: 0x0000000000af97f6 en88_CallCoroutineKernelTaskMain +0x001a

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE -

---

> End of Stack Back Trace <----

[Former Member · Accepted solution]

...we don't know which table belongs to this data page, since the statement "select * from roots where root=16777414" returns no result set.

[Former Member · Accepted solution]

...also a manual log backup doesn't work, because "autolog" is set to "on"

[markus_doehr2 · Accepted solution]

dbmcli -U c autolog_off
dbmcli -U c backup_start <logmedium> log
dbmcli -U c autolog_on

How big is your LOG_SEGMENT_SIZE configured? The database will back up as soon as that size is reached when autolog is turned on.

The table may be a temporary table created during runtime and deleted afterwards.

Markus

[Former Member · Accepted solution]

Hello Markus,

thanks for answering quickly.

The parameter "LOG_SEGMENT_SIZE" is set to "17066".

I recently restarted the database and thereby the log has been cleared.

The database came back online without error, puuuhhhhhh....

I'm afraid of the situation that if the next attempt of writing the log to disk fails, we'll have the same situation again.........shall we plan a structure check in admin mode..?!?!

regards...GERD...

[lbreddemann · Accepted solution]

--> I wrote a more elaborate answer, but this was blocked due to the funny "forbidden words" filter !???

1. This is not a paid support organization, but just a forum where users try to help each other voluntarily.

2. Disable the automatic log backup and run the log backup manually afterwards.

3. The crash is independent of the log-area. Run a CHECK DATA WITH UPDATE in ADMIN mode.

regards,

Lars

[Former Member · Accepted solution]

Hello Lars,

yes, we know, this is "just" a forum, but a quite good one

After restarting the database everything's fine, no errors and log is written as expected.

Shall we still plan this "check in admin mode"...(this involves downtime of our productive system for 2-3 hours) ?

regards....GERD....

[lbreddemann · Accepted solution]

> Shall we still plan this "check in admin mode"...(this involves downtime of our productive system for 2-3 hours) ?

Well, to avoid a second unplanned downtime, I recommend to take a full data backup right away and to run the CHECK DATA WITH UPDATE later e.g. at the weekend.

regards,

Lars

[Former Member · Accepted solution]

Hello,

I've created a full backup yesterday in the evening (just to be sure).

But today we ran into the same troubles without having any messages in knldiag.err =>

"

2009-03-18 10:44:17 5670 ERR 11599 BTRACE /opt/sdb/7500/pgm/kernel

2009-03-18 10:44:17 5670 ERR 11599 BTRACE Frameinfo [0x0]

2009-03-18 10:44:17 5670 ERR 11599 BTRACE -

---

> End of Stack Back Trace <----

2009-03-18 15:19:28 ___ Stopping GMT 2009-03-18 14:19:28 7.5.0 Build 038-123-133-420

2009-03-18 15:19:35 --- Starting GMT 2009-03-18 14:19:35 7.5.0 Build 038-123-133-420

"

Will we have this issue again and again until we perform the check in admin mode..?!?!

This means we have to restart our database regularly till the weekend.....

-GERD-

[lbreddemann · Accepted solution]

> I've created a full backup yesterday in the evening (just to be sure).

> But today we ran into the same troubles without having any messages in knldiag.err =>

Was the stack back trace the same?

>> Will we have this issue again and again until we perform the check in admin mode..?!?!

Just a moment - checking the crystal ball.. ah ... hmmm ... yes, this could be the case.

> This means we have to restart our database regularly till the weekend.....

Probably, yes.

See, the database is corrupt. That doesn't means that the whole database is crap - but at least parts of the space management is. So whenever the database needs to touch it, it may crash.

regards,

Lars

[Former Member · Accepted solution]

Hello,

last night the database check has been finished successfully.

The result after 2hours "checking the database and clearing unused data

pages" was:

PAGES_USED = 0003859082

BLOCKS_RELEASED = 0000001385

At the moment everything's running nice....?!?!

Since we had such issues (corrupt index>failed backup/log>check db in admin mode to "repair" the db) several times, is there a known "bug"/"bad behaviour" with corrupt indexes in this version ?

We're running MaxDB7.5.0.38 on opensuse10.3-64bit

thanks in advance...GERD...

[lbreddemann · Accepted solution]

> At the moment everything's running nice....?!?!

Why shouldn't it?

The converter has been completely rebuild by the CHECK DATA WITH UPDATE therefore it's unlikely that there will be another "illegal page access".

> Since we had such issues (corrupt index>failed backup/log>check db in admin mode to "repair" the db) several times, is there a known "bug"/"bad behaviour" with corrupt indexes in this version ?

Not that I'm aware of.

Anyhow, just to point this out again: currently there is no evident connection between the corrupt index and the log-backup problem.

In fact these point to totally different corners of the MaxDB architecture.

> We're running MaxDB7.5.0.38 on opensuse10.3-64bit

Well - WHY?

This release is pretty old and newer MaxDB versions have been available for a very long time now.

Since you're obviously not hanging on AWE there is really no reason to stay on 7.5.

Move on to 7.6 or 7.7.

regards,

Lars

[Former Member]

same problem again....

[Former Member]

Hello,

the log devspace gets filled up again, and there is no message in knldiag.err !?!?

These are the last entries in knldiag.err =>

2009-03-19 10:39:46 ___ Stopping GMT 2009-03-19 09:39:46 7.5.0 Build 038-123-133-420

2009-03-19 10:39:59 --- Starting GMT 2009-03-19 09:39:59 7.5.0 Build 038-123-133-420

2009-03-19 22:06:31 ___ Stopping GMT 2009-03-19 21:06:31 7.5.0 Build 038-123-133-420

2009-03-19 22:06:33 --- Starting GMT 2009-03-19 21:06:33 7.5.0 Build 038-123-133-420

2009-03-19 22:09:01 ___ Stopping GMT 2009-03-19 21:09:01 7.5.0 Build 038-123-133-420

2009-03-19 22:21:25 --- Starting GMT 2009-03-19 21:21:25 7.5.0 Build 038-123-133-420

There's no bad index, what can we do check what causes the increasing log ????

regards...GERD...

[Former Member]

Hello,

a bit more information. There's an additional tool which creates a log every 10 minutes, and it seems that this is working without any problems.

Here are the last entries from "Utility Statements" file =>

...

2009-03-23 10:00:45 49C74FBD01AD 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto'

2009-03-23 10:00:45 49C74FBD01AD 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto': RETURNCODE 0

2009-03-23 10:00:46 49C74FBE01AE 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto'

2009-03-23 10:00:46 49C74FBE01AE 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto': RETURNCODE 0

2009-03-23 10:10:55 49C7521F01AF 0000 ASE AUTOSAVE END

2009-03-23 10:10:55 49C7521F01AF 0000 ASE AUTOSAVE END: RETURNCODE 0

2009-03-23 10:11:00 49C7522401B0 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto'

2009-03-23 10:11:00 49C7522401B0 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto': RETURNCODE 0

2009-03-23 10:11:00 49C7522401B1 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto'

2009-03-23 10:11:00 49C7522401B1 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto': RETURNCODE 0

2009-03-23 10:21:10 49C7548601B2 0000 ASE AUTOSAVE END

2009-03-23 10:21:10 49C7548601B2 0000 ASE AUTOSAVE END: RETURNCODE 0

2009-03-23 10:21:15 49C7548B01B3 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto'

2009-03-23 10:21:15 49C7548B01B3 0000 SLG SAVE LOG QUICK TO '/devspace/autolog/autosave' FILE FVERSION MEDIANAME 'auto': RETURNCODE 0

2009-03-23 10:21:16 49C7548C01B4 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto'

2009-03-23 10:21:16 49C7548C01B4 0000 ASO AUTOSAVE ON '/devspace/autolog/autosave' FILE MEDIANAME 'auto': RETURNCODE 0

And also the "Backup History" shows a successfull autolog every 10 minutes.

Since we performed the "Check Database in Admin mode" last Thursday, we really don't know what's going on now..?!?!?

regards...GERD...

[lbreddemann]

> the log devspace gets filled up again, and there is no message in knldiag.err !?!?

Why do you expect there any message. Because of the LOGFULL? Is there a LOGFULL situation at all or is the used log are just increasing?

Have you checked whether the log backups are running?

> There's no bad index, what can we do check what causes the increasing log ????

Well, a BAD INDEX has nothing to do with a LOGFULL situation (why do you think that?).

Don't mistake the co-incident from your first problem you posted with a dependency between both issues.

Concerning the second part of your query: no, there is no way to attribute the amount of createad log to a transaction or session.

Typically rollbacks would lead to an increase of log data (as most often the application would try to run the same statement again).

regards,

Lars

[Former Member]

Hello Lars,

I expected an entry because the parameter "autolog" is set to "on", but it seems that it is not working, since we have currently 600MB used space in the log area.

The mysterious thing is, that obviously log creation is working (see log history, or the utility statements in my last post) but despite this the log devspace gets filled up...(and I think we have to restart the database again)

-Gerd-

[lbreddemann]

> I expected an entry because the parameter "autolog" is set to "on", but it seems that it is not working, since we have currently 600MB used space in the log area.

Hmm... ok. the logbackup is working, therefore there are no 'errors' present that need reporting.

Anyhow, for some reason it looks like the log area does not get freed up

> The mysterious thing is, that obviously log creation is working (see log history, or the utility statements in my last post) but despite this the log devspace gets filled up...(and I think we have to restart the database again)

I really don't see how a db restart should change anything here.

Have you performed a data backup recently?

Are there any informational entries in the KNLDIAG file (that's where I would look first - KNLDIAG.ERR only contains really bad errors).

What's the output of 'info log' ?

regards,

Lars

[Former Member]

Hello,

here is the output of "info log":

/opt/sdb/programs/bin/dbmcli on TISYS>info log

OK

END

Name | Value

Log Mirrored = No

Log Writing = ON

Log Automatic Overwrite = OFF

Max. Size (KB) = 816280

Backup Segment Size (KB) = 136528

Used Size (KB) = 661880

Used Size (%) = 81

Not Saved (KB) = 33224

Not Saved (%) = 4

Log Since Last Data Backup (KB) = 0

Savepoints = 98898

Checkpoints = 0

Physical Reads = 47919

Physical Writes = 7720663

Queue Size (KB) = 400

Queue Overflows = 0

Group Commits = 31251

Waits for Logwriter = 7730466

Max. Waits = 29

Average Waits = 0

---

[Former Member]

...and additionally some more information about x_cons =>

dbsrv01:/opt/sdb/programs/bin # ./x_cons TISYS show active 10 6

SERVERDB: TISYS

ID UKT UNIX TASK APPL Current Timeout Region Wait

tid type pid state priority cnt try item

T112 7 -1 User 6677* Running 0 186 135412736(r)

T255 9 -1 User 6673* Running 0 0 149845105(r)

T338 10 -1 User 11895* Running 0 359 85 99626541(r)

SERVERDB: TISYS

T255 9 -1 User 2349* Vendexcl 0 442 92 140733343245585(r)

SERVERDB: TISYS

T181 8 -1 User 11897* IO Wait (R) 0 0 4 140733428884335(r)

T186 8 -1 User 2354* Vbegexcl 0 186 84 140733428884335(r)

T255 9 -1 User 2412* Running 0 16 140733343260134(r)

T338 10 -1 User 6687* Running 0 33 140733293050958(r)

SERVERDB: TISYS

T112 7 -1 User 6725* Running 0 3 140733328828002(r)

T330 10 -1 User 6738* IO Wait (R) 0 0 11 140733293071832(s)

SERVERDB: TISYS

T111 7 -1 User 6691* Command wait 180 0 0 140733328837168(r)

T184 8 -1 User 6741* Running 0 39 140733428934906(r)

T255 9 -1 User 6687* Vbegexcl 0 14 140733343294010(r)

T331 10 -1 User 6752* Running 0 155 140733293089966(r)

SERVERDB: TISYS

T184 8 -1 User 11949* Vbegexcl 120 0 71 140733428956286(r)

T255 9 -1 User 6689* Running 0 58 140733343311361(r)

T334 10 -1 User 2460* Running 0 14 140733293113703(r)

[lbreddemann]

Ok,

the x_cons output shows that you're currently not facing a LOGFULL situation - the database is still acitve.

Anyhow, for some reason the backed up log does not get marked as overwriteable.

Please try the following:

- deactivate the automatic log backup

- run a manual log backup

- run 'sql_execute force savepoint'

- check 'info log' again.

- activate the automatic log backup again

Did that change anything?

regards,

Lars

[Former Member]

Hi Lars,

you're right, we restarted the database at 90% log level

Next time we're in that situation, we'll try your suggestion. Can you provide us with the statements to perform the steps at command line, please ?

Since the database doesn't really have a problem, obviously, for me it looks like we're facing e.g. a long running transaction with huge data modifications......

a) Can we check what are the current running transactions (start timestamp, statement, ...), and how ?

b) how can we determine the tables and their size, to detect which table is involved ?

many thanks in advance...GERD...

[lbreddemann]

> you're right, we restarted the database at 90% log level

Hmm... restart out of fear and without knowing whether it would help... I'm not a big fan of that.

> Next time we're in that situation, we'll try your suggestion. Can you provide us with the statements to perform the steps at command line, please ?

I already did:

dbmcli -d <sid> -u <dbm-user>,<pw> db_execute force savepoint

> Since the database doesn't really have a problem, obviously, for me it looks like we're facing e.g. a long running transaction with huge data modifications......

To me there's nothing obvious here right now...

> a) Can we check what are the current running transactions (start timestamp, statement, ...), and how ?

Nope. With the database version you're using this is not possible.

You can however, check the currently active tasks and try to figure out what client process is attached to them. Maybe this gives an insight.

> b) how can we determine the tables and their size, to detect which table is involved ?

First of all you need to now the statement - once you know it, you also know the involved tables.

And from there on, you can just query the system tables like FILES or TABLES to get size information.

Anyhow, as already mentioned a few times, you're really running a old version of the MaxDB software.

With more current versions, there are some improvements for system analysis - so it really would be a good idea to upgrade.

regards,

Lars

[Former Member]

> Hmm... restart out of fear and without knowing whether it would help... I'm not a big fan of that.

we're also not a fan of this, but we didn't know any other solution to "clean" the log

> I already did:

>

> dbmcli -d <sid> -u <dbm-user>,<pw> db_execute force savepoint
> 

I meant all the steps, since we do not know how to enable/disable autolog and how to create a manual log backup. WeI don't want to mix using GUI and command line.

>

> > Since the database doesn't really have a problem, obviously, for me it looks like we're facing e.g. a long running transaction with huge data modifications......

>

> To me there's nothing obvious here right now...

With "obviously" I meant, that there are no (error-)messages at all regarding the increasing log

> Anyhow, as already mentioned a few times, you're really running a old version of the MaxDB software.

> With more current versions, there are some improvements for system analysis - so it really would be a good idea to upgrade.

Yes, seems like we have to.....but sounds like huge effort....

[lbreddemann]

> I meant all the steps, since we do not know how to enable/disable autolog and how to create a manual log backup. WeI don't want to mix using GUI and command line.

Don't get me wrong, but there is a thing called 'documentation'...

Anyhow, you can also do all these steps (except the 'force savepoint') via DBMGui.

Personally I find it easier to do it in dbmcli:

dbmcli -d <dbsid> -u <dbm-user>,<pw>
 -> autolog_off
 -> db_execute force savepoint
 -> util_connect
 -> backup_start <logmedium name>  LOG 
 -> util_release
 -> autolog_on <autologmedium name>

> Yes, seems like we have to.....but sounds like huge effort....

What effort do you mean?

Why not simply:

1. take a backup of the current system

2. build up a second database instance from that backup on a test server

3. run the upgrade to 7.6.06 via SDBSETUP

4. check how your application performs on the new DB version?

Doesn't look like a lot of effort to me.

The hardes part will likely be to test your application (unless you've already a bunch of unit tests available that you can just fire up and check the results.)

regards,

Lars

[Former Member]

Hi Lars,

>

> dbmcli -d <dbsid> -u <dbm-user>,<pw>
>  -> autolog_off
>  -> db_execute force savepoint
>  -> util_connect
>  -> backup_start <logmedium name>  LOG 
>  -> util_release
>  -> autolog_on <autologmedium name>
> 

thanks for this, we'll try it.

> What effort do you mean?

I remembered the effort from upgrading 7.3 to 7.5 years ago, but hopefully it will be much easier

> Why not simply:

> 1. take a backup of the current system

> 2. build up a second database instance from that backup on a test server

> 3. run the upgrade to 7.6.06 via SDBSETUP

> 4. check how your application performs on the new DB version?

Sounds good, since we installed via rpm is it as easy as:

1.) stop db

2.) upgrade rpm => rpm -U <maxdbXYZ.rpm>

3.) start db

?

Is 7.6 the recommended version, or can we also use latest 7.7 ?

regards...GERD....

[lbreddemann]

>

> > What effort do you mean?

> I remembered the effort from upgrading 7.3 to 7.5 years ago, but hopefully it will be much easier

Well.. the change from 7.3 to 7.4 or higher involved the complete restructering of the way the converter is stored to disk.

This took quite some time depending on the size of the database (thank good this was not linear due to the B*Tree structure of the converter).

Anyhow, this is not necessary when moving from 7.5 to a higher release.

The only thing that may take time after the upgrade is the first collection of file directory statistics.

> Is 7.6 the recommended version, or can we also use latest 7.7 ?

Sure, use whatever works for your application.

MaxDB 7.7 is in productive use for quite some SAP systems today.

regards,

Lars

[Former Member]

Hello Lars,

thanks for your great support.

Let me ask one last question: I searched for (opensuse 10.3 64bit-)rpm's including the latest 7.6.06.03 release, but didn't find some. At sdn I can download the .tgz only

Where can I get the rpm's for the latest 7.6 ?

regards....GERD....

[lbreddemann]

> thanks for your great support.

you're welcome.

> Let me ask one last question: I searched for (opensuse 10.3 64bit-)rpm's including the latest 7.6.06.03 release, but didn't find some. At sdn I can download the .tgz only

> Where can I get the rpm's for the latest 7.6 ?

sorry, no idea about this one.

Personally I never used the rpm method and I actually don't see a big advantage in it.

I'm also not aware about any release of the current 7.6 patches that come in that format.

regards,

Lars