HP TIM 7.1.2 2017 - Document store reporting the usage size incorrectly
A few weeks ago our TRIM admins decided to save many records of the large size (20 - 50 Mb each) in TRIM. For that they switched the document store (CS1) for a particular record type to a different document store (DS2), for a few days. At the end they switched that record type's Doc store (DS2) back to the original one (DS1). Some time later they noticed a sudden drop in the Usage reported by TRIM for the DS1, which, instead of reporting 85% used and total of over 1 000 000 documents, reported only 23% used and 230 000 documents . The physical disk usage on the server, where DS1 is configured, shows the capacity used about 85 - 85%, with the total number of documents, actuaklly stored on the disk - which is about right.
I ran the Integrity check on both stores andit did not report any significant errors. I tried opening the documents, which might have been put in TRIM during that time, and they open Ok. The audit logs don't show anything suspisious.
Has anyone come across this or similar issue? Does TRIM calculate the capacity used for a doc store, by looking at the records that have that store's id as saved in the database?
Re: HP TIM 7.1.2 2017 - Document store reporting the usage size incorrectly
There is no particular solution to the issue. The following was the reply from HP to me asking about what was the tell-tail in the log...
This line told me straight away that it wasn’t reading the File share correctly:
Error : TS User: AUSYDAPD10 - Workgroup Error. Document store operation failed - the Document Store has insufficient capacity.
I have seen similar errors in different applications and back to my IT Engineer days, it was an error that came up from time to time. From what I have learnt it’s a Microsoft thing, the system misreads the directory size and generally stuffs it up so any application querying the Operating System gets the wrong information, the bad news is the only fix I have seen that works is to reformat if it’s a physical drive and with a virtual, recreate the virtual machine as there is a double whammy with a virtual, it could be the Operating System or the Virtual Software that is causing the problem. Now that we have identified the problem, you will just need to work around that share and that should be OK.
I would log a call with HP so at least they have an idea of the frequency of the occurrence or, if you are lucky, there might be a fix now....