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)
asked
04 Apr '20, 14:27
Breck Carter
32.5k●539●724●1050
accept rate:
20%
it seems that you see maximum unsigned int64. I know it is not a solution, just thoughts. It looks suspicious.
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 :)
> 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.