Hi,
I have a DB that was 70MB with 20,000 docs in it. I created an archive copy of the DB, and archived over 19,000 of these docs to it.
The weird thing is, despite compacting all DB’s (only through the client workspace though) I find that the live app is still 60MB, whereas the archive is only 38MB.
Really, as the app started out around 15MB with no docs, I expected it to go back to near this size. I don’t understand why the size isn’t reduced more?
Please help, as i’m no Notes Administrator, and my actual Notes Administrator is a real, real newbie…
Subject: DB Size not reducing after archiving docs…
Lee, Check your archive settings. Go to Actions/Archive/Settings/Advanced and make sure to remove the check mark in the box that says “do not delete documents that have responses”. If this is checked your documents are archived but they are not deleted if they have a response. Consequently you database size does not decrease very much after archiving.
Subject: RE: DB Size not reducing after archiving docs…
Thanks guys.
My DB doesn’t have response docs, so that isn’t the problem.
I’ve run the Compact function from a view in the Notes Administrator client, is that the same as the compact function that’s automatically run on the server overnight?
I’ve just checked again today, and the 2 copies with 2000 docs in are still around 62MB, and the copy with 18,000 docs is 36MB…
Thanks for the suggestions so far.
Subject: RE: DB Size not reducing after archiving docs…
Thanks a lot Haydn, that makes a lot of sense.
Can I just ask for clarification though - I have two replicas on our server (a main replica which is used to replicate to our stores, and a replica which allows Head Office staff to use the app directly).
To remove the deletion stubs without causing any other problems, do I need to check the box?
We create a new set of documents each week (usually Tuesday), then export the data (usually the following Monday) then archive them to another DB (on the Monday) and remove them from the main DB’s. We then start the whole process again on Tuesday. So our archive DB holds everything except the current week’s data, this keeps our replication time with the stores at a reasonable amount, whilst maintaining all the data in a copy of the DB here in Head Office.
Basically, we should only ever have documents from the last 7 days in the DB, and it’s only the deletion stubs remaining that are causing the problem.
Should I then check the box and choose, say 7 days? Would this mean that the deletion stubs would go after 7 days?
How can I set the DB to just purge the deletion stubs immediately, and avoid this “remove docs not modified” option altogether?
Sorry if i’m being stupid but i’m just not entirely clear on the best course of action…It seems like checking this box does more than I want.
Subject: RE: DB Size not reducing after archiving docs…
Firstly, as you’re replicating be careful. 1. What happens if you clear stubs before they have replicated? Then the docs won’t be deleted in remote replicas and, in fact, will be replicated back into the main db. The well known phenomena of ‘reappearing documents’.
- If you delete the stubs after all dbs have replicated, then you will have to clear them in all replicas or they will just replicate back the next time around.
Its best to just reduce the period and let notes do the rest.
Deletion stubs are cleared periodically. The period is 1/3 of the setting in the replication parameters. i.e. with default 90 days 30 days worth are cleared every 30 days so you have 60 days of stubs hanging around. The period should be set so that you are sure no stubs will be cleared before all dbs have replicated so, if you replicate daily, a setting of say 3 would theoretically be sufficient but you should allow for any problems caused by a server being down for longer periods.
Checking the box will cause notes to delete documents automatically. As you are already archiving yourself you don’t need that facility and it won’t help as it still leaves deletion stubs. You only have to change the number to something reasonable.
“How can I set the DB to just purge the deletion stubs immediately”
You would set the number to 0 but as I said you can’t do that if you’re replicating. Notes needs the stubs to update remote replicas. You can only reduce the length of time for which they are held.
Subject: RE: DB Size not reducing after archiving docs…
Hi Haydn, thanks for taking the time for a detailed reply.
I’ve read the Help, and I understand what your saying, but I think where i’m unclear now is that, if I don’t check the box where am I setting this time period to clear the deletion stubs?
The checkbox field has a number of days associated with it - which is 7 at the moment - is this the field which is supposed to default to 90 or am I looking in the wrong place?
Basically, I want to set the Properties to remove the deletion stubs roughly every 2-3 days ( as you’ve suggested ), as i’ll know if there are any replication issues well before this happens, but i’m not clear where I set this value. If it is the field i’ve mentioned, does that mean it’s still applicable if I don’t check the box too?
I’m sorry to keep asking questions, but I think i’m almost there!
Subject: RE: DB Size not reducing after archiving docs…
As I said in the post I linked you to, its a bit confusing. The number to the right of the checkbox has TWO functions. If you check the box it controls how often DOCUMENTS are auto deleted. But whether you check the box or not it ALSO controls how often STUBS are cleared, as I’ve explained.If that number is at 7 already then its probably at the lowest safe value and there shouldn’t be that many stubs left. Its possible that you have a different problem.
There was a tool called notespeek for R4/5 which showed you exactly how many docs/stubs e.t.c were in a db. I believe there is some alternative for R6. If you search on notespeak you should be able to find it. It would be advisable to find out exactly whats in the db and whether the no. of stubs is much greater than you would expect.
As a quick test I would make a local replic copy of the db, use shift f9 to ensure all views are build, set that number to 0 and compact. If the db is then still too large, the problem lies elsewhere.
Subject: DB Size not reducing after archiving docs…
Choosing compact from the client workspace does not reduce the database size. The compact must be done by the administrator - or there might already be a nightly program scheduled to compact databases with file size reduction.