Thursday Apr 02, 2015

Demantra Installing 12.2.4.1 as SYS or SYSTEM Installer Fails or is Failing

We are aware of a bug that might raise an error during the installation of the 12.2.4.1 Generic Patch recently released.

In some cases, when using SYS as the DBA user and “Enable Automatic Table Maintenance” checkbox has been checked, sys_grants.sql script which is being
run as part of the installation may fail.

sys_grants.sql is using an internal function in with a specific combination of hardware/platform may generate invalid value.

Run the installer using SYSTEM and not SYS, then, after the installation completes, replace sys_grants.sql with the attached file and run it as sys.
Make sure to add “TRUE” as the 4th parameter.

For example:

@sys_grants.sql DEMANTRA ACL_DEFAULT ACL_DEFAULT TRUE

This has been addressed in release 12.2.5.1.

Also:

Uptake of VCP 12.2.4.1 is mandatory for all VCP and Demantra 12.2.4 installations.

Are you already at 12.2.4.1?

Demantra 12.2.4.1 has a new required patch 19945449, ARU# 18420277, Demantra patch 12240066 - is now available. It was discovered that the engine throws a segmentation fault while running CDP consumption profile.  Please see the additional information in the readme Notes.

Reference Notes:
Oracle Demantra Post Release 12.2.4.1 Mandatory Patch Application - Patch 19945449 (Doc ID 1960180.1)
Demantra 12.2.4.1 Cumulative Patch. This CU is Specifically for r12.2.4.1. There are 13 Issues Patched and or Improved. (Doc ID 1952805.1)
Oracle Demantra Release Notes for Release 12.2.4.1 (Doc ID 1947062.1)
Demantra Release 12.2.4.1 Known Upgrade and Known Product Issues with Workarounds (Doc ID 1948769.1)
Oracle Demantra Demand Planning Announcing New Release 12.2.4.1 is Now Available (Doc ID 1948684.1)
Troubleshooting Demantra 12.2.4.1 Installation (Doc ID 1986634.1)

 

Wednesday Apr 01, 2015

New SQL to Determine Out of Order Ratio and Cluster Factor

Hello!  Please run the following for both mdp_matrix and sales_data.     Questions?  Email at Jeffery.goulette@oracle.com

1. The first SQL will need to be adjusted to accommodate your PK for sales_data and your PK for mdp_matrix.  Adjust the select and from clause to match your PK.   In the case of this sample, the PK was:

ITEM_ID
LOCATION_ID
SALES_DATE
IS_T_EP_SPF


-- ShowOOR.sql

SELECT (ROUND((
 (SELECT COUNT(*) AS CNT
 FROM
   (SELECT ITEM_ID,
     LOCATION_ID,
     SALES_DATE,
     IS_T_EP_SPF ,
     RELATIVE_FNO ,
     BLOCK_NUMBER ,
     ROW_NUMBER ,
     DATA_ROW ,
     (LAG(DATA_ROW) OVER(PARTITION BY RELATIVE_FNO, BLOCK_NUMBER ORDER BY ROW_NUMBER)) AS PREV_DATA_ROW
   FROM
     (SELECT ITEM_ID,
       LOCATION_ID,
       SALES_DATE,
       IS_T_EP_SPF ,
       RELATIVE_FNO ,
       BLOCK_NUMBER ,
       ROW_NUMBER ,
       (DENSE_RANK() OVER(PARTITION BY RELATIVE_FNO, BLOCK_NUMBER ORDER BY ITEM_ID,LOCATION_ID,SALES_DATE,IS_T_EP_SPF)) AS DATA_ROW
     FROM
       (SELECT ITEM_ID,
         LOCATION_ID,
         SALES_DATE,
         IS_T_EP_SPF ,
         DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) RELATIVE_FNO ,
         DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) AS BLOCK_NUMBER ,
         DBMS_ROWID.ROWID_ROW_NUMBER(ROWID)   AS ROW_NUMBER
       FROM SALES_DATA
       ) C
     ) B
   ) A
 WHERE DATA_ROW != PREV_DATA_ROW
 AND DATA_ROW   != PREV_DATA_ROW + 1
 )                               /
 (SELECT COUNT(*) FROM SALES_DATA
 )),3)*100) AS "Out Of Order Ratio %"
