Question Vst Tables Not Capturing The Information

D

Deepu

New Member
Hi,

I am trying to make an utility module, which would show the number of index and table hits done by module. I am using the concept of VST ‘s ie, trying to get the reads/creates/deletes, using _usertablestat & _userindexstat.

We have 8 progress databases in our application, interestingly for 7 databases the VST’s returning correct reads, for one DB alone the reads/creates/deletes are not getting captured. I checked _tablestat and _indexstat. Even there for the particular DB data is not getting captured.

Can anyone let me know what would be the possible reason for this ? Is there any way to enable the VST logging? Version used is OPEN EDGE 11.2.1

Thanks

Deepu
 
Thanks !, I executed it against the DB where I am facing problem,
Statistics for tables with numbers higher than 50 will be missed. To get full statistics start a database with -tablerangesize 210

-basetable = 99 which is sufficient for CURRENT SCHEMA

Statistics for indices with numbers higher than 50 will be missed. To get full statistics start a database with -indexrangesize 1093

-baseindex = 1 which is sufficient for CURRENT SCHEMA

So this means that we are good , so what can be the possible reasons reads are not captured?
 
That does not mean you are good... it means you need to fix the -tablerangesize and -indexrangesize as specified in the output.
 
Why would you set -basetable to 99? Does this database really not contain any application tables numbered 1 to 98? Or is 99 what was suggested by the code you ran?

If you want to set the *rangesize parameters "high enough", this is a simple approach that works:
  • Don't specify -basetable or -baseindex. They default to 1 which is a good default. There are valid reasons for settings values other than 1 but I would say they aren't typical.
  • Set -tablerangesize equal to or higher than your highest application table number. If your schema tends to change often (e.g. adding new tables online) then set it higher so you have room for growth without having to restart the database to increase -tablerangesize.
  • Set -indexrangesize equal to or higher than your highest application index number. Same rule as above applies for growth.
  • Find those numbers like this:
Code: 
find last dictdb._file no-lock where _file._tbl-type = "T" use-index _file-number.
find last dictdb._index no-lock where not _index._index-name begins "_" use-index _index-number.

display
  "Highest table number: " _file._file-number skip
  "Highest index number: " _index._idx-num    skip
with no-labels.

Sample output:
Code: 
┌─────────────────────────────┐
│Highest table number:     468│
│Highest index number:     904│
└─────────────────────────────┘

If you set -basetable to a value other than 1 then set -tablerangesize to (highest table # - basetable + 1).
If you set -baseindex to a value other than 1 then set -indexrangesize to (highest index # - baseindex + 1).
 
Thanks Rob, Issue fixed. The tablerangesize and index rangesize parameters were not setup ,because of which it was picking the default max range (ie 50), changed the parameter and restarted the DB, results are getting displayed.

Now the only problem I am facing is -
say i am running a simple query of contracts-
for each contract no-lock:
i = i + 1.
if i >1000 then leave.
end.

this query results 1014 reads in usertablestat and 1013 reads in userindexstat at the same time. Not sure whether this would be the expected out put. I thought it should only show the reads in usertablestat, not in userindexstat.
 
Every time you read a record in the 4GL (unless you use the tablescan option or look up by ROWID/RECID) you are reading one or more index entries.

The very high level process is as follows... the 4GL reads the appropriate index blocks as well as it can based on the where clause and existing indexes... records are retrieved based on the ROWID stored in the index blocks.
 
You must log in or register to reply here.
Back
Top