Too much space in DB XMETA db2
Moderators: chulett, rschirm, roy
Too much space in DB XMETA db2
I request your help in the next issue,
I have the db2 XMETA database with 164 gb that after setting up projects with RTLogging = 1 is kept growing and kept the following weight
./T0000002 1.2G
./T0000003 162g
./T0000004/C0000000.TMP 8.0K
./T0000004 12K
./T0000001/C0000000.TMP 8.0K
./T0000001 12K
./T0000005 33M
./T0000000 97m
./T0000006/C0000000.UTM 8.0K
./T0000006 12K
164g.
I believe it is too much space and ask me to release, try to reduce the log space by deleting the table LOGGING_XMETAGEN_LOGGINGEVENT1466CB5F that was about 30 million records and decreased only 5 GB.
Please if you know something should be done to free up more space I would greatly appreciate it.
Thanks!
I have the db2 XMETA database with 164 gb that after setting up projects with RTLogging = 1 is kept growing and kept the following weight
./T0000002 1.2G
./T0000003 162g
./T0000004/C0000000.TMP 8.0K
./T0000004 12K
./T0000001/C0000000.TMP 8.0K
./T0000001 12K
./T0000005 33M
./T0000000 97m
./T0000006/C0000000.UTM 8.0K
./T0000006 12K
164g.
I believe it is too much space and ask me to release, try to reduce the log space by deleting the table LOGGING_XMETAGEN_LOGGINGEVENT1466CB5F that was about 30 million records and decreased only 5 GB.
Please if you know something should be done to free up more space I would greatly appreciate it.
Thanks!
I wouldn't try cleaning up space directly in XMETA unless I was certain what I was doing. Perhaps you could set a project purge for x-job runs or x-days; this will go a long way in keeping XMETA smaller (another option would be to switch logging back to the hashed files).
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
I already configured all projects to only record the last five runs and did not reduce space, also the log also not stored in XMETAArndW wrote:I wouldn't try cleaning up space directly in XMETA unless I was certain what I was doing. Perhaps you could set a project purge for x-job runs or x-days; this will go a long way in keeping XMETA small ...
Did you also set ORLogging = 0? The logs are not purged immediately after making the setting change, but only upon the next run, so it might take some time for the logs to be pruned down to size after specifying purge settings.
The size really is quite large. Do you have QS or any other add-ons in use?
The size really is quite large. Do you have QS or any other add-ons in use?
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
Yes, is configured with ORLogging = 0, and the change was made three weeks ago and space don't moved.ArndW wrote:Did you also set ORLogging = 0? The logs are not purged immediately after making the setting change, but only upon the next run, so it might take some time for the logs to be pruned down to size after ...
Just changing the two settings in the DSParams won't clear the XMETA space. I am not savvy enough with the XMETA tables to start clearing them, but perhaps you might be able to switch the logging back to XMETA, (re)set project level autopurge and run all your jobs or manually clear the logs from the director and then, once you've cleaned up, switch back logging.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
I didn't know that existed - thanks! But the OP still needs to redirect logging back to XMETA before executing the command.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Premium Member
- Posts: 425
- Joined: Sat Nov 19, 2005 9:26 am
- Location: New York City
- Contact:
Serices,
The scheduled task delete a 1000 entries at a time and run every 30 minutes. It will loop until all the DataStage entries are purged ... so wait a bit and it will clear your old logs and your database size will decrease ..
If you want just increase the number of entries to be deleted each time to speed up the process
The scheduled task delete a 1000 entries at a time and run every 30 minutes. It will loop until all the DataStage entries are purged ... so wait a bit and it will clear your old logs and your database size will decrease ..
If you want just increase the number of entries to be deleted each time to speed up the process
Julio Rodriguez
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses
ETL Developer by choice
"Sure we have lots of reasons for being rude - But no excuses
ok, I'll wait until tomorrow, and tell them if they kept the size.JRodriguez wrote:Serices,
The scheduled task delete a 1000 entries at a time and run every 30 minutes. It will loop until all the DataStage entries are purged ... so wait a bit and it will clear your old logs and your database size will decrease ..
If you want just increase the number of entries to be deleted each time to speed up the process
Just a thought...
Once all of settings suggested by ArndW and JRodriguez have been implemented, wouldn't recompiling clear the logs? That is what happens when I recompile my Server stuff. Just wondering...
Bestest!
John Miceli
System Specialist, MCP, MCDBA
Berkley Technology Services
"Good Morning. This is God. I will be handling all your problems today. I will not need your help. So have a great day!"
John Miceli
System Specialist, MCP, MCDBA
Berkley Technology Services
"Good Morning. This is God. I will be handling all your problems today. I will not need your help. So have a great day!"
Re: Just a thought...
It is not necessary to compile but it is necessary to restart the DataStage servicesjdmiceli wrote:Once all of settings suggested by ArndW and JRodriguez have been implemented, wouldn't recompiling clear the logs? That is what happens when I recompile my Server stuff. Just wondering...
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Clearing the logs does not relinquish automatically allocated table space. There are DB2 utilities for recovering table space. (Ask your DB2 DBA which are the preferred utilities at your site.)
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.