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
Comments
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
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. |
Commented by: @livius2 No problem here as a monitoring tool is always connected :) |
Commented by: @pavel-zotov > This info can be used to monitor database e.g. how many new attachements are done during period. fb_lock_print -c -d <dbname> LOCK_HEADER BLOCK "Free owners" shows how detla between absolute maximum of attachments and thos which are present now. |
Commented by: @livius2 Yes Pavel, but this is another tool. I can read Next att by service using isc_spb_sts_hdr_pages. |
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. |
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. >> 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. |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 4.0 RC 1 [ 10930 ] |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Resolved [ 5 ] QA Status: No test => Done successfully |
Modified by: @pavel-zotovstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @dyemanovissuetype: New Feature [ 2 ] => Improvement [ 4 ] |
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
The text was updated successfully, but these errors were encountered: