stat architecture detail

Copyright 2006 Quest Software Inc. Page 5 of 27

Internal Partner Win Story

Pre-Installation Checklist

STAT ARCHITECTURE AND COMPONENTS

Stat is based on a four-tier architectural model consisting of a client tier, a Web tier, a business logic tier, and a database tier. The components within each tier work together to provide a complete change management solution for PeopleSoft and Oracle Applications, as well as other application environments.

Figure 1 Stat Architecture

Client Tier Users interact directly with Stat through the client application installed on their Windows-based workstation. They interact with Stat Web through a browser window. You can install the Stat Windows Client either locally or on a network. It connects with the Stat Repository through various native environment interfaces.

Web Tier and Business Logic Tier The Stat Server is a Web-based application that occupies the Web Tier and the Business Logic Tier. It comprises the Web Container and EJB Container. Depending on your business needs, however, it is possible to implement the Web Container and EJB Container on separate servers.




Web Container The Web Container implements the JSP pages and servlets of Stat Web. It represents Stat Web’s user interface or presentation layer. This includes both the Web Console, which features some of the same functionality as the Stat Windows Client, and the Job Monitor, which is used to check the status of the Stat Agent.

EJB Container The EJB Container holds the Enterprise JavaBeans that implement the business logic and functionality of Stat Web and the Stat Agent. The Stat Agent interacts directly with the Stat Repository and the application environments to automate such tasks as generating and printing reports, sending e-mail messages, archiving objects, and maintaining database parameters.

Database Tier The Stat Repository contains activity data and configuration information for the Stat Windows client and the Stat Server.




STAT INSTALLATION REQUIREMENTS

Several key components, existing and new, must work together for successful integration and implementation of the Stat Application Change Management solution. The diagram on the following page gives an overview of the component requirements discussed in this document. Browse this graphic and its notes as it may provide you a general understanding of the system structures and communications/protocols in use. After surveying the figure, read the remainder of this document for finer detail and necessities for each of the listed components.




Figure 2 Stat Installation Requirements




STAT DATABASES

ORACLE OR MS SQL SERVER REQUIRED. YOU NEED ONLY REVIEW THE RELATED SECTION FOR YOUR RDBMS CHOICE, LOCATED BELOW OR ON THE FOLLOWING PAGE. LICENSING REQUIREMENTS SHOULD BE DISCUSSED WITH YOUR ORACLE OR MICROSOFT REPRESENTATIVE.

In accordance with accepted implementation principles, Quest will use development (DEV) and production (PROD) environments for the respective initial and final configuration of business processes in the Stat Application.

Stat on Oracle One (1) or two (2) empty Oracle databases for Stat Development and/or Production environments must be created prior to the arrival of the Stat installer or implementation consultant. An empty database is the creation of system tablespace & related datafile only. No other rollback, temporary, undo, etc. tablespaces are necessary. Proprietary scripts will be executed against each database to create & populate application data, index, and temporary datafiles / tablespaces. If you are at Oracle9i or higher, you must have database with Automatic Undo Management enabled. REQUIRED SCRIPTS

DBA should ensure, at minimum, that the following scripts have been executed by the SYS user: Catalog.sql (Loads the catalog views, synonyms and grants) Catproc.sql (To use the procedural option to have PL/SQL and stored procedure, package and trigger capability Catdbsyn.sql (Creates the DBA_ series of views in SYSTEM) Catexp.sql (Builds the tables and views required for the import and export programs) SYSTEM USER RIGHTS

DBA should ensure that the SYSTEM User has been granted all DBA-level roles and the following privileges: CONNECT, DBA, RESOURCE, and UNLIMITED TABLESPACE. This is critical for an error-free installation. INIT.ORA

Recommended starting values for init.ora parameters:

Oracle 8i Oracle 9i or 10g DB_BLOCK_SIZE=8192 DB_BLOCK_SIZE=8192 (for 9i only) DB_BLOCK_BUFFERS=10000 DB_CACHE_SIZE=78 MB SHARED_POOL_SIZE=60 MB SHARED_POOL_SIZE=60 MB

DB_BLOCK_SIZE: Specifies (in bytes) the size of Oracle database blocks. Typical values are 4096 and 8192. The value of this parameter must be a multiple (generally 512 bytes) of the physical block size at the device level. Set to at least 4096, and in most cases 8192 works best. If in doubt, set the block size to the largest supported on your system. Beginning with the Oracle 9i version, the BLOCKSIZE parameter lets you create tablespaces with block sizes that differ from your database’s default block, specified by the DB_BLOCK_SIZE parameter. In order to use this option, you need to set DB_CACHE_SIZE instead of the older DB_BLOCK_BUFFERS and you need to have DB_nK_CACHE_SIZE set, where ‘n’ is the block size you specify above.




DB_BLOCK_BUFFERS: Specifies the number of database buffers in the buffer cache. It is one of several parameters that contribute to the total memory requirements of the SGA (Shared Global Area) of an instance. Note: DB_BLOCK_BUFFERS cannot be combined with the dynamic DB_CACHE_SIZE parameter; combining these parameters in the same parameter file will produce an error. DB_BLOCK_BUFFERS is retained for backward compatibility DB_CACHE_SIZE: Specifies the size of the DEFAULT buffer pool for buffers with the primary block size (the block size defined by the DB_BLOCK_SIZE parameter). For example If DB_BLOCK_SIZE = 8192 and DB_BLOCK_BUFFERS = 10000, the Buffer Cache Size will be = 8192 * 10000 = 78MB or a single parameter of DB_CACHE_SIZE = 78M SHARED_POOL_SIZE: Size of the shared buffer pool in the SGA. For a small- to medium-sized system, 25 to 30 megabytes is usually adequate. For a medium- to large-sized system, it is usually optimally set at between 60 and 80 megabytes. Sites with large applications using many packages and procedures achieve improved performance when the SHARED_POOL_SIZE is enlarged beyond 100 megabytes. Please indicate the appropriate information below:

Requirement Information Quest Verified

Oracle Release Version:

Server OS:

Stat DEV

Instance Name:

SYSTEM User Password:

Tnsnames.ora Net Service Name:

Tnsnames.ora Host Name:

Tnsnames.ora Port Name:

Stat PROD

Instance Name:

SYSTEM User Password:

Tnsnames.ora Net Service Name:

Tnsnames.ora Host Name:

Tnsnames.ora Port Name:

stat architecture detail

Documents