on 09-17-2011 4:56 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
> 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
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
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
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.