If you have used same database o configure REpository service, please check if its still pointing the old database details.
Login to Adminconsole -> Repositry service > properties -> Dtabase details.
Disable the repository service and confirm with DBA, if user is still trying to log into the old SQL server. In that case see if any old pmrepagent processes are still running on the server. Example using ps -ef | grep pmrepagent. If yes, kill those old processes, and then recycle RS. Check the details of the user in RS login details as well.
Informatica PC RS uses native clients for some supproted DBs (e.g. Oracle, DB2). If you are in such scenario, since such clients rely on the user's environment, it might be useful to test the parameters used in PC RS' properties via a DB client (e.g. sqlplus, db2) running on the Informatica server where the PC RS is running.
NOTE: make sure you log in as the user running the Informatica services before carrying out the test.
This should help you understand which DB server/schema you are connecting to.
The DBA should also be able to query some DB views and provide more details about the session they are complaining about (e.g. v$session for Oracle).
Did the server host change or the database server or both?
The infasetup UpdateGatewayNode command just changes the server hostname and the database server details for the node/domain.
However, the Repository Service still connects to the same old database.
If the database host has changed, you will need to update the database configuration at the PowerCenter Repository in the AdminConsole which should be pointing to the old database server.
If you directly change the database server details, it will connect to the new database server but you might miss the repository metadata.
As a safer side, follow the below steps.
1. Take a backup of the existing Repository Service from the Admin Console
2. Shutdown the RS
3. Update the RS database connection details
4. If there are no contents in the database schema, it will prompt stating that there are no contents in the repository
5. Restore the repository contents from the backup file collected in Step#1.
If not, you should be good.
Hope this helps.
1 of 1 people found this helpful
Please specify the database type ( DB2/Oracle/SQLServer, etc.) that the RS is hosted on, and the connection string ( is it native client/ODBC). That will provide some clues.
it is on sql server. thanks.
when I ran this command I got error message ' The term 'grep' is not recognized as the name of a cmdlet, function, script file, or operable program.
I have updated the connection string on admin console for repository service. Thanks.
Any external tool connecting to the repository? Maybe a reporting tool?
If so, update also the connection details on these tools to stop receiving these login attempts.
1 of 1 people found this helpful
Are you still facing an issue? If so, can you please attach the recent error message otherwise we can close this thread.
Yes. I am still facing the same issue.
The new observations are:
I disable and enable again the reporting service and the user stopped to try to login to old server.
However. by midnight, the user account starts again.
I've checked all scheduled workflows, did not find any connection strings to the old server.
If the same user ID is used at midnight to connect to the old server, then there must be some other process which connects to the old server using this user ID.
Whether this process is started as some PowerCenter session or something else I cannot say.
Honestly my suggestion is this: have the DBA disable this user ID from logging on to the old server and simply wait. If this "foreign" process is intended for legitimate use, then sooner or later someone will show up and ask why the server connection no longer works. But I am almost 100% sure that no PowerCenter workflow will try to connect to the old server; and in particular I am 100% sure that no repository service will try to connect to that old server.
Actually it's the task of the server management and change management to make sure such things don't happen after a server switch. So it's not your responsibility that this odd connection is attempted.
Of course you could examine the repository table OPB_CNXS (if memory serves me right) which connection might use the old server. Then you can start to search for any PowerCenter process which may use this connection. This way you may be able to help identify the "culprit" for this odd connection.
If connections to old server are no longer needed, you can remove the TNS entry for that old server on Informatica node.
2 of 2 people found this helpful
Thanks everyone for giving so many valuable suggestions.
I've found the old connection string from the data source of Data Analyzer.
Unfortunately reporting service is not supported anymore (we are in 10.1), I am not able to remove the data source nor recreate the reporting service.
Since the reporting service is not supported anymore, so I just disabled it.