FROM DUAL;


-- ShowCF.sql
undefine table_name
SELECT ui.index_name, us.blocks as "Table Blocks", ui.clustering_factor as "Index clustering Factor", ut.num_rows as "Table Rows"
FROM   user_indexes     ui,
       user_tables      ut,
       user_constraints uc,
       user_segments us
WHERE  ui.table_name = ut.table_name
AND    ut.table_name = uc.table_name
AND    ui.index_name = uc.index_name
AND    ut.table_name = us.segment_name
AND    us.segment_type = 'TABLE'
AND    uc.constraint_type = 'P'
AND    ut.table_name      = '&table_name';

Wednesday Mar 18, 2015

Importing Legacy Data into Demantra, Running the Engine, Proven Process

Hello!  Are you attempting to import legacy data into Demantra?  Would you like to see the complete process from beginning to end?  How about working the process successfully using given data, becoming familiar with the process.  You can see all of this and then use the same principles to implement your legacy import.

See:

https://mosemp.us.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=371725098182420&id=800030.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=1r590meld_179

March 11, 2015:  Demantra, Are you importing Legacy data in Ascii flat files or Oracle Tables?

Questions?   Contact me directly at Jeffery.goulette@oracle.com

Thursday Feb 26, 2015

Setting Worksheet Related Parameters and Hardware Requirement Example

 Hello!   This is an example when determining how to set critical aps_params for worksheet performance:


If you expect to have 150 users with concurrency rate of 30% your setting and hardware should be:

   50 users * 30% = 45 users

   threadpool.query_run.per_user = 8

   threadpool.query_run.size = Number of concurrent users * threadpool.query_run.per_user (8) = 360

   MaxDBConnections = threadpool.query_run.size + 10 = 370

   To run a production environment with those setting you should have:

   Database: DB machine with 60 CPU's (= MaxDBConnections / 6 = 60)

   Application Server: AP with 27 CPU's (= threadpool.query_run.size/16) + 4), 4GB of memory

Only with this hardware you can run Demantra with 150 users with concurrency rate of 30%, is your hardware powerful enough for your environment?

Tuesday Feb 17, 2015

Demantra Table_Reorg. A new version has been released!

Demantra Customers, there is a new release of the table_reorg Tool.  This patch will install updates to the TABLE_REORG tool.  Demantra Version: 7.3.1.x and 12.2.x.  The minimum 7.3.1.x version is 7.3.1.3.   You can download this patch using bug 17640575 in My Oracle Support.  For additional information see MOS note:
Demantra TABLE_REORG Tool New Release with Multiple Updates! Partitions, Drop_temps and More! 7.3.1.x to 12.2.x. (Doc ID 1980408.1)

Friday Feb 13, 2015

Demantra Table Reorganization, Fragmentation, Null Columns, Primary Key, Editioning, Cluster Factor, PCT Fee, Freelist, Initrans, Automatic Segment Management (ASM), Blocksize....

Hello All!   Why does Demantra require table reordering and null column movement on a, what seems to be, frequent basis?  Your other apps do not require this type of action.  Can this be explained?   I can give you the following.  Let me know if you have questions.  Thank You!   Jeff

 

Addressing the reason why Demantra requires frequent reordering/reorganization and null column placement, I can explain the reason as follows.  As data is inserted into the Demantra table it will not be in any particular order.  The null columns will be scattered throughout the row.  The main quest is to increase throughput and reduce contention.  Since Demantra is both OLTP and data warehouse the apps DBA must tune accordingly.  Of course EBS and VCP applications have elements of both OLTP and data warehouse but are largely transaction processing at their core.  Applications such as EBS and VCP can typically provide satisfactory response time using typical DBA tuning methods.  Specifically, indexing and proper SQL tuning is plenty to improve and maintain acceptable performance.  However, large tables in data warehouse implementations require unique DBA tuning techniques to reduce IO when accessing the big database tables.  Reducing wait times by eliminating contention is the main goal of table reorganization and the movement of null columns to the end of the row.  The data warehouse requirements of Demantra are no different than other data warehouse applications.

