8.3 System Logger duplexing of interim storage

---

8.3 System Logger duplexing of interim storage

As discussed in "Duplexing log data for CF-Structure based log streams" on page 42, System Logger always keeps two copies of the data that is currently resident in interim storage. The interim storage could be a CF structure or a staging data set (for DASD-only log streams), and the second copy could be a dataspace or a staging data set (for CF-Structure log streams). We will address CF-Structure log streams and DASD-only log streams separately.

8.3.1 CF-Structure log stream

The maximum IXGWRITE rate that a log stream can handle is determined by the placement of the log data interim storage and its duplex copy. A log stream that is duplexing to staging data sets will be limited to roughly the same IXGWRITE rate that can be achieved with DASD-only log streams. All other things being equal, the maximum IXGWRITE rate for a CF log stream that is not using staging data sets is at least one order of magnitude higher than for a DASD-only one.

Bearing these attributes in mind, the best performance can be obtained by ensuring that CF-Structure log streams are duplexed to dataspaces, and keeping the associated structure size as small as possible, while still being able to deliver the required levels of performance.

For a CF-Structure log stream, the location of the second copy of the data depends on how you specified STG_DUPLEX and DUPLEXMODE in the log stream definition. If you specify STG_DUPLEX(YES) and DUPLEXMODE(UNCOND), the second copy of the data will always be in a staging data set. If you specify STG_DUPLEX(YES) and DUPLEXMODE(COND), the location of the second copy depends on the volatility of the CF and on whether the CF is in the same failure domain as this z/OS system.

If the CF is volatile, the second copy of the data currently in interim storage will be placed in a staging data set. If the CPC containing the CF has a battery backup, the CF will know that it is non-volatile. If the CPC does not have battery backup, but you have a UPS and are 100% confident that the UPS will not fail, you can issue a command on the CF console to tell it that it is non-volatile. Placing a System Logger structure in a volatile CF will cause all log streams in that structure that have specified DUPLEXMODE(COND) to be duplexed to staging data sets on DASD, impacting performance at higher logging rates.

If the z/OS is in the same failure domain as the CF (that is, they reside in the same CPC), the second copy of the data will again be placed in the staging data set. If two z/OSs in two CPCs are connected to the same log stream, it is possible that one of the z/OSs will be in the same failure domain as the CF, but the other will not. In this case, one of the System Loggers will be writing the second copy of the data to a staging data set and the other will be using a dataspace.

If neither of these conditions apply, the second copy of the data will be placed in a dataspace.

And as discussed in "Other recovery processes and errors" on page 71, the dataspace is used to repopulate the structure as part of a structure rebuild operation. Therefore, having a large amount of log stream data in a dataspace can result in significant paging during certain recovery processing. This is another reason for not over-sizing the interim storage for a log stream—the larger the interim storage defined for a log stream, the larger the dataspace that is required to hold the duplex copy of that data.

Tip 

If at all possible, configure your System Logger environment so that the second copy of the data is kept in a dataspace. This provides the best configuration relative to performance throughput, although not necessarily from a recovery situation, since using staging data sets can offer better benefits. For any log stream you can find the current location of the second copy by issuing the following command:

    D LOGGER,C,LSN=log_stream_name,DETAIL 

If the DUPLEXING: line in the response contains LOCAL BUFFERS, the data is being kept in the dataspace. Remember that you must issue this command on each system that is connected to the log stream in question.

If you are using SMF Type 88 records to check this, the second bit of the SMF88LFL field indicates whether that log stream used a staging data set during that SMF interval.

8.3.2 DASD-only log streams

With DASD-only log streams, the second copy of the log data is always kept in a dataspace—this is something that you have no control over.

However, you can, indirectly, control the size of the dataspace. Remember that all the log data in a staging data set at any one time will also exist in a dataspace. So, the larger the staging data set, the larger the dataspace needs to be. As for CF log streams, we do not recommend specifying the interim storage for a DASD-onlylog stream any larger than necessary.

8.3.3 Sizing duplex copy of CF log streams

When sizing the interim storage for your log streams, it is important to bear in mind the requirements for the second copy of the log data. There are a number of factors that make this a little complex.

If the log stream in question is a CF one, the first thing to consider is how many log streams will normally reside in the structure. The structure storage is divided equally between all the connected log streams in the structure. So, if you have a 46 MB structure with 10 log streams, each log stream will have roughly 4 MB of storage in the CF.

Because the unit of storage in the CF is more granular (256 or 512 bytes) than in the staging data sets (4 KB), it is likely that a staging data set will need to be larger to hold the same amount of log data as a structure. For example, if you were writing small log records (100 bytes), the staging data set would need to be 16 times larger than that log stream's portion of the CF structure to hold the same number of records (because each record would take up 256 bytes in the CF, but 4096 bytes in the staging data set).

To get optimum performance from a CF log stream, it is important that offloads are initiated because the CF interim storage hit the HIGHOFFLOAD threshold, and not because the staging data set hit the threshold first. When sizing the staging data sets, you should use the formula we described in "Sizing interim storage for funnel-type DASD-only log streams" on page 268. You should also monitor for non-zero values in the STG THLD field in the IXGRPT1 report. If you encounter instances of non-zero values, increase the STG_SIZE specification on the log stream definition in the LOGR policy by a small amount to make the staging data set larger, and continue to monitor.

---