Migrating Databases to Advisors Release 8.5.2

Content on this page is specific to migrating your Genesys Performance Management Advisors database installations to Advisors release 8.5.2.

General Considerations

• Starting with Advisors release 8.5.202, both the Platform and the Metric Graphing database scripts are supplied in the Platform IP in the ip\platform-database-sql and \ip\metric-graphing-database-sql folders, respectively.
• Upgrade all AGA metrics schemas before you start the Platform schema upgrade.
• If you have the Bulk Configuration tool installed, you need to upgrade it separately by executing the blkObjectsCre.sql script taken from the corresponding folder in \ip\platform-database-sql\<rdbms>\bulkconfig. The blkObjectsCre.sql script must be applied after the general migration script is applied.

Migrating MS SQL Server Databases to Advisors Release 8.5.2

To migrate MS SQL Server databases to release 8.5.2:

1. Stop all Advisors components.
2. Apply the gc_metrics_db_<version>.sql script, supplied in the \ip\configuration-schema\mssql folder of the AGA installation package, to the AGA metrics database of any version.
3. Apply the advisors-platform-migrateSchema_8.5.101(102)-<version>.sql script, supplied in the corresponding folder within the \ip\platform-database-sql\mssql\ folder, to the Platform database of any version between, and including, 8.5.101 and the current release.
4. Apply the mg-new-database-<version>.sql script, supplied in the corresponding folder within the \ip\metric-graphing-database-sql\ folder, to the metric graphing database of any version between, and including, 8.5.101 and the current release.

Migrating Oracle Schemas to Advisors Release 8.5.2

If you use Oracle databases in your environment, use the procedure on this page to migrate to Advisors release 8.5.2.

Prerequisites

• Ensure that you have a backup of your current Advisors components and all associated configuration before migration. In particular, you must back up the Platform database. Genesys strongly recommends that you also back up the Metric Graphing database and the Advisors Genesys Adapter metrics database. Before proceeding with the procedure on this page, ensure that your backup databases can be restored.
• If you moved Advisors schemas to another Oracle database, run the DBMS_SCHEDULER.sql script as a privileged user to create a job class for Advisors, or ask your DBA to run the script. This is a one-time, database-wide operation that does not need to be repeated as long as the same Oracle database is used.
• Advisors release 8.5.2 supports the Oracle 12C In-Memory option. If you choose to use the In-Memory option, have your DBA enable the option. Enabling the option can result in extra charges from Oracle, so make sure you have confirmed the choice with your management team.
• Advisors release 8.5.2 needs the Oracle JServer Java Virtual Machine component installed in the Oracle database. If the component is not installed, and cannot be added to the existing Oracle installation, ask your DBA to grant the following privilege:

  GRANT EXECUTE ON SYS.DBMS_LOCK TO <Platform schema owner>;

1. Migrate the AGA metrics schema objects.

Note that there is no need to run the gc_metrics_<version>_ObjectsDrop.sql script before the object creation script while upgrading the AGA metrics schema. The object creation script will replace the existing objects, where necessary. Do one of the following:

• If you use SQL*Plus, apply the gc_metrics_<version>_ObjectsPlus.sql script while connected as the AGA Metrics schema owner.
• If you want all of the AGA metrics objects recreated in the AGA Metrics user default tablespace, connect as the AGA Metrics schema owner and run the gc_metrics_<version>_ObjectsDefault.sql script from Oracle SQL Developer or SQL*Plus.
• If you want to separate the AGA metrics objects by placing them into different tablespaces, and want to use SLQ Developer, then run the gc_metrics_<version>_ObjectsCustom.sql script while connected as AGA Metrics schema owner.

After you have performed one of the preceding actions, then do the following, if applicable:

• If you are using the In-Memory option, then execute gc_metrics_<version>_INMEMORY.sql in AGA metrics schema. This change can be easily reverted at any time by running the gc_metrics_<version>_NO_INMEMORY.sql script.

Finally, perform the following mandatory action:

• Grant select permissions to the Platform user on all views contained in the migrated AGA metrics schema. If such permissions were granted earlier, you still have to re-issue them before you proceed to the next Step.

Repeat all of the above for each schema if you use more than one AGA metrics schema.

2. Migrate the Platform schema objects.

To migrate the Platform schema objects, do the following:

• Ask your DBA to grant the following privileges to the Platform schema owner:

GRANT EXECUTE ON SYS.GENADVISORSJOBCLASS TO &&platformschemaowner;
GRANT CREATE JOB TO &&platformschemaowner;

• Make sure that the Platform schema owner has select privileges to all views that belong to all GENESYS sources listed in the Platform ICM_DATABASE table.

  To verify the privileges, connect as the Platform schema owner and run the following set of queries for each <AGA Metrics Schema Name> listed in the Platform ICM_DATABASE table.

SELECT * FROM  <aga metrics="" schema="" name="">.AGENT_SKILL_GROUP_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.CALL_TYPE WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.CALL_TYPE_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.CONTROLLER_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.INTERACTION_QUEUE WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.INTERACTION_QUEUE_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.LOGICAL_INTERFACE_CONTROLLER WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.PERIPHERAL WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.PERIPHERAL_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.SERVICE WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.SERVICE_MEMBER WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.SERVICE_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.SKILL_GROUP WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.SKILL_GROUP_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.QUEUE_SET1_REAL_TIME WHERE ROWNUM<2;
SELECT * FROM  <aga metrics="" schema="" name="">.QUEUE_SET2_REAL_TIME WHERE ROWNUM<2;