By themselves these are not unique and are implemented in data warehouse applications every day.  For each and every read operation we want to fetch as many relevant rows as possible.  To that end we reorder the large tables according to the PK of each table.  The PK is the main access method to the data according the business requirement.  In the case of Demantra, the PK chosen covers approximately 80% of the data access needed for the main forecasting worksheets.  The rest are addressed using typical DBA tuning methods.  There are new booked, shipped orders inserted into the Demantra world daily, weekly, etc.  When this occurs, the rows naturally loose table/index locality and thus the selectiveness is reduced.  This increases the cluster factor because the number of read operations increases to fetch the desired rows.  The CBO recognizes this and calculates the access method accordingly. 

We want to assist the CBO decision making process as much as possible.  If data was static this effort would be greatly reduced.  Because the Demantra data is dynamic, we need to push the CBO our way to deliver the access plan we desire.  If the table is in Primary Key (PK) order, making your Out of Order Ratio (OOR) low, rows are brought into the SGA in sequential order.  Reducing muli-block reads to process data.  The Cluster Factor (CF) is closely related to OOR.

To review the cluster factor concept, see Demantra Large Database Object Diagnosis and Maintenance Best Practices for Best Performance (Doc ID 1629078.1)

The selectivity of a column value, the db_block_size, the avg_row_len and the cardinality all work together in helping the optimizer to decide whether to use an index versus a full table scan.  If a data column has high selectivity and a low CF, then an index scan is usually the fastest execution method.  Once your large tables are in PK order with a low CF, performance can increase dramatically.  The main goal of table reorganization is to reduce IO when accessing the big database tables.  What it does is two main things:

1. Reorders the table data according to the primary key index.
2. When using the “C” which stands for column reordering, it also pushes columns that have no data, nulls, to the end of the table row. This is good thing for tables having a high number of rows as Oracle works in a 254 columns chunks.

Some of the larger Demantra tables have upwards of 200+ columns.  Since every customer uses the Demantra tool in a different manner a portion of these columns will naturally be left as null.  Pushing the null columns to the end of the row decreases data access waits or contention by streamlining the fetch action.  The end result is a column ordered, less fragmented table that will reduce the IO operations for range operations, for example scan data between dates.  The cluster factor will be lower and thus the CBO will look at our desired access method favorably.

Demantra is sensitive to database scans therefore reviewing and implementing sound database performance techniques is essential.  While the EBS and Value Chain Planning (VCP) RDBMS can provide adequate response with proper statistics, indexes, tuning and patching, Demantra brings processing methods to the table that require tighter controls.  I will highlight some of these areas that require tighter control.

1) Tables that have 300+ columns many of the columns are null.  The columns are in the table to represent the family of Demantra solutions.  For
   example Demand Planning, Advanced Demand Planning, Promotion Planning, S&OP, etc.  When the null columns are pushed to the end of the row, the
   read operation becomes streamlined thus increasing performance.

2) Demantra moves significant amounts of data to and from the disk.  It behooves the implementer/Applications DBA to implement a strategy that reduces wait constraints.  Here is a sample of techniques that require strategic implementation attention:

   - Block size 16k or larger
   - PCTFREE set at 30% to 40%
   - FREELIST increased according to your particular implementation
   - INITRANS increased according to your particular implementation
   - Statistics maintained at a 30% sample or larger
   - Parallel Processing at every possible contention point
   - Redo size appropriate to keep switches at 3-4 per hour
   - No Automatic Segment Management (ASM)
   - No Editioning
   - Partitions implemented
   - Large SGA to accommodate multi-block reads
   - Synchronous IO implemented
   - Careful setting of Demantra CBO parameters


