1 of 1 people found this helpful
Never seen this behaviour before.
Could you (or your admin) please run a repository query to look for Deleted objects not yet purged? Maybe your "new" source definitions have been deleted but not yet purged; then you should be able to recover them.
Other than that open a service request (a "case") with Informatica Global Customer Support (GCS). If anyone can help you, it's probably those guys.
And yes, Ctrl-S saves the current status of whatever you have changed since the last Ctrl-S to the repository tables. But if the check-in process has a bug, then this won't help.
It MAY have happened that during the check-in process the version status information (kept in OPB_OBJECT_STATUS, if memory serves me right) became corrupted and so the Designer doesn't display these source definitions anymore. But that's indeed something for the GCS engineers to check.
Hi Nico, thanks for your reply.
For now, the admins decided to restore a backup that was created at the end of the previous week, connect to it and extract the objects that were "in-use", "locked" or whatever status an object gets when it's checked-out.
I will pass on your suggestions, but since this all my be very time consuming (and our project is quite in a hurry and under a lot of stress (as always :-) ), the above mentioned solution hopefully will help us get back on track within a few hours.
For now, my main concern is getting my objects back somehow as quickly as possible ;-)
The admin/dba guys restored a backup database, but are unable to connect the tooling to it.
Is it possible to "export" objects to xml (similar like using the informatica tooling) directly on the database, by using queries? I'm rather interested in querying my objects (lets say user Gene) from the backup database, with last saved date greater or equal to "24 august 2020". Probably server names, domain names, schema names and stuff also need to be added? Wish i was an admin right now with knowledge of getting stuff from the database without tooling :-(
1 of 1 people found this helpful
unfortunately a DB backup works only if it's restored to the exact same host name as the original DB server of the repository. The repository name is stored within the repository along with the host name (and IP address), so any mismatch will be "punished" by the repository service not being able to start up.
From this point of view I always recommend taking repository backups using the command-line utility pmrep; DB backups only work if they are restored (as mentioned above) to the same IP host name.
And no, there's no way (which I know of) to extract the data directly from the repository DB to XML files or anything similar.
Maybe they would be willing to perform a "temporary" restore in the following manner:
- Stop the repository service.
- Backup the DB contents somewhere.
- Restore the DB backup from last week.
- Start the repository service.
- Back up all objects which you need or may need. pmrep can be your friend here because you can save a whole folder to one XML file.
- After you have saved all your work from last week, stop the repository service again, restore the "real" contents backed up in step 2, and restart the repository service.
That is the only way to get the DB backup from last week working.
I'm sorry that I don't have any better news to offer.
Good luck and regards,
Is this the first version of the workflow or a previous version exists . If a previous version exists , that can probably exported from Rep Mgr and can be imported to restore this .
But only if the repository DB is still intact. Which is not the case here because they have restored a DB backup to a new DB server, if I understood correctly.
Possible Nico. Based on How I read the above. Looked like the DBAs restored in a diff DB so it may be possible they have the original intact. However my understanding can be incorrect as well.
I don't think they are even going to consider this option. Way to many projects in development. Thanks so much for your comments! I'm going to start doing some two weeks of rework....ah well, there are worse things in life :-)
But maybe you can convince your admins to not take DB backups anymore after this experience. Taking a repository backup in the Administrator tool or via the command-line tool pmrep imposes far less burden onto the DB server and is the only safe way to restore a repository to any DB server. Maybe by now they see the need for "real" repository backups instead of DB backups... I'll press my thumbs for you.