Unique constraint (AVUSER.PK_WP_USER_DATA) violated error while upgrading RSA ​​​​​​​Identity Governance & Lifecycle
3 years ago
Originally Published: 2019-03-09
Article Number
000040740
Applies To
RSA Product Set:  Identity Governance & Lifecycle
RSA Version/Condition:  7.0.2, 7.1.0
 
Issue
While applying RSA Identity Governance & Lifecycle 7.0.2 P08+ or 7.1.0 P02+, the Admin Console shows the following error:
 
Initialization Status
Initialization operations completed with errors. Please resolve the problem(s) before the application server can accept requests.
ORA-00001: unique constraint (AVUSER.PK_WP_USER_DATA) violated
ORA-06512: at line 27

As shown below, /the home/oracle/wildfly-10.1.0.Final/standalone/log/patch.log will show the error during the running of the script /home/oracle/wildfly/standalone/tmp/vfs/deployment/deployment24c7e79a06e7d86f/aveksa.war-dd0019419b195b21/WEB-INF/database/updates/7.0/ACM-85359.sql.
 

The file location listed above will be different for every customer and through every ACM restart.

END;
java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (AVUSER.PK_WP_USER_DATA) violated
ORA-06512: at line 27

   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
   at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
   at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059)
   at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522)
   at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257)
   at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587)
   at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210)
   at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30)
   at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931)
   at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150)
   at oracle.jdbc.driver.OracleStatement.executeUpdateInternal(OracleStatement.java:1707)
   at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:1670)
   at oracle.jdbc.driver.OracleStatementWrapper.executeUpdate(OracleStatementWrapper.java:310)
   at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:375)
   at com.aveksa.migration.jdbctool.SQLFileExecutor.execute(SQLFileExecutor.java:225)
   at com.aveksa.migration.jdbctool.SQLFileExecutor.execute(SQLFileExecutor.java:107)
   at com.aveksa.migration.jdbctool.SQLFileExecutor.execute(SQLFileExecutor.java:98)
   at com.aveksa.migration.jdbctool.IncrementalUpdate.update(IncrementalUpdate.java:481)
   at com.aveksa.migration.jdbctool.MigrateSchema.execute(MigrateSchema.java:159)
   at com.aveksa.migration.jdbctool.CheckDatabase.migrateSchema(CheckDatabase.java:1382)
   at com.aveksa.migration.jdbctool.CheckDatabase.check(CheckDatabase.java:558)
   at com.aveksa.server.runtime.AveksaSystem.initialize(AveksaSystem.java:308)
   at com.aveksa.init.Startup.init(Startup.java:52) at com.aveksa.gui.core.ACMFramework.init(ACMFramework.java:94)
   at com.aveksa.gui.core.ACMFramework.initInstance(ACMFramework.java:83)
   at com.aveksa.init.InitServlet.init(InitServlet.java:42)
   at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
   at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.handle(RunAsLifecycleInterceptor.java:66)
   at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:77)
   at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
   at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
   at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
   at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
   at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88)
   at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)       at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
   at java.lang.Thread.run(Thread.java:748)
[0:00:00] File Completion Time: /home/oracle/wildfly/standalone/tmp/vfs/deployment/deployment24c7e79a06e7d86f/aveksa.war-dd0019419b195b21/WEB-INF/database/updates/7.0/ACM-85359.sql
[0:00:13] Total Migration Time
Cause
Starting with RSA Identity Governance & Lifecycle 7.0.2 P08 and 7.1.0 P02, an internal variable for workflows was changed from acm.Priority to acm.emailPriority. During the patch upgrade the upgrade script replaces the existing variable name acm.Priority to acm.emailPriority.  

If you import workflows from 7.0.2 P08 or 7.1.0 P02 to a lower patch version, it will cause the acm.emailPriority variable name to be created on a lower version of the product causing the conflict during the upgrade. RSA recommends to only import workflows/metadata between the same version and patch to avoid these kinds of issues. 



 
Resolution
This issue has been resolved in the following patches:
  • RSA Identity Governance & Lifecycle 7.1.1 GA +
  • RSA Identity Governance & Lifecycle 7.1.0 P06 + 
  • RSA Identity Governance & Lifecycle 7.0.2 P13 +
The fix was to modify the upgrade script to handle the use case described in the Cause section of this article.
Workaround
Please contact RSA Identity Governance & Lifecycle support for a workaround and mention this RSA Knowledge Base Article (000037243) for reference. Please have the results of the below query ready when you place your call. 
SELECT COUNT(*) FROM wp_user_data WHERE VAR_NAME LIKE 'acm.emailPriority%';


 
 

 

Related Articles

Trending Articles

Don't see what you're looking for?