| Oracle® Database System Administration Guide 10g Release 2 (10.2) for IBM z/OS (OS/390) Part Number B25398-01 |
|
|
View PDF |
| Oracle® Database System Administration Guide 10g Release 2 (10.2) for IBM z/OS (OS/390) Part Number B25398-01 |
|
|
View PDF |
The performance of your Oracle server depends on a number of factors. This chapter describes some of those factors and provides recommendations for improving and tuning your system to promote better Oracle performance.
The following topics are included:
An excellent method for reducing the real storage requirements for Oracle is to place reentrant modules in z/OS link pack areas. Most Oracle modules are link-edited with AMODE set to 31 and RMODE set to ANY. Place such modules in the extended pageable link pack area (EPLPA) above the 16M line. Some modules are linked with RMODE set to 24. Place them in the pageable link pack area (PLPA) below the 16M line. Current versions of z/OS automatically load modules from the link pack area libraries into the appropriate link pack areas.
Keep in mind that under the current z/OS implementation, placing modules into LPA reduces the private area of every address space in the system. In other words, there is a trade-off between code sharing and virtual memory availability.
Note:
If you choose to take advantage of this z/OS feature, be aware that any STEPLIB/JOBLIB definition in the JCL has precedence over the placed modules of any link pack areas. Make sure that such modules do not exist in the STEPLIB/JOBLIB libraries so that the link pack area copy will be used instead.Only the subsystem code module (ORASSI) is automatically shared, and it is shared by all Oracle subsystems and services.
The Oracle database and Net regions run different programs from the Oracle AUTHLOAD library. Each Oracle database address space has its own copy of ORARASC and a few other modules, and the Net address space has ORANET and several others modules as well. There is no sharing of this code, even between address spaces of the same database service. Due to an operating system restriction, you cannot put ORARASC into LPA -- doing so makes it impossible to run any other copy of ORARASC (for example, an ORARASC at a different maintenance level), whether from LPA or not. ORARASC is also quite small in size, so it is not necessary for it to be shared. The Net modules, such as ORANET, are also quite small in size. In addition, because a single Net service can be used to access multiple database services, typically only one Net service will be deployed. As a result, sharing of Net code is also typically unnecessary.
If you are running multiple Oracle database regions (from either the same or different instances), an excellent candidate for LPA usage is the Oracle kernel (in other words, the ORACLE module), because it is quite large in size. As described above, prior consideration should be given to the impact on any non Oracle workloads that may be constrained by virtual storage.
If your installation will run multiple concurrent local users, you can place the following modules from the Oracle CMDLOAD into the link pack:
LIBCLNTS contains the interface routines for all Oracle client accesses. This includes tools, utilities, precompilers, precompiler applications and Access Managers. LIBCLNTS is an excellent candidate because of it's relatively large size. Place it in the EPLPA above the 16M line.
SQLPLUS is the primary Oracle batch and interactive SQL processor. It is used for user database queries, updates, table creates and drops, and so forth. In many systems, this module is used heavily enough to warrant link pack area placement. Place it in the ELPA.
The Oracle server makes static-fixed, static-variable, and dynamic virtual memory allocations as the Oracle regions are started up and begin providing database services to users. Static-fixed memory allocations are storage areas that are always allocated in the regions including space for the Oracle load modules, working storage, and z/OS data areas. Static-variable memory -- mainly the SGA -- differ from one warm start of the server to the next, depending on initialization parameter values. Dynamic memory allocations occur as users connect to the instance and access information that is stored in the server. The primary factors determining the number of concurrent Oracle users that can be supported under z/OS are the user memory allocation requirements (depending on the application design), the INITORA and OSDI parameter values, the amount of virtual memory that Oracle regions are allowed to allocate, and the amount of central storage that is available for use by the Oracle regions.
Exhausting virtual memory in an address space will lead to any of a number of types of failures, because it is impossible to predict which system activity requests for memory are going to be denied.
This scenario is best avoided by configuring a database instance with enough address spaces to contain the largest expected workload in terms of memory required. Doing this requires an understanding of the workload as well as of the database address space topography on z/OS.
In addition to carefully configuring server address spaces, you can use certain database region parameters that provide controls designed to reduce the likelihood of exhausting address space memory. These are discussed in "Limiting Sessions in a Server Address Space", and "Limiting Memory Allocations in a Server Address Space".
Each database address space starts out with a given amount of private virtual memory: 2048 megabytes less the memory that is used or reserved by z/OS for shared access by all address spaces: SQA, CSA, LPA, and the z/OS nucleus and related data. The sizes of these spaces, and thus the amount of private memory remaining in each address space, varies from one z/OS system to another. You may need to consult with your systems staff to determine the available private area size on your system.
Once you know the private area size of your system, you must subtract from it the amount of memory that will be allocated in each address space for purposes other than Oracle sessions. This memory allocation includes the SGA, the Oracle kernel -- usually named ORACLE -- and other minor load modules (ORARASC, ORARSSRB, ORADIE), and the load modules and data structures of the z/OS Oracle infrastructure, including the IBM Language Environment (LE) interface. The size of the SGA is determined primarily by parameters that you specify in the INITORA file and is displayed during Oracle startup. (For additional discussion of the SGA, refer to section "Oracle SGA on z/OS".) The size of the Oracle kernel and other modules can be determined using ISPF browse on the load library that contains it.
After the foregoing are subtracted, the remaining private memory in each server address space is available for Oracle sessions. The maximum amount of memory that is required by a given session depends mainly on the behavior of the application: the number of cursors opened, the specific SQL statements used, PL/SQL and/or Java requirements (if any), and so forth. In addition, there are several INITORA parameters (SORT_AREA_SIZE, HASH_AREA_SIZE, and so forth) and a database region parameter (INIT_STACK_SIZE) that affect the memory resources that are allocated during each session execution. This can be quite difficult to estimate in advance of running the application. The most reliable way to determine memory requirements is to review the Oracle session SMF records (which contain a session memory high-water mark) and analyze them to determine the average peak session memory. For more information on Oracle SMF records refer to "Interpreting an Oracle Accounting SMF Record".
Once you know the average session memory requirement you can calculate the number of sessions that will fit in one address space as:
N = P / S
where:
Table 15-1 Variable Descriptions for Code Example
| Variable | Description |
|---|---|
|
|
is the desired result |
|
|
is the available private memory per address space |
|
|
is the average peak session memory |
If we let T be the total number of concurrent Oracle sessions to be supported then you need (T / N) server address spaces. This number should be rounded to the next higher whole number, and to allow for reasonable variability in workload level, it may be advisable to add one more address space. In doing so, keep in mind that an SQA cost is associated with starting additional address spaces, which is discussed in the section "Oracle SGA on z/OS".
Oracle Corporation recommends that you specify the number of address spaces calculated here as the INIT_ADR_SPACES parameter (so the address spaces all start when the service is started). A somewhat higher number can be specified as MAXAS (maximum address spaces) on the DEFINE SERVICE command. This makes it possible to start additional address spaces dynamically if the initial estimate proves to be low. There is no cost for having additional address spaces in the MAXAS parameter until those address spaces are actually started. Note that MAXAS must be equal to or greater than INIT_ADR_SPACES. Care should be taken to specify a high enough value to accommodate unpredictable workload growth or spikes.
Note that using more than one address space results in the Oracle server becoming a "cross-memory address space" in z/OS terms. These address spaces are not available for reuse when the Oracle server terminates. The z/OS PARMLIB parameter RSVNONR specifies the number of address space numbers to reserve for use as they become unavailable. If you use multiple address spaces for the Oracle server, then you should increase the value specified for this parameter. Specifying too small a value, or letting RSVNONR take the default value could result in an unscheduled IPL if the number of address space IDs becomes exhausted. For example, you could stop the Oracle server for maintenance and then become unable to restart without an IPL. For more information, refer to the IBM document MVS Initialization and Tuning Reference.
An Oracle Database instance has a single SGA, System Global Area, regardless of the number of address spaces or regions configured. The SGA is shared across all of regions of a server using a z/OS service called IARVSERV that allows one address space to "view" a range of private virtual memory that belongs to another address space. The SGA belongs to the first server address space (primary region) and is viewed (shared) by any other regions that are configured for that server. The virtual address range of the SGA must be reserved in each of the auxiliary regions to support the viewing mechanism. This is why the SGA size is subtracted from the private area size in every server address space of a given instance (not just the primary region) in the memory calculations of the previous section, "Determining the Number of Oracle Address Spaces".
Sizing the SGA and, most significantly, sizing the database buffer cache and the shared pool, are important instance tuning activities. The numerous INITORA parameters that do this and the general considerations for specifying their appropriate values are covered in the Oracle Database Reference and Oracle Database Performance Tuning. The following paragraphs describe some z/OS-specific issues to be aware of when tuning the SGA.
Because the SGA is not permanently pagefixed on z/OS as it is on some other systems, there is little benefit in reserving SGA expansion space with the SGA_MAX_SIZE parameter. When you specify SGA_MAX_SIZE, the indicated maximum size is reserved (in virtual memory) in all server address spaces even if it is not all used.
Keep in mind that the SGA is mapped in all of the server address spaces of a given instance as discussed above. This means that increasing a server's SGA size reduces the virtual memory available for Oracle sessions in every server region for that instance. If you do this, you may need to increase the number of regions in order to support your peak workload. The relationship is not linear. A 25% increase in SGA size may require more than a 25% increase in the number of server regions. When you make a significant change in the SGA size, repeat the calculations described in the previous section to determine the number of server address spaces that you need.
Another factor in SGA sizing is the overhead of the IARVSERV memory sharing mechanism. Currently, z/OS must reserve 32 bytes of ESQA (Extended System Queue Area) for each "view" of each 4K page of memory shared. SQA is an expensive resource because it is page-fixed (always backed by real memory) and because it is globally addressable, using up an address range that would otherwise be part of the private area of each address space. Exhausting z/OS SQA is a situation best avoided, so you should calculate the SQA overhead for your SGA and discuss this with your z/OS systems staff before attempting to start the server.
Note:
The total amount of SQA to reserve for all uses is a z/OS system initialization parameter and cannot be changed without an IPL.As an example, an Oracle server configured to run in 10 address spaces with a 512 megabyte SGA requires
or 40 Megabytes, of SQA, a significant amount.
Note:
The IARVSERV SQA overhead occurs only when running Oracle servers in two or more address spaces. When a server is configured to run in a single address space only, IARVSERV is not used, and no SQA requirement is imposed. The current IARVSERV implementation provides page-level (4K unit) sharing granularity with a rather high cost in real memory overhead (on the order of 3% of all aggregated virtual views) for mapping tables.Each Oracle server user requires some extent of private memory to be used as a save area during normal execution. This area is known as the user stack.
When a user session is initiated, the connection is routed to a particular Oracle region. This region will then acquire a stack area based on the INIT_STACK_SIZE parameter. If the user requires more stack, additional extents are dynamically allocated and freed when they are no longer required. The actual stack requirement is dependent on the type of database call being used (SQL, PL/SQL, Java, OCI) and its complexity.
To fine tune this parameter, you might want to use the Oracle session SMF records analysis method described in the "Database Server Address Space Configuration" section (that was presented earlier in this chapter), or you can run your workload by varying the INIT_STACK_SIZE settings and then comparing the CPU usage of the various tests. The lower the INIT_STACK_SIZE value, the higher the potential CPU overhead that is caused by dynamic stack expansion.
As a starting point, you can use the Oracle Corporation recommended minimum value of 128K.
The MAX_SESSIONS parameter also plays a role in managing virtual memory use. This is a hard limit on the number of sessions that can be active in one server address space, and it defaults to 1024 sessions. If a new bind (client connection) is routed to an address space that is at the MAX_SESSIONS limit, the server waits until some existing session unbinds (disconnects) before accepting the new session.
The idea behind MAX_SESSIONS is to keep the address space from accepting so many sessions that virtual memory is exhausted and unpredictable failures occur. The assumption is that it is better not to let an application connect and get started than to let it connect and incur transaction failure partway through its processing. A good value to use for MAX_SESSIONS is the value N (maximum sessions per address space) that was calculated in the section "Database Server Address Space Configuration".
Both INITORA and database region parameter values must be set high enough to allow the required number of users to connect to the server.
Two more database region parameters provide additional control over memory consumption in a server address space. The MAX_SESSION_MEM parameter allows you to impose a limit on the total virtual memory allocated to any single session in the Oracle server. This applies to all session-private memory requests made by the server, including the C stack and "heap" areas.
The limit is imposed on all sessions, including background processes and even parallel query slaves. If a session requests memory that would take it over the limit, the session receives an error (usually an ORA-04030) and the current transaction is rolled back.
Care should be taken not to choose too small a session limit. STARTUP processing in the current Oracle release requires about 10 megabytes of session memory. Note that session memory usage is reported in the Oracle SMF record, which can be used to help determine an appropriate limit amount.
Another parameter, REGION_MEM_RESERVE, allows you to limit the total memory allocated to all sessions and the SGA in an address space before exhausting address space private area. The "reserve" amount you specify remains available for internal implementation and z/OS system function use.
Specifying an adequate reserve amount prevents the situation of exhausting address space memory and significantly reduces the impact of memory consumption problems. Requests for memory that would exceed the aggregate limit are rejected, resulting in an error and transaction rollback in the affected session.
The amount of real storage ("working set size") that is required by the Oracle regions is very workload dependent, varying significantly with transaction complexity and rate, user concurrency, and locality of program and data reference. A lightly-loaded instance might require only 50K of working set for every megabyte of virtual memory that is allocated, while an instance that is supporting a much higher workload might require 750K of working set for every megabyte of virtual memory that is allocated. In general, Oracle load modules and the SGA remain in central storage while the context areas, sort work areas, and other individual session-related areas are more likely to be paged out to expanded or auxiliary storage when they are not heavily used.
The amount of virtual memory that is consumed by the server regions may vary significantly at run time because memory usage levels are very dynamic and fluctuate according to user workload. This is especially true when users connect and/or disconnect frequently or when users execute applications that open and close a large number of cursors, and when sorts are performed. Region size limitations can therefore become important, even with a small number of users connected to the instance. A region size limit that is too small prevents users from connecting to the server or from accessing information. Oracle Corporation recommends that you allow the server to allocate as much virtual memory as required and that you avoid imposing any region size limitations on the software. Other z/OS facilities can be used to control the amount of central and expanded storage that is used by the server. The easiest way to allow Oracle Database for z/OS to use the maximum amount of virtual storage is to specify the REGION=0M keyword parameter on the EXEC statement in the region startup JCL. For information on the REGION=0M keyword and IEFUSI Exit, refer to the section "Database Region JCL".
The Workload Manager (WLM) is a z/OS facility that allows installations to effectively manage their Oracle as well as non-Oracle workloads based on business priorities. Goals can be defined to reflect business priorities. The system manages the amount of resources, such as CPU and storage that are necessary for a given workload, to achieve its goal.
Earlier versions of z/OS had a Workload Manager mode called "compatibility mode" where the installation had direct control over performance parameters such as the dispatching priority of the various Oracle address spaces. z/OS 1.4, required for Oracle Database 10g, only supports Workload Manger goal mode. With this mode, the installation has no direct control over the detailed performnance parameters, but assigns an importance and a goal to each element of work.
Like other WLM managed workloads, Oracle workloads should be assigned to appropriate service classes based on attributes such as subsystem name, service name, user name, and transaction name. Service class structure and importance are determined by the business needs of an installation. Workloads should also be classified into report classes to facilitate monitoring and validation of an installation's workload management policies.
Service classes allow you to control the priority of your Oracle instances relative to other workloads. Service classes should be defined for your Oracle instances based on the performance requirements of the instances. You usually do not need to define a service class for each Oracle instance, because multiple Oracle instances with similar performance requirements can typically be mapped to a given service class (production instances versus test and development instances, for example). Report classes provide more granular reporting capability for different Oracle instances within a given service class and should be used where necessary to monitor CPU, memory, and I/O resources that are consumed by individual Oracle instances in the reports that are generated by SMF/RMF and other measurement subsystems.
The service class of the Oracle regions determines the relative dispatching priority of the background processes and other special tasks within the Oracle instances. The Oracle regions typically consume very moderate amounts of CPU resources. Normally, the bulk of the CPU resources that are consumed to process database requests are incurred by the client address spaces for local requests (and Oracle Net SRB enclaves in the case of remote requests) and should be managed accordingly (refer to "Local Clients" and "Remote Clients"). Oracle, therefore, typically does not need to run at a high priority, but you may want to consider the special conditions that are associated with the parallel execution feature that is discussed below in the last paragraph of this section.
In general, the Oracle regions can be configured for lower dispatching priority (or lower importance) than high priority CICS TS and TSO workloads, and at about the same priority as high importance (or non-discretionary) batch workload. For example, CICS TS users for a given Oracle instance should be configured for higher priority (or importance) than the corresponding regions of the Oracle instance. Similarly, in the case of TSO, higher priority (or importance) should be assigned to first or second period TSO workloads than to the Oracle regions. A higher dispatching priority is obtained by assigning these address spaces a service class with a high importance. Importance 1 is the highest importance level and Importance 5 is the lowest.
If the Oracle dispatching priority is too low, and if the system suffers from significant CPU contention (indicated by high processor delay in the Oracle regions), then some important Oracle internal requests might not get immediately processed, or the background tasks might not get dispatched often enough to perform the required work. For example, the buffer pool might become filled with modified buffers, and users might need to wait for Oracle to get dispatched and write out some database blocks to allow user processing to continue. The following scenario illustrates this situation:
You see the 'free buffer waits' event (from a UTLBSTAT/UTLESTAT, STATSPACK, or similar report) showing a significant total value (the unit is hundredths of second) relative to the report interval during a DML-intensive period (update, delete, or insert operations). First, consider enlarging the buffer pool, or pools, to trade memory for I/O requests (you can have multiple buffer pools in Oracle Database for z/OS). Assuming that no significant I/O bottlenecks are affecting the database files (fix them first if any occur), and if the AS1 or Control Address Space CPU delay is low, then it might be necessary to increase DB_WRITER_PROCESSES to schedule more parallel I/O. If the AS1 CPU delay is significant, however, you probably need to set the dispatching priority to a higher value first. Be aware that checkpoint activity also forces modified buffers to disk, adding to the I/O stress. You should also compare the 'physical writes' and 'physical writes non checkpoint' statistics from your report to make sure that the write activity is not being unnecessarily inflated by a poorly tuned checkpoint mechanism. Refer Oracle Database Performance Tuning for information on minimizing checkpoint overhead and for information on the UTLBSTAT/UTLESTAT and STATSPACK script utilities.
On the other hand, whenever users take advantage of the parallel execution feature that runs under special subtasks in the Oracle regions, the dispatching priority of the Oracle regions becomes an increasingly important tuning issue. In this case, Oracle dispatching priority determines how quickly these special requests are serviced and how much those Oracle users impact the overall throughput of the z/OS system.
The following considerations apply to resource intensive Oracle workloads within a TSO environment:
Increase the relative importance levels of TSO first and second periods. This supports transactions requiring greater resources and may result in a larger percentage of all transactions being completed in the first and second periods.
Consider adding a fourth or fifth performance period to account for extremely resource intensive TSO transactions.
Establish separate service classes for Oracle users. Use the service classes to reflect goals and relative importance of different TSO workloads that are classified by user attributes such as userid or accounting information.
CICS TS and IMS TM workloads can be managed using service classes and can be classified using attributes such as userid, transaction name, luname, and subsystem instance name.
Because batch workloads are typically discretionary in nature, Oracle batch jobs do not need to be separately classified. However, Oracle batch jobs can be distinguished from other batch jobs by establishing separate service classes, as described for the TSO environment.
When Oracle batch jobs are run under a certain service class, consider their priority relative to other Oracle and non-Oracle workloads. In a normal to heavily loaded system, if Oracle batch jobs run at a lower priority than others, the Oracle jobs might be swapped out for lengthy periods. If an Oracle job is swapped out while holding a critical latch, it may adversely impact the performance of other Oracle users.
Special services classes should be considered for privileged users or special jobs such as those described below.
The database administrator (DBA) frequently needs priority access to the database in order to perform functions on behalf of all Oracle users. Granting higher relative importance to these types of work shortens the elapsed time for these functions to the benefit of all users. Except for database import and export, DBA functions generally do not require large amounts of Oracle and system resources compared to those of the user community.
Import and export functions are good candidates for higher relative importance when they involve the entire database. If the performance parameters of your system force swapping among long running batch jobs, you might want to consider non-swappable status for import and export.
Import and export performance can be optimized by maximizing the size of the buffer that is used to transfer rows to and from the export file. The buffer needs to be large enough to hold approximately 1000 table rows to get the best performance from these utilities. In addition, you can improve performance by increasing the number of buffers that are available for reading and writing the export file. Use the DCB BUFNO JCL parameter to increase the number of buffers. The I/O operations that are issued by QSAM and BSAM will not generate a channel program using more than 30 buffers or more than approximately 240 KB. For I/O bound processes such as Export and Import, you should specify a BUFNO that allocates approximately 480 KB of buffers. This value will give you the maximum amount of overlap between two maximum I/O channel programs. Refer to Oracle Database Utilities for more information.
The direct path in SQL*Loader is much more efficient than the conventional path. When using the DIRECT option, SQL*Loader is generally I/O bound on the input data file. To reduce the elapsed time that is required for a load operation, you need to increase the number of buffers that are available for reading the input file by adding a DCB BUFNO parameter to the input file allocation. Performance improvements occur as the number of buffers is increased to 200, although 48 buffers yield a significant improvement in the data load rate.
If you cannot use the DIRECT option, then specify the largest bind array size (using the ROWS parameter) that you can. An array size of approximately 1000 rows improves performance significantly over the default size of 64 rows.
The creation of indexes on large tables can consume significant resources. Consider higher relative importance and non-swappable status for these functions.
In addition to z/OS tuning parameters, you need to consider special session settings to support index creation in large tables. Increasing the SORT_AREA_SIZE parameter value can substantially reduce the elapsed times of index creation jobs. This can be done selectively at the session level by using the ALTER SESSION SQL command so that other non-critical jobs will still use the INITORA specified value.
You can use SYNCSORT, DFSORT, or another z/OS sort utility to sort the data by key before loading it into Oracle. Once the data is sorted, load the data into Oracle and create the index with the NOSORT option. For large data loads, this technique can save significant amounts of time when loading data and creating the index.
Remote clients that access an Oracle server through the Oracle Net service are dispatched on a lightweight unit of work called an enclave SRB within the Net address space. The performance characteristics of such work can be effectively managed when used with WLM in goal mode. Enclave transactions are managed separately from one another as well as from the Oracle Net address space they run in.
The Net startup option ENCLAVE (CALL|SESS) controls how the database request from the client is handled (described under "PARM"). With ENCLAVE(SESS) specified in the PARM value used at Net startup, classification of the work is done once when a new remote connection is made. Oracle Net presents WLM with attributes for workload classification. Some of the network specific attributes that can be used for classification include protocol, host name, or IP address. The list of WLM attributes available for classification is shown in Table 15-2, "Workload Manager Attributes and Values". The enclave will be deleted at session termination (logoff) time. Because the classification happens only once per session, only velocity goals are appropriate for the enclave's service class.
If ENCLAVE(CALL) is specified in the PARM value used at Net startup, then the enclave is deleted when the request from the client is finished (when Net needs more data from the client). Deleting the enclave reports the transaction completion to WLM, providing response time and transaction counts to any workload monitors such as RMF. The next request arriving from the client will be classified into a new enclave. The values available for classification are the same as with ENCLAVE(SESS) above, and are shown in Table 15-2, "Workload Manager Attributes and Values". Because the classification is done for each network request, response time goals should be used for the enclave's service class.
Table 15-2 Workload Manager Attributes and Values
| ATTRIBUTE | VALUE |
|---|---|
|
Subsystem Type |
C'OSDI' |
|
SI |
OSDI subsystem name, for example, WFM1 |
|
UI |
User ID from connect |
|
NET |
first eight characters of dotted IP address (example: 100.024.) |
|
LU |
last seven characters of dotted IP address (example: 020.003) |
|
CT |
Protocol from connect 'TCP' |
|
SPM |
position 1-8: Oracle database service name |
|
SPM |
position 9-89: TCP/IP hostname (left justified) |
Note:
Leading zero characters must be used in the nodes of the dotted IP address."Subsystem Type" is not strictly an attribute. WLM has several predefined subsystem types (JES for example). You must define a new subsystem type of "OSDI" to WLM if you desire WLM monitoring of OSDI work. Refer to the IBM document, MVS Planning: Workload Management, for information on how to do this, and for information on how to utilize the attributes listed above to manage work. Generally, WLM is configured using ISPF and the IWMARIN0 REXX exec.
As z/OS 1.4 is a pre-requisite for Oracle Database 10g, the use of WLM goal mode is required and installations must specify a WLM policy. It is highly recommended that you include a section in this policy for the OSDI subsystem.
If you choose to run without a section in the policy for the OSDI subsystem, then the client work will be assigned the service class SYSOTHER, which has a discretionary goal. Performance is likely to be unsatisfactory.
The following is an example of a WLM classification rules ISPF panel:
Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 1 to 4 of 4
Command ===> ____________________________________________ SCROLL ===> PAGE
Subsystem Type . : OSDI Fold qualifier names? Y (Y or N)
Description . . . OSDI SubSystem Type
Action codes: A=After C=Copy M=Move I=Insert rule
B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
-------Qualifier------------- -------Class--------
Action Type Name Start Service Report
DEFAULTS: ORACLES ________
____ 1 SI ORAC ___ ________ ________
____ 2 NET 010.100 ___ ________ ________
____ 3 LU 001.080 ___ ORACLEM ________
____ 3 LU 001.081 ___ ORACLEH ________
**********************************BOTTOM OF DATA *******************************
This rule assigns the service class ORACLEM to all work arriving from a client at IP address 10.100.1.80, and assigns ORACLEH to all work from the client at IP address 10.100.1.81. Note that the service class ORACLES is assigned as the default service class to Net workloads that cannot be classified by the above rules. It is very important to specify a default service class. Without a default service class, an error in the classification rules could result in no rules matching. In this case, the request will be assigned service class SYSOTHER, which has a discretionary goal. This will result in undesirable performance characteristics.
If ENCLAVE(CALL) is specified in the PARM value at Net startup, you should specify response goals, or percentile response goals for the service classes used by Oracle enclaves. If ENCLAVE(SESS) is specified in the PARM value at Net startup, you should specify velocity goals for the service classes used by Oracle enclaves.
The following shows a sample screen defining a service class with three periods. The first period has a response time goal of 15 ms. at importance 1. This gives short requests high priority access to the CPU. If the request takes more than 50 CPU service units, the enclave is migrated to a second period at importance 3. If the request is still running after 500 service units, it is then migrated to a third period at importance 5. This design of service class goals is only feasible if the ENCLAVE(CALL) parameter is used. It has the advantage of providing fast, high priority response to short requests, while treating longer requests at low, batch-like priorities.
Service-Class Xref Notes Options Help
----------------------------------------------------------------------
Modify a Service Class Row 1 to 2 of 2
Command ===> _________________________________________________________
Service Class Name . . . . . : ORACLEH
Description . . . . . . . . . Oracle Mid Tier #1
Workload Name . . . . . . . . ORACLE (name or ?)
Base Resource Group . . . . . ________ (name or ?)
Specify BASE GOAL information. Action Codes: I=Insert new period,
E=Edit period, D=Delete period.
---Period--- ---------------------Goal---------------------
Action # Duration Imp. Description
__
__ 1 50 1 Average response time of 00:00:00.015
__ 2 500 3 Average response time of 00:00:00.500
__ 3 5 Execution velocity of 10
******************************* Bottom of data **********************
