Replicating cubes
You can replicate cubes from one IBM®
TM1® server to another, and synchronize the updates across the
copied cubes. Depending on your access privileges, you can copy cubes (and their associated
dimensions, rules, subsets, and views) from one server to another, and synchronize the updates among
the copied cubes either at specified time intervals or on demand. The process of copying cubes from
one server to another is called replication.
Note: Replication and synchronization operations in IBM Planning
Analytics should be performed only by members of the ADMIN
group. Members of other predefined groups (DataAdmin, SecurityAdmin,
OperationsAdmin) do not have all the required access privileges to perform these
operations.
Advantages of Using Replication
Replication offers the following advantages.
- Enhances response time because users can update a cube locally without having to communicate across a network.
- Lets users access and update a copy of a cube, even when they are not connected to the remote server on which the original cube resides.
- Greatly enhances the scalability of TM1.
TM1 provides bidirectional synchronization for replicated cubes. During the synchronization process, TM1 copies the data updates and metadata from the original cube to its replicated versions, and copies the data updates from the replicated versions back to the original cube.
Considerations when using replication
The following considerations apply to replication:
- TM1 versions
- All TM1 Servers in a replication process must be the identical version.
- Remote servers
- You can replicate cubes that reside on remote servers only. You cannot replicate cubes that reside on local servers.
- Local servers
- TM1 clients can replicate cubes to their local server only if they are running that server as an independent process. The machine must have a network card. To run a local server as an independent process, clients need to select the Local Server Execution Mode: Independent Process option in the TM1 Options dialog box.
- Access privileges
- When you replicate a source cube on a remote server to a local server, any elements to which the local client has NONE access on the remote server, will have a value of zero. If the client has READ (or higher) access to a consolidation that includes elements to which the client has NONE access, the consolidation will appear to be the sum of only those elements to which the client has READ (or higher) access. The consolidation, as reported to the client, will not be the sum of all elements, as in the source cube.
- Tm1s.cfg file
- The Tm1s.cfg file must be configured to register the target and source servers with the same TM1 Admin Server. For more information, see Configure the tm1s.cfg file to support replication.
- Length of directory path and cube name
- The total length of the path name for the target TM1 Server's data directory and the name of the cube you are replicating cannot exceed the Windows path name limit of approximately 256 characters. If this limit is exceeded, due to a long path name or cube name, TM1 displays the following error message: Could not register the cube.
- Transaction Logging
- If you are performing a synchronization process, transaction logging must be enabled for the mirror cubes on the target server that are part of the replication and synchronization process. If you are performing a bidirectional synchronization, transaction logging must be enabled for all the related cubes on both the source and target servers.
- CubeProperties Control Cube
- The values stored in the CubeProperties control cube are specific to a TM1 Server and are not copied from the primary to the target server during a replication process. For example, if you want the Measures dimension for a replicated cube to be set on the target server, you must manually set the value in the CubeProperties control cube on the target server.