Article Content
Article Number | 000037875 |
Applies To | RSA Product Set: Identity Governance & Lifecycle RSA Version/Condition: 7.0.2, 7.1.0, 7.1.1 |
Issue | RSA Identity Governance & Lifecycle unification fails with the following error in the aveksaServer.log file and you have already applied the patches noted in RSA Knowledge Base Article 000036137 -- RSA Identity Governance & Lifecycle unification fails with ORA-30926: unable to get a stable set of rows in the source tables. 05/03/2018 14:10:51.048 INFO (Exec Task Consumer#1) [com.aveksa.server.xfw.UnificationExecutor] Failed method=Process subTask=CompleteMergeTasks Default User Population, 1026095 com.aveksa.server.db.PersistenceException: java.sql.SQLException: ORA-30926: unable to get a stable set of rows in the source tables ORA-06512: at "AVUSER.UNFC_PROCESSOR", line 47 ORA-06512: at line 1 at com.aveksa.server.db.persistence.PersistenceServiceProvider.runStoredProcedure(PersistenceServiceProvider.java:1601) at com.aveksa.server.db.persistence.PersistenceServiceProvider.runStoredProcedure(PersistenceServiceProvider.java:1459) at com.aveksa.server.db.PersistenceManager.runStoredProcedure(PersistenceManager.java:267) at com.aveksa.server.xfw.UnificationExecutor.executeTask(UnificationExecutor.java:122) at com.aveksa.server.xfw.TaskExecutor.execute(TaskExecutor.java:99) at com.aveksa.server.xfw.ExecutionTaskQueue$Worker.run(ExecutionTaskQueue.java:116) at java.lang.Thread.run(Thread.java:745) Please refer to RSA Knowledge Base Article 000030327 -- Artifacts to gather in RSA Identity Governance & Lifecycle to find the location of the log files for your specific deployment. |
Cause | This error has occurred when there is an Identity Data Collector (IDC) that can create users (the primary IDC) which joins to an IDC that does not create users (a secondary IDC) on a custom attribute. Initially both IDCs collect a record and are correctly joined. Subsequently, if the primary IDC detects a change in the custom attribute which it uses to join to the secondary IDC, the secondary IDC still collects the original record that was joined to the primary IDC and it also collects a new secondary IDC record which matches the new value in the custom attribute of the primary IDC. The secondary IDC is not being properly reset when the custom attribute changes. |
Resolution | This issue is resolved in the following RSA Identity Governance & Lifecycle patches:
|