Hi
We are planning to upgrade Datastage from 7.5.1 to 7.5.3 and database from oracle 9i to 10g....Does anybody faced any issues during this upgrade like any stage not working as expected etc.
Also like to know if any special precaution needs to be taken for the upgrade
Thanks
Datastage Upgrade from 7.5.1 to 7.5.3
Moderators: chulett, rschirm, roy
-
udayk_2007
- Participant
- Posts: 72
- Joined: Wed Dec 12, 2007 2:29 am
No issues that I recall seeing. There's no "special" precautions, just all of the usual ones, primary revolving around backups and making sure you have them. And make sure you upgrade all of the clients as well.
Will this be an "upgrade in place" or will you be building a new server?
Will this be an "upgrade in place" or will you be building a new server?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
udayk_2007
- Participant
- Posts: 72
- Joined: Wed Dec 12, 2007 2:29 am
Sure, you've made the process harder as there's lots of little fiddly bits to bring over but the backups don't really come into play as there isn't that remote danger of destruction of the 'old' server. That and you'll need to install the Multi-Client Manager and both clients in separate directories on anyone's PC who will need access to both servers.
Build out the new server and then bring over .dsx exports of all of the projects you want to transfer over and import them in the new project. If you are using Version Control there's more to it than that for any VERSION projects you might need to migrate but I'm pretty sure there's a post out here on the subject of 'migrating version control projects' where the process of handling all of its magic hashed files is spelled out.
Then you'd need to ensure you migrated all of the things that an export does not include:
1. ODBC connection information.
2. PX Config files
3. Customizations to your dsenv file
4. Hashed Files in a project if using (SDKSequences, etc)
5. Pathed / Directory based hashed files
6. Project level environment variables (DSParams)
7. Other stuff I'm probably forgetting
An "in place" upgrade is quick and painless but building out a new server? Not so much.
Step 4 above is not as straight-forward as 5. For 5 you can simple tar them up and untar them on the new server. While you can do that for 4, you'll first need to ensure they are created in the new projects properly so they get a VOC record established and then the untar can overwrite the file structures with the transferred data. Or you could bring them over regardless and learn how to manually create the VOC records, something a search here for SET.FILE would reveal.
That's about it off the top of my head, if I think of something else I'll add it and I'm sure others will remind me of things I've missed as well.
Build out the new server and then bring over .dsx exports of all of the projects you want to transfer over and import them in the new project. If you are using Version Control there's more to it than that for any VERSION projects you might need to migrate but I'm pretty sure there's a post out here on the subject of 'migrating version control projects' where the process of handling all of its magic hashed files is spelled out.
Then you'd need to ensure you migrated all of the things that an export does not include:
1. ODBC connection information.
2. PX Config files
3. Customizations to your dsenv file
4. Hashed Files in a project if using (SDKSequences, etc)
5. Pathed / Directory based hashed files
6. Project level environment variables (DSParams)
7. Other stuff I'm probably forgetting
An "in place" upgrade is quick and painless but building out a new server? Not so much.
Step 4 above is not as straight-forward as 5. For 5 you can simple tar them up and untar them on the new server. While you can do that for 4, you'll first need to ensure they are created in the new projects properly so they get a VOC record established and then the untar can overwrite the file structures with the transferred data. Or you could bring them over regardless and learn how to manually create the VOC records, something a search here for SET.FILE would reveal.
That's about it off the top of my head, if I think of something else I'll add it and I'm sure others will remind me of things I've missed as well.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
We have faced some issues while this upgrade. If you are using OCI in the look up for the server jobs then the ordering of the look up variable should be the first one.
The look should start with :1, :2 etc.. You cannot have :2 directly. This works in 7.5.2 where as it won't in 7.5.3.
There is one more issue in parallel job which we got was to unable to prepare the SQL.
The look should start with :1, :2 etc.. You cannot have :2 directly. This works in 7.5.2 where as it won't in 7.5.3.
There is one more issue in parallel job which we got was to unable to prepare the SQL.