We are seeing an Oracle error during OM package import related to the number of open cursors. We checked the documentation, but there is no recommendation of what the cursor size should be for large OM package imports. We are currently on 500. Has anyone seen this issue or performed a successful upgrade in this regard? What is the optimal cursor size being used by different clients?
I checked with one of the senior TRIRIGA architects, and he said he would recommend setting open_cursors to at least 2000 for an OM package import. I hope this information helps!
[Admin: To see other related posts, use the Object Migration tag or Upgrade tag.]
I wanted to see if anyone has set up the following settings in an Oracle Database for TRIRIGA 10.5.2 and 3.5.2:
- 1. NLS_LENGTH_SEMANTICS: Should this be set to CHAR? In our current production environment, it’s set to BYTE, but the TRIRIGA support documentation says that this can lead to data loss, so they recommend using CHAR.
- 2. NLS_CHARACTERSET: This is set to WE8ISO8859P1 in our current production environment, but the support document says that it must be UTF-8 or UTF-16.
- 3. Block size: This is set to 8k, but the documentation recommends using 16k.
For (1) and (2), if you never want to store multibyte characters, then what you have is fine. But if you do, then you must use what the support documentation suggests. Once you have your database created, it is difficult and time-consuming to change it, and it needs to be done outside of TRIRIGA. As for (3), I would encourage you to use 16k, since it will allow you better throughput and paging, unless you have a strong reason why you need to stay at 8k.
[Admin: This post is related to the 04.04.16 post about database character settings. NLS refers to National Language Support parameters in Oracle. To see other related posts, use the Multibyte tag, MBCS tag, or NLS tag.]
The most critical aspect of all production systems is being able to ensure high-availability in case of critical failures. The traditional approach was to operate a disaster recovery site and fail-over clusters. This requires 24×7 maintenance and monitoring activities and adds the significant costs for hardware, software, and human resources engaged. Due to this, many companies opt-out of having the high-availability for their EAM system.
Thankfully, there is a new option with database-as-a-service (DBaaS) offerings being provided by all major database vendors. Providing a high-availability system for 10,000 users can now be achieved by filling the single web form. You will then be provided with a database service that is available 24×7 and all maintenance, monitoring, and backup activities are automated in the background.
We tested DBaaS offerings from several vendors such as Amazon, Microsoft, and Oracle and found all of them being able to deliver on their promise. Although some products like IBM Maximo and IBM TRIRIGA are not officially certified for these platforms, we managed to successfully migrate several clients to a DBaaS database on Oracle and MS SQL Server…
[Admin: To see other related posts, use the High Availability tag or SaaS tag.]
Does anyone have any experience in extracting TRIRIGA data from the database directly through Oracle SQL Developer? I am trying to extract through SQL code, and combine in one table, the data from triSpace, triSpaceClassCurrent, and triSpaceStandardsSpec. The idea is to create a single table with all spaces, space classifications, and space standards.
[Admin: To see other related posts, use the Oracle tag or SQL tag.]
We imported an Oracle 12c database dump from a TRIRIGA platform running TRIRIGA 126.96.36.199 into another Oracle 12c server. The Oracle Data Pump Import (impdp) completed without error. The plan was to install and upgrade the TRIRIGA platform to 3.5.2. This is something we’ve done multiple times with different releases. So platform upgrades are usually painless.
We went right through the upgrade process dialogs, a successful database server conductivity test, but here’s something we’ve never experienced before. Instead of installing and upgrading the database to the new platform, “Installed by InstallAnywhere 17.0 Premier Build 5158” throws up the following dialog box.
“Upgrade Not Supported. An upgrade from the version of your platform is no longer supported. Please upgrade to 188.8.131.52 first, before upgrading to this platform version. Back or Exit.”
Does anyone have any ideas why we are getting this message?
We found the issue. The schema name was “TR1DATA”, not “TRIDATA”. The terminal font was not showing a clear distinction between “1” and “I”. We’d better take a much closer look next time. Thanks for the assistance from everyone.
After upgrading to TRIRIGA 3.5.1.x or later, some customers are having issues with thumbnail images on reports and/or queries not being displayed correctly.
WebLogic incorrectly parses a JSP by adding white space that corrupts image thumbnails. Meanwhile, WebSphere and Liberty parse the JSP correctly. Moving forward, we resolved an issue where Oracle WebLogic was incorrectly interpreting TRIRIGA code, and injecting extra white space that caused thumbnail images to be displayed as broken images.