Hi Team,
my question is regarding migration in pulse.
as i m aware we can increase the element size for migration in cfg file of pulse, but i would like to know the ideal maximum limit we can increase without compromising pulse performance?
similarly i also want to know the maximum cube size with data , withour compromising pulse performance?
as once i migrated a cube of 330GB it crashed pulse.
so just want to know what is the ideal maximum size for cube?
We can’t provide an exact size limit for cubes or dimensions that can be migrated with Pulse, as it depends on several factors—such as whether Pulse is already handling other tasks, speed of the network or if it has sufficient memory available. In theory, there’s no hard limit, but based on your experience, attempting a live migration of something as large as 330 GB is generally too much.
That said, we can share some best practices for migrating large dimensions and cubes using Pulse.
As outlined in this article: Migrating Dimensions Live with Pulse for TM1, the most efficient way to migrate a large dimension or cube is to have Pulse execute a process. This approach allows Pulse to first create an empty object, and then run a process to populate the dimension or load the data—resulting in a faster and more reliable migration.
thanks Vincent for such a quick reply.
but, it would be great if it has some clear numbers so we could demarcate properly which cubes we can migrate.
but can you help me with the maximum element limit we can set as currently it is 5000 but as Mohmmad Eissa suggested we can increase that limit .it would be great if you could suggest some limit on the element.
There is no fixed limit—similar to when we’re asked how much data Pulse can store. While Pulse can handle large volumes of data, the more you store, the more memory it will require.
This also applies to migrations. As a general best practice, it’s recommended to use a process to update dimensions and cubes, rather than relying on live migration.
Pulse crashing is extremely rare. Since you experienced a crash, it’s important to open a support ticket to investigate the cause. It might simply be a matter of increasing memory allocation. For example, migrating a 330 GB cube will be significantly faster and more stable if done through a process, rather than attempting a live migration of that volume.