1. There is no direct upgrade path from 9.5.1 to 10.2. You can have to upgrade to 9.6.1 first and then to 10.2
2.You can follow steps in below guide.
This has detailed information about prerequisite and upgrade steps.
3.While upgrading you have to find one common version of DB and OS between two versions and use that version
ex: 9.5.1 is supported on 6.9 RHEL as well as 9.6.1. And 9.5.1 supports 11gr2 database as well as 9.6.1.
Once you upgrade to 9.6.1 you have to find similar versions between 9.6.1 and 10.2 and then upgrade.
4. Take repository and domain schema backups before performing upgrade.
NOTE: 10.2 will be reaching EOL by Sep 30th 2021, so please plan to upgrade to the latest version i,e 10.5.
If you need further assistance you can raise support case with Informatica.
Thanks Smitha for quick response. So below are some of the steps I will be performing.
1. We will take the respository back-up from current Informatica server. (Informatica 9.5.1, OS Sun Solaris 5.11, Informatica repository on Oracle 11g)
2. We will create new VNM with RHEL 6.7, Install Informatica 9.5.1 on it pointing to different Oracle 11g instance.
3. We will then restore the repository back-up to this instance.
4. I will then install Informatica 9.6.1 on same VM and follow the steps for in-place upgrade.
Do you see any issues in this process?
Just to make sure you don't mix up two things, sorry for being pernickety here.
What Informatica calls an "in-place" upgrade is always an upgrade of the software on an existing system, including all repositories. Not my favourite for a couple of reasons.
I always prefer separate installations to make sure you don't run into really bad problems if the hardware gives up during the upgrade process.
You back up your repositories in 9.5.1 and restore them to some empty database schemas. Then you remove the repository services but leave the DB contents intact.
You install 9.6.1 on a new machine (or on the same machine using a different user ID and/or separate environment including separate installation path). After this step, you upgrade the repositories one by one to 9.6.1.
The fact that a repository database can only be upgraded by the new software version does NOT imply that this new version must be installed on the same machine in the same environment (including same installation path). A parallel installation will leave the old version intact and runnable even if the new installation fails for whatever reason.
Ok I think I can do separate installation on different machine to avoid any issues and hardware failure.
My main concern is around taking existing repository back-up and restoring to different informatica 9.5.1 instance pointing to different repository database. Tried to show in below image .
Apart from having same DB version and code page, do I have to consider anything else here?
No, that's fine. We're doing this all the time whenever we have to update the 10.4.1 repositories (we're in the middle of the migration from 10.1.1 to 10.4.1).
The only thing I have to "warn" you about is that with a parallel installation there's one additional step needed which won't occur during an "in-place upgrade" (namely when you upgrade the original software to a new version). Let me explain the background, I'll explain the necessary steps later.
Since version 9.5, the Informatica platforn uses a so-called "site key file" to store an encryption key. This encryption key is used for all domain-related data and is stored in a file named siteKey , located in $INFA_HOME/ips/config/keys (a hidden directory for which you need special permissions to do anything in it, under Windows you need a "real" administrator user like an installation user, on Unix/Linux you probably need the help of a root user). This siteKey file contains - among other details - an encryption key for all passwords stored in a PowerCenter repository.
Now when you copy a PowerCenter repository from one domain to another one (which you will do during the upgrade process, see steps below), the new domain will recognise that the PowerCenter repository used a different siteKey than the siteKey file of the new installation. Since the new domain does not know this old siteKey, it cannot decrypt the passwords in the repository and re-encrypt them with its own (new) siteKey.
That means you will have to provide the old siteKey to the new domain during the upgrade process. And you do that by copying over the old siteKey file into the directory on the new server with a different name, namely siteKey_old .
So what I will do during the final migration is the following list of steps.
Suppose you have a 9.5.1 installation named domold and a 9.6.1 installation named domnew.
domold has all its repositories stored on a DB server dbserv.
Both domold and domnew can access dbserv without hassle (meaning the DB client versions are fine, firewalls have been set up correctly, and the like).
Now you perform the following steps:
On dbserv, you create a new database (resp. a new schema).
In domold, you create a new PowerCenter repository service RepoUpg pointing to this new database (resp. schema) without any contents.
Still in domold, start RepoUpg in Exclusive mode.
In the Administrator tool, there's one repository action named Copy From... ; you can use this to copy the contents of the current 9.5.1 repository into RepoUpg.
You can also do a backup / restore, that doesn't really matter (only that you need disk space for the backup file and a little more time).
Now you disable RepoUpg and remove this repository service from domold. But leave the DB contents of this repository service intact.
In the Administrator tool of domnew, create a new repository service RepoUpg pointing to the database (resp. schema) set up in the very first step (which still contains the copy of the 9.5.1 PowerCenter repository). Do NOT create contents during this step.
Now when you start RepoUpg in domnew, the Administrator tool will inform you that the DB contains a repository from an older software version and that an upgrade may be needed.
Now perform a repository upgrade. This will upgrade all structures in the repository DB to the 9.6.1 structures.
Afterwards set the execution mode of RepoUpg to Normal and try to recylce the repository service.
The Administrator tool will inform you that the repository contents have been encrypted with a different encryption key than the encryption key of the current domain (which is logical because this repository originates from the 9.5.1 installation and not from the 9.6.1 installation). So you will have to upgrade the repository contents again, but only after having copied the siteKey file from domold to the same directory on the domnew machine but with the file name of siteKey_old.
IMPORTANT: even if you have copied the siteKey from the old installation to the new server before this step (switching the execution mode to Normal), the Administrator tool will still tell you that the encryption key is different. This is normal behaviour!
When you now upgrade the repository contents, the upgrade process will be far faster than the first time. This is normal because this time only the passwords are de-crypted (using siteKey_old) and re-encrypted (using siteKey), the DB structures are already correct for 9.6.1.
After this step you can switch the execution mode to Normal and recycle the repository service.
Final word: of course the RepoUpg repository doesn't have the name that you need in the 9.6.1 domain. There's no way to get around having to create it empty in domnew and copying the contents from RepoUpg to the "real" repository service. At least no way which I know of.
Thanks Nico! This is very helpful.
I would appreciate your inputs on one step before upgrade. So we have existing dev/test environments but I will not be able to use it. I am creating parallel environment on Azure VM. Below are the steps that I will be using.
1. I am installing Informatica 9.5.1 on RHEL 6.9.
2. I am following steps from below blog for Informatica installation and will quit installation at Create/Join domain. I will perform after installation steps of copying sitekey,odbc.ini files etc.
3. Restore the back-up of existing server repository to this new server.
My concern here is I am not pointing to the same repository database as existing server. Rather I will have separate db instance and new server will point to that oracle database. Also existing oracle database is 11g but I will be using Oracle 12c, will that be a problem?
If this looks ok let me know if there is anything else i should keep in mind.
Regarding the database version, it should not be a problem to have 11g and 12c for both PowerCenter versions. As far as I recall (the PAMs should indicate this) both versions support both Oracle versions without hassle as long as you're working with 11gR2; 11gR1 is a no-go.
Regarding the database instance, PowerCenter doesn't care where the database is located as long as firewalls are set up correctly so that the PowerCenter machine can connect to the database instance(s).
Whether you use one instance and different database users / schemas, or whether you use two separate database instances, that's totally up to you. Informatica just recommends that each repository (be it a domain repository or a PowerCenter repository) is always stored in its own database schema; it's NOT possible to share one schema for e.g. a domain and a PowerCenter repository.
Thanks Nico! This helps. I might ask more questions on this thread as I go through the process .
Please feel free to ask your questions, that's what we are here for.
So I have set up new instance of Informatica 9.5.1 and trying to import repository from test 9.5.1 server.
I am getting below error on restore.
Value too large for column OPB_WIDGET.COMMENTS(Actual 2001, maximum 2000).
Attached is the error for details
What's the code page of the repository DB of the 9.5.1 source repository DB and the target DB?
So I don't have the details from repository DB as such, But in the admin console of source repository, code page is ISO-8859-1 Western European. So I created target repository with same code page.
On Target DB when I checked LANG it was UTF8 and so was informatica server LANG.
If this is the problem, can you guide me if,
1. I have to reinstall Informatica server and DB server both with ISO 8859? Or
a. Can I change the code page, restart the service and then create repository?
Any other details will also help.