Migration of DS Installation
Moderators: chulett, rschirm, roy
Migration of DS Installation
Hi,
If the whole directory where the DS installation resides migrated to new server, will I be able to access the jobs as usual.
We were in the process of migrating server. So should I need to aware if something else.
Pls advise.
If the whole directory where the DS installation resides migrated to new server, will I be able to access the jobs as usual.
We were in the process of migrating server. So should I need to aware if something else.
Pls advise.
You cannot just copy a DataStage Server or project directory from one machine to another. The installation directory needs to be reinstalled on the new machine. There are ways of getting an existing project directory from one machine to another at the OS level, but they do require that the path remains identical.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
No, if what you have in mind is, for example, restore from system backup onto new system.
The problem is that there is a lot of information in system tables that is not updated by this method.
There is a "UniVerse" utility for exporting a project so that it can be rebuilt, called format.conv (it also is known as fnuxi). This command has -export and -import options (among many others). But it still creates an export file that has to be moved and imported from, so you may as well use the DataStage utilities.
The problem is that there is a lot of information in system tables that is not updated by this method.
There is a "UniVerse" utility for exporting a project so that it can be rebuilt, called format.conv (it also is known as fnuxi). This command has -export and -import options (among many others). But it still creates an export file that has to be moved and imported from, so you may as well use the DataStage utilities.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Read about it as FORMAT.CONV in the UniVerse User Reference page 1-191 and following.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
I was able to successfully backup the entire installation directory using tar and copy over to a new server. There were a few other files that needed to be copied over as well such as /etc/services and /.dshome. I also needed to make sure that the node name stayed the same. uname -S<node name> and setup an alias in /etc/hosts. For the most part, exactly the same concept that you would follow when setting up DS for failover using HA in an active/passive configuration. Except instead of the volume groups moving between clusters to expose the software you are copying the software. You must use root to do the copy and place the software in the same directory structure.
I am now keeping the node name across all installations the same. I call it etlbox and setup an alias in /etc/hosts. I did this as an initial test for the active/passive cluster we created.
I am now keeping the node name across all installations the same. I call it etlbox and setup an alias in /etc/hosts. I did this as an initial test for the active/passive cluster we created.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Of course you can copy - there's nothing outside the file system. However, how did you go about updating system tables such as UV.ACCOUNT, UV_SCHEMA and so on?
Or did you copy the Engine directory as well? With identical configuration a "copy everything" approach would work, because the pathnames and other references in the system tables (which are in/beneath the Engine directory) would be identical.
I'm not sure whether such an approach is in accord with licensing conditions, however. Does anyone read the licence agreement that you agree to when installing the server?
Or did you copy the Engine directory as well? With identical configuration a "copy everything" approach would work, because the pathnames and other references in the system tables (which are in/beneath the Engine directory) would be identical.
I'm not sure whether such an approach is in accord with licensing conditions, however. Does anyone read the licence agreement that you agree to when installing the server?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Ultramundane - I am about to do one. Is the node name setting required only for licensing issues? Or do the Universe will have an entry for the Host name in it?
Do we need to have the new IP address with old Host name?
Ray - You should be kidding about, reading the licensing conditions. Its always 'I Accept'.
Do we need to have the new IP address with old Host name?
Ray - You should be kidding about, reading the licensing conditions. Its always 'I Accept'.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
I copied everything using tar and it worked without problems. When I say everything I mean ESP, db2, Oracle, Sybase, Datastage, etc... Everything you would need to copy to pseudo test a active/passive cluster configuration without actually having a cluster ready to test.
The node name is used by certain file types such as datasets. That is, it is part of the metadata of the file. In addition, it used as the fastname in the configuration files. You can copy and use a different node name. I found that works as well. I did not run into any license issue. The license gets carried over as well. However, if you change the node name, you must delete all files that have references to the node name. Files such as datasets, if you do not the programs will not function. Also, you will need to update all of your configuration files to point to the node name or fast name what have you.
I keep the node name the same across all servers now because I can use the same configuration files without changing them. Thus reducing chances of errors because I made a change to config incorrectly and could not test in test fully because of the different node name/fastname.
Being that this is the node name and not the system name, hostname will still return the host of the system. So, if you copy from servera to serverb it is likely that both the node name and the system name of servera are servera and for serverb serverb. To make it work, assuming you are copying from servera to serverb, set the node name of serverb to servera and create an alias in /etc/hosts to whatever interface you would like the servera node name on serverb to use.
To update the node name on AIX use uname -S<node name>. Note, this is not permanent and you will need to add the uname -S<node name> call to your appropriate files during startup. Then, you must add an alias to /etc/hosts for the servera node name to use.
The node name is used by certain file types such as datasets. That is, it is part of the metadata of the file. In addition, it used as the fastname in the configuration files. You can copy and use a different node name. I found that works as well. I did not run into any license issue. The license gets carried over as well. However, if you change the node name, you must delete all files that have references to the node name. Files such as datasets, if you do not the programs will not function. Also, you will need to update all of your configuration files to point to the node name or fast name what have you.
I keep the node name the same across all servers now because I can use the same configuration files without changing them. Thus reducing chances of errors because I made a change to config incorrectly and could not test in test fully because of the different node name/fastname.
Being that this is the node name and not the system name, hostname will still return the host of the system. So, if you copy from servera to serverb it is likely that both the node name and the system name of servera are servera and for serverb serverb. To make it work, assuming you are copying from servera to serverb, set the node name of serverb to servera and create an alias in /etc/hosts to whatever interface you would like the servera node name on serverb to use.
To update the node name on AIX use uname -S<node name>. Note, this is not permanent and you will need to add the uname -S<node name> call to your appropriate files during startup. Then, you must add an alias to /etc/hosts for the servera node name to use.
Kumar - the normal hashed files don't hold information about their path or system name. Indices hold absolute paths and thus can only be copied correctly when the target path remains the same. The DataStage server installation directory contains not only indices (thus it needs to go in the same place) but also internal information in files that reference the node name and must remain the same as well.