R12 d49656 gc10-apps dba 07

Editor's Notes

• #2: Schedule: Timing Topic 30 minutes Lecture 30 minutes Practice 60 minutes Total
• #3: <Course name> <Lesson number> -
• #4: <Course name> <Lesson number> - Overview Within its multi-tier architecture, Oracle Applications stores business data in Oracle database tables. Additional database objects such as indexes and views are used when processing these tables. Oracle Applications code modules, in the form of stored procedures, are also contained within the database. This module discusses: The database objects used by Oracle Applications Oracle Applications’ use of schemas to control access The APPS schema Oracle Applications product schemas Multiple Organization Architecture Multiple Reporting Currencies Database tier server process scripts
• #5: <Course name> <Lesson number> - Oracle Applications Database Objects Oracle Applications stores data and some code in the Oracle database. Each Oracle Applications product has its own set of database objects, and may share these objects with other products. Database objects can be divided into the following categories: Data objects - Used for storing and accessing business data. These objects include tables, indexes, sequences, and index-organized tables. Code objects - Used to process the data. These objects include triggers, PL/SQL packages, Java stored procedures, synonyms, and views. Hybrid objects - Used to both store and process data. Materialized views are an example of hybrid objects.
• #6: <Course name> <Lesson number> - Multiple Languages in the Database Oracle Applications features that support multiple languages store translated data in translation tables . These tables are appended with “_TL”. For example, the FND_ APPLICATION_TL table stores translated information about all the applications registered with Oracle Application Object Library. Compare this with the FND_APPLICATION table, which stores base information about all the applications registered with Oracle Application Object Library. There are also views that are appended with “_VL” that use the LANGUAGE column of the _TL tables and the user’s session language setting to retrieve data in the correct language. Instructor Note: _TL tables are built during the installation, regardless of whether additional languages are installed.
• #7: <Course name> <Lesson number> - Schemas A schema is a named collection of database objects. The schema is the owner of the objects it contains, and controls access to them. A schema can allow another schema to use its objects. by granting the second schema the appropriate level of access. The concept of a database schema is directly tied to the concept of a database user. That is, there is a one-to-one relationship between schemas and users in an Oracle Applications database. The database user and the schema have the same name. There are several important characteristics of schema usage by Oracle Applications: An Oracle Applications product’s database objects are divided between the product schema and the APPS schema. A product’s schema contains only its own data objects (tables, sequences, and indexes). All code objects (triggers, views, packages, and synonyms) for all products reside in the APPS schema. Instructor Note: For Oracle Applications, materialized views are created in the APPS schema, as they may need to reference tables belonging to multiple products. Only APPS is guaranteed to have required privileges on those tables.
• #8: <Course name> <Lesson number> - Oracle Applications Product Schemas In general, each product has a corresponding schema that is used to store that product’s data objects. The default Oracle schema name and password for a product are usually the same as the product’s abbreviation. For example: Oracle General Ledger data objects are stored in the GL schema. Oracle Receivables data objects are stored in the AR schema.
• #9: <Course name> <Lesson number> - APPS Schema To achieve a high level of mutual integration, Oracle Applications products must to be able to access objects as required. For example, a package or view owned by one product may need to access data or other packages or views owned by other products. Maintaining individual access rights between all product schemas would be inefficient and inflexible. Instead, all code objects are kept in the central APPS schema, which facilitates access as follows: Each product’s schema grants full privileges to the APPS schema The APPS schema has synonyms to all base product tables and sequences Hence, APPS has universal access to Oracle Applications Runtime usage of Oracle Applications is through the APPS schema only. Users do not connect directly to product schemas such as INV.
• #10: <Course name> <Lesson number> - Additional Schemas The data objects for some products are combined within a single schema. For example, data objects for the Human Resources products (Human Resources - PER, Payroll - PAY, and so on) are stored under a dedicated HR schema, whereas data objects for the Applications technology layer products (FND, AD, and so on) are all stored under the APPLSYS schema. There is also a public schema, APPLSYSPUB, which is used only during the signon process and has no data objects, only synonyms to APPS. Instructor Note : The APPS_MRC schema (for the Multiple Reporting Currencies option) is not used in Release 12, having been dropped in Release 11.5.10.
• #11: <Course name> <Lesson number> - Schemas Used During Signon When you sign on to Oracle Applications, you initially connect to the public schema, APPLSYSPUB. Once your user name and password have been verified, Oracle Applications connects you to the APPS schema and allows you to choose a responsibility. You can then use the Forms interface or HTML interface to access data that resides in a product schema.
• #12: <Course name> <Lesson number> - Implementing Multiple Organizations The Oracle Applications Multiple Organizations Architecture provides support for multiple organizations in a single installation of Oracle E-Business Suite.  The Multiple Organizations feature enables implementers to partition data by various types of organizational units, such as operating units and inventory organizations. Database objects that utilize Multiple Organizations can easily be identified by their object name. Base tables which provide unsecured data access have a suffix of "_ALL“, whereas synonyms for the same logical object, but without the suffix, provide secured data access. For example, AP_INVOICES_ALL and AP_INVOICES are examples of a base table and secured synonym respectively. Before Release 12, the Multiple Organizations feature had to be enabled explicitly, by running the AD Administration utility and choosing the 'Convert to Multi-Org' program. This converted existing data, and (where applicable) replicated seed data. By contrast, Multiple Organizations is enabled by default in a fresh install of Release 12. You only need to run the seed data replication program if you define new operating units from the Define Organization form in Oracle HRMS. For further details, see Oracle Applications Multiple Organizations Implementation Guide.
• #13: <Course name> <Lesson number> - Reporting Currencies The Reporting Currencies feature permits an organization to report and maintain accounting records at the transaction level in more than one functional currency. You do this by defining one or more reporting sets of books in addition to your primary set of books. In your reporting sets of books you maintain records in a functional currency other than your primary functional currency. Your primary functional currency is the currency you use to record your business transactions and accounting data within Oracle Applications. The primary functional currency is defined within your primary set of books. A reporting functional currency is a functional currency as defined in a reporting set of books. You can use any defined functional currency to support financial reporting. Reporting Currencies can be used even if the Multiple Organization Architecture is not implemented. Instructor Note : As noted previously, the separate APPS_MRC schema is not used in Release 12, having been dropped in Release 11.5.10. Instructor Note : In Release 12, the older term “Multiple Reporting Currencies” has been replaced by “Reporting Currencies”.
• #14: <Course name> <Lesson number> - Database Performance Features The Oracle database server documentation contains in-depth information on each of these features. Instructor Note: The database performance features information provides a general overview of some of the Oracle database features used by Oracle Applications. These topics are covered in more detail in the Oracle database-specific course offerings by Oracle University, particularly Oracle Database Administration Fundamentals and Oracle Database Performance Tuning . Students requiring further information about these features should be encouraged to take one of the above courses.
• #15: <Course name> <Lesson number> - Database Performance Features The Oracle database server documentation contains in-depth information on each of these features.
• #16: <Course name> <Lesson number> - Automatic Workload Repository (AWR) The Automatic Workload Repository is a repository of database performance statistics built in to the Oracle 10g Release 2 database. AWR automatically generates snapshots of performance data at regular intervals (typically, once an hour) and collects the statistics for use in problem detection and tuning. The gathered data can be displayed in both reports and views. You can access AWR through Oracle Enterprise Manager Database Control, managing snapshots or modifying settings in order to create baselines that capture typical performance periods. The baselines can be used for comparisons with similar workload periods where performance problems have been reported. Instructor Note : AWR is new with Oracle Database 10g.
• #17: <Course name> <Lesson number> - Automatic Database Diagnostic Monitor (ADDM) The Automatic Database Diagnostic Monitor is a tool that allows the Oracle database diagnose its own performance, and determine how problems can be resolved. ADDM analyzes Automatic Workload Repository data on a regular basis, locating the root causes of performance problems and providing recommendations for correcting them. Because AWR stores historical performance data, ADDM can be used to analyze performance issues after the event, saving time and resources in reproducing a problem (where this is even possible). Automatic database diagnostic monitoring is enabled by default, and its primary interface is Oracle Enterprise Manager Database Control. Instructor Note : ADDM is new with Oracle Database 10g.
• #18: <Course name> <Lesson number> - Database Performance Features Active Session History is a means by which a detailed history of database activity is captured and stored. Only active sessions are captured, so the amount of data recorded is directly related to the work being performed. The V$ACTIVE_SESSION_HISTORY view records current sampled session activity. Unlike the instance-level statistics gathered by AWR, ASH gathers data at the session level. You can run ASH reports to analyze transient performance problems with the database that may only occur during specific times. For example, ASH can often be used to identify short-duration problems (perhaps lasting only a few minutes) that would represent too small a proportion of an ADDM analysis period to be noticeable. Instructor Note : ASH is new with Oracle Database 10g.
• #19: <Course name> <Lesson number> - Cost-Based Optimization The Oracle optimizer evaluates many factors to calculate the most efficient way to execute a SQL statement. It is capable of using either a rule-based or cost-based approach for execution of the statement. Rule-based optimization was used in earlier Applications releases, but since the SQL used in Release 12 has been extensively tuned for cost-based optimization, Release 12 (like Release 11 i ) requires the optimizer to use cost-based optimization (CBO). Using CBO, the optimizer considers the available access paths, factoring in statistical information for the tables and indexes that the SQL statement will access. CBO also considers hints, which are optimization suggestions placed in a comment block of an SQL statement. For some operations, such as batch processing, Release 12 uses CBO to achieve the most efficient means of processing all rows that are accessed by the statement. For other operations, such as accessing forms or communication with the desktop client, Release 12 uses CBO to achieve the best response time for processing the first rows that are accessed by the statement. Several other Oracle database performance enhancements used in Release 12, such as partitioned tables, also require use of the cost-based optimizer.
• #20: <Course name> <Lesson number> - Database Resource Manager The Database Resource Manager gives the system administrator extensive control over processing resources on the database server node. The administrator can distribute server CPU based on business rules, ensuring that the highest priority activities always have sufficient CPU resources. The administrator could, for example, guarantee Order Entry users 40% of CPU resources during business hours, regardless of the load or number of users in other groups on the system. System administrators can also use the Database Resource Manager to limit the impact of any inefficient ad hoc queries. For example, a limit of 5% of CPU resources could be placed on ad hoc queries against the database.
• #21: <Course name> <Lesson number> - Partitioned Tables Partitioning helps support very large tables and indexes by dividing them into smaller, more manageable pieces called partitions . Once the desired partitions have been defined, SQL statements can access them instead of the original tables or indexes. Partitioning reduces access time, and partitions are especially useful in data warehouse applications, which often store and analyze large amounts of historical data. For example, operations that involve copying or deleting data are improved by use of partitioned tables. Partitioning of standard Applications tables in Oracle Applications Release 12 is fully supported. Most Applications tables do not have a natural partitioning key that would apply to all installations, because of differences in data distribution and access paths in different implementations. Tables should therefore be partitioned in a logical manner, to meet specific requirements. For example, period_name and set_of_books_id are likely candidates for partitioning the GL_BALANCES table. Operations such as data loads, index creation and rebuilding, and backup/recovery are much faster tat the partition level than on the entire table. Instructor Note: Partitioning should always be planned carefully, and subsequently tested to confirm that the expected performance benefits have been achieved.
• #22: <Course name> <Lesson number> - Temporary Tables Characteristics of temporary tables include: Data in a temporary table is private to each user’s session. Each session can only see and modify its own data. Locks are not acquired on the temporary table because each session has its own private data.
• #23: <Course name> <Lesson number> - Locally Managed Tablespaces In the traditional model, each Oracle Applications product had its own table and index tablespaces. For optimum performance, these are created as locally managed tablespaces. Oracle Applications tablespaces have a standard naming convention, in which ‘D’ (for data) or ‘X’ (for index) is added to the product’s short name or Oracle schema name. For example, the tablespaces APD and APX are the tablespaces for Oracle Payables tables and indexes, respectively. The new tablespace model (OATM) also uses locally managed tablespaces.
• #24: <Course name> <Lesson number> - Oracle Applications Tablespace Model In the traditional model, each Oracle Applications product had its own table and index tablespaces. With an increasing number of products available, this would mean a need for several hundred product tablespaces. The Oracle Applications Tablespace Model (OATM) accommodates the schema objects for all products in a much smaller number of locally managed tablespaces. OATM groups Oracle Applications schema objects based on characteristics such as size, lifespan, and the type of data they contain. For example, tables that contain seed data are allocated to a different tablespace from tables that contain transactional data. Instructor Note: Conversion to OATM (for example, after an upgrade) can be performed using the OATM Migration Utility. During the process of migrating data and index segments from the old tablespaces to OATM, the Migration Utility reclaims any unused space.
• #25: <Course name> <Lesson number> - Oracle Real Application Clusters (Oracle RAC) A large processing task, divided into subtasks and distributed among multiple nodes of a cluster of computers, is completed more quickly and efficiently than if the entire task was processed on one node. As nodes or disks are added to a cluster, Oracle RAC utilizes these resources beyond their limits as individual components, maximizing their usefulness in catering for larger workloads and growing user populations. In Oracle RAC environments, all active instances can concurrently execute transactions against a shared database. Oracle RAC coordinates each instance’s access to the shared data, providing data consistency and data integrity. From a developer’s point of view, RAC enables applications to be scaled to meet increasing demand, without the need to modify the application code.
• #26: <Course name> <Lesson number> - Oracle Real Application Clusters (Oracle RAC) All Oracle Applications products can be successfully deployed against an Oracle RAC-enabled database. Using Parallel Concurrent Processing, concurrent managers on separate application tier machines can be configured to direct requests to different database servers in an Oracle RAC cluster.
• #27: Materialized Views Materialized views are schema objects that can be used to summarize, precompute, replicate, and distribute data. When used to precompute and store aggregated data such as sums and averages, they can greatly increase the speed of queries on very large databases. Materialized views can therefore improve performance of Oracle Applications products, such as Daily Business Intelligence, that perform many queries on summary data. They are also potentially very useful in data warehouse environments. Cost-based optimization, discussed earlier in this module, use materialized views to improve query performance, by automatically recognizing when one can be used to satisfy a request. In such a case, the optimizer transparently rewrites the request to use the materialized view instead of the underlying tables or views. In distributed environments, materialized views can be used to replicate data at remote sites, providing local access to data that would otherwise have to be accessed from the main site via a network link.
• #28: <Course name> <Lesson number> - Database Tier Server Process Scripts The key directory on the database tier is <RDBMS_ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME>. This directory contains control scripts to start and stop the database and database listener processes and to run AutoConfig.
• #29: Database Tier Server Process Scripts UNIX uses shell scripts (.sh) to control database server process startup and shutdown. On Windows, command files (.cmd) are used.
• #30: <Course name> <Lesson number> - Database Tier Server Process Scripts On Windows, you can also start up or shut down database server processes as follows: 1. Go to Start > Administrative Tools > Services 2. Select a service from the Services window 3. Click Start or Stop, as required
• #31: <Course name> <Lesson number> -
• #32: <Course name> <Lesson number> -
• #33: <Course name> <Lesson number> - Refer to Practice - Starting and Stopping the Database [LAB41F5Y]