Beruflich Dokumente
Kultur Dokumente
January 2014
Oracle E-Business Suite Technical Planning Guide, First Edition, Release 12.2
Part No. E35675-06
Copyright 2012, 2014, Oracle and/or its affiliates. All rights reserved.
Primary Author: Mildred Wang, Robert Farrington
Contributing Author: Samer Barakat, Santiago Bastidas, Deepak Bhatnagar, George Buzsaki, Steven Chan,
Kevin Hudson, Lisa Parekh, Scot Robson
Contributor: Kevin Brown, Clara Jaeckel
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of
their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are
used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron,
the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. UNIX is a registered trademark of The Open Group.
This software and related documentation are provided under a license agreement containing restrictions on
use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your
license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license,
transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse
engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is
prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If
you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software,
any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are
"commercial computer software" pursuant to the applicable Federal Acquisition Regulation and
agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation
of the programs, including any operating system, integrated software, any programs installed on the
hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the
programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications.
It is not developed or intended for use in any inherently dangerous applications, including applications that
may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you
shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its
safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this
software or hardware in dangerous applications.
This software or hardware and documentation may provide access to or information on content, products,
and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly
disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle
Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your
access to or use of third-party content, products, or services.
Contents
Introduction
Purpose of this Book................................................................................................................. 1-1
Hardware Resources
Hardware Sizing Requirements................................................................................................ 2-1
CPU Requirements...............................................................................................................2-1
Memory Requirements........................................................................................................ 2-2
Disk Space Requirements..................................................................................................... 2-3
Additional Guidelines for Database and Application Tier Sizing ......................................... 2-5
iii
Index
iv
Send Us Your Comments
Oracle E-Business Suite Technical Planning Guide, First Edition, Release 12.2
Part No. E35675-06
Oracle welcomes customers' comments and suggestions on the quality and usefulness of this document.
Your feedback is important, and helps us to best meet your needs as a user of our products. For example:
If you find any errors or have any other suggestions for improvement, then please tell us your name, the
name of the company who has licensed our products, the title and part number of the documentation and
the chapter, section, and page number (if available).
Note: Before sending us your comments, you might like to check that you have the latest version of the
document and if any concerns are already addressed. To do this, access the new Oracle E-Business Suite
Release Online Documentation CD available on My Oracle Support and www.oracle.com. It contains the
most current Documentation Library plus all documents revised or released recently.
Send your comments to us using the electronic mail address: appsdoc_us@oracle.com
Please give your name, address, electronic mail address, and telephone number (optional).
If you need assistance with Oracle software, then please contact your support representative or Oracle
Support Services.
If you require training or instruction in using Oracle software, then please contact your Oracle local office
and inquire about our Oracle University offerings. A list of Oracle offices is available on our Web site at
www.oracle.com.
Preface
Intended Audience
Welcome to Release 12.2 of the Oracle E-Business Suite Technical Planning Guide, First
Edition.
This guide assumes you have a working knowledge of the following:
If you have never used Oracle E-Business Suite, we suggest you attend one or more of
the Oracle E-Business Suite training classes available through Oracle University.
See Related Information Sources on page viii for more Oracle E-Business Suite product
information.
Documentation Accessibility
For information about Oracle's commitment to accessibility, visit the Oracle
Accessibility Program website at
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Structure
1 Introduction
2 Hardware Resources
vii
Online Help - Online help patches (HTML) are available on My Oracle Support.
PDF Documentation - See the Oracle E-Business Suite Documentation Library for
current PDF documentation for your product with each release.
Release Notes - For information about changes in this release, including new
features, known issues, and other details, see the release notes for the relevant
product, available on My Oracle Support.
Integration Repository
The Oracle Integration Repository is a compilation of information about the service
endpoints exposed by the Oracle E-Business Suite of applications. It provides a
complete catalog of Oracle E-Business Suite's business service interfaces. The tool lets
users easily discover and deploy the appropriate business service interface for
integration with any system, application, or business partner.
The Oracle Integration Repository is shipped as part of the E-Business Suite. As your
instance is patched, the repository is automatically updated with content appropriate
for the precise revisions of interfaces in your environment.
You can navigate to the Oracle Integration Repository through Oracle E-Business Suite
Integrated SOA Gateway.
viii
Oracle provides powerful tools you can use to create, store, change, retrieve, and
maintain information in an Oracle database. But if you use Oracle tools such as
SQL*Plus to modify Oracle E-Business Suite data, you risk destroying the integrity of
your data and you lose the ability to audit changes to your data.
Because Oracle E-Business Suite tables are interrelated, any change you make using an
Oracle E-Business Suite form can update many tables at once. But when you modify
Oracle E-Business Suite data using anything other than Oracle E-Business Suite, you
may change a row in one table without making corresponding changes in related tables.
If your tables get out of synchronization with each other, you risk retrieving erroneous
information and you risk unpredictable results throughout Oracle E-Business Suite.
When you use Oracle E-Business Suite to modify your data, Oracle E-Business Suite
automatically checks that your changes are valid. Oracle E-Business Suite also keeps
track of who changes information. If you enter information into database tables using
database tools, you may store invalid information. You also lose the ability to track who
has changed your information because SQL*Plus and other database tools do not keep a
record of changes.
ix
1
Introduction
Introduction 1-1
2
Hardware Resources
CPU Requirements
CPU requirements for running Oracle E-Business Suite depend on, in no particular
order:
Number of concurrent manager processes and the types of jobs that they are
running
Memory Requirements
The Oracle E-Business Suite Database requires adequate memory to support the specific
needs of a given installation. To determine the total memory requirements on the
machine where the database is installed, you must take the following into account:
Any non-Oracle software that has to run on the machine (this is not recommended)
You should aim to allow for any expected growth in usage over the planned lifetime of
the Oracle E-Business Suite system. It is, however, relatively straightforward to scale up
a system later to meet additional requirements, either by adding nodes to the
application tier or employing Oracle Real Application Clusters (Oracle RAC) on the
database tier.
Important: To help determine your memory requirements for the
can be employed, and may rise either to meet the needs of new releases
or the deployment of components such as additional managed servers.
Space Required
Stage area
For a production database installation, running Rapid Install from a stage area requires
at least 48 GB to accommodate the file system and database files in the stage area.
Important: Because the size of the staging area mainly depends on the
Tip: Log and output files are not automatically purged. Determine a
strategy for archiving and purging these files after the installation, and
monitor the disk space they consume to determine how much space
you may need in the future.
Other files
The total disk space estimate must account for the requirements of files other than those
directly related to Oracle E-Business Suite. For example:
Online backups
Patching requirements.
Number of
Concurrent
Users
Database
Machine
Memory
Number of
Database
Machine CPUs
Application Tier
Machine
Memory
Number of
Application Tier
Machine CPUs
0-10
4 GB
6 GB
100-200
8 GB
8 GB
200-400
12 GB
10 GB
400-800
20 GB
14 GB
You should plan your resources using the above figures as guidelines.
Required Memory
100
4 GB
200
8 GB
400
16 GB
800
32 GB
On the database tier, there is one database session per open form, with a minimum of
two database sessions per Oracle Forms user (one session for the Navigator form, and
one for the active form). Each Oracle Forms session requires approximately 30 MB of
PGA memory on the database.
For Oracle Forms processes on the database, an additional 30 MB per session for the
PGA allocation is needed. The following table lists the memory required for the number
of database sessions:
Number of Forms Database Sessions
Required Memory
100
3 GB
200
6 GB
400
12 GB
800
24 GB
JVM Memory
Forms Memory
Resident Memory
OS Kernel Memory
Aside from the stack, the two main contributors to the middle tier memory are the JVM
memory and Forms memory (the frmweb process). The JVM heap size is equal to
(Number of Self-Service users / 150 ) x 1 GB. The Forms Processes memory is equal to
the (Number of Forms users) x 40 MB. Thus, for 100 concurrent users spanning
self-service applications and Forms, an additional 4 GB of memory and 1 CPU is
needed.
Automatic Workload Repository Advisory sections from test runs should be used to
size relevant database memory components for the actual upgrade.
Important: To minimize unforeseen contigencies, prior to the actual
Server memory: 34 GB
Number of CPUs: 32
this example.
SGA: 5 GB
Shared pool: 1 GB
PGA: 3 GB
Log buffer: 30 MB
job_queue_processes: 32
Note: During the upgrade of the "Admin Tier", batchsize and number
The data in the following table was determined from an upgrade from Release 12.1.3 to
Release 12.2.
Before Upgrade
Database Size (GB)
After Upgrade
Database Size (GB)
Delta (GB)
% Growth
456
481
25
5.5
Note that the delta (difference in size) is a result of adding 25 GB in system table space
as a prerequisite for Online Patching enablement.
On the application tier in this sample upgrade, the Oracle E-Business Suite Release 12.2
is installed with three file systems, to accommodate the new Online Patching feature.
fs1 (production file system) - Used by the current users of the system.
fs_ne (non-editioned file system) - Used to store data that is kept in the file system
(such as data import and export files, reports, and output and log files).
Component
ORACLE_HOME
3.6 GB
3.6 GB
APPL_TOP
28 GB
N/A
INST_TOP
20 MB
N/A
N/A
30 GB
N/A
29 GB
fs_ne
N/A
660 KB
3
Technology Stack Considerations
Upgrade Checklist
In preparation for upgrading to Oracle E-Business Suite Release 12.2, you should do the
following:
1.
Migrate database to Oracle Database 11g Release 2. Oracle E-Business Suite Release
12.2 requires at a minimum Oracle Database 11g Release 2 (11.2.0.3).
Oracle strongly recommends that all Oracle E-Business Suite customers upgrade
their current environments to the 11.2.0.3 Database patchset. If you have not
already upgraded your Oracle E-Business Suite database to 11.2.0.3, you should do
so now. You will not only benefit by receiving the latest updates for security,
performance, and stability before you move to Release 12.2, but will have one fewer
step to perform when you upgrade to Release 12.2.
Note: Consult Certify on My Oracle Support for the latest certified
version.
2.
If you are on Release 11i, prepare an upgrade plan to move to Release 12.X.
The benefits here are similar to those in point 1 above, but in this case for Oracle
E-Business Suite instead of Oracle Database. A large number of significant product
enhancements were introduced in Oracle E-Business Suite Release 12.X, including
features such as subledger accounting, support for a shared services model,
multiple-organization access control, and extensive new reports. Many customers
have found that these Release 12.X enhancements provide an opportunity to update
existing business processes, introduce new business models, and retire redundant
customizations.
3.
11g and higher. If you are running Oracle Single Sign-On, you should migrate to
Oracle Access Manager before upgrading to Release 12.2.
4.
5.
4
Introduction to Online Patching
Patching operations are carried out while the applications are in use and users are
online. This is accomplished by means of a copy of the application components that
are stored in the database and file system (data stored in transaction tables is not
copied).
Patching is performed using the new adop (AD Online Patching) utility.
A short period of downtime is required, but this amounts to little more than a
restart ("bounce") of the application tier services: the time the applications are
unavailable is measured in minutes rather than hours, and this can be set to be at
the most convenient time, for example outside normal business hours.
The patching model used before Release 12.2 was designed to minimize downtime by
performing its operations in the shortest time possible, using whatever resources are
needed. In contrast, the online patching model is designed to minimize downtime by
allowing patching operations to be performed while users remain on the system.
Overview
In traditional patching, application of a patch is a single logical operation. In online
patching, it can be thought of as a series of related steps:
1.
A copy is made of the code of the running system that resides in both the file
system and database.
2.
Patches are applied to the copy while users continue to access the running system.
3.
4.
The original running system (now obsolete) is recycled for use in future patching
cycles.
These steps constitute the online patching cycle. To implement this mechanism, various
changes have been made to the Oracle E-Business Suite infrastructure.
Any method used to create a copy of the running application must take into account
that an Oracle E-Business Suite application comprises both code and data, stored in the
database and the file system. A key concept is the edition as a copy of the application
code: the running application executes on the run edition, while any patching activity
takes place in the patch edition. The implementation mechanism uses the Oracle
Database 11g Edition-Based Redefinition (EBR) feature to cater for database objects, and
a dual file system to cater for objects stored in the file system.
Two complete file systems are always present in an Oracle E-Business Suite Release 12.2
system. As noted above, the run file system is the one currently in use by the running
application, while the patch file system is the either being patched or awaiting the start
of the next online patching cycle. In other words, the two file systems swap roles with
every online patching cycle.
In the database, there is also a run edition and patch edition, but they do not swap roles
back and forth as in the file system: the patch edition only comes into existence during a
patching cycle, and becomes the new run edition at the end of the cycle. The former
database run edition (the old edition) and the obsolete objects it contains are discarded
at the end of an online patching cycle, and the space reclaimed during the cleanup
phase.
These concepts will all be described in more detail after a discussion of the way they are
used in the online patching cycle.
Prepare
Apply
Finalize
Cutover
Configures patch edition file system to be the new run edition file system.
Cleanup
The patch file system is synchronized with the run file system.
2.
The patch edition files become an exact copy of the run edition files.
Note: By default, synchronization is incremental: that is, only files that
In the database:
1.
2.
All code objects in the patch edition begin as pointers to code objects in the run
edition. Code objects in the patch edition begin as lightweight "stub objects" that
point to the actual object definitions, which are inherited from earlier editions. Stub
objects consume minimal space, so the database patch edition is initially very small
in size.
3.
As patches are applied to the patch edition, code objects are actualized (have a new
definition created) in that edition.
Note: Storage objects (such as transaction tables) are not copied.
Apply
The following actions are taken in this phase:
1.
Patches are applied to the patch edition. During this process, any changed stub
objects will become actual code objects in the patch edition.
2.
The changes introduced by the patches are made in the isolation of the patch
edition.
Changes to code objects are only visible in the patch edition of the file system
and database.
Changes to tables are stored in new columns or rows that are only visible to the
patch edition.
Note: At this point, users still remain connected to the application and
Finalize
This phase is used to perform the final operations that can be executed while the
application is online:
1.
2.
3.
Any actions that must be performed at cutover are pre-computed and stored for
quick execution at that time.
Cutover
This phase involves:
1.
2.
3.
Configuration of the patch edition of the file system as the new run edition.
4.
Configuration of the patch edition of the database as the new run edition.
5.
Although the cutover phase does require a short period of application tier services
downtime, the online patching cycle can be paused for as long as required prior to
running this phase. You could, for example, add such a pause to ensure that the
downtime period will be outside business hours.
Note: The database remains open throughout the entire online patching
Cleanup
The following database actions are taken in this phase, which occurs after users have
been brought back online to the newly-patched application:
1.
Old code objects that are no longer visible in the run edition are dropped.
2.
Old data (rows or columns) that is no longer visible in the run edition is deleted or
dropped.
3.
Old database editions that no longer contain actual objects are dropped.
Database Implementation
Creating a copy of the database part of the running system has been accomplished by
taking advantage of the Oracle Database 11g R2 Edition-Based Redefinition (EBR) feature.
This allows an application to efficiently store multiple copies of its application
definition in the same database, and thereby enables online upgrade of the database
tier.
The term edition refers to the isolation mechanism that allows pre-upgrade and
post-upgrade schemas to co-exist. The simplest way to think of an edition is as a
separate (isolated) copy of all database code objects that are changed by a patch.
The three types of database edition are:
Run: Online users connect to this edition, which is always the default database
edition. The run edition will always exist.
Patch: Patching tools connect to this edition. A child of the run edition, the patch
edition exists only while a patching cycle is in progress.
Old: When a patch edition is promoted to be the run edition, the previous run
edition is now regarded as an old edition. There may be zero or more old editions at
a given time. They are discarded when a full cleanup (described later) is performed.
You cannot connect to an old edition.
data between the run edition and patch edition storage columns. The result is that new
transactions entered into the system are patched in place.
More specifically, crossedition triggers allow the run edition to signal that a data update
is required. They fire in response to an insert into, delete from, or update of,
FND_TABLE. For example, suppose that a patch updates a column called
DESCRIPTION from upper case to mixed case. Editioning views project different views
of the table to the run and patch editions, so the running application still sees the
column data as upper case, while the patched application sees the column data as
mixed case. The updated column is maintained by a crossedition trigger.
In summary, crossedition triggers are used to upgrade both existing data and ongoing
changes that occur while the run edition remains in use.
Editioning Views and the Application Data Model
Editioning views can be thought of as providing a cover layer, or logical representation
of the data, on top of the physical representation. All code (Oracle E-Business Suite,
custom, or third-party) must access Oracle E-Business Suite data via the cover layer:
accessing the data model via the physical layer may result in obsolete data been
returned.
all code to access the data model via the APPS synonym, which points
to the editioning view (logical model).
obsolete columns.
Updates to seed data in the run edition are automatically propagated to the patch
edition by the use of crossedition triggers.
The two file systems are sometimes referred to as a dual file system, and swap roles at the
end of each patching cycle. That is, the file system that has just been patched is now put
into use as part of the running system (becoming the new run file system), and the
previous run file system now takes over the the role of patch file system (in readiness
for commencement of the next patching cycle).
Important: The existence of the dual file system has significant
However, two file systems are not sufficient to meet all the practical needs of an online
patching environment for Oracle E-Business Suite. A third file system, described in the
next section, is also required.
The non-editioned file system is therefore completely separate from file system 1 and
file system 2.
Context Variables for Online Patching File Systems
Several AutoConfig context variables support the file systems used in online patching.
For example, the s_ne_base context variable stores the location of the non-editioned file
system, and AutoConfig sets the environment variable $NE_BASE to the corresponding
Files containing transactions that are needed across all file systems.
Note: The non-editioned file system is not designed to store shared
5
Preparing for Online Patching
Introduction
Oracle E-Business Suite includes a utility, the Online Patching Readiness Report, to help
you identify database components that need updates in preparation for Release 12.2
and Online Patching enablement. This utility is to be run in a Release 11i, 12.0, 12.1, or
12.2 environment (before Online Patching is enabled).
This utility is available independent of Release 12.2 for customers preparing to upgrade
prior to acquiring Release 12.2. It is also available for Release 12.2. Download the
appropriate patch for your release (Release 11i, 12.0, 12.1, or 12.2). To find the patch
number, refer to My Oracle Support Knowledge Document 1531121.1, "Using the
Online Patching Readiness Report in Oracle E-Business Suite Release 12.2." The patch
README file has the most up-to-date information on this utility.
Important: You must fix all violations that are reported by this utility
Executing the Summary Readiness Report and the Manual Fix Readiness Report
You must run the readiness reports described in the sections below from the application
tier APPL_TOP. This reports lists objects that do not comply with the edition-based
redefinition (EBR) rule that noneditionable objects may not refer to editionable objects
(editionable objects are synonyms, views, and PL/SQL objects). This report also lists
several naming standard violations that must be fixed prior to applying the online
patching enablement patch.
In addition, you must run the Global Standards Compliance Checker (GSCC) script and
address errors that are reported by this script. For up-to-date information on this script,
refer to My Oracle Support Knowledge Document 1531121.1, "Using the Online
Patching Readiness Report in Oracle E-Business Suite Release 12.2," as well as the
related patch README file.
The steps involved with running the report are illustrated in the following diagram:
Running the Summary Readiness Report and the Manual Fix Readiness Report
1.
2.
3.
Execute the Manual Fix Readiness Report (ADZDPMAN.sql), the Online Patching
Database Compliance Checker, and the Global Standards Compliance Checker.
If there are no exceptions reported, go to Step 5. Otherwise, go to Step 4.
4.
5.
File system check report (gscc.pl) - This script scans the file system for source files
that violate the standards.
The readiness reports described earlier and the Database Standards Checker (also called
the Database Compliance Checker, or DBCC) are designed to be executed on a system
that has not yet been online patching-enabled. They can and should be run after
enablement as a final check. The sequence for the procedure after online patching has
been enabled is as follows:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Fix any errors and repeat Step 8 until no errors are reported.
Note: The subsequent steps assume that you are running in the
2.
Create the online patching log file location and set it as the current directory:
mkdir $LOG_HOME/appl/op
cd $LOG_HOME/appl/op
ADZDPAUT.sql - Lists all the objects with violations to the EBR rules that will be
fixed automatically from the enablement process. This report is provided for
information purposes and no action should be taken for this report.
Note: Many violations in the readiness report can be automatically
fixed by registering your custom schemas. Review the last section of the
Summary Readiness Report (ADZDPSUM.sql) for sample commands
on how to register your custom schemas, as well as any schema
installed as part of an Oracle technology such as APEX, XDB, and
OWBSYS. You must register any custom or third-party schema that
does not support Oracle E-Business Suite Online Patching. The
following schemas should NOT be registered:
SYS
SYSTEM
CTXSYS
Oracle recommends that you perform the chosen fixes by customizing the template file
$AD_TOP/sql/ADZDPCUST.sql. The reports provide more details on this step.
6
Development Standards for Online Patching
Introduction
This chapter documents new or modified standards designed specifically for database
object development and online patching in Oracle E-Business Suite Release 12.2. Other
development standards are not covered.
Note: These standards only apply to objects and data that can be
Sections in this chapter are organized by object type. For each object type, the following
types of standards are given.
Definition Standards - These are rules that must be followed concerning the
definition of the object. These rules apply to all objects in the base release of Oracle
E-Business Suite Release 12.2.
Usage Standards - These are rules that must be followed when using the object
during application runtime.
Dynamic DDL Standards - These are rules that must be followed when generating
or altering the object definition during application runtime.
An online patch must only change editioned objects in the Patch Edition.
The running application must replicate dynamic changes to editioned objects to the
Patch Edition.
The remaining development standards provide guidance to help ensure you meet the
Editioned Objects
Editioned objects may have different definitions in each database edition. This means
that such objects can be easily patched (in the patch edition) without affecting the
running application (in the run edition).
View (Ordinary)
Definition Standards
A join view should define a ROW_ID column mapped to the ROWID of the base
table.
Usage Standards
Do not reference the implicit ROWID pseudo-column of a join view. The availability of
implicit ROWID from a join view may change without warning. Instead, use the explicit
ROW_ID column that should be present in all join views.
Dynamic DDL Standards
If the running application creates, replaces or drops a view while a patch edition exists,
then the same action must be executed in the patch edition. This requirement can be
satisfied in either of two ways:
1.
/* Code example:
declare
L_APP
varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
begin
l_app := 'FND';
l_name := 'FND_EXAMPLE_V';
l_stmt :=
'create or replace view '||l_name||' as '||
'select user_id, user_name from fnd_user '||
'where user_id < 10000';
ad_ddl.do_ddl(
ad_zd.applsys_schema,
l_app,
product
ad_ddl.create_view,
l_stmt,
l_name
);
end;
/
2.
Disable or block application processing that executes dynamic DDL during online
patching.
This approach can only be used if the dependent functionality can be unavailable
for days at a time without disrupting normal customer operations.
This approach is meant only as a temporary workaround.
See:
PL/SQL Package
Definition Standards
The package name must be a non-quoted identifier.
Note: Non-quoted identifiers may only use the following characters:
A-Z 0-9 _ # $. Quoted identifiers are reserved for use by the technology
components.
Usage Standards
No special considerations.
2.
Disable or block application processing that executes Dynamic DDL during online
patching.
This approach can only be used if the dependent functionality can be unavailable
for days at a time without disrupting normal customer operations.
This approach is meant only as a temporary workaround.
See:
PL/SQL Trigger
Definition Standards
A table trigger must be on the editioning view (EV), not the table. Triggers on tables
will be automatically moved to the corresponding editioning view during the
Release 12.2 upgrade. For information on editioning views, see: Oracle Database
Advanced Application Developer's Guide 11g Release 2 (11.2).
Tip: The simplest way to comply with this standard is to create
Use AD_DDL, which will replicate run edition DDL for triggers in the patch edition
automatically.
For example:
/* Code example:
declare
L_APP
varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
begin
l_app := 'FND';
l_name := 'FND_EXAMPLE_TRG';
l_stmt :=
'create or replace trigger '||l_name||' '||
'before insert or update on fnd_user for each row '||
'begin '||
' ad_zd_log.message(''test'', ''STATEMENT'', ''hello!''); '||
'end;';
ad_ddl.do_ddl(
ad_zd.applsys_schema,
l_app,
product
ad_ddl.create_trigger,
l_stmt,
l_name
);
end;
/
2.
Disable or block application processing that executes dynamic DDL during online
patching. This approach can only be used if the dependent functionality can be
unavailable for days at a time without disrupting normal customer operations.
This approach is meant only as a temporary workaround.
See:
Synonym
Definition Standards
Most APPS synonyms are automatically created by the adop patching tool. Do not
create, modify, or drop automatically-managed synonyms.
A table synonym must point to the editioning view, not the table.
Usage Standards
Use APPS synonyms to reference Oracle E-Business Suite tables. Do not reference tables
directly.
Dynamic DDL Standards
If the running application creates, replaces, or drops a synonym while a patch edition
exists, then the same action must be executed in the patch edition. This requirement can
be satisfied in either of two ways:
1.
declare
L_APP
varchar2(8);
L_NAME varchar2(30);
L_STMT varchar2(32000);
begin
l_app := 'FND';
l_name := 'FND_USERS';
l_stmt :=
'create or replace synonym '||l_name||' for fnd_user';
ad_ddl.do_ddl(
ad_zd.applsys_schema,
l_app,
product
ad_ddl.create_synonym,
l_stmt,
l_name
);
end;
/
2.
Disable or block application processing that executes dynamic DDL during online
patching.
This approach can only be used if the dependent functionality can be unavailable
for days at a time without disrupting normal operations.
This approach is meant only as a temporary workaround.
See:
Effectively-Editioned Objects
These object types are non-editioned at the database level, meaning they have a single
definition that is visible to all database editions. But for each object in this category, the
Online Patching tools implement special support so that the object can be patched
without impacting the running application. New restrictions and standards apply to
each effectively-editioned object type.
Table (Ordinary)
An ordinary table is created, altered or dropped during application patching. In
contrast, a dynamic table is created, altered, or dropped by the application at runtime.
The standards in this section apply to ordinary tables only.
In order to implement effectively-editioned support for ordinary tables, the online
patching technology installs and maintains a new editioning view layer over each table.
The editioning view maps logical column names used by the application to the actual
storage columns used to hold those attributes in each edition. Although the editioning
view is maintained automatically during online patching, developers who create or
alter tables by hand in a development database must follow new procedures to
maintain the editioning view.
Note: For some of these standards, a code corresponding to the Global
Definition Standards
A base column name may only use '#' as last character. (GSCC File.Gen.36)
The column type must not be LONG or LONG RAW. See: LONG to CLOB
Conversion Procedures, page 6-32. (GSCC File.Xdf.4)
Usage Standards
Query/DML statements must access tables via the table synonym or editioning
view. (GSCC File.Gen.41)
If you query, display, or store table column names in your application runtime
code, you should use logical column names rather than physical column names in
most cases.
Follow the Logical versus Physical Column Guidelines, page 6-20 for runtime
application code.
Warning: Some dictionary views (such as
Ensure your query obtains the logical or physical column information you
need.
DDL statements such as TRUNCATE will not work on an APPS table synonym that
points to an editioning view. To truncate a table, you must supply the actual base
table (owner.table_name) in the truncate command.
Dynamic DDL Standards
Ordinary tables are created and maintained by online patching (and will have an
editioning view).
If the application logic modifies an ordinary table at runtime, it must use the
AD_DDL interface to execute the dynamic DDL.
Do not modify ordinary tables in the run edition while a patch edition exists.
Block modification of run edition seed data content from the patch edition.
Seed data tables in Oracle E-Business Suite Release 12.2 must be upgraded to
editioned data storage during the upgrade to Release 12.2.
Each product must create a seed data table upgrade script using the
template below. Add one call to AD_ZD_SEED.UPGRADE for each seed
data table owned by the product.
Important: Do not call the UPGRADE procedure for tables
REM $Header: $
REM dbdrv: sql ~PROD ~PATH ~FILE none none none sqlplus
&phase=last+95 \
REM dbdrv: checkfile:~PROD:~PATH:~FILE
REM
/*============================================================
===========+
REM |
Copyright (c) 2012 Oracle, California, USA
|
REM |
All rights reserved.
|
REM
+=============================================================
==========+
REM | Seed Data Table Upgrade for Online Patching:
REM | Converts Seed Data Tables to support Editioned Data
Storage
REM
+=============================================================
==========*/
SET VERIFY OFF
WHENEVER SQLERROR EXIT FAILURE ROLLBACK;
WHENEVER OSERROR EXIT FAILURE ROLLBACK;
exec AD_ZD_SEED.UPGRADE('FND_NEW_MESSAGES')
exec AD_ZD_SEED.UPGRADE('FND_APPLICATION')
exec AD_ZD_SEED.UPGRADE('FND_APPLICATION_TL')
commit;
exit;
This standard does not apply if the table is read-only to the runtime application.
Usage Standards
ROWID values for rows in seed data tables may change after an online patch. You
may use Seed Data ROWID values within a single transaction or program
execution, but it is no longer valid to store a seed data ROWID across a patching
boundary.
FNDLOAD Configuration Files (LCT files) must include a PREPARE statement for
each entity listing the seed data tables that the UPLOAD command loads into.
Syntax:
PREPARE <entity>
TABLE <seed_data_table_name1>
TABLE <seed_data_table_name2>
...
The entity is not patched during online patching or does not support UPLOAD.
The seed data tables loaded by a child entity are prepared by the parent entity.
You should only list seed data tables that will be loaded. For example, if the upload
logic initially stores data in temporary tables, the temporary tables should not be
listed in the PREPARE statement. Only seed data tables can be prepared.
Example:
# $Header: wfmlrp.lct 120.0 2005/05/07 16:19:43 appldev ship $
COMMENT = "dbdrv: exec fnd bin FNDLOAD bin &phase=daa+52
checkfile:~PROD:~PATH:~FILE &ui_apps 0 Y UPLOAD
@FND:patch/115/import/wfmlrp.lct @~PROD:~PATH/~FILE"
DEFINE MAILERPARAMS
KEY NAME
VARCHAR2(12)
KEY PARAMETER
VARCHAR2(30)
BASE VALUE
VARCHAR2(200)
BASE REQUIRED
VARCHAR2(1)
BASE CALLBACK
VARCHAR2(60)
BASE ALLOWRELOAD VARCHAR2(1)
END MAILERPARAMS
DOWNLOAD MAILERPARAMS
"select NAME, PARAMETER, VALUE, REQUIRED, CB, ALLOW_RELOAD
from WF_MAILER_PARAMETERS
where NAME = :NAME"
###
### Do NOT call AD_ZD_SEED.PREPARE from the UPLOAD statement of an
LCT file.
### Use the LCT PREPARE statement instead (see below)
###
UPLOAD MAILERPARAMS
"begin
wf_mailer_parameter.PutParameter(:NAME, :PARAMETER,:VALUE,
:REQUIRED, :CALLBACK, :ALLOWRELOAD);
end;"
###
### New for Online Patching
###
PREPARE MAILERPARAMS
TABLE WF_MAILER_PARAMETERS
Other (non-FNDLOAD) Seed Data Loaders that will be used for online patching
must call the Seed Data Manager PREPARE procedure before loading data into a
table. Note that this requirement does NOT apply to scripts and loaders that will
only be used for the Oracle E-Business Suite Release 12.2 upgrade.
Syntax: AD_ZD_SEED.PREPARE('<table_name>');
Note: <table_name> is the name used to refer to the table from the APPS schema (in
other words, it is the name of the APPS synonym that points to the table). If the
APPS synonym name is different from the actual table name, then use the APPS
synonym name for this argument.
The AD_ZD_SEED.PREPARE procedure cannot be called from scripts using the
"dbdrv: sql ... sql" execute method. Use "dbdrv sql ... sqlplus" instead.
Bad Example: dbdrv: sql ~PROD ~PATH ~FILE none none none sql
&phase=upg+14 ...
Good Example: dbdrv: sql ~PROD ~PATH ~FILE none none none
sqlplus &phase=upg+14 ...
Execute the PREPARE call BEFORE loading data into the table. "Loading" includes
any modification of seed data content (insert, update, delete).
Example SQL script with AD_ZD_SEED.PREPARE procedure call:
REM $Header: $
REM dbdrv: sql ~PROD ~PATH ~FILE none none none sqlplus_single
&phase=upa \
REM dbdrv: checkfile(115.2=120.1):~PROD:~PATH:~FILE &un_fnd &pw_fnd
REM
/*==================================================================
=====+
REM |
Copyright (c) 2012 Oracle, Belmont, California, USA
|
REM |
All rights reserved.
|
REM
+===================================================================
====+
REM |
REM | NAME
REM |
ldrexample.sql
REM |
REM | DESCRIPTION
REM | This script adds a policy to the wf_signature_policies
REM
+===================================================================
====*/
SET VERIFY OFF;
WHENEVER SQLERROR EXIT FAILURE ROLLBACK
WHENEVER OSERROR EXIT FAILURE ROLLBACK
--- NEW FOR ONLINE PATCHING
-exec ad_zd_seed.prepare('WF_SIGNATURE_POLICIES')
insert into WF_SIGNATURE_POLICIES
(SIG_POLICY, SIG_REQUIRED, FWK_SIG_FLAVOR,
EMAIL_SIG_FLAVOR, RENDER_HINT, DEFAULT_POLICY)
select 'DEFAULT', 'N', Null, Null, Null, 'Y'
from dual
where not exists
(select 1
from WF_SIGNATURE_POLICIES
where SIG_POLICY = 'DEFAULT');
commit;
exit;
Upload logic executed during online patching must not reference materialized
views, since materialized views are non-editioned objects and will be defined
according to the run edition rather than the patch edition.
Usage Standards
No special considerations.
Index
Definition Standards
The unique index on a seed data table should have at least one not-null column
besides ZD_EDITION_NAME.
Note: If the unique index has all nullable columns, then each row in
the table must have at least one non-null column value for the
indexed columns. You must ensure that this is true as part of the
Oracle E-Business Suite 12.2 upgrade (select rows where all
indexed columns are null and either delete or update as needed to
meet this standard).
Integrity Constraint
Definition Standards
Do not create a primary key constraint on a table. Create a unique index or unique
constraint instead.
An existing primary key constraint will work, but it is not possible to create a
revised primary key constraint in an online patch.
A foreign key constraint should not be created, and must not reference a seed data
table.
Test the materialized view definition for accuracy before generating the
materialized view implementation.
For example:
A materialized view definition must specify a column alias for each item in the
select list.
Failure to specify a column alias may cause the error ORA-00998 "must name
this expression with a column alias".
Do not specify the /*AUTOREFRESH*/ tag for large materialized views that will
take a long time to refresh. For these cases use a concurrent program to refresh
the materialized view after patching cutover.
Usage Standards
Do not assume that fast refresh is always possible. After an online patch, complete
refresh may be required. When refreshing a materialized view, us the 'FORCE' clause
instead of 'FAST'.
See: Oracle Database SQL Language Reference 11g Release 2 (11.2) for more information on
the 'FORCE' option.
Dynamic DDL Standards
Use AD_MV to execute dynamic DDL for materialized views. Here is an example of
creating a materialized view using the AD_MV package:
--- Code Example: Create a materialized view using AD_MV interface.
--- Note:
-when executed in the Run Edition, the MV is created immediately.
-when executed in the Patch Edition, the MV is generated at
CUTOVER.
-begin
-- Create MV
ad_mv.create_mv('FND_EXAMPLE_MV',
'create materialized view FND_EXAMPLE_MV '||
' tablespace '||ad_mv.g_mv_data_tablespace||' '||
' build deferred refresh on demand as '||
'select /*AUTOREFRESH*/ '||
'
upper(oracle_username) USERNAME '||
' ,
decode(read_only_flag,''C'',''pub'',''E'',''applsys'',''U'',''apps'')
USERTYPE '||
'from fnd_oracle_userid '||
'where read_only_flag in (''C'',''E'',''U'') ');
end;
database data dictionary views, then it must take care select the correct (logical or
physical) column names depending on the purpose for getting the names.
If column names are selected for the purpose of constructing query or DML
statements (select, insert, update, or delete) then you must select logical column
names.
If column names are selected for the purpose of constructing table DDL statements
(for example, to create an index), then you must select physical column names.
Normally, application runtime code should not be modifying tables that are
managed through online patching, so this should be a rare situation.
Note that the distinction between logical and physical columns only exists for table
columns where the table has an editioning view. If you are getting column information
for any object that does not have an editioning view then you do not need to make any
changes. Queries that do not need to be changed include:
Queries that run as part of the Oracle E-Business Suite Release 12.2 upgrade. During
the main upgrade phase editioning views are not yet installed, and so all existing
upgrade scripts will work correctly.
Queries for table column information, where the table does not have an editioning
view. This category includes:
Temporary tables.
Index-organized tables.
Dictionary views in this category contain information for both logical and physical table
columns, depending on how the view is queried. You must examine each reference to
these dictionary views and determine whether you intend to select logical or physical
column information.
ALL_UPDATABLE_COLUMNS, DBA_UPDATABLE_COLUMNS,
USER_UPDATABLE_COLUMNS
To select physical (table) column names, select from the dictionary view for a specific
physical table name (where table_name = x_table_name). You can use where
table_name not like '%# to search across all tables while excluding logical views.
To select logical (EV) column names, select from the dictionary view for a specific
editioning view name, where table_name = ad_zd_table.ev_view(x_table_name).
Another way to get the logical view information is to start with the APPS synonym and
join the synonym table_name to the dictionary view to get the correct logical view
information. The APPS synonym will point to the EV if one exists, or directly the
physical table if there is no EV. This will provide correct logical column results in either
case.
/*
** This query returns logical columns for the table pointed to by APPS
** table synonym X_SYNONYM_NAME. Compatible with old releases.
*/
select col.column_name
from user_synonyms syn, all_tab_columns col
where syn.synonym_name = x_synonym_name
and col.owner
= syn.table_owner
and col.table_name = syn.table_name
order by col.column_id
/
If you do not know whether you are querying a table or a view, you can union the
results from the two possible queries:
/*
** This query returns logical columns for X_OBJECT_NAME, and works
whether
** the object is an APPS table synonym or view. Compatible with old
releases.
*/
select col.column_name, col.data_type
from user_synonyms syn, all_tab_columns col
where syn.synonym_name = x_object_name
and col.owner
= syn.table_owner
and col.table_name = syn.table_name
union
select col.column_name, col.data_type
from user_tab_columns col
where col.table_name = x_object_name
/
If the application logic must use a physical table name as the input rather than the APPS
object name, and you are sure that the table has an editioning view, then you can just
convert the table name to the editioning view name with a utility function:
*
** This query returns logical columns for effectively editioned table
** X_OWNER.X_TABLE_NAME. Use this only if you cannot start from
** the APPS synonym name and are sure that the table has an EV.
** This query works on Oracle E-Business Suite Release 12.2 only.
*/
select col.column_name
from all_tab_columns col
where col.owner
= x_owner
and col.table_name = ad_zd_table.ev_view(x_table_name)
order by col.column_id
/
In the most general (worst) case, your application code may not be able to guarantee
that the input table name has an EV. In this case you can outer-join to the EV
information to provide logical column names if they exist, or physical columns if they
do not:
/*
** This query returns the logical columns for table
X_OWNER.X_TABLE_NAME.
** If the table has an editioning view, then the editioning view columns
are
** returned, otherwise the physical table columns are returned.
** ONLY use this query if you must query by physical table name rather
** than APPS synonym name and the table might not have an EV.
** This query works on Oracle E-Business Suite Release 12.2 only.
*/
select
col.owner
, col.table_name
, decode(ev.view_name, NULL, col.column_name, evc.view_column_name)
logical_column_name
, col.column_name physical_column_name
from
all_tab_columns col
, all_editioning_views ev
, all_editioning_view_cols evc
where col.owner
=
x_owner
and col.table_name
= x_table_name
and ev.owner(+)
= col.owner
and ev.table_name(+) = col.table_name
and evc.owner(+)
= ev.owner
and evc.view_name(+) = ev.view_name
and (ev.view_name is null or evc.table_column_name = col.column_name)
order by col.owner, col.table_name, evc.view_column_id
/
ALL_EDITIONING_VIEW_COLS, DBA_EDITIONING_VIEW_COLS,
USER_EDITIONING_VIEW_COLS
ALL_EDITIONING_VIEW_COLS_AE, DBA_EDITIONING_VIEW_COLS_AE,
USER_EDITIONING_VIEW_COLS_AE
ALL_AUDIT_POLICY_COLUMNS, DBA_AUDIT_POLICY_COLUMNS,
USER_AUDIT_POLICY_COLUMNS
ALL_LOB_SUBPARTITIONS, DBA_LOB_SUBPARTITIONS,
USER_LOB_SUBPARTITIONS
ALL_PART_KEY_COLUMNS, DBA_PART_KEY_COLUMNS,
USER_PART_KEY_COLUMNS
ALL_STREAMS_COLUMNS, DBA_STREAMS_COLUMNS,
USER_STREAMS_COLUMNS
ALL_SUBPART_KEY_COLUMNS, DBA_SUBPART_KEY_COLUMNS,
USER_SUBPART_KEY_COLUMNS
ALL_UNUSED_COL_TABS, DBA_UNUSED_COL_TABS,
USER_UNUSED_COL_TABS
Non-Editioned Objects
Non-editioned objects have the same definition shared across application editions. Such
objects must be patched carefully to avoid affecting the running application.
Sequence
Definition Standards
No special considerations.
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
Usage Standards
Editioned objects should reference a non-editioned UDT using its APPS synonym.
Temporary Table
Definition Standards
No special considerations.
Note: Unlike ordinary tables, temporary tables do not have editioning
views.
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
Application Context
Definition Standards
No special considerations.
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
XML Schema
Definition Standards
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
Database Link
Definition Standards
Not applicable.
Usage Standards
Accessing objects over a database link always uses the run edition of the target
database, even if the access originates from the patch edition.
Dynamic DDL Standards
No special considerations.
Partition
Definition Standards
No special considerations.
Usage Standards
No special considerations.
Dynamic DDL Standards
No special considerations.
Any other data files that are dynamically generated or consumed by the
runtime application
$APPL_TOP_NE/<product_short_name>/<directory_name_used_bef
ore>/
Usage Standards
Reference the non-editioned APPL_TOP using the 'APPL_TOP_NE' environment
variable.
For example, $APPL_TOP_NE/fnd/import
Use the Concurrent Program window or page to edit your concurrent program
definition.
2.
3.
Add a new global incompatibility rule for your program with the following
program:
After:
(select profile_option_value from fnd_profile_option_values
where level_id = 10001 and (profile_option_id, application_id) =
(select profile_option_id, application_id from fnd_profile_options
where profile_option_name = 'MSC_HUB_REGION_INSTANCE'))
Notes:
The general case for fetching profile option values is very complex, that is why
there is a PL/SQL package dedicated to doing it. But materialized views results
have to be valid in any context, so profile options referenced in materialized views
should only have site level values, and the replacement SQL only needs to support
fetching the site level value.
This replacement SQL will only use the profile option value set at site level.
After:
Notes:
This replacement SQL will only retrieve the US language message text and is not
sensitive to any session language settings.
Materialized view queries cannot contain a sub-SELECT within the main SELECT
clause; therefore, the replacement SQL needs to be more sophisticated if the
function call was used in the MV SELECT clause.
Before:
select fnd_message.get_string('FND', 'CANCEL')
from dual
where 1=1
/
After:
select fmgs.result
from dual
, (select substrb(REPLACE(message_text, '&&', '&'),1,2000) result
from fnd_new_messages m, fnd_application a
where m.message_name = 'CANCEL'
and m.language_code = 'US'
and a.application_short_name = 'FND'
and m.application_id = a.application_id) fmgs
where 1=1
/
After:
(select nvl(max(lt.security_group_id), 0)
from fnd_lookup_types lt
where lt.view_application_id = 279
and lt.lookup_type = 'INTEREST_STATUS'
and lt.security_group_id in (
0,
to_number(decode(substrb(userenv('CLIENT_INFO'),55,1),
' ', '0',
null, '0',
substrb(userenv('CLIENT_INFO'),55,10)))))
Note: This replacement is valid only in a materialized view. For other uses of
Oracle Forms
For each table column that has been changed from LONG to CLOB, any form block item
that has references to the column will need to have its Oracle Forms data type changed
from 'Char' to 'Long'. Remember that CLOB is the database column type and 'Long' is
the Forms item data type. To change the form's data type, open your form in the Forms
Builder and open the property sheet (Property Palette) for the item that references the
CLOB.
Scan your form and form library code for any references to the modified form item.
Since the form item is now a Forms Long data type, functions like LENGTH(),
LENGTHB(), SUBSTR() may behave differently. Thoroughly test your form to exercise
the logic referencing the Forms Long data type.
Pro*C / C
If you are binding a LONG or LONG RAW that is being changed to a CLOB, then you
should change the bind from SQLT_LNG to SQLT_CLOB. Otherwise, an unknown
datatype error will be thrown.
If you are using UPI code, ensure that you have applied the RDBMS patch 13259364.
PL/SQL
Check all packages to ensure that all affected variables are changed from LONG to
CLOB.
Examples (with updated variables):
PROCEDURE insert_flex_validation_events( flex_value_set_id IN NUMBER,
event_code IN varchar2, user_exit IN CLOB)
document_long_text CLOB;
document_long_text fnd_documents_long_text.long_text%type;
Java
In JDBC 2.0 and 3.01, you should fetch the data from a CLOB column using
ResultSet.getClob() to obtain a reference to the column, and then obtain a
character input stream object to read the contents of the CLOB field in a parallel fashion.
Because Oracle Database 11g Release 2 JDBC drivers fully implement getString() for
CLOBs, no program conversion should be necessary.
Model
Database column field for the attribute - The type should be changed to
CLOB.
Read-only View Objects (VO) (not associated to an EO): The datatype of the
attributes should be changed.
Database column field for the attribute - The type should be changed to
CLOB.
After your modifications, perform suitable tests using the BC4J tester object.
View
Export button - If there is any manipulation of standard data handling with the
export bean, it should be modified to reference the correct data types.
Index
A
adop
online patching tool, 4-12
online patching utility, 4-1
ADZDPAUT.sql, 5-5
ADZDPMAN.sql, 5-5
ADZDPSUM.sql, 5-5
fs_ne
See non-editioned file system
C
cover layer
in online patching of data, 4-7
CPU
requirements, 2-1
crossedition trigger
in online patching, 4-6
D
Database
memory requirements, 2-2
dual file system
definition, 4-10
E
edition
in online patching, 4-6
Edition-Based Redefinition, 4-6
editioned data storage
in online patching, 4-9
editioning view
definition, 4-6
G
Global Standards Compliance Checker (GSCC),
5-6
L
log files
disk space, 2-3
purging, 2-4
logical view
of data model, 4-6
M
Memory requirement for Oracle E-Business
Suite, 2-2
N
non-editioned file system
used in online patching, 4-10
O
old edition
in online patching, 4-6
online patching, 4-1
Online patching, 4-1
Online Patching
introduction, 1-1
Index-1
P
patch edition
in online patching, 4-6
patches
disk space, 2-4
patch file system, 4-10
phases
of online patching, 4-2
R
run edition
in online patching, 4-6
run file system, 4-10
S
seed data
in online patching, 4-9
sizing
suggestions, 2-1
T
temporary directories
disk space, 2-4
temporary files
disk space, 2-4
temporary space
required for installation, 2-4
Index-2