As you know, support for version 8.3 is ending in a few months, so we are planning to upgrade to 8.4.
We have read the release notes and see that a new database must be created for Access History.
Our managers have asked why we should create this database instead of merging it into the existing one.
We believe the reason is to avoid overloading the main database, but they’re asking about the number of processes executed and the storage required, and we haven’t found information on these metrics.
Our system currently has about 60,000 active identities and typically handles around 200,000 operations on a normal day (up to 300,000 on peak days), according to the audit search.
Does anyone have guidance on these metrics or any real-world examples of the resources (storage and RAM) required for an Access History database in a similar system?
@Tommy98 IIQ created a separate database to store the comprehensive history data which was not there in primary IIQ. You should keep them separate to avoid any performance issues on your primary DB (like suggested by @robert-hails ). History DB is going to consume storage faster than your primary DB.
During initial load it requires ~10-15% storage of your primary DB. like if your primary DB is 250 GB then you roughly need 35-40 GB for identityiqah database. Then for all new events, it keep appends the data. To start with you go for 2x-3x allocation and keep observe for few weeks to provide the accurate estimation.
IIQ is using it to build the Identity Timeline which you can view in the UI. Try out the docs available in community and let us know if you stuck anywhere.
Hi @Tommy98, it uses a lot of space. We have a comparable number of active users and the history records accumulate rapidly. The average database growth is around 1 or 2 GB per day.
