| Oracle® Retail Advanced Inventory Planning Operations Guide Release 14.1.1 |
|
 Previous |
 Next |
The maintenance of servers and applications is an ongoing necessity. Occasionally, it may be necessary to perform maintenance on the existing AIP RPAS global domain.
Refer to the Oracle Retail Advanced Inventory Planning Implementation Guide for information on configuring and partitioning AIP RPAS domains at build time.
There are three directory path references inside of an AIP global domain that must be mentioned before discussing domain relocation.
Table 9-1 Directory Path References
|
globaldomainconfig.xml |
The AIP Implementation Guide provides instructions regarding customizing the globaldomainconfig.xml file required for an RPAS domain build using the build_aip_domains.ksh script. This XML file contains the absolute path to all domain components, namely, the master domain path and all local domain paths. |
|
configmeasdata.db |
The master domain contains the directory configmeasdata.db, located in $AIPDOMAIN/data directory. This directory contains an array named r_subdomainpath%1 which contains a map from all partitioning dimension positions to the local domains which contain each position. |
|
admin.db |
Each local domain contains the directory admin.db, located in each local domain's data directory. This directory contains an array named domain_properties. This array contains the path to the master domain. |
It is important that these references to the master domain's path and local domains' paths be synchronized at all times to ensure the global domain's integrity. Following the procedures in this chapter ensures the pointers are correct. Using UNIX mv or cp on the domain build directory (master domain) or sub-directories (local domains) results in a corrupted set of internal links.
In addition, the shell script $RPAS_HOME/bin/aip_env_rpas.sh contains the assignment of the $AIPDOMAIN variable. If the master domain is moved, then the $AIPDOMAIN variable must also be updated to reflect the new path.
The standard domain build procedure described in the AIP Installation Guide and AIP Implementation Guide specifies that the absolute path to each domain component be specified in the globaldomainconfig.xml file prior to running the build_aip_domains.ksh script. As a result, the three references listed in Table 9-1 contain absolute paths at the conclusion of the domain build process.
The globaldomainconfig.xml can be configured such that the master domain and local domains do not reside in the same directory. For example, the local domains can, but do not have to, be subdirectories of the master domain. This is configurable according to the needs of the client to accommodate disk space.
There are two supported utilities that can be run on the AIP domain to relocate all or part of the domain from one directory to another directory. Operations that are supported are those which maintain the integrity and correctness of the three domain references listed in the previous section, Notes on AIP Domain Builds.
If required, a local domain or the master domain may be moved from one directory to another. The RPAS utility, moveDomain, can be used to accomplish this task. See the Oracle Retail Predictive Application Server documentation for usage information on the moveDomain utility.
The global domain can be consolidated into a directory structure where all local domains are subdirectories of the master domain.
Consolidating the Domains
For example, given master domain path:
/files1/AIPm
and local domain paths
/files2/AIPl-a
/files3/AIPl-b
using the command:
copyDomain -d /files1/AIPm
results in the following paths:
/files1/AIPm/AIPl-a
/files1/AIPm/AIPl-b
By not specifying a target domain destination, the copyDomain utility updates the domain to have relative paths. Copies of spread out local domains are made as subdirectories of the master domain, and the references between the master and local domains are updated.
|
Note: This operation leaves behind orphan local domains /files2/AIPl-a and /files3/AIPl-b, which are no longer attached to a master domain. These domains should be deleted. |
While not elaborated in this Operations guide, copyDomain has other command line options which can be used to copy part of a local domain, translate from UNIX to Windows, and compress the copied domain. See the usage information for the utility (copyDomain -help) and the RPAS documentation for full usage of this utility.
The AIP RPAS domain does not contain any accounts. The domain build process for previous versions of AIP and RPAS created the default accounts of adm and usr during the domain build. These accounts are not created in the domain build process for this release.
For details and instructions on how to create admin and user accounts for the AIP RPAS domain, read the following documentation:
Oracle Retail Predictive Application Server Release Notes
Oracle Retail Predictive Application Server Administration Guide for the description of the usermgr utility in the chapter, Operational Utilities
Oracle Retail Predictive Application Server Administration Guide in the chapter, Security and User Administration
On occasion it is understood that clients may wish to reclassify positions. Reclassification is changing a dimension position's rollup position from one position to another. For example, SKU 30 might roll up to subclass 15, but as a result of a reclassification, the SKU would instead roll up to subclass 40. AIP supports reclassification at hierarchy load time by loading a hierarchy data file that contains the new rollup. This can happen during calls to the loadHier and reconfigGlobalDomainPartitions RPAS utilities embedded inside the AIP batch scripts.
In order for reclassification through loadHier or reconfigGlobalDomainPartitions to be successful, the client should note the old and new rollup positions in relationship to the local domains of the RPAS global domain. If, by reclassifying a position, the position would roll up into a dimension position located in a different local domain than the former rollup dimension position, then the dimension must be buffered in order for the reclassification to be successful. In addition, all dimensions, below the dimension whose position is reclassified, must be buffered.
The default configuration shipped with AIP (as listed in the hierarchy.xml) contains buffering percentages set to 0% low and 0% high for all dimensions. As a result, buffering is disabled. The affected dimension's buffering percentages must be non-zero for the reclassification from one local domain to another. Therefore, before trying to load hierarchy data that has reclassified positions where the local domain rollups change, please read the RPAS documentation on how to use the dimensionMgr RPAS utility to manually increase buffering percentages on the dimensions whose positions are reclassified. This operation takes place outside of AIP batch.
To continue the example: if the domain is partitioned across subclass, SKU 30 rolls up to subclass 15 in local domain ldom0. Subclass 40 is in local domain ldom1. The reclassification requires SKU 30 to be moved to a new local domain and by default the low and high buffering percentages for all dimensions are 0%. Therefore, the SKU dimension and all dimensions below it must be rebuffered in order for SKU 30 to move from local domain ldom0 to the local domain ldom1 during the reclassification hierarchy load.
In AIP-Oracle, store_order and non_contents_order are the key tables that store released and forecast orders. These are partitioned in such a way that they can support a big volume of load, release and purge cycle. Although the AIP-Oracle batch processes do the partition maintenance by themselves, there can be an occasional need for manual maintenance on some of the partitions. This section describes the structure and the usage of partitions on these tables.
These two tables are:
First range-partitioned on release_date column (ship date of order)
List- subpartitioned on source_type column
In AIP, partition and sub-partition names are Oracle database generated names. Typically partition names are of the format SYS_PXXXXX and sub-partition names are of the format SYS_SUBPXXXXX.
A default partition named FIRST_RELEASE_DATE is provided with each table with a release_date upper bound of January 01, 1970 to act as a seed partition. Partition FIRST_RELEASE_DATE by itself normally remains empty.
Each partition has two subpartitions: A subpartition to store purchase orders and a subpartition to store transfers.
In AIP new range partitions are created at run-time by Oracle database whenever new records are inserted. The default partition interval size is 1 release date which means that each partition can have at the most 1 release date specific orders. If there are no orders for a given release date but there are orders for a later release date then there may be a separate partition for the later release date but no additional partition for the given release date that has no orders. This way of creating partitions is done by Oracle 11g database itself.
When upgrading to this version of AIP from a previous release, any existing data in store_order and non_contents_order table is preserved by scripts provided in upgrade patch. However it is still recommended that you backup the existing data in these tables before executing any upgrade script.
While Oracle 11g database is responsible for run-time partition creation, AIP does run-time partition removal as part of Order Purge process. The Order Purge process first creates a list of distinct release dates for which there are physical orders in the table. It then executes the main purging procedure that physically removes the closed orders that have exceeded their purge age. Then using the distinct release date list, it drops all partitions that are left empty as a result of purging done by main purging procedures.
