Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Next attachment id, next statement id [CORE6300] #6542

Closed
firebird-automations opened this issue May 11, 2020 · 11 comments
Closed

Next attachment id, next statement id [CORE6300] #6542

firebird-automations opened this issue May 11, 2020 · 11 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @livius2

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.

Commits: 22ad236

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

No problem here as a monitoring tool is always connected :)
Ofcourse must be documented as tool can varry and csn work as ping measuring

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

> 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).

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 RC 1 [ 10930 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Done successfully

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

issuetype: New Feature [ 2 ] => Improvement [ 4 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants