cancel
Showing results for 
Search instead for 
Did you mean: 

Problem MAXDB TEMP Data Area full

Former Member
0 Kudos

Hi.

I have a Probelm with MaxDB 7.8.01.18 under Netweaver 7.01 ABAP SAP BW

19 Datavolume with 20GB

Uses Space 120 GB

Cache Size 20GB

Total Memory 24 GB

2 Log Volume with 2 GB

If I run a process chain i have more the 100 GB Data on MAXDB TEMP Area and the Size increase more an more until my DB ist full an stopped.

How can I reduce or clean the TEMP Area of MAXDB during my Process chain?

Is ther any parameter or job to control the TEMP Area?

Thanks for Help.

Regards

Sven

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello,

I don't think there is any TEMP area or temp tablespace concept in MaxDB (as we have in Oracle).

Total free space in database is the space which would be utilized for all these TEMP related work or you say process chains.

I would like to wait for our colleagues here to help us more in this.

Thanks

Former Member
0 Kudos

Thanks for your reply. I agree that MAXDB runs different as an ORACLE DB.

Ill wait for your colleagues.

Thanks

Sven

Answers (1)

Answers (1)

lbreddemann
Active Contributor
0 Kudos

Hello Sven,

it's not necessary to manually trigger the removal of temp. pages in MaxDB.

This will be done by the user task that created these pages automatically.

Unfortunately the handling of these pages is not very efficient at all (only one single task removes these pages, no prefetching used for that until 7.08.02, removal is not not done in background but user session has to wait for it).

So, when running BW on MaxDB it can become important to try to to keep the temp area usage low.

This can be done by splitting DTPs into multiple smaller ones and by avoiding semantical groups (which would lead to sorting of intermediate result sets and thus to additional temp page usage).

I guess you can well remember the support message from may we worked on together and where we reduced the total runtime from far beyond 16 hours to 1.5 hours

If you really got the impression that the temp. pages are never released until you restart the instance then I would recommend to open a new message to have this investigated!

The designed behaviour is to have the temp. pages removed, one-by-one/slow-by-slow but still released.

regards

Lars

Former Member
0 Kudos

Hi Lars.

Thanks for You Reply. I remeber the Steps to solve the last problem with your assistance. (its the same DB and the same Project )

Now I restart the hole Machine last nigth and run the Process chain again with success.

But the TEMP Area full with 60 GB. Nothing will removed.

The Performance of the the chain are OK. Rund each DTP with 8 processes step by step.

We have two chains with full load because there are no time stamps in my source systeme and i cant change this to delta load.

For sure! The TEMP pages are released only until a restart of Database.

So Ill open a new Ticket to SAP.

Regards,

Sven

lbreddemann
Active Contributor
0 Kudos

> For sure! The TEMP pages are released only until a restart of Database.

>

> So Ill open a new Ticket to SAP.

> Sven

Hmm... interesting.

While you're waiting for the final analysis by the MaxDB support colleagues, you may have a look at the DBAnalyzer detail protocols "DBAN_FILLING"

Keep an eye on "TempUsed" - does it change up and down over time or does it only increase?

best regards,

Lars

Former Member
0 Kudos

Hi Lars.

Temp Area increase permanently and its decrease only 1 ore 2 GB while the process chain running on different DTPs.

Ill take a look to the Analyzer and let you know what DBAN_FILLING says.

Regards

Sven

Former Member
0 Kudos

Hi Lars.

This is the result of DBAN_FILLING during runs the process chain.

Temp Area 70 GB

Regards

Sven

DB_VolUsedSize PermUsed TempUsed

used database size on data volumes Permantly used memory Temporary used memory

P A P A P A

17616957 15130916 4096955

17500320 15185911 4119474

18156956 15210497 4584014

18251946 15106430 4689913

18501739 15130724 4941587

18861387 14958480 5236749

19468866 15109181 5629862

19802050 15117643 5456310

19812964 15138514 5456317

19861094 15067578 5665983

19736822 14914737 5671488

19910612 14901888 5485783

19865817 14914267 5551461

19871361 14922729 5684893

20284227 15062722 6268142

20682408 15052069 6434656

20987960 15319223 6924018

20931158 15240625 6706960

21701345 15428438 7095378

21450298 14881214 7054690

21626884 14900774 7445458

21877093 15128514 7772957

21877076 15128514 7772935

21877076 15128514 7772935

21877077 15128515 7772936

21877078 15128516 7772937

21877079 15128517 7772937

21877079 15128517 7772937

21877085 15128523 7772938

21877085 15128543 7774707

21877200 15128641 7774304

21877203 15128641 7774302

21877208 15128647 7774304

21877209 15128647 7774305

21877209 15128647 7774305

21877210 15128648 7774305

21877217 15157718 7774328

21948077 15152186 7859057

22341685 15265710 8703824

22651825 15193273 8874405

lbreddemann
Active Contributor
0 Kudos

Hmpf - ok, time to open a support message!

regards,

Lars

Former Member
0 Kudos

OK Lars. Ill open the Ticket.

Thanks for your assistance.

Regards,

Sven

Former Member
0 Kudos

Hi Lars.

Problem solved by SAP Support. The Command Monitoring was aktiv and add Information to table COMMANDMONITORPARAMETERS.

The Monitoring dont switch off automatically when I restart the System with my Release of MAXDB.

Regards,

Sven

lbreddemann
Active Contributor
0 Kudos

Hi Sven,

thanks for the update in the forum.

As I've seen you got the answer and the workaround directly from the developer of the MaxDB optimizer

For the other readers in this forum:

The problem here was that the COMMANMONITOR was set to keep data for statements that touch more than 1000 pages, which regularly happens in BW systems.

As of MaxDB 7.8 the command monitor setting is kept even after a restart of the database and thus the temp pages had been allocated again also after bouncing the instance.

This behavior will be changed back with MaxDB 7.8.02 Build 26 onwards - so a restart of the instance will reset the monitor settings again.

best regards,

Lars