What’s new with Oracle database 19.7 versus 19.6
This blogpost takes a look at the technical differences between Oracle database 19 PSU 6 (january 2020) and 7 (april 2020). This gives technical specialists an idea of the differences, and gives them the ability to assess if the PSU impacts anything.
Functions
code symbol names unique in version 19.6 versus 19.7 (top 5) keb keb kernel event MMON/MMNL infrastructure 4 qes qes query execute services 5 qos qos query optimizer statistics 6 kpd (kp)d kernel programmatic interface ?? 10 kub (ku)b kernel utility ?? 11 code symbol names unique in version 19.7 versus 19.6 (top 5) ksf ksf kernel service functions 9 kpd (kp)d kernel programmatic interface ?? 11 kqr kqr kernel query dictionary/row cache 12 kzr kzr kernel security virtual private database 20 kub (ku)b kernel utility ?? 34
kub: most of the functions starting with kub that have been removed are starting with kubsprq: kernel utility big data sql parquet. Most functions starting with kub are actually kubscrf, so big data sql related probably, but I have no idea currently what ‘crf’ means. Suggestions are welcome. Also 4 kubsprq functions are added.
kpd: the kpd function that are gone are actually kpdb, which likely means kernel programmatic interface pluggable database. In fact, there are two ‘layers’ which are unknown to me: kpdboc and kpdbocws. The kpd functions that have been added seem to have letters added to indicate extra layers besides kpdb, but only two of them are kpdboc, the rest are quite random.
qos: the qos functions removed are actually qosd, query optimizer statistics sql plan directive. There have been no functions returned starting with ‘qosd’.
qes: most of the qes functions are actually starting with qesdpi, which according to my current insights means query execute services adaptive features internationalisation (timezones). Of course this is speculation.
keb: the keb (kernel event MMON/MMNL infrastructure) functions seem to have something to do with ‘auto tasks’. There are some keb functions returned too, but not in the top 5 of returned function groupings.
kzr: the kzr functions are actually kzra, kernel security virtual private database privileges. I don’t know what the work done here is, but it seems there has been work done.
kqr: these are quite normal dictionary cache functions, with some letters added. This looks like work done to make enhancements to the dictionary cache processing.
ksf: most of the functions with ksf are actually ksfs, kernel service OFS filesystem, and a few ksfd, kernel service functions disk IO.
Parameters
parameters unique in version 19.6 versus 19.7 NAME -------------------------------------------------- _eighth_spare_parameter _fifteenth_spare_parameter _hang_bool_spare1 _ninth_spare_parameter _one-hundred-and-fifty-ninth_spare_parameter _one-hundred-and-sixtieth_spare_parameter _seventh_spare_parameter _twelfth_spare_parameter parameters unique in version 19.7 versus 19.6 NAME -------------------------------------------------- _asm_max_kfsg_free_heap_perc _asm_max_kfsg_free_heap_size _bug30186319_lm_hb_lgio_timeout _bug30352623_asm_enable_vfreloc_on_rm _hang_mark_some_idle_waits_terminal _kswsas_pdb_auto_close_timeout _link_ts_force_online _pdb_datapatch_violation_restricted
A number of spare parameters have been used to create undocumented parameters. We see the two ASM related parameters, just like with version 18 and 12.2. Also two “bug parameters”.
Waitevents
waitevents unique in version 19.6 versus 19.7 NAME ---------------------------------------------------------------------------------------------------- first spare wait event waitevents unique in version 19.7 versus 19.6 NAME ---------------------------------------------------------------------------------------------------- CRS get service attributes
It seems that with version 19.7, a spare parameter was changed for an actual wait event. It’s unknown to me what the wait event times currently.
DBA/CDB tables columns
dba tables columns unique to 19.6 versus 19.7 NAME COLUMN_NAME ---------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- DBA_APP_VERSIONS APP_ROOT_CLONE_NAME DBA_WORKLOAD_CAPTURES ENCRYPTION_VERIFIER cdb tables column unique to 19.7 versus 19.6 NAME COLUMN_NAME ---------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- CDB_WORKLOAD_CAPTURES ENCRYPTION_VERIFIER
One column in two different DBA tables have been removed from version 19.7, and one of them came back as a CDB table column. The weird thing here is not the switch of a column going from a DBA table to its CDB counterpart, that is something that I saw between 18.9 and 18.10, but that with Oracle 19.7 this is only one column of the two gone missing from DBA tables came back in a CDB table.