In conclusion, it is true that Demantra requires RDBMS implementation strategies that are unique but not uncommon for OLTP and Warehouse systems.
However, VCP requires a unique trick that is unique to VCP.  Creating statistics on empty MLOG$ objects then locking the statistics to the object.
It has been proven that this increases performance by reducing a bottleneck.

Reference Notes:
- Demantra Out of Order Ratio, Table_reorg Procedure, Partitions and Clustering Factor - Manage Your Demantra Database Objects (Doc ID 1548760.1)
- Demantra DB Health and Performance: Oracle Demantra Database Best Practices - A White Paper / Demantra Performance Clustering Factor Out of Order Ratio TABLE_REORG CHECK_REORG (Doc ID 1499638.1)
- Demantra Performance Clustering Factor Out of Order Ratio TABLE_REORG CHECK_REORG (Doc ID 1594372.1)
- Demantra How to Use TABLE_REORG to Reorder MDP_MATRIX in Primary Key (PK) Order Action Plan Version 7.3.1.3 and Later. See 1085012.1 Prior to 7.3.1.3 (Doc ID 1528966.1)
- Demantra Large Database Object Diagnosis and Maintenance Best Practices for Best Performance (Doc ID 1629078.1)
- Demantra Large Database Object Diagnosis and Maintenance Best Practices for Best Performance (Doc ID 1629078.1)

Tuesday Jan 20, 2015

Demantra Large Table Partitions and Using the Flashback Recycle bin, recyclebin, dba_recyclebin and sys.RECYCLEBIN$ Purge Best Practice

This is covered using MOS note:

Demantra Large Table Partitions and Using the Flashback Recycle bin, recyclebin, dba_recyclebin and sys.RECYCLEBIN$ Purge Best Practice (Doc ID 1962730.1)

When you are using the  feature and Oracle partitions are involved you will need to perform additional due diligence.  After the automatic
purge that occurrs when the quota is reached or after you issue a purge command to the recyclebin, you will notice that there are orphaned
BIN$ objects that consume the same space as the original partition that was dropped and the purged.

 

This was the solution based off of a customer SR that puzzled us at first.  The flashback documentation does not discuss the flashback purge
and partitions.  We recommend following the current best practice when managing the flashback feature and partitions.

If you have already performed or if the auto purge has occured, you will need to perform the following.  Of course customized to you BIN$ object name:

ALTER SESSION SET RECYCLEBIN=OFF;
drop table lpudemantra."BIN$A3+yI1NBASrgUwoVBkIBKg==$0";
drop table lpudemantra."BIN$A4gGznhiAVbgUwoVBkIBVg==$0";
.
.
.
.
drop table lpudemantra."BIN$9WCVYRl3BGbgQwoVBkIEZg==$0";

If you have not experienced the purge of the recycle bin, attempt the following:

  1) select count(*) from sys.recyclebin$;

  2) Instead of simply trying to purge the table we can use the following alternative:

     a) flashback table <table_name> to before drop;

          or

          if  <table_name> is currently used by another object:

        flashback table <table_name> to before drop rename to <new_table_name>;


     b) create a script that will drop all the partitions one by one :

        spool drop_<table_name>_partitions.sql

        select 'alter table '|| table_owner|| '.'|| table_name ||' drop partition '|| partition_name||';'
        from dba_tab_partitions
        where table_name='<table_name>'
        /

        spool off


     c) run drop_<table_name>_partitions.sql


     d) drop table <table_name>;


     e) purge recyclebin;


To turn off the recyclebin
  - alter system set recyclebin=off scope=spfile;

Friday Jan 09, 2015

Demantra 12.2.4.1. Are you upgrading or have upgraded? New Mandatory Patch is available.

