Thursday, January 23, 2020
Tuesday, January 21, 2020
EPM 11.2
Hi All,
I am posting all the related links or documents for EPM 11.2
https://www.youtube.com/watch?v=jNSQiGfN0ec&t=1929s
I am posting all the related links or documents for EPM 11.2
https://www.youtube.com/watch?v=jNSQiGfN0ec&t=1929s
HFM Deployment to EPMA is Hung At 22% With Status Of "Running" and Never Completes
HFM deployment in EPMA is hung at 22% with status of "Running" and never completes. HSVDatasource utilizes CPU and memory, but never finishes deployment in hsveventlog.log.
Solution:
Make the period dimension symmetrical by making sure that all hierarchies have the same number of levels.
Solution:
Make the period dimension symmetrical by making sure that all hierarchies have the same number of levels.
Tuesday, January 14, 2020
FDMEE ADF_FACES-60096:Server Exception during PPR
Symptoms:
JBO-29114 ADFContext is not setup to process messages for this exception. Use the exception stack trace and error code to investigate the root cause of this exception. Root cause error code is JBO-26061.
ADF_FACES-60097:For more information, please see the server's error log for an entry beginning with: ADF_FACES-60096:Server Exception during PPR, #2
Solution:
Please change the session timeout for FDMEE using the below steps:
1. Login to weblogic console in the environment
2. Select Deployments from the Domain structure panel in the left
3. Select aif
4. Navigate to the configuration tab
5. Change the value of 'Session Invalidation Interval (in seconds):' to 600
6. Ensure the value of 'Session Timeout (in seconds):' is 36000
Plesae check Intermittent ADF errors after FDMEE has been idle for a short time (Doc ID 2131492
JBO-29114 ADFContext is not setup to process messages for this exception. Use the exception stack trace and error code to investigate the root cause of this exception. Root cause error code is JBO-26061.
ADF_FACES-60097:For more information, please see the server's error log for an entry beginning with: ADF_FACES-60096:Server Exception during PPR, #2
Solution:
Please change the session timeout for FDMEE using the below steps:
1. Login to weblogic console in the environment
2. Select Deployments from the Domain structure panel in the left
3. Select aif
4. Navigate to the configuration tab
5. Change the value of 'Session Invalidation Interval (in seconds):' to 600
6. Ensure the value of 'Session Timeout (in seconds):' is 36000
Plesae check Intermittent ADF errors after FDMEE has been idle for a short time (Doc ID 2131492
Wednesday, January 8, 2020
FDMEE Tablespace reached max size like 90
Percentage of Used Bytes of FDMEE is critical because its value 90 >= 90 %.
[Threshold Details : Critical if value >= 90, Warning if value >= 85, Clear if value < 85]User Message : CRITICAL : Tablespace greater than 90% used
Solution:
We have resize the datafile of FDMEE. Below are the details.
Tablespace Used MB Free MB Total MB % Free
[Threshold Details : Critical if value >= 90, Warning if value >= 85, Clear if value < 85]User Message : CRITICAL : Tablespace greater than 90% used
Solution:
We have resize the datafile of FDMEE. Below are the details.
Tablespace Used MB Free MB Total MB % Free
Tuesday, January 7, 2020
Transaction control table is full. Its number of entries reaches the limit
Essbase Database is Not Accessible, Error "Transaction control table is full. Its number of entries reaches the limit [64512]" (Doc ID 2378147.1)
Steps to resolve: If there is no backup
Steps to resolve: If there is no backup
Can implement the below action plan
1 Restore from Backup
2 Run the below Commands and
NOTE: This workaround could take a long time to complete, there is no way to determine how long. You may want to schedule this to run overnight while no users are accessing the system.
1. Using ESSCMD, run getdbstats; confirm that database has successfully loaded.
2. Replicate the tct full message.
3. Add the following undocumented settings to the essbase.cfg. There is no need to restart the Essbase service):
EVENT 65
EVENT 69
__TCTCleanupDmEndedTxnThreshold__ 1
4. Reload the database using MaxL:
alter application <appname> unload database <dbname>;
alter application <appname> load database <dbname>;
5. If starting the database does not trigger a TMG cleanup, bounce the application again.
6. If after restarting the application it still does not trigger cleanup try below using MaxL:
alter database <appname>.<dbname> begin archive to <filename>;
alter database <appname>.<dbname> end archive;
7. In the application.log you should see messages that being with:
tracing [adTmgCleanup] and/or tracing [adTmgCleanupTransAsync]
and one of the message would be:
tracing: Transaction Cleanup cycle [1] begins.
If on Unix, you can run the following command at the os level and check for the cleanup messages:
tail -f application.log
8. After the process is done, remove the following 2 entries:
EVENT 65
EVENT 69
The following entry's value should be set to 50 instead of 1:
__TCTCleanupDmEndedTxnThreshold__ 50
This setting, __TCTCleanupDmEndedTxnThreshold__, provides a threshold count of ended transaction. Upon exceeding this limit server will trigger cleanup of the transaction control table. Default is 512.
Note: After upgrade to 11.1.2.4.022+ the setting __TCTCleanupDmEndedTxnThreshold__ 50 does not need to remain in the essbase.cfg file.
1 Restore from Backup
2 Run the below Commands and
NOTE: This workaround could take a long time to complete, there is no way to determine how long. You may want to schedule this to run overnight while no users are accessing the system.
1. Using ESSCMD, run getdbstats; confirm that database has successfully loaded.
2. Replicate the tct full message.
3. Add the following undocumented settings to the essbase.cfg. There is no need to restart the Essbase service):
EVENT 65
EVENT 69
__TCTCleanupDmEndedTxnThreshold__ 1
4. Reload the database using MaxL:
alter application <appname> unload database <dbname>;
alter application <appname> load database <dbname>;
5. If starting the database does not trigger a TMG cleanup, bounce the application again.
6. If after restarting the application it still does not trigger cleanup try below using MaxL:
alter database <appname>.<dbname> begin archive to <filename>;
alter database <appname>.<dbname> end archive;
7. In the application.log you should see messages that being with:
tracing [adTmgCleanup] and/or tracing [adTmgCleanupTransAsync]
and one of the message would be:
tracing: Transaction Cleanup cycle [1] begins.
If on Unix, you can run the following command at the os level and check for the cleanup messages:
tail -f application.log
8. After the process is done, remove the following 2 entries:
EVENT 65
EVENT 69
The following entry's value should be set to 50 instead of 1:
__TCTCleanupDmEndedTxnThreshold__ 50
This setting, __TCTCleanupDmEndedTxnThreshold__, provides a threshold count of ended transaction. Upon exceeding this limit server will trigger cleanup of the transaction control table. Default is 512.
Note: After upgrade to 11.1.2.4.022+ the setting __TCTCleanupDmEndedTxnThreshold__ 50 does not need to remain in the essbase.cfg file.
Subscribe to:
Posts (Atom)