Customer Use of SSD (Solid State Drives)

Consider is using the Knob to keep unmarked data off the SSD and marked data onto SSD. Without this option, the system will spread data to all DASD in the ASP regardless of if it is SSD arms or non-SSD.

To enable the Knob, you should do the following:

1. Issue the STRSST command.
2. Select Option 1. Start a service tool
3. Select Option 4. Display/Alter/Dump
4. Select Option 1. Display/Alter storage
5. Select Option 2. Licensed Internal Code (LIC) data
6. Select Option 14. Advanced analysis
7. On the blank line, type one of the following commands. Note that there are no options to be added:

smsetstayoffssd - Puts the block in place to keep 'unmarked' data off of SSD (except for some storage for OS usage).
No options before TR1, after TR1 put the ASP number in HEX as this will individually work different for each ASP.
smresetstayoffssd - (SHIPPED DEFAULT) Turns the block off which has SM treat SSDs pretty much like any other DASD unit.
No options before TR1, after TR1 put the ASP number in HEX as this will individually work different for each ASP.
smgetstayoffssd - Displays the current setting of the block.
No options before TR1, after TR1 put the ASP number in HEX as this will individually work different for each ASP.
hex_asp_num is used for IASPs. Passing in no number, or 1 means SYSBAS which is ASP1 - 32.

Moving Files at the Object level
Files can be moved at the object level on and off of SSD units. This can be done for files where read performance is critical. This is done with the CHGPF and CHGLF commands.

CRTPF lib1/pf1 UNIT(*SSD)
CHGPF lib1/pf1 UNIT(*SSD)
SQL: Create Table lib1/tbl unit ssd
SQL: Alter Table lib1/tbl alter unit ssd
SQL: Create Index lib1/idl unit ssd

Notes:
1.    This is a mechanism to set a "USER RECOMMENDED MEDIA PREFERENCE". This is a "suggestion" and, depending on available space, other system settings, and so on, the system allocates the storage as appropriate.
2.    The machine does not need to have SSDs. You can set your files to have an "SSD Media Preference" on a system that has no SSDs. Then, you can distribute those files to other systems (in other words, using save/restore). Those systems with SSD will have their data allocated on SSD.
3.    This applies to the CRTPF, CRTLF, CHGPF, CHGLF, CRTSRCPF, CHGSRCPF, and SQL commands.
4.    When using the CRTPF, CRTLF, CHGPF, CHGLF commands, if table or physical file has multiple partitions or members, the media preference applies to all partitions or members.

To remove the media preference, you should use DASD Unit *ANY from command line or SQL.
5.    The move starts right away in the background.
6.     Background moves can only work on the parts of an object that are not on PINed pages.  Commitmit Control and Journal Caching can both use PINed pages, so it is possible part of an object might not move, or if we have 5 failures for one object, that object will be skipped.
7.    If any Logical File that implicitly shares an access path is set to be on *SSD, the access path will move to *SSD regardless of what Logical file actually owns the access path. For the access path to move off of SSD, every logical file that shares the access path must be set to *ANY. Check DSPDBR of the physical file and DSPFD of the logical file for information on other logical files that share the access path.
8.    This change is unaffected by the Knob setting.
9.    To see information on what files you might want to move you engage IBM Lab Services at:

https://www-03.ibm.com/systems/campaignmail/services/labservices/contact.html

Moving Files at the Member level
Files can also be moved at the member level on and off of SSD units. This can be done for files where read performance is critical for only one member. This is done with the CHGPF and CHGLF commands.

CHGPFM FILE(LIB1/PF1) MBR(M1) UNIT(*SSD)
CHGLFM FILE(LIB1/PF1) MBR(M1) UNIT(*SSD)

