Hello,
We have tried to follow the process https://community.rsa.com/docs/DOC-45917 to reset our database data but after process the createSchema script, nothing seems reset. Our identity are still presents, activities too, etc...
How can we reset the database without reinstalling the product?
Can you share the exact steps you performed?
Were there any errors during the execution of the script?
What G&L version?
Local or remote DB?
I follow the process so restarting all RSA and running the script createSchema.sh
About error, only 4 but it's about constrain violation in the database because the script try to create an existing value in setting table, but the script ended successfully to 100%(see log attached).
IGL V7.1P5 & local manual database installed but like a RemoteDB
Can you clarify the following statement in more detail?
What does it mean like RemoteDB?
"local manual database installed but like a RemoteDB"
It means I have install oracle database server not with RSA installation script so it's consider like a remote database for the product when I have install it (choice about "remote database ?" to yes)
Ok, as far as I remember the createSchema.sh only works for true local database setups because it uses the sysdba connection to drop avuser and recreate it from scratch.
If you have setup Oracle on your own this way, then the application does not have the sysdba password and cannot perform that task. I do have two useful scripts that you can run manually to do the same thing:
I created these scripts based on the 7.1.0 database setup and management guide assuming default names for all users and tablespaces. If you use a different version or different database object names, I recommend you go over the database setup and management guide from your version and create your custom CREATE_USERS_sql script.
Hope this helps
perfect, will try it ! thank you !
I keep you in touch
Hello,
I have tried the purge and two things :
1- You create users seems incomplete. (missing permissions) so I have drop again users and execute the database sample of the installation.
2- When application start, I have the following message :
Unable to create schema. (class java.lang.RuntimeException: java.lang.ClassNotFoundException: com.aveksa.migration.db.password.ViewPasswordSettingMigrator from [Module "deployment.aveksa.ear:main" from Service Module Loader])
Strange … I've done this tens of times on my labs and never had any problems. Which version and app-server did you try this on? I created this for 7.1.0.
Found the log and it's pretty weird, the script which is being used for create the schema found a schema name already existed and in my db, this name doesn't existing.
I will check with my DBA team and let you know.
This means the Drop users script didn't really finish correctly. Did you run it as sysdba? Make sure that all 3 users are dropped before running the create script.
Yes drop users has being done by a dba admin. It seems to be a bug in odb side because in my sqldeveloper, I can't see this name used. I'm in progress with them.
Hi Mostafa,
We have completly redrop users and recreate them.
When we start for the first time the application, tables seems created now but crash :
SQL/line#: /home/oracle/wildfly-10.1.0.Final/standalone/tmp/vfs/deployment/deployment9e582d7dfa8ede37/aveksa.war-5b8c7bed54fb01ab/WEB-INF/database/updates/7.0/ACM-73375.sql(1):
Start time [Fri Apr 05 10:33:48 CEST 2019]
java com.aveksa.migration.db.password.ViewPasswordSettingMigrator
java.lang.ClassNotFoundException: com.aveksa.migration.db.password.ViewPasswordSettingMigrator from [Module "deployment.aveksa.ear:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.aveksa.migration.jdbctool.SQLFileExecutor.execute(SQLFileExecutor.java:211)
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.CreateSchema.execute(CreateSchema.java:103)
at com.aveksa.migration.jdbctool.CheckDatabase.createSchema(CheckDatabase.java:1448)
at com.aveksa.migration.jdbctool.CheckDatabase.check(CheckDatabase.java:537)
at com.aveksa.server.runtime.AveksaSystem.initialize(AveksaSystem.java:309)
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:65)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:76)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[0:00:00] File Completion Time: /home/oracle/wildfly-10.1.0.Final/standalone/tmp/vfs/deployment/deployment9e582d7dfa8ede37/aveksa.war-5b8c7bed54fb01ab/WEB-INF/database/updates/7.0/ACM-73375.sql
This appears to be a bug on one of our patches. Please log a case with RSA support referencing ACM-96101 to see if they can provide you a workaround on your current patch, or apply 7.1.0 P06 as it should have the fix.
Ok thank you Mostafa, will try it with the P06.
Ok with the P6 it's better !
The error disapear but an other one pop at the end of the init about name already existed.
I have reboot the application because found no reason of this error and finally the application show up the interface and I have successfully logon.
I hope this not hide any error in backend.
Thank you for your time and your help Mostafa.
This appears to be a bug on one of our patches. Please log a case with RSA support referencing ACM-96101 to see if they can provide you a workaround on your current patch, or apply 7.1.0 P06 as it should have the fix.