In my opinion after Package builds, Server Migrations are the real staple food for a JDEdwards CNC consultant. The constant changes in OS technologies and the ever expiring hardware support contracts ensure that we do at least a couple of such migrations in a financial year. If your setup is configured for high availability then you get to do it more often than you would like.
I still remember as a young trainee getting a grasp of this was a nightmare. I have an unexplained fear of the Typical Installation Plan (P98240) application and the white space that it shows. Grids do not scare me as much as that particular white space. All the mumbling rumblings of creating and add on plan, adding the new enterprise server and then removing the old one went over my head in those days as a trainee. But I did one thing well, nodded my head as though I understood every last word of my trainer and sailed through the training. I am more of a guy who knows that if he is drowning he can swim but just wont do it for leisure in a swimming pool. I got to have the waves to challenge me.
Finally when I got to do my first real Unix Enterprise Server Migration at a client's place i dug deep. I dug so deep that I landed at the tables that govern them all. It all started making sense and i have done 9 such migrations this far. Lets talk about the tables that we should be looking at:
If you just change the old server name to new server name in the above tables your migration is half done. Here's a sample Update query that can be run to update the same in say SYSXXX.F98611.
Update SYSXXX.F98611 set omsrvr = 'newserver' where omsrvr = 'oldserver';
All you need to do is get the old server name and replace it with the new one, matching case to case.To get the entire list of updates that you should make, you can just go to the tables I specified and pick the values that you need to change. Once you get all the values it should be fairly easy chalking all the update statements out. Be very careful with the case of the name, specially in Unix
The next step is fairly simple. Once you get the new server ready, make sure you have "rsync" command working on the new server. Make sure you have the same user id configured on this new box. Once you are able to login to the new box with the same id, follow the following steps.
I still remember as a young trainee getting a grasp of this was a nightmare. I have an unexplained fear of the Typical Installation Plan (P98240) application and the white space that it shows. Grids do not scare me as much as that particular white space. All the mumbling rumblings of creating and add on plan, adding the new enterprise server and then removing the old one went over my head in those days as a trainee. But I did one thing well, nodded my head as though I understood every last word of my trainer and sailed through the training. I am more of a guy who knows that if he is drowning he can swim but just wont do it for leisure in a swimming pool. I got to have the waves to challenge me.
Finally when I got to do my first real Unix Enterprise Server Migration at a client's place i dug deep. I dug so deep that I landed at the tables that govern them all. It all started making sense and i have done 9 such migrations this far. Lets talk about the tables that we should be looking at:
- SYSXXX.F98611 : DataSource Master Table
- SYSXXX.F986101: Object Configuration Master Table
- SYSXXX.F91300: Schedule Job Master Table
- SYSXXX.F9650: Machine Master Table
- SYSXXX.F9651: Machine Detail Table
- SVMXXX.F98611: Data Source Master (Server Map DataSource)
- SVMXXX.F986101: Object Configuration Master (Server Map DataSource)
If you just change the old server name to new server name in the above tables your migration is half done. Here's a sample Update query that can be run to update the same in say SYSXXX.F98611.
Update SYSXXX.F98611 set omsrvr = 'newserver' where omsrvr = 'oldserver';
All you need to do is get the old server name and replace it with the new one, matching case to case.To get the entire list of updates that you should make, you can just go to the tables I specified and pick the values that you need to change. Once you get all the values it should be fairly easy chalking all the update statements out. Be very careful with the case of the name, specially in Unix
The next step is fairly simple. Once you get the new server ready, make sure you have "rsync" command working on the new server. Make sure you have the same user id configured on this new box. Once you are able to login to the new box with the same id, follow the following steps.
- Copy and paste your .profile from the old server to the new server
- Make sure you can reach your database from the new server. If you have NAS mounts for the database clients make sure they are connecting properly
- Check the "cc" libraries if they are consistent with those on the old server. Make sure the version is in the MTR.
- Run "Rsync" to sync up the base "\jdedwardsoneworld" directory on the new server with the old server. Here's the syntax of typical rsync run: rsync -avz --rsync-path=/usr/local/bin/rsync /apps/jdedwardsoneworld/* jdeuser@newservername:/apps/jdedwardsoneworld
- Update the JDE.INI to reflect the newservername as the security server. Do this step only if you know that the old server was a security server.
- Run ./RunOneWorld.sh and you should be delighted and dancing by now.
- Before you get too excited run the porttest and check the output.
No comments:
Post a Comment