Notes:
1.    An exclusive seize is acquired by SLIC DB to actually move the data.
2.    This is a mechanism to set, at a database MI object level (Data Space & Data Space Index), a "USER RECOMMENDED MEDIA PREFERENCE". This is a "suggestion" and, depending on available space, other system settings, and so on, SM allocates the storage as appropriate.
3.    The machine does not need to have SSDs. You can set your files to have an "SSD Media Preference" on a system that has no SSDs. Then, you can distribute those files to other systems (in other words, using save/restore). Those systems with SSD will have their data allocated on SSD.
4.    The move starts right away in the background.
5.    If any Logical File that implicitly shares an access path is set to be on *SSD, the access path will move to *SSD regardless of what Logical file actually owns the access path. For the access path to move off of SSD, every logical file that shares the access path must be set to *ANY. Check DSPDBR of the physical file and DSPFD of the logical file for information on other logical files that share the access path.
6.    This change is unaffected by the Knob setting.
7.    This is fine to use with file partitions

Checking on the movement of Physical and Logical files
The best way to see if the files moved or not is checking in Vlogs.
1) STRSST
2) 1. Start a service tool
3) 5. Licensed Internal Code log
4) 1. Select entries from the Licensed Internal Code (LIC) log
5) Change Major code to 0600, leave minor as 0000. Adjust time/date as needed.

VL06008410 - Success (Async)
VL0600840C - Success - Synch move for a small file
VL0600840F - Problem encountered and only partial data moved
VL06008409, VL0600840A, VL0600840B - Failures, contact support. You can also try Sweeper for the last two to try again.

Find and move other hot data
This will use the trace and balance functions to determine additional "hot" data on the system that can be moved to the SSD. It is important to only run the trace during times of high disk usage. The target is for the top 50% of reads to go to SSD, if that amount of space is available. The balance algorithm does not move cold data off of the SSDs unless it needs more space for the hot data.

Clear the trace:
TRCASPBAL SET(*CLEAR)

Start the trace at a high DASD usage time:

TRCASPBAL SET(*ON) ASP(x) TIMLMT(*NOMAX)

End the trace after a high DASD usage time:
TRCASPBAL SET(*OFF) ASP(x)

Start the data migration
STRASPBAL TYPE(*HSM) SUBTYPE(*CALC) ASP(x) TIMLMT(*NOMAX)

Check the data migration:
CHKASPBAL

Trace and balance will not be able to remove files and members that were flagged to be on SSD. However, it can move data that it had previously moved to SSD that no longer seems to fit the criteria based on the new trace information used in a balance.

When the movement of COLD data off of the SSD is running, control does not return to the console. This could take an extended number of minutes to run, depending on the amount of data to be moved.

Sweeper Maintenance
The sweeper part of STRASPBAL will allow someone to sweep data marked with a media preference onto Solid State drives and will sweep non-media preference data off of the Sold State drives.

The commands that can be used are as follows:

o Start the sweeper balance function:
STRASPBAL TYPE(*MP) TIMLMT(*NOMAX) SUBTYPE(*CALC)
o End the sweeper balance function:
ENDASPBAL
o See the sweeper balance status:
CHKASPBAL

Other Subtype options for the STRASPBAL:

o *CALC will move non-media preference data off of SSD and move media preference data from HDD to SSD.
o *SSD will move non-media preference data off of SSD.
o *HDD moves media preference data from HDD to SSD.

Note: Sweeper/STRASPBAL TYPE(*MP) will not undo data moved by TRCASPBAL and STRASPBAL TYPE(*HSM)
Do not use Sweeper at the same time as CHGPF/CHGLF moves are happening.

Checking SSD for Files
There are two new SQL catalog files that can be used to see what files are on SSD, and what percentage of the file. Remember that not all parts of a file will go on SSD. For reasons like Trace and Balance, files without a media preference could also have parts on SSD drives.

Files to use:
QSYS2.SYSPARTITIONDISK shows what physical files are on SSD.
QSYS2.SYSPARTITIONINDEXDISK shows what logical files are on SSD.

When using queries over QSYS2.SYSPARTITIONINDEXDISK you have to be careful of spanning indexes, because spanning indexes will return the same size for each underlying physical member and you can only count one of them.  However you can use a query like this:

 
If you need help with Solid State Drive performance, you can contact IBM lab services:
https://www-03.ibm.com/systems/campaignmail/services/labservices/contact.html