Are you already at 12.2.4.1?  Demantra 12.2.4.1 has a new required patch 19945449, ARU# 18420277, Demantra patch 12240066 - is now available.
It was discovered that the engine throws a segmentation fault while running CDP consumption profile.  Please see the additional information in the readme Notes.

Wednesday Dec 17, 2014

Demantra 12.2.4.1 Has Been Released. See details below

Hello Demantra Customers!  Are you at version 12.2.4?  A new cumulative patch has been released.  This 12.2.4.1 cumulative patch is different to the 12.2.x patch strategies in the respect that it will only contain fixes that are new to 12.2.4.  

Uptake of VCP 12.2.4.1 is mandatory for all VCP and Demantra 12.2.4 installations.

    Demantra Patch Number is 19973580.
    For E1 customers Long Item Code  Patch Number is 19608405.
    Demantra 12.2.4.1 will only work with VCP 12.2.4.1.
    Demantra 12.2.4.1 and VCP 12.2.4.1 will work with EBS 12.1.3 or EBS 12.2.4.

see MOS Note:

Demantra 12.2.4.1 Cumulative Patch. This CU is Specifically for r12.2.4.1. There are 13 Issues Patched and or Improved. (Doc ID 1952805.1)

and

Oracle Demantra Demand Planning Announcing New Release 12.2.4.1 is Now Available (Doc ID 1948684.1)

and

Demantra Release 12.2.4.1 Known Upgrade and Known Product Issues with Workarounds (Doc ID 1948769.1)

and

Oracle Value Chain Planning (VCP) Readme, Release 12.2.4.1 (Doc ID 1931390.1)

Wednesday Dec 10, 2014

Hello Demantra Customers! Are you at version 12.2.4.1? A new cumulative patch will be released soon.

Hello Demantra Customers!  Are you at version 12.2.4.1?  A new cumulative patch will be released soon.  This 12.2.4.1 cumulative patch is different to the 12.2.x patch strategies in the respect
that it will only contain fixes that are new to 12.2.4.1.  This cumulative patch is scheduled to be released later this month, December 2014.  To monitor, see this note, 1952805.1 or visit the Oracle Demantra BLOG at https://blogs.oracle.com/demantra/

Wednesday Nov 26, 2014

Oracle Demantra Demand Planning Announcing New Release 12.2.4.1 is Now Available MOS Note 1948684.1

Announcing Oracle Demantra Demand Planning 12.2.4.1 Release

We are excited to announce Oracle Demantra Demand Planning 12.2.4.1 is now available for new and existing customers.

Oracle Demantra Demand Planning 12.2.4.1 includes several features in 12.2.4. Key features include:

  • Oracle In-Memory Consumption-Driven Planning
  • 64-bit Analytical Engine
  • User Access Control
  • Additional Demantra Hierarchies in APCC
  • Launch Management Extended to DM and PTP Components
  • APCC Support for Trade Hierarchies and Data
  • Streamlined Promotion Creation and Improved Method Usability
  • Promotion Calendar Enhancements
  • Printing Promotion Calendar
  • Streamlined Simulations
  • Enhanced Shipment and Consumption Planning Support
  • Demantra- Improved Worksheet Performance
  • VCP and Demantra- Support E1 Long Item Code
  • VCP and Demantra- Certified with Oracle 12.1.0.2 DB in Memory


Uptake of VCP 12.2.4.1 is mandatory for all VCP and Demantra 12.2.4 installations.

  • Demantra Patch Number is 19973580.
  • For E1 customers Long Item Code  Patch Number is 19608405.
  • Demantra 12.2.4.1 will only work with VCP 12.2.4.1.
  • Demantra 12.2.4.1 and VCP 12.2.4.1 will work with EBS 12.1.3 or EBS 12.2.4.


Questions?


If you would like additional information regarding Oracle Demantra 12.2.4.1 functionality, certification and deployment please refer to the Demanta Documentation Library on My Oracle Support (Document  443969.1).

Contact Jeffery.goulette@oracle.com with direct questions.   Regards!   Jeff

Monday Nov 24, 2014

