It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×11,927
×10,908
×4,692

question asked: Feb 09 '17, 5:14 a.m.
question was seen: 2,628 times
last updated: Mar 05 '17, 10:10 p.m.

Related questions

FAQ - How this Forum works

RQM: When doing DB2 incremental Backup, why does db2pd show 'dirty' even when the server had no activity at all?

0
George Harada (32●2●13) | asked Feb 09 '17, 5:14 a.m.
edited Feb 13 '17, 12:05 p.m. by Muralidhar Rajagopal (101●1●4)

The customer is using incremental backup for CLM.
They are seeing that the backup file size for RQM is as large as when doing a full backup.
We understand this precondition:
• If a table space contains long field or large object data and an incremental backup is taken, all of the long field or large object data will be copied into the backup image if any of the pages in that table space have been modified since the previous backup.
• If you take an incremental backup of a table space that contains a dirty page (that is, a page that contains data that has been changed but has not yet been written to disk) then all large object data is backed up. Normal data is backed up only if it has changed.

However the customer has set aside a full weekend for when they have not touched their clm server at all.
Yet, after using the command db2pd -tablespaces, they have noticed that the values were 'dirty' for all tables after a day, indicating there were some changes.

There is a similar question for ccm here:
https://jazz.net/forum/questions/125614/size-of-db2-incremental-backup-seems-to-be-too-big-for-no-activity-ccm-database

Escalation Questions:
Is there a reason for all table turning 'dirty'? Where/how do these changes take place?
Is it possible to prevent this change? Because with it we cannot perform the incremental backup effectively.

2 answers

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
Frank McGrath (242●1●6●2) | answered Feb 24 '17, 6:09 p.m.
JAZZ DEVELOPER
I am not an expert on DB2 management, but here are some thoughts.   I believe when you are reporting on a table space being dirty, it is asking if there are any pages at all associated with the table space that are dirty.  This document talks about dirty pages: https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.perf.doc/doc/c0005393.html

There is a command you can use to see how many dirty pages there are:

db2pd -db <yourdb> -dirtypages summary

So for example on my test this shows 
   Dirty pages %       : 135 / 1000 (13.50% dirty)

You can leave off the summary to see all the dirty pages:
db2pd -db <yourdb> -dirtypages

On my DB the primary table space for QM artifacts (CONTENTTS) is id 3. 
The second column in the non-summary dirty pages output is the table space ID.
I ran this command to ask how many of the dirty pages are from that tablespace:

db2pd -db <yourdb> -dirtypages | grep "^\d\s3" | wc
and the answer was 66 (about half of the 135 dirty pages). 

I disconnected all clients from my db, stopped it and started it, and then checked the dirty pages.  There were 2. 

 

Comments
George Harada commented Mar 05 '17, 10:09 p.m.

Hi Frank,
Thank you for your response. This idea about getting more information about the 'dirty' pages is very useful. Thank you for the link as well.

0
permanent link
George Harada (32●2●13) | answered Mar 05 '17, 10:10 p.m.

I got an answer from one of the RTC developers and thought I'd share, as below:

For a running server DB is always being written. Even if you do not login or do anything.
There are several tasks that are executed in the background at regular interval that are constantly changing DB tables. Specially  ITEM_CURRENTS, ITEM_STATES, CONTENTS.
And in case there are automated processes associated to the server then other query tables for example results  for executions , builds , etc etc are going to be updated when server is not used by any formal user.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.