OE 12 database features

Posted by Rob Fitzpatrick on 25-Apr-2019 21:21

I see some changes in _database-feature from 11.7 to 12.0.  Several feature IDs that previously had names (15: Concurrent JTA and Replication, 17: MT Index Rebuild, 18: MT Data Move, 20: TP Index Rebuild, 22: Read-only Partitions, 23: New VST Tables, and 25: Partition Copy) are now just "Reserved". 

I understand that for a feature like 23, where an 11.x database may or may not have that VST schema, but all 12.x databases do.  But for the add-on-related features (MT and TP), isn't there still a need in 12.x to determine whether the feature is enabled or not?  Or is the purpose of the record to determine whether a feature *could* be enabled?

Also, there is now a typo in "After Image Mangement/Archiver" (feature 8).

Posted by Libor Laubacher on 25-Apr-2019 21:27

I suppose it could have been presented better, but reserved in this context means that the feature is already enabled by default. IE for example prior 12.0 the "RO partitiions" wasn't enabled by default and you would need to specifically enable it (same goes for JTA, MT IDX, move TP idx...). OE 12 they are enabled by default (to prevent the need of enabling them in future (and needing to stop the db for it)).

All Replies

Posted by Libor Laubacher on 25-Apr-2019 21:27

I suppose it could have been presented better, but reserved in this context means that the feature is already enabled by default. IE for example prior 12.0 the "RO partitiions" wasn't enabled by default and you would need to specifically enable it (same goes for JTA, MT IDX, move TP idx...). OE 12 they are enabled by default (to prevent the need of enabling them in future (and needing to stop the db for it)).

Posted by Rob Fitzpatrick on 26-Apr-2019 00:23

Thanks Libor

Posted by gus bjorklund on 26-Apr-2019 14:16

aside from letting you see what (optional) features have been turned on, the feature bitmap in the database master block also serves another purpose.

the executables also have a feature bitmap in them. that bitmap tells what for which features the executable has the required code to implement them. so when the database is opened, the bitmap in the database is compared against the bitmap in the executable to verify that executable has the code to handle the features that are present in the database.

the point of that mechanism is to reduce the need for database conversions and allow more flxibility in point releases.

Posted by jiclark on 26-Apr-2019 14:23

How did you happen to come by the typo in "After Image Management/Archiver" (feature 8)?

Dev ran a test query on the _Database-Feature VST in OE120.  The After Image Management/Archiver feature appears as follows:

 Database Feature ID     Database Feature Name                   Database Feature Enabled       Database Feature Active

-------------------------------------------------------------------------------------------------------------------------------------------------------------

                                    8      After Image Management/Archiver   0                                                      0

Posted by Rob Fitzpatrick on 26-Apr-2019 15:12

Sorry for the false alarm, I misspoke.  The typo actually was in the 11.7 database I was using for comparison.  Sports DB, created in 11.7.3 on Linux.

Posted by jiclark on 26-Apr-2019 20:20

Thanks for double checking that.  There was a bug filed for that particular issue that has been since fixed.  It should appear correct in 11.7.5 and beyond.  Sorry for any confusion with your 11.7.3 configuration.

This thread is closed