Share all details about your problem, including any error messages you may have received.
Hi All, our team is trying to upgrade from IIQ 8.2p1 to 8.4p2 “definitely after upgrading to 8.3”
The upgrade process was done successfully from 8.2p1 to 8.3GA, but it’s failing to go to 8.4, the error is:
FAILURE: An unexpected error occurred: Could not find unique class sailpoint.object.YAMLConfig with name AccessHistoryExtractConfig
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist
I attached the logs here as well
Our team checked identityiq jar, and it contains the YAMLConfig class as well, then they asked the customer to give a DBAdmin privilages to the user but still with no luck…
Is deploying the latest patch 8.4p2 an option for you? This is because I’ve seen that it includes major fixes in areas such as ActiveMQ, Data Extract, and Access history.
That error seems suspect in the fact that not all the database scripts were run. I would re-run the DDLs and make sure you create the access history schema, tables and update the iiq.properties connection string.
Though I haven’t tried through SSB, I can say by seeing logs that - error (ORA-00942: table or view does not exist) is database related. IIQ 8.4 involves major changes at DB end too where it creates new database (identityiqai) along with identityiq and identityiqplugin, also new tables are added at identityiq database. Make sure all these DB and tables are present, can execute DDL again and cross check the permissions too.
In addition to previous comments and instructions I would like to add additional pointers validation checks at database/schema level:
from Database: Security → Logins → right click on identityiqProperties – > User Mapping
validate the correct settings of below three values for all three databases(identityiq,identityiqPlugin,identityiqah) |Databse|User|Default Schema|
check the presence of the identityiq.spt_yamlconfig table with below values.
identityiqah – new access history database required mandate staring from IIQ 8.4 even if you are not planning to use it for a successful upgradation/migration.
verify the version specific details in below tables: identityiq.spt_database_version identityiqah.spt_hist_database_version
These will help validate successful schema upgrade.
Note:
There’s no need to update the schema_version in the tables below during a fresh installation, but it might be necessary during an upgrade.
update identityiqah.spt_hist_database_version set schema_version = '8.4-87' where name = 'main':
commit;
update identityiq.spt_database_version set schema_version = '8.4-87' where name = 'main';
commit;
../WEB-INF/classes log4j.properties – changed to log4j2.properties
Hi @iiq-isc, thsnks a lot for your reply.
Actually p2 is necessarily, but they are not reaching to this point even (which is patching 8.4GA with the latest patch)…
It’s failing with this error from 8.3 to 8.4
Thanks a lot @phodgdon for your reply and yes, seems it’s DB issue, however they made sure that the scripts were run successfully and the DB also created successfully (multiple times), which is weird…
Also iiq.properites updated correctly.
Hi @Arpitha1 thanks a lot for your reply, it’s not SSB one, and yes, seems it’s DB issue, however they made sure that the scripts were run successfully and the DB also created successfully (multiple times), which is weird…
This issue has previously occurred in my experience. To address it, begin by verifying the user configured in the iiq.properties file for database access. If you are using a database user other than the default IDENTITYIQ schema owner, ensure that appropriate synonyms are created in your schema for the newly introduced tables under the IDENTITYIQ schema.
This step is necessary due to the way SailPoint IdentityIQ utilizes Hibernate for object-relational mapping. Hibernate expects direct access to specific table names without fully qualifying them with the schema. As a result, missing synonyms can lead to errors during runtime or upgrade processes when the application attempts to query tables that are not directly visible to the configured user.
Thanks a lot @iiq-isc, @phodgdon, @pattabhi for contributing to the topic, really appreciated and thanks again for taking some time to check and reply.
@MohamedSaad that works and I marked it as a solution, thanks over and over again :).
