18c Scalable Sequences Part II (Watch That Man) May 2, 2018
Posted by Richard Foote in 18c, 18c New Features, Oracle Indexes, Scalable Sequences.trackback
In Scalable Sequences Part I, I introduced this new 18c feature (although it was hidden and undocumented in previous releases). By adding a 6 digit prefix value that constitutes the first 3 digits for the Instance Id and the next 3 digits for the Session Id, it results in a sequence value that doesn’t always hit the right hand most leaf block of the associated Primary Key index.
If we look at the prefixes of the ID column after rows were inserted from 3 different sessions:
SQL> select distinct substr(to_char(id),1,6) from ziggy; SUBSTR(TO_CHAR(ID),1,6) ------------------------ 101389 101398 101260
We notice there are indeed 3 prefix values associated with the 3 sessions. Notice also that the first 3 digits (101) are all the same as each session was established from the same instance (this is a non-RAC environment).
If we would ever want to look at a specific range of more current ID values, we would have to play funny games in extracting the non-prefix portion of the sequence:
SQL> select * from ziggy where to_number(substr(to_char(id),7)) between 158280 and 158290; ID NAME ----------------------------- ------------ 1012600000000000000000158280 DAVID BOWIE 1012600000000000000000158285 DAVID BOWIE 1012600000000000000000158286 DAVID BOWIE 1012600000000000000000158287 DAVID BOWIE 1012600000000000000000158288 DAVID BOWIE 1012600000000000000000158289 DAVID BOWIE 1012600000000000000000158290 DAVID BOWIE 1013980000000000000000158281 DAVID BOWIE 1013980000000000000000158282 DAVID BOWIE 1013980000000000000000158283 DAVID BOWIE 1013890000000000000000158284 DAVID BOWIE
The price we pay for having a prefix value that skews the data in a manner that prevents contention on the associated index.
As discussed in Part I, we also pay a price in that only one of these 3 sessions will actually be the one which does indeed insert the maximum current ID value in the index, thereby hitting the right hand most leaf block and generating 90-10 splits. All other sessions will be inserting elsewhere within the index structure thereby generating 50-50 block splits, resulting in more free space in the associated index.
But at least we do reduce possible index contention related wait events
In Part III, I’ll take a look at the additional EXTEND option with Scalable Sequences.
[…] previously looked in Part I and Part II how Scalable Sequences officially released in 18c can reduce index contention issues, by […]
LikeLike
[…] Part 2: https://richardfoote.wordpress.com/2018/05/02/18c-scalable-sequences-part-ii-watch-that-man/ […]
LikeLike