So we get a new TLA (Three Letter Abbreviation) to try and wrap our heads around in the busy busy world of mainframe databases. This time it comes with a twist, as FTB is actually not “Feed The Beast” sadly, but “Fast Traversal Block”.
In reality, it is referred to everywhere as:
FIT (Fast Index Traversal)
All clear on this and still with me? Good then I may begin!
The problem with modern indexes
The core problem these days is time… the time it takes to go through the leaf pages down to the actual data page is just too long. The vast amount of data we have forces upon the index a large number of layers which, in turn, forces a lot of non-leaf page accesses.
Index structure
We all know how indexes look in Db2, but remember they all have a root page (which is always technically speaking a non-leaf page) which points, normally, to non-leaf pages which, in turn, point to either more non-leaf pages – so you are getting extra levels in the index here – and finally they point to a leaf page which actually contains pairs of keys and RIDs so that Db2 can get the data from the table page.
Which level are you?
One of the quirks of Db2, is that the leaf pages are called Level 0 and then the non-leaf pages directly above them are Level 1. The root page above these is then Level 2 and so you have a “two level” index.
So how many fetches for a random data access?
The first thing Db2 does is read the root page, looking at the root page it sees which non-leaf page must be fetched and it repeats this until it lands on the leaf page and then it fetches the data. So in my two level index it takes four fetches to get to the data. Now imagine you have a seven level index? Yep you end up fetching a ton of non-leafs!
The solution? FTB!
In Db2 12, IBM introduced the Fast Traversal Block to keep a copy of the non-leaf data in a new area, separate from the buffer pools.
The major reasons for the expected performance boost, are the facts that the structure is L2 cache-aware and each page is equal in size to one cache line (256 bytes), and I/O is massively reduced for the “other” non-leaf pages.
The major reasons for the expected performance boost, are the facts that the structure is L2 cache-aware and each page is equal in size to one cache line (256 bytes), and I/O is massively reduced for the “other” non-leaf pages.
One size fits all?
The size of the FTB is determined by the new ZPARM INDEX_MEMORY_CONTROL with valid values AUTO, DISABLE or 10 – 200,000 MBs. By default AUTO is on. With this value, the size of the FTB is either 20% the size of all available buffer pools or 10MB, whichever is the highest.
The devil is in the detail
To actually start working with FTBs, you have to wait until the FTB Daemon has found an eligible index. From all of your indexes there will be quite a few candidate indexes. These must follow the following rules:
It cannot be longer than 64 bytes
It cannot be versioned (So the OLDEST_VERSION and CURRENT_VERSION must be the same!)
It cannot contain a TIMESTAMP column with TIMEZONE
It cannot have more than 2,000,000 leaf pages
Once through that selection list, the Daemon starts seeing what is happening to this index, is it a random select? That’s is a good thing! Is it an index only access? That’s even better! A split! Oh dear, that’s very bad…from all this, every two minutes, the daemon decides whether or not to use FTB for this index.
Control is in your hands
This is all well and good, but there are a lot of people who like to see *exactly* what is going on and where! So IBM introduced a new command:
-DIS STATS(IMU)From this you get to see which indexes are being processed and how much space they are using. The Daemon also spits out console messages so you can see what happened and why. Further there is a new Catalog table SYSIBM.SYSINDEXCONTROL where you can micro-manage exactly which indexes to attempt to force into FTB and which ones to exclude. I would try and avoid this option and just let Db2 do the business!
Gotcha’s?
Always! FTB is limited to 10,000 per member which is probably ok! When a MASS DELETE (or TRUNCATE TABLE) happens then the FTB is removed for the related indexes and, even more importantly, is to keep up with current Db2 maintenance! As always with new things, it takes a while to get the birthing pains out of the way!
INCLUDE can kill you!
Finally, remember that the length cannot be greater than 64 bytes. So if you decide to add that one byte character column to the index to get Index Only access, you might then push the index over the edge and up to 65 bytes…
Before ALTERing indexes always check if they are in the FTB (or were!) and check if your alteration will disallow the FTB!
A little SQL to show you what you have
WITH INPUT (NLEVELS, LENGTH, INDEX_NAME) AS
(SELECT COALESCE(E.NLEVELS , A.NLEVELS ) -- FIRST RTS THEN INDEXES
, SUM(CASE D.COLTYPE
WHEN 'DECIMAL ' THEN
-- IF , SEPERATOR SMALLINT( CEILING(( D.LENGTH + 1,0 ) / 2 ))
SMALLINT( CEILING(( D.LENGTH + 1.0 ) / 2 ))
WHEN 'GRAPHIC' THEN D.LENGTH * 2
WHEN 'VARG' THEN D.LENGTH * 2
WHEN 'LONGVARG' THEN D.LENGTH * 2
ELSE D.LENGTH
END)
+ SUM(CASE A.PADDED
WHEN 'Y' THEN 0
ELSE
CASE D.COLTYPE
WHEN 'VARG' THEN 2
WHEN 'LONGVARG' THEN 2
WHEN 'VARCHAR' THEN 2
WHEN 'LONGVAR' THEN 2
WHEN 'VARBIN' THEN 2
WHEN 'DECFLOAT' THEN 2
ELSE 0
END
END)
+ SUM(CASE D.NULLS
WHEN 'Y' THEN 1
ELSE 0
END) AS LENGTH
, STRIP(A.NAME) CONCAT '.' CONCAT STRIP(A.CREATOR) AS INDEX
FROM SYSIBM.SYSINDEXES A
,SYSIBM.SYSKEYS C
,SYSIBM.SYSCOLUMNS D
,SYSIBM.SYSINDEXSPACESTATS E
WHERE A.UNIQUERULE <> 'D' -- NOT DUPLICATE
AND D.COLTYPE <> 'TIMESTZ' -- NOT TIMEZONE
AND A.OLDEST_VERSION = A.CURRENT_VERSION -- NOT VERSIONED
AND A.TBNAME = D.TBNAME
AND A.TBCREATOR = D.TBCREATOR
AND A.NAME = C.IXNAME
AND A.CREATOR = C.IXCREATOR
AND A.NAME = E.NAME
AND A.CREATOR = E.CREATOR
AND C.COLNAME = D.NAME
GROUP BY A.NAME, A.CREATOR , E.NLEVELS, A.NLEVELS)
SELECT NLEVELS, LENGTH , INDEX_NAME
FROM INPUT
WHERE LENGTH <= 64
ORDER BY NLEVELS DESC
FOR FETCH ONLY
WITH UR
; I have limited it to just show you just the eligible unique, non timezone, non-versioned indexes with a length of 64 or less of course!
Blog time
Here’s an excellent write up from John Campbell with even more technical details:
and from Akiko Hoshikawa: a very good IDUG Blog:
https://www.idug.org/p/bl/et/blogaid=646
As always I would be pleased to hear from you!
TTFN,
Roy Boxwell
Senior Architect