UPDATED: Does Demantra support Edition Based Redefinition (EBR)? How do I address EBR in my EBS instance?

Hello Demantra Customers!  Do you know what Edition Based Redefinition (EBR) is or how it impacts Demantra?  EBS uses EBR for online patching.

There is a new update to the referenced MOS note below.  Demantra DOES NOT support Edition Based Redefinition. 

Edition-Based Redefinition enables you to upgrade an application's database objects while the application is in use, thus minimizing or eliminating down time. This is accomplished by changing (redefining) database objects in a private environment known as an edition.  Only when all changes have been made and tested do you make the new version of the application available to users.

Edition-based redefinition allows multiple versions of PL/SQL objects, views and synonyms in a single schema, which makes it possible to perform upgrades of database applications with zero down time.

Large, mission critical applications built on Oracle Database 11g Release 1 and earlier versions are often unavailable for tens of hours while the application’s database objects are patched or upgraded.  Oracle Database 11g Release 2 introduces edition-based redefinition, a revolutionary new capability that allows online application upgrades with uninterrupted availability of the application.  When the installation of the upgrade is complete, the pre-upgrade application and the post-upgrade application can be used at the same time.

EBS supports EBR from the 12.2 release onwards in the online patching feature.

To read about EBR and Demantra, see the new white paper, Oracle Demantra and RDBMS Edition-Based Redefinition (EBR) EBS schema - Processing and Patching (Doc ID 1932210.1)

Friday Oct 31, 2014

Demantra Upgrading to 12.2.x? Critical Known Issues and Lessons Learned

Oracle Demantra customer, are you considering an upgrade to you Oracle Demantra software?  There are three ciritical MOS notes that you may want to review.

  • 12.2.1, 12.2.2, 12.2.3 and 12.2.4 Install Upgrade ADVISOR: Demantra (Doc ID 1664177.2)
  • DEMANTRA WARNING Have you OR are you Planning to Upgrade to Release 12.2.2? Upgrade from 12.2.2 to 12.2.3 or 12.2.4 Collections EP Load is Failing ORA-20002, ORA-00001, ORA-06512 (Doc ID 1917715.1)
  • Upgrading to Demantra 12.2.4? Here are current known issues from Demantra Development, Proactive Services and Oracle Support (Doc ID 1928367.1)

New White Papers in Development Sponsored White Paper Library!

Hello Demantra Customers!  There is a new Development sponsored Value Chain Planning and Demantra library!  This library is exclusive to Demantra Development and Oracle Proactive Support.  There are excellent white papers and more!  See Development and Proactive Services Document Library White Papers (Doc ID 1669052.1)

 As of today, we provide

    Value Chain Planning
    - ASCP Data Collections
    - Demantra Demand Planning  * see below
    - Strategic Network Optimization
    - Rapid Planning
    - Global Order Promising
    - Collaborative Planning
    - WebLogic
    - IO Inventory Optimization
    - SPP Service Parts Planning
    - DP Distribution Planning
    - Integration
    - Information Centers

    Specifically for Demantra
    - Architecture
    - Install and Upgrade
    - Integration, Data Loading and CTO
    - Workflow Issues
    - Worksheet Related
    - Engine Related
    - Performance
    - User Interface Use and Design
    - Diagnostic Tools
    - Weblogic Related

Demantra Development Sponsored White Paper Library, NEW ADDITIONS!

Hello Demantra Customers!  As you know we a Development and Proactive Services document library.  These are hand picked, powerful notes.  Two new notes have been added;

Custom Hierarcies and Demantra SSO using Oracle Access Manager (OAM) 11g - synchronization between Demantra and Oracle Identity Management / Oracle Virtual Directory (OID/OVD).

Look under Demantra Worksheets and Demantra Integration.  See My Oracle Support note 1669052.1.

About

This blog delivers the latest information regarding performance and install/upgrade. Comments welcome

Search

Archives
« April 2015
SunMonTueWedThuFriSat
   
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  
       
Today