on 07-20-2011 12:28 PM
We are running MaxDB 7.7.07.16 unicode in a non SAP environment (is basis for a web application).
Database Server has 4 Cpu's, 8 Gb RAM, operating system Debian-Linux 6.0.
Data Area are 2 volumes, each 20Gb size, filling is actual around 60% (24 Gb)
MaxUserTasks 200.
We encountered a problem that the database stops due to the fact that the data area was full (100%), what is in principle clear to me. So we restarted the database and the filling of the data area was 60% again.
During our analysis we get aware that the 40% of the data area (16 Gb) were filled with temporary data, we assuming resulting from the user sessions temporary data.
I didn't found much information regarding this behaviour and our possibilities to adjust some parameters regarding this issue.
My intention would be to advice MaxDB to release temporary data before reaching 100% filling of data area.
How can I prevent happening this again?
Any hints are welcome.
Best regards
Hannes
> During our analysis we get aware that the 40% of the data area (16 Gb) were filled with temporary data, we assuming resulting from the user sessions temporary data.
>
> I didn't found much information regarding this behaviour and our possibilities to adjust some parameters regarding this issue.
> My intention would be to advice MaxDB to release temporary data before reaching 100% filling of data area.
Hello Hannes,
in fact there isn't much so setup or tune here.
The temp. pages required to execute queries will always be automatically removed after the cursor is closed or the command was aborted. With 7.7 and before this unfortunately can take very long times due to the single-block-access-through-the-data-buffer implementation that was used for releasing the temp pages.
However, in case the DB runs full because of temp. page allocation the statement that wanted to allocate more pages will be cancelled and the already allocated pages will be released ... one by one
This has been improved with the most current release of 7.8.
Anyhow, if you regularly see that much temp. space allocated, I highly recommend to review your execution paths - looks like there are too many intermediate result sets beeing build.
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,
Automatic log area should be enabled to avoid these issues.Please check whether automatic logging is enabled in your scenario. If it is not enabled than you need to take the complete backup of your DB using DBMGUI/DBMCLI after you will be able to enable automatic logging.
Regards,
Sahil
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
> Automatic log area should be enabled to avoid these issues.Please check whether automatic logging is enabled in your scenario. If it is not enabled than you need to take the complete backup of your DB using DBMGUI/DBMCLI after you will be able to enable automatic logging.
Automatic log backup and temporary data have NOTHING to do with each other.
Sorry, but this is just not correct.
regards,
Lars
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.