Issue Details (XML | Word | Printable)

Key: CORE-6300
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Karol Bieniaszewski
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Next attachment id, next statement id

Created: 11/May/20 06:18 AM   Updated: Sunday 09:35 AM
Component/s: Engine
Affects Version/s: None
Fix Version/s: 4.0 RC 1

QA Status: No test


 Description  « Hide
Please provide easy access to the info:
- next attachment id
- next statement id

Currently we can read in easy way only next transaction id as MON$NEXT_TRANSACTION in MON$DATABASE.
Next statement id we can read from joining current attachment with mon$statements.
But next attachment id can be read only by statistics service (reading header page) and it does not show real time values only some "updated one" and not correlated with current snapshot of database state taken by MON$ tables.
Of course we can made new connection - but this is to costly and not natural way.

This info can be used to monitor database e.g. how many new attachements are done during period. In a period there can be many short leaving attachment and reading MON$ATTACHEMNT can simply miss it.



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 11/May/20 03:14 PM
The possible problem with the Next Statement ID is that it's not persistent. This counter is memory-only and reset to zero every time the last connection to a database goes away. So your interval-based measuring makes sense only as long as somebody is connected. Which in practive may be rather pointless.

Karol Bieniaszewski added a comment - 11/May/20 06:18 PM - edited
No problem here as a monitoring tool is always connected :)
Ofcourse must be documented as tool can varry and csn work as ping measuring

Pavel Zotov added a comment - 11/May/20 07:06 PM
> This info can be used to monitor database e.g. how many new attachements are done during period.
> In a period there can be many short leaving attachment and reading MON$ATTACHEMNT can simply miss it.

fb_lock_print -c -d <dbname>

LOCK_HEADER BLOCK
. . .
        Owners (6): ...
        Free owners (3): ...
. . .

"Free owners" shows how detla between absolute maximum of attachments and thos which are present now.
So, subsequent calls of fb_lock_print can show chronology of attachments establishing (and fb_lock_print is completely non-invasive when we ask only LT header).

Karol Bieniaszewski added a comment - 12/May/20 06:15 AM
Yes Pavel, but this is another tool. I can read Next att by service using isc_spb_sts_hdr_pages.
It is not correlated with transaction which run MON$ tables.
And it is not so simple as SELECT * FROM MON$DATABASE to read it.

Sean Leyne added a comment - 19/May/20 03:54 PM
Karol,

I think you need to describe what you are trying to accomplish.

You have already said that sc_spb_sts_hdr_pages already provides details on the next attachment, so why do you feel it is necessary to have it available via other path?

Further, an attachment can exist without a transactions, so your comment "It is not correlated with transaction which run MON$ tables." is confusing.

I wonder if what you are looking for is better accessed from DB trace information.

Karol Bieniaszewski added a comment - 19/May/20 06:07 PM - edited
Yes Sean,

>> attachment can exist without a transactions, so your comment "It is not correlated with transaction which run MON$

i mean transaction which run MON$ query, you can miss some short connection

>> I wonder if what you are looking for is better accessed from DB trace information.

trace and monitoring tables are two different things. They can be merged toogether but they have different performance impact.
Trace have permanent impact, monitoring tables have impact only when called, and you can run it e.g one times per 5 minute

>> You have already said that sc_spb_sts_hdr_pages already provides details on the next attachment, so why do you feel it is necessary to have it available via other path?

sc_spb_sts_hdr_pages can read data but it is not correlated with snapshot taken from mon$ tables. e.g you ask service of value and then ask monitoring tables of value. You can have different one. as between there can be some short connection.
Also asking sc_spb_sts_hdr_pages have some issue. As for me it stuck multiple times and do not progress of Next attachment id value.
E.g. i read value 500 but when i run MON$ATTACHMENTS i have there value 501, 502. and repeated multiple times i still got 500 when new one att in next call exists as 504, 505.
It progress then in some situation. I do not know which situation must occure.
And it is much simple to read all info from one place like MON$DATABASE then calling external service.