Performance arsdoc delete / arsadmin unload

[ewirtz]

Hi,
we use 'arsdoc delete' to delete documents and 'arsadmin unload' to delete complete loads. This works fine. If a lot of index entries have to be deleted the performance is very slow. A delete of 1000 documents ('arsdoc delete') was done in 10 minutes.
A PMR was opened for 'arsdoc delete' and 'arsadmin unload'. The 'arsadmin unload' PMR is closed, the 'arsdoc delete'  PMR is still open. When closing the 'arsadmin unload' PMR an enhancement request was opened, which is rejected.

Does anybody has similar Problems with  'arsdoc delete' and 'arsadmin unload' in case of many rows in the Application group data table
or does nobody is deleting many rows?

regards

Egon

[GlendaRegpala]

Hi Egon,

I perform the unload from the Admin Client and it completes almost instantly.  Then the 'arsdoc delete', we seldom use but I recently ran it for less than 200 items and it took 10 seconds per document ... so it's even much worse than your experience.   I used a parameter file input and each entry on the file input results to only one document (I used a very strict condition such that it won't delete more items than intended).   Since this was a very unusual task that we do, and we don't have very many items to delete,  I didn't bother to open a PMR.    I'll be concerned too if I need to delete thousands of records.   

Also, I ran 'arsdoc query' prior to my 'arsdoc delete' and I got very close response times.

Glenda 

[ewirtz]

Hi Glenda,

the problem occurs whenever a lot of entries have to be deleted in the 'Application group data table'.

I can tell you a simple business case.

You are printing statements every day by generating one AFP file. After ten years you are gonig to delete them. In germany retention logic forces to delete after ten years at the of the year (legal requirement). This implies that you have to delete all statements of one year in one delete process.

regards

Egon

[Alessandro Perucchi]

Hello Egon,

just one info, "ardoc delete" deletes only indexes, not the document behind in the object server.
Either the object server is configured to delete document automagically after X years, or it won't delete them.

So if you are legally bounded to delete documents (as we are in Switzerland), then arsdoc delete won't do the trick because technically the document is still somewhere, not easily accessible, but still there.

Sincerely yours,
Alessandro

[ewirtz]

Hello Alessandro,

I know this. So the question is whether it's anough to have no supported way to find deleted documents. The arsdoc delete does make only sense if the whole load must not be deleted.

regards

Egon

[GlendaRegpala]

Hi Egon,

We also have a similar requirement for document retention.   The way we handled that was to set the expiration for the Application Group to 10 years.      Since all the documents that were loaded on the same day would be expiring at the same time, there is no need to pick out specific items within a 'load'.   The whole 'load' gets unloaded, I believe during ARSMAINT run.

I'm not aware of any other supported way to delete individual items aside from 'arsdoc delete'.   There is an OnDemand Toolbox out there, but I haven't been successful getting it to work.   IBM doesn't support that product, it is provided 'as is'. 

Glenda

[ewirtz]

Hi Glenda,
if you have a retention period of one year beginning with the end of the year you have the following situation.
All ducuments loaded in 2010 are allowed and have to be deleted at the beginning of year 2012. This cannot be done with an 'out of the box' solution. This is true as well for enhanced retention management. You would have to do a lot of 'hold and release programming'.

regards

Egon

[ojoerge1]

Hi
We have a possible connected problem, running ARSDOC GET with pretty slow performance using the 8.5.0.6 or -5 version of ARSDOC.  Running the 8.4.1.7 version of ARSDOC GET, it runs pretty fine.  This problem of performance for the 8.5.0.6 has been reported, and the PMR is assigned to Developement, and has been for some weeks now.
Regs Ole