• Re-issue the select privileges on any <AGA Metrics Schema Name> views where they are missing.

  To do this, connect as an AGA Metrics schema owner, issue the following command, copy the result, and execute it as a script while connected as the AGA Metrics schema owner:

SELECT 'GRANT SELECT ON '||view_name||' to <platform schema owner>;' FROM USER_VIEWS;

Once all privileges are in place, proceed to the next item.

• Verify that there are no live sessions from any machine that hosts the Advisors components, or ask your DBA to implement this verification. Any hanging sessions can be killed.
• Connect as the Platform user and execute the advisors-platform-migrateSchema_8.5.101(102)_<version>.sql script supplied in the Platform installation package.

  If you have your Platform schema in a database that does not have the JServer component installed, use the migration script for the database installation without JServer. The migration script for Oracle that does not have JServer installed can be located in the /ip/sql/platform-database-sql/oracle/oracleNoJserver directory.

• Wait for the Platform script to finish the execution.
• Verify that the PATCH_LOG table contains a record about the applied migration script.
• If you are using the In-Memory option, execute the advisors-platform-<version>_INMEMORY.sql script. If necessary, this change can be easily reverted by running the advisors-platform-<version>_NO_INMEMORY script.
• If you have the bulk configuration tool installed, upgrade it by running the blkObjectsCre.sql script taken from the corresponding folder in the \ip\platform-database-sql\oracle\bulkconfig directory.
• Review and consider the information provided in the Database Recommendations for Oracle Users section of the Genesys Performance Management Advisors Deployment Guide.
• If you are migrating to Advisors release 8.5.202.09, and you have an installation with CISCO ICM, you must apply the advisors-platform-8.5.202.09_CiscoPostInstall.sql post-installation script, which can be found in the \ip\platform-database-sql\oracle\CISCO folder. The script must be applied before you start any of the 8.5.202.09 components for the first time.

   

  If you make a mistake and start the components before you apply this script, stop all components, verify that there are no live sessions from any machine that hosts Advisors components, connect as the Platform schema owner, and issue the following command:

DELETE tmpImportCallType;
COMMIT;

• Once that has completed, re-run the advisors-platform-8.5.202.09_CiscoPostInstall.sql script.

  In addition to the preceding action, you can also repeat the verification script described in the Database Recommendations for Oracle Users section of the Performance Management Advisors Deployment Guide.

   

  There is no negative impact if you execute the advisors-platform-8.5.202.09_CiscoPostInstall.sql script more than once, or if you execute the script in installations that do not use CISCO ICM.

3. Migrate the metric graphing schema.

To migrate the metric graphing schema:

• You can completely recreate the metric graphing schema as there is no need to preserve any data in it, or you can run the migrate_mg_8.5.101.15_<version>.sql migration script against the existing schema.
• If you are using the In-Memory option, then execute the mg-<version>_INMEMORY.sql script against the metric graphing schema. This change can be easily reverted by running the mg-<version>_NO_INMEMORY script.

Other considerations

In addition to migrating the Oracle databases according to the preceding procedure, be sure to read the following notes carefully for additional work that might be required in your environment.

• Make sure that you do not mention any data sources in the CCAdv/WA installer, or, if you do, be sure to specify the names that exactly match the current ICM_DATABASE content.
• If any schema listed in the Platform ICM_DATABASE table no longer needed, it must be removed from Platform ICM_DATABASE table and the corresponding AGA metrics schema must be dropped from the Oracle database. Contact Genesys support if you have difficulties with deleting the obsolete entry from the Platform ICM_DATABASE.
• Starting with Advisors release 8.5.202, the Advisors components can access the database using low-privileged, runtime application user accounts (Oracle installations) or database user accounts (MS SQL Server installations) rather than schema/database owner accounts.

  If you choose the least privilege option for your current installation, or if you had the “Least Privileges” setup in your previous installation, then before you run the Advisors installation wizards, make sure that you do the following:

  • Reinstate all privileges granted in the previous installation, if applicable.
  • Grant new object privileges by following the instructions contained in the following section of the Pulse Advisors Deployment Guide: Least Privileges: How to Configure Advisors Database Accounts with Minimal Privileges.

  In Oracle installations, the minimum version of Oracle with which you can use the “Least Privileges” feature is Oracle 12c R2.

• After running the installer wizards, verify the content of the AGA_INSTANCES and CLUSTER_MEMBER tables and remove obsolete content, if any exists.
• If you see an "ORA-28040: No matching authentication protocol" error in the XML Generator application log, do not try to start the application again; the XML Generator Oracle user account might lock if XML Generator makes too many attempts to start.

  Have your DBA review the issue and follow his/her recommendation.

  Resolving the issue might require a stronger password or possibly lowering the SQLNET.ALLOWED_LOGON_VERSION_SERVER setting to an acceptable level.