Hi,
I am a bit confused by looking at the no. of records. You mentioned 2 million a month, i.e. 24 million a year. If I divide the total no. records (2,250 million = 2.25 billion) by 24 million yearly, then you should have a history of almost 94 years. Can you please confirm these figures?
Anyway, taking the total no. of records as the baseline, your InfoCube becomes unmanageable from a data volume point of view. I strongly recommend to also use Logical Partitioning (i.e. splitting up one InfoProvider into multiple InfoProviders). Please consider using the SPO (Semantically Partitioned Object functionality). Please refer to my blog series Pattern-based Partitioning using the SPO BAdI - Part 1: Introduction for more information.
Data volume recommendations are dependent on the underlying database. I heart in the past recommendations like 100 million for MS SQL Server and 300 million for Oracle and DB2. I expect that higher data volumes will not lead to problems but you should avoid a single InfoProvider with a billion records. It is also not scalable, it can and will only increase.
Logical Partitioning based on year (calendar year or fiscal year) is often a practical way to make the data storage of your InfoProviders scalable.
Logical Partitioning can be combined with database partitioning (a.k.a. physical partitioning). This is dependent on the underlying database. It will split up the fact table of the InfoCube into multiple partitions. Often calendar month or fiscal month are used for this purpose.
Re. repartitioning, I suggest to do it the manual way, considering the data volume and my recommendation to introduce Logical Partitioning. I.e. moving to an SPO-based InfoCube (with database partitioning) and reloading the various PartProviders (e.g. yearly time slices).
Best regards,
Sander