Using Databasedirectory in several TM1 servers

[EP_explorer]

First of all - I found such text in documentation

You can specify that you want IBM Cognos TM1 to use multiple data directories
by separating the directory names with semicolons

For example, suppose you want to store dimensions in a directory called tm1dims,
and cubes in a directory called tm1cubes. You would specify the following in the
Tm1s.cfg file:
DatabaseDirectory="c:\tm1dims;c:\tm1cubes"

And here first question:
How I have to write in Cfg file (or somewhere else) that TM1 server put objects in specific folders (dims in its folders, cubes in its, rules in its etc.). I haven't found any mentions in other parts of documentation

Actually first question is interesting to me not so much as the second
it is concerning interaction between two TM1 servers using DatabaseDirectory

I want to create share objects (dims - for example list of months and data in Cubes for example exchange rate) for different TM1 servers. I create one TM1 server where change these objects and when using them in other servers. For it in cfg file on the other servers I put the folder of the first server first in DatabaseDirectory

But here I meet with difficults. I found how change data in Cubes on the other servers when they are changed on the first one. (Savedataall on the first TM1 server, when unload cube and load cube on the others TM1 servers).
But I don't know way to change dimensions. Only thing which helps - it is stop TM1 servers and launch them again. But I don't think it is good idea.
May be somebody makes a hint.

[qml]

When you specify multiple data directories, TM1 does the following:

Accesses cubes and dimensions from each of the specified directories. If there is a duplicate object, TM1 accesses the object from the first directory specified.

Writes changes to the directory where the object is located. When you create a new object, TM1 writes to the first directory you had specified.

[George Regateiro]

That parameter was never set up to share a data directory between servers. As you have seen it works somewhat but you are setting yourself up for issues with savedataall and server restarts that can cause havoc to your data and the timing of which server wrote which cube when. Your best bets are

1) Replication - Depending on your environment replication might be the simplest option. I don't particularly like it, but it is a lot better to me then your current path.

2) Have Import\Export processes that will keep the servers in synch. This is more work then replication but works better depending on your model. In this case you would asciioutput all your dims and cubes that you need to replicate and then consume the output files in the destination server.

[Steve Vincent]

2) Have Import\Export processes that will keep the servers in synch. This is more work then replication but works better depending on your model. In this case you would asciioutput all your dims and cubes that you need to replicate and then consume the output files in the destination server.

Don't i know it - that is exactly what i have just spent 3 days working on in my dev servers. Its amazing how annoying replication is, yet the output it (eventually) manages is pretty impressive. Just a shame it's too flaky to rely on. Also depends what else you want to sync - views, subsets, rules all able to be done by replication but i've yet to tackle them in my TIs. Not even sure if i will bother...

[EP_explorer]

When you specify multiple data directories, TM1 does the following:

Accesses cubes and dimensions from each of the specified directories. If there is a duplicate object, TM1 accesses the object from the first directory specified.

Writes changes to the directory where the object is located. When you create a new object, TM1 writes to the first directory you had specified.

You mean that I have to put objects in folders manually and it wasn't TM1 which will do it?

[EP_explorer]

That parameter was never set up to share a data directory between servers. As you have seen it works somewhat but you are setting yourself up for issues with savedataall and server restarts that can cause havoc to your data and the timing of which server wrote which cube when. Your best bets are

The thing is that I don't need restart server if I want receive new portion of data on the other servers from the first one
I hoped may be the way exists to changed dimensions.

Anyway thank you for hints

[EP_explorer]

1) Replication - Depending on your environment replication might be the simplest option. I don't particularly like it, but it is a lot better to me then your current path.

BTW. Does the command of TI exists which run replication?

[George Regateiro]

The thing is that I don't need restart server if I want receive new portion of data on the other servers from the first one
I hoped may be the way exists to changed dimensions.

Your way of unloading and reloading may work, but what I was getting at is you have to be entirely sure that changes are made on one side only. The following is an example of the issues you may encounter

Server 1 - Modify data in rates cube
Server 2 - Modify data in rates cube
Server 1 - SaveDataAll
Server 1 - Shutdown Service for maintenance
Server 2 - SaveDataAll
Server 1 - Restart

In this case if your synch had not occurred yet when server 1 comes up it would now have the contents of server 2's rate cube. The same goes for dimensions if you are doing maintenance on both servers and somehow the dims become out of synch you risk losing data on one of the servers when it restarts. My point in steering you away from your current path is that it is entirely against the intention of TM1's design and you are setting up for issues, not that it is not possible through some workarounds.

As far as your dimensions, TM1 handles these differently. When you make a change to the dimension (whether in TI or in Dimension Editor) the changes are written directly back to disk so TM1 always assumes it has the latest dim stored in memory. So there is no corresponding Unload\Reload that I am aware of.

If these are small cubes you can very well get away with replication and your job is done. Many people use this with great success. If your cubes to sync are large you will encounter issues. I would give replication at try. It is IBM supported functionality and could solve your issues in minutes rather then working around the system.

Just saw your last question, I believe that Replication can be scheduled as a core, I don't believe it is callable as a process (Caveat: It has been a while since I tried to use replication)

[George Regateiro]

You mean that I have to put objects in folders manually and it wasn't TM1 which will do it?

Yes, but if you wanted a batch file that you run when the service is shutdown would also do the trick to organize the directories.

[Alan Kirk]

2) Have Import\Export processes that will keep the servers in synch. This is more work then replication but works better depending on your model. In this case you would asciioutput all your dims and cubes that you need to replicate and then consume the output files in the destination server.

Don't i know it - that is exactly what i have just spent 3 days working on in my dev servers. Its amazing how annoying replication is, yet the output it (eventually) manages is pretty impressive. Just a shame it's too flaky to rely on. Also depends what else you want to sync - views, subsets, rules all able to be done by replication but i've yet to tackle them in my TIs. Not even sure if i will bother...

Don't get your hopes up on views and subsets. It would be more correct to say "there are checkboxes for saying that you'd like to replicate views and subsets, but you should regard these as having outcomes which are as certain as those gained from writing a letter to Santa Claus when you were 7". I gave up on it and had the replication of subsets done via George's second method; TI Export / Reimport. Dimensions on the other hand are easy since most of ours are done via .xdi. The .xdi need only live on the master server and as long as you're logged onto whatever servers you need to update the .dim on, you just go ahead and save it onto all of them.