Highlighted
Morrissey Super Contributor.
Super Contributor.
982 views

Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

I know its an old chestnut, but can anyone advise if they stick to the recommendation / guideline by HP, to limit the number of documents contained within a standard container, to 300 records? Is 300 a number that is an absolute, must-do limit, in accordance with the warning of degradation of response time during navigation within containers

See attached snippet from the Specs document for HPRM 8.1.7919:

0 Likes
1 Solution

Accepted Solutions
Harry-Koppanyi Outstanding Contributor.
Outstanding Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

Carol, one of the env (pre-upgrade) had similar issue when TRIM 7.3 was running lower spec machines and there were not much resources given to the Databases Server for processing. Can you share your machine resources where you have this issue?

In my case, it was Windows 2008 R2 and SQL Server 2008 R2 (base release) with 2 CPU dual core, 8GB RAM for the database. Database server machine had 1 Disk allocated to the database and everything was running from there including the backups . Database was poorly installed with out of the box database Creation and no parameters were setup for performance with very small block size. On the Workgroup sever itself it was only 1 disk which was also hosting some File Share for Document Queues from other systems. To give you an example of the lack of resources, Customer even could not change the Location from one to another for few hundreds of records  it was failing /crashing it all the time. Since the upgrade and properly configured system, these issues are not faced any more and system is very smooth.


Cheers,
Harry
7 Replies
Harry-Koppanyi Outstanding Contributor.
Outstanding Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

(This post reply is purely based on my personal observation and approach to design and use HPRM as a Transactional engine which many traditional functional RM specialist may have different opinion).

The limit of these 300 documents per container is legacy in nature when SQLServer database was its initial data volumes and lack of robust architecture what we have today in 2012 and 2016 versions. The limit was imposed due to retention calculations and updating the relational tables etc which was indeed a challenge in early SQLServer releases. However with modern database architecture to manage thousands of transactions per second and faster hardware resources available these limits can be safely overridden by properly design your RM Records type - Container layout for high volume data storage.  There may be triggers on certain tables but thats can be compensated and kept in consideration while you design the RM architecture.

One of the things which I encourage in my designs is Alternate Folder Concept which provides users full feature of drill down folder approach however at backend still stands as standalone folder. I have folders holding range of 3000 - 18000 records mix  of Engineering Drawings and some other folders holding even IoT related sensor data xml, docx and pdf (size range of 250Kb - 2M) with count of about 16000 records per month for last 6 months. Search results on these files are mostly under 5 sec. So from my obersations these limits did not effect my design or usage at all. As I mentionde above that its all about the usage and implementation architecture design and layout how RM is implemented and what machine resources are in use.


Cheers,
Harry
hafizah
New Member.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

Hi Harry,

can you share trim version you are using, sql db version, server version and all that.

thank you. 

0 Likes
Harry-Koppanyi Outstanding Contributor.
Outstanding Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

The settings I mentioned are running on the following (different env)

2x Citrix Xen Server 6.5 - 4 CPU quad core Hosting 2 Machines Each with 24 GB - 4x1GB NIC Bonded

Windows 2012 R2 - Latest Updates - HPE RM8.3 Patch 3, SQLServer 2012 SP2 Jul-Aug16 Patchlevel., TRIMBocX 2013 suite (our own SharePoint 2013 - HP RM integration Appliance)

-------------------------

3x Citrix Xen Server 6.5 - 6 CPU x6core Hosting 4 machines each with 16 GB machines 8x1GB NIC Bonded

Windows 2012 R2 - Latest Updates - HPE RM8.3 Patch 3, SQLServer 2016 Jul-Aug16 Patchlevel., TRIMBocX 2016 suite (our own SharePoint 2016 - HP RM integration Appliance)

This environment also pushes and sync Information & Records including documents with Azure Cloud HPE RM 8.3 (small pilot) and SharePoint Online O365 ( publishing and sync from RM only)

-----------------------

For HPE CM 9 Pilot I have similar specs as of 3x Citrix defined above, the difference is RM is spread across two different locations and replicating to Azure in real time along SharePoint 2016 integrated with HP TRIM 7.35, HP RM 8.3 and RM 9 simulating Migration , Consolidation  env based on customer's different business untis which used to be different Org before consolidations.

Customer provided Vmware 5.5 - dont have exact Hware specs 

Windows 2008 R2 - Nov 14 Updates - HPE RM8.01 Patch 3, SQLServer 2008 R2  SP2 Patched

They only had about 1000-2000 records per folder however leveraged on Alternative Within feature.

In all my instances Windows servers, Files systems, SAN, Networks, Databases, IIS and highly tuned for performance and then RM structure layout for optimal use. If you have specific question I will be happy to  answer.


Cheers,
Harry
Carol Collins Honored Contributor.
Honored Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

I agree with Harry.  It has been our experience that, at this point in HPE RM development, almost everything works fine with many more than 300 documents in a container.  And, it is easier on the users, since the concept of container parts and related concepts / limitations can be confusing. 

I would like to add one thing, though I can't verify whether this is still an issue in version 8 and above.  In previous versions, there were problems with destruction of folders containing more than 300 documents.  So, our destruction process has been to move records into a folder containing 300 or fewer, and then destroying that folder.

--Carol

Morrissey Super Contributor.
Super Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

Hi Carol - would it be possible for you to expand on that issue you were describing in regard to the issue of destroying records in folders containing in excess of 300 documents, and the process you use to circumvent the possible problem? The method you mentioned (moving documents around) seems like a major overhead when an Archving officer is processing hundreds of records at a time. 

* (to all subscribers)  Has anyone else experienced this and or tested it or reported it to HP ?

Thanks

0 Likes
Carol Collins Honored Contributor.
Honored Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

We last attempted to destroy more than 300 records about 5 months ago, under TRIM V7.3.4.  I had to look back through some old emails to recall what happened.  The destruction process apparently did not complete, although there was no obvious indication that it did not.  A spot check of records within the container showed that the electronic document had been removed, but the record status was not changed to destroyed.  An attempt to view the record would throw an error (I no longer have the text of it), which, of course, is not the normal behavior of a correctly destroyed record.

Our process is to create a container (with a high enough level to contain other containers, if necessary), move no more than 300 records into it, and perform the destruction on the container itself.  We title the container appropriately beforehand, e.g. with "Destroyed", the date, and a general description of contents.  Note that, once destroyed, you cannot change the title of the container.

I hope this helps. 

--Carol

 

For us, it's a bit more of a hassle, but not really a major overhead.

Harry-Koppanyi Outstanding Contributor.
Outstanding Contributor.

Re: Contained Documents Limit - 300 as recommended in the HPRM Limitations document

Jump to solution

Carol, one of the env (pre-upgrade) had similar issue when TRIM 7.3 was running lower spec machines and there were not much resources given to the Databases Server for processing. Can you share your machine resources where you have this issue?

In my case, it was Windows 2008 R2 and SQL Server 2008 R2 (base release) with 2 CPU dual core, 8GB RAM for the database. Database server machine had 1 Disk allocated to the database and everything was running from there including the backups . Database was poorly installed with out of the box database Creation and no parameters were setup for performance with very small block size. On the Workgroup sever itself it was only 1 disk which was also hosting some File Share for Document Queues from other systems. To give you an example of the lack of resources, Customer even could not change the Location from one to another for few hundreds of records  it was failing /crashing it all the time. Since the upgrade and properly configured system, these issues are not faced any more and system is very smooth.


Cheers,
Harry
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.