it's strongly recommended. For a certain load it becomes absolutely necessary. The problem is that your database license doesn't support partitioning.
What partitioning tries to solve is that the daily clean-up task (by default scheduled to run at 02:00 AM) has to delete a lot of records after aggregating them, and this gets very cumbersome as the size of the installation increases. As the clean-up task runs into the business hours (we've seen it running for 15+ hours at large sites), it impacts the writing performance for the db up to a point where you'll lose data.
With partitioning enabled we'd just be dropping a partition per day, no need for expensive DELETEs.
Once you observe that your clean-up task runs for more than 8 hours or so, please consider upgrading to an enterprise edition license, if possible. Best regards,
I'll have limited access to the mail till November 2th, I'll reply you as soon as possible.
Je suis en client avec accès limité au courrier jusqu’au 2 Novembre. Je vous répondrai le plus tôt possible.
Tendré acceso limitado al correo hasta el 2 de Noviembre. Responderé a sus correos lo más pronto que me sea posible
I'm planning partitioning of my client's AppMon PWH and have everything set for the actual work. Just one crucial question.... The client has opted for a High Res data retention period of 2 months (currently; fairly low throughput environment). How many days should I specify for the "high_retention_time()" function? The number of days per month differs, as you must know, so the value could be 59 for Jan/Feb (non-leap years) or 62 for Jul/Aug or 61 for May/Jun.
Have you dealt with this scenario before? Which value will be the appropriate one to use?
"2 months" means exactly 60 days for this pourpose in our product. The exact value in milliseconds is stored in the repository.config.xml file in the .../server/conf folder. Best regards,