During TRIRIGA install, we encountered “Build Failed” and the Oracle WebLogic log contained the following. What happened?
####<Jan 23, 2018 4:47:14 PM ART> <Error> <Deployer>
<S-Tririga> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <7bf5687e-a5eb-47f9-9610-fd0f96db07ae-0000042e> <1516736834996> <BEA-149265> <Failure occurred in the execution of deployment request with ID "7285840482438638" for task "2". Error is:
[Admin: To see other related posts, use the WebLogic or Installation tag.]
We have an issue where sometimes after applying a cost code template to a project, the hierarchy path will not be complete. It will be missing all of the parent path and only shows the name. This issue is only visible in the app by viewing the System Path field inside the form or by using a SQL query, because the system path in the T_TRICOSTCODE table is correct, but the object path field in the IBS_SPEC table is the one that’s not complete. The issue does not have much consequence unless you are using the rollup fields, in which case the corrupt cost code path will cause a posted transaction to fail.
If there are customers who use cost codes heavily, you can try running the following SQL, and if you get any results back, then that means the issue is present at some level in your environment. It is not necessary that you use the Apply Template to create your cost codes, as I have heard of others having the issue where their cost codes are created via an integration. This SQL is for Oracle and may need a tweak for SQL Server. If any customers can run this, and see if they have the issue, it may help us identify how it happens.
select tripathsy, triprojectnamesy, OBJECT_PATH from t_tricostcode T1, IBS_SPEC T2 where T1.spec_id in (select spec_id from ibs_Spec where type_name = ‘triCostCode’ and object_path not like ‘%\Cost Code%’) AND T1.spec_id = T2.spec_id and tripathsy like ‘%\Cost Code%’
[Admin: To see other related posts, use the Cost Code tag or Templates tag.]
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 188.8.131.52 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 184.108.40.206 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.