Out of range property values in 17.0.10.5963 dbsrv17 -k

[Breck_Carter]

Update 2: This is another symptom caused by dbsrv17 -k... so don't use dbsrv17 -k if you need these property values (such as when you use Foxhound).

To determine if your server is running with -k:

SELECT IF PROPERTY ( 'CollectStatistics' ) = 'Yes' 
       THEN 'dbsrv -k NOT specified'
       ELSE 'dbsrv -k IS specified'
       END IF AS "dbsrv -k";

dbsrv -k
'dbsrv -k IS specified'

dbsrv -k
'dbsrv -k NOT specified'

---

Two snapshots of 17.0.10.5963 property values have revealed unexpectedly large numeric values.

property                                                                      

sa_conn_properties HeapsQuery                            18446744073709551588 
sa_conn_properties HeapsQuery                            18446744073709551590 
sa_conn_properties HeapsRelocatable                      18446744073709551609 
sa_conn_properties HeapsRelocatable                      18446744073709551611 
sa_conn_properties PrepStmt                              18446744073709551612 
sa_conn_properties PrepStmt                              18446744073709551613 
sa_conn_properties QueryCachedPlans                      18446744073709551613 
sa_conn_properties QueryCachedPlans                      18446744073709551614 
sa_conn_properties QueryCachePages                       18446744073709551609 
sa_conn_properties QueryCachePages                       18446744073709551611 
sa_db_properties   Cursor                                18446744073709551615 
sa_db_properties   CursorOpen                            18446744073709551615 
sa_db_properties   HeapsLocked                           18446744073709539678 
sa_db_properties   HeapsLocked                           18446744073709547711 
sa_db_properties   HeapsQuery                            18446744073709551615 
sa_db_properties   HeapsRelocatable                      18446744073709539728 
sa_db_properties   HeapsRelocatable                      18446744073709547759 
sa_db_properties   LockCount                             18446744073709548295 
sa_db_properties   LTMTrunc                              18446744073709551615 
sa_db_properties   QueryCachedPlans                      18446744073709551608 
sa_db_properties   QueryCachedPlans                      18446744073709551615 
sa_db_properties   QueryMemActiveCurr                    18446744073709551615 
sa_db_properties   RemoteTrunc                           18446744073709551615 
sa_db_properties   RollbackLogPages                      18446744073709551611 
sa_db_properties   RollbackLogPages                      18446744073709551615 
sa_db_properties   SyncTrunc                             18446744073709551615 
sa_eng_properties  AvailIO                               18446744073709551376 
sa_eng_properties  AvailIO                               18446744073709551611 
sa_eng_properties  CacheFileDirty                        18446744073709548666 
sa_eng_properties  Cursor                                18446744073709551613 
sa_eng_properties  Cursor                                18446744073709551614 
sa_eng_properties  CursorOpen                            18446744073709551613 
sa_eng_properties  CursorOpen                            18446744073709551614 
sa_eng_properties  HeapsQuery                            18446744073709551615 
sa_eng_properties  QueryMemActiveCurr                    18446744073709551615 

Other diagnostic trace data shows that DB_PROPERTY ( 'ConnCount' ) frequently returned values like 18446744073709551613, 18446744073709551614 and 18446744073709551615.

This is a preliminary report of customer experience and it hasn't been reproduced yet.

---

Update 1: Failed to reproduce symptoms on a overloaded 17.0.10.5963 server (503 Conns, 42000 Req/s, 24000 Commits/s, 450 Unsch Req, 55% CPU of 8, 3000% Recovery Urgency, 4000 Disk Writes/s)

[Vlad]

it seems that you see maximum unsigned int64. I know it is not a solution, just thoughts. It looks suspicious.

[Breck_Carter]

My guess is that when CollectStatistics is 'No' then all the underlying variables are left uninitialized (e.g., garbage UNSIGNED BIGINT).

IMO they should all be initialized to NULL which is what you see if you SELECT PROPERTY ( 'UnknownPropertyName' )... that would be my reading of The Watcom Rule 🙂

[Breck_Carter]

> I know it is not a solution

FWIW dbsrv17 -k is an effective test of how Foxhound handles garbage properties, where "effective" means "Foxhound fails" 🙂

Changes are in progress to handle garbage properties better (because it can happen any time, and has happened in the past).

A change to detect CollectStatistics = 'No' is also under consideration because "Foxhound == Pointless" when that's the case.

These changes will force a new build since a patch probably won't work for the OFSS component.