Showing results for 
Search instead for 
Do you mean 

Moving a dataset to a different Trim server

Super Advisor

Moving a dataset to a different Trim server

I plan on migrating our development dataset to another machine. Currently the Trim server is a separate machine from our development Oracle server and both VMs are underutilized to the extreme so we want to consolidate.  I will install 6.2.5 build 1300 (what we are running) on the Oracle server and not create a dataset. Then am I correct in saying that all I need to do is use the migrate feature to migrate the dataset from one Trim server to another? Or is that wrong since I won't be moving the dataset to a new database server at all? I am in effect registering it on a new server. Basically follow the instructions? Then just copy the content index and datastore folders to the other machine and I'm up up and away? Any thing I'm not thinking of?

 

Actually is the only thing I have to do is shut down the old Trim Workgroup Service, copy the content indexes and datastore to the new server, then register the new dataset?

 

Thanks ahead of time.

10 REPLIES
Honored Contributor

Re: Moving a dataset to a different Trim server

With a NEW install of TRIM, yes you need to "register" the dataset regardless.  In addition, as it pertains to the document stores, you need to provide the new UNC path to the document store; and when you create the new Content Index (assuming you've copied these over), you need to provide the UNC for it too.

 

Then you need to check in the TRIM Client for any additional document stores (if any) and make sure they're copied over and the paths set for them.

 

Here's an old document that talks/explains about copying over a dataset to a test / development server - pretty much what you need to do.

 

 

Super Advisor

Re: Moving a dataset to a different Trim server

Thanks. THe DBID is the question and I'm guessing it doesn't matter in my situation whether I use the same one or make up a new one as the old machine is going away. Probably safe to just make up a new one. But have to read the doc to see if the dataset needs to be called the same thing  on the new Trim server.

Super Advisor

Re: Moving a dataset to a different Trim server

I think I want to keep the DBID the same after reading the document. Also since my servername will be changing it seems I want to change the TSEVENTPRO table to reflect the new server name.

Super Advisor

Re: Moving a dataset to a different Trim server

Can you change the dataset name? For instance the dataset is called "servernameDB".  The server in that name is actually the name of the Trim server hostname. I'd like that to be changed either to the new server's hostname or a generic name in case we move it again. Is that name stored somewhere in the dataset schema?

Honored Contributor

Re: Moving a dataset to a different Trim server

 


samd wrote:

I will install 6.2.5 build 1300 (what we are running)


 

I would strongly advise that you upgrade your TRIM versions while you have the chance. e.g. 6.2.5 1332.

We've covered this a few times around the forum, but that build (1300) had some major issues and was replaced quite quickly with a later 6.2.5 version.

 

 



::::::::::::::::::::::
NOT A HP EMPLOYEE
::::::::::::::::::::::

INFORMOTION.com.au
Honored Contributor

Re: Moving a dataset to a different Trim server

 


samd wrote:

Can you change the dataset name? For instance the dataset is called "servernameDB".  The server in that name is actually the name of the Trim server hostname. I'd like that to be changed either to the new server's hostname or a generic name in case we move it again. Is that name stored somewhere in the dataset schema?


 

You can call the dataset whatever you like.

It just means that you need to update the dataset connection settings on the client side. (Though in theory if you use the same DBID it should still connect I think)



::::::::::::::::::::::
NOT A HP EMPLOYEE
::::::::::::::::::::::

INFORMOTION.com.au
Super Advisor

Re: Moving a dataset to a different Trim server

I would gladly upgrade to that version or even 7.1. However we have to maintain a development copy of that version as that is what version or customer uses. They are having no problems since we upgraded from 6.24 (latest build) to 6.25 to solve the Outlook Integration problems that were in 6.24.  It's not a quick process to upgrade 200+ users in an environment especially as the prior upgrade took some time as I'm not the network admin in that environment.

 

This is why I wish Trim came with a way to integrate with Outlook without installing things on the user's workstation so I don't have to maintain rich clients and worry about upgrading them.

 

Can you point out the major problems we might run into? I can see the 1322 fix list but the list is long.

 

I imagine there is a problem with two servers running the same DBID but with a different dataset name. I think this won't work as I've done this one time.

Super Advisor

Re: Moving a dataset to a different Trim server

This was pretty darn easy. Updated the TSEVENTPRO table with the name of the new server.
Super Advisor

Re: Moving a dataset to a different Trim server

Well it was ok for a day. This morning the Trim workgroup service and Event service were down. Here's the exact message from the log file. Seems yesterday around 7pm or so both Trim services decided to crash and only the Event service will now start. I rebooted the machine and now the workgroup server starts.

 

"A problem was encountered while starting TRIM Workgroup Server. Could not read TRIM Workgroup Server configuration information. Invalid pointer(#80004003)"

Super Advisor

Re: Moving a dataset to a different Trim server

Also had to put startup delays (via the registry entry DependOnService) for both the Trim Workgroup Service and the Trim Event Service as Trim was trying to connect to Oracle before Oracle was totally opened. Now I have those services depending on Oracle and no errors in the log files. I was getting the following errors every reboot in the log file.

 

"A problem was encountered while starting . ORA-12528: TNS:listener: all appropriate instances are blocking new connections"

//Add this to "OnDomLoad" event