Model 204 Part 2: In-Memory Data Equates to High Performance - Resident Requests
By Jim Damon
In Part 1 of this series I discussed the advantages of keeping large numbers of database pages in memory by allocating a large disk-buffer pool. This was the in-memory data discussion.
Introducing Resident Requests
Equally important in achieving high performance, reducing CCASERVR and CCATEMP I/O, and reducing end-user response time is the Resident Request feature, which enables another type of in-memory data. Resident Requests are effectively re-entrant code that can be used concurrently by multiple users. This feature keeps the QTBL and NTBL portions of APSY precompiled requests in dynamically getmained control blocks (virtual storage), outside of all servers. These control blocks are shareable by all users, are allocated -- one per resident UL request, and are used in the evaluation of that request on behalf of any user.
Without the Resident Request feature, each user loads all compiler tables for a precompiled request into the current server and runs a private copy of that program. Since the QTBL and NTBL portions of a precompiled request never change regardless of the user (with two exceptions), loading this part of the request is unnecessary.
With the Resident Request feature enabled, QTBL and NTBL are not loaded to each individual server. Also, the CCATEMP I/O normally required to bring the pages of compiled QTBL and NTBL entries into the buffer pool is eliminated. CCATEMP physical reads, DKRDs, are reduced and overall database I/O is reduced. Given the high I/O activity usually associated with CCATEMP, this can result in substantial performance improvements in the entire Model 204 Online system.
Briefly, the Resident Request feature:
Often a single, production APSY precompiled request requires 60 -120K for QTBL and another 10 -15K for NTBL, which are saved in CCATEMP pages. This amount of table space represents 12 - 25 CCATEMP pages which must be loaded into the user's server prior to the evaluation of one request. To complete the APSY load, these pages must be either
Total byte count down
The Resident Request feature also reduces the number of bytes transferred during each server swap - either a server read, SVRD, or a server write, SVWR. When you execute a Resident Request that incurs a server swap, the QTBL and NTBL portion of that request, which is not part of your server, does not participate in the I/O. Consequently, the number of bytes transferred by the server read or write is reduced by the number of bytes consumed by QTBL and NTBL. Additionally, due to the revised order of tables in a server (required to accommodate Resident Requests), the unused bytes in STBL are also not transferred. This can result in 100 - 200K bytes of server data which are not moved by a server I/O, which substantially reduces device and channel busy times and further improves your response time.
Parameters enabling Resident Requests
Precompiled APSY requests are made resident when two conditions are satisfied:
The two parameters that enable Resident Requests are RESSIZE and RESTHRSH, which can be set in CCAIN and dynamically reset at any time by the system manager. The default settings of these parameters disable Resident Requests.
CCA recommends starting values of RESSIZE=5000000 and RESTHRSH=3. The RESSIZE value indicates that five million bytes of virtual storage are available for Resident Requests. The RESTHRSH value indicates that an APSY precompiled request must be involved in at least three server swaps to be considered eligible to be made resident.
Coming attractions
In Part 3 I'll discuss two view -only parameters, RESCURR and RESHIGH that indicate the current number of bytes and the high-water-mark number of bytes used by the Resident Requests feature and other statistics. I will also discuss the output from the MONITOR SUBSYS (PROCCT) LIKE SUBSYSNAME command to assist you in determining the benefits and costs associated with the Resident Request feature.
System 1032 Debug Messaging Options for ODBC Driver
by Tym Stegner
The System 1032 ODBC Driver comes equipped with many options that provide debugging information. While most often debugging information is required by System 1032 Support to assist in fixing problems, you can also use this information to help optimize queries by examining the System 1032 commands generated to fulfill the queries.
However, to run most efficiently for production, you must be sure to completely disable the debugging commands to provide the maximum throughput for an ODBC Driver session. In some instances, even though no debugging output is being preserved, debugging output is still being generated.
Capturing debugging information
The three major switches for capturing debugging information in the S1032 ODBC Driver are:
Debugging information from the data source level
Within the ODBC.INI file found at S1032ODBC_INIPATH, the DrmSpy switch is used at the data source level to toggle the display of record management layer internal messages for debugging support. The syntax of the enabled switch is:
DrmSpy=1
The syntax for the disabled switch is:
;DrmSpy=1
The DrmSpy switch is usually the final item in the data source entry, for example:
[S1032_IVP] DBQ=S1032ODBC_DEMO:IVP_DICTIONARY description=S1032 ODBC IVP tempFileDir=SYS$SCRATCH: newTableDir=SYS$LOGIN: ;DrmSpy=1
[S1032_IVP]
DBQ=S1032ODBC_DEMO:IVP_DICTIONARY
description=S1032 ODBC IVP
tempFileDir=SYS$SCRATCH:
newTableDir=SYS$LOGIN:
You can enable some data sources without enabling others depending on which data sources you want to retrieve messages for.
Supporting the DrmSpy switch is an additional section for the top of the ODBC.INI file, as shown in the following example. This section is available in the CCAPRINT directory of the FTP download site at FOX.CCA-INT.COM.
[Simba Trace] LnaTrace=4095 DrmTrace=4095 EngineTrace=4095 OdbcTrace=4095 ManagerTrace=4095 LnaSrvTrace=4095 ProtocolTrace=4095 ServerTrace=4095 TraceOutput=stdout
[Simba Trace]
LnaTrace=4095
DrmTrace=4095
EngineTrace=4095
OdbcTrace=4095
ManagerTrace=4095
LnaSrvTrace=4095
ProtocolTrace=4095
ServerTrace=4095
TraceOutput=stdout
The entries in this section enable the display of different types of messages. In some circumstances, System 1032 Support may direct you to comment out one or more types of message, when such messages are immaterial to the problem being diagnosed.
Debugging information from the system level
The S1032ODBC_DBGFILES logical name is defined at the system level to toggle the preservation of debugging information. By default, its value is FALSE. Within S1032ODBC.COM, this setting defines the SYS$OUTPUT and SYS$ERROR channels to the null device. When its value is TRUE, the SYS$OUTPUT channel is directed to S1032ODBC.OUT, and the SYS$ERROR channel is directed to S1032ODBC.ERR.
S1032_ODBC_MESSAGE Logical Name
This logical name is defined within S1032ODBC.COM. It controls the extent of the System 1032-specific messages that are displayed in the output files. The following four values are supported:
If you do not define the logical name S1032_ODBC_MESSAGE, the default value is NONE.
Debug Message Overhead
It is important to use the nondebugging settings in your production environment. Even though switches and logical names may be set to not preserve the debugging messages, they are still generated by System 1032 or the ODBC Driver code.
To fully disable all debugging overhead, you should apply the following settings:
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
