Re: [firebird-support] Re: Awaiting Garbage Collector
Thank you very much for your answer Alexey, I was very bussy these days. Looking at the page 46 it seems more understandable now. Greetings. Walter. On Wed, Mar 25, 2015 at 2:02 PM, Alexey Kovyazin a...@ib-aid.com [firebird-support] firebird-support@yahoogroups.com wrote: Hi Walter, On slide 46 of http://www.slideshare.net/ibsurgeon/3-how-transactionswork we consider how transaction 20 view record versions. It's important to note that transaction 20 is a snapshot. Tx16 did the INSERT? Yes, it created original version of Record 1. Tx12 can do a COMMIT although it had started before Tx16 and Tx18 is still active? Sure, why not? Tx25 can change what Tx14 did although Tx14 is still active? Yes, it looks a bit confusing, but this is a snapshot view which highlights that Tx 20 CANNOT see record versions from a) active transactions, b) transactions with Number 20. It means that for snapshot transaction 20 all transactions above its number look like active, and as a result, it cannot view record versions from both from Tx 14, which was active at the moment when snapshot copy of TIP for Tx25 was taken, and it also cannot view record version from Tx 25, which, obviously was created after Tx 14 was committed. But, again, for Tx 20 these both record versions are invisible. Tx20, as a snapshot, thinks that Tx is active, but in reality it was committed. Regards, Alexey Kovyazin IBSurgeon Hi Alexey Yes, that's right, I can not understand well the page 46. I suppose that R1 means record version 1, R2 means record version 2, etc. Tx16 did the INSERT? Tx12 can do a COMMIT although it had started before Tx16 and Tx18 is still active? Tx25 can change what Tx14 did although Tx14 is still active? These things had confused me. Of course, I think that I am not understanding rightly the graph, that's why some words can help to do it clear.
Re: [firebird-support] Re: Awaiting Garbage Collector
Hi Walter, I have just one doubt, and it is with page 46. Do you mean Record versions visibility? Regards, Alexey
Re: [firebird-support] Re: Awaiting Garbage Collector
Hi Alexey Yes, that's right, I can not understand well the page 46. I suppose that R1 means record version 1, R2 means record version 2, etc. Tx16 did the INSERT? Tx12 can do a COMMIT although it had started before Tx16 and Tx18 is still active? Tx25 can change what Tx14 did although Tx14 is still active? These things had confused me. Of course, I think that I am not understanding rightly the graph, that's why some words can help to do it clear. Greetings. Walter. On Wed, Mar 25, 2015 at 5:10 AM, Alexey Kovyazin a...@ib-aid.com [firebird-support] firebird-support@yahoogroups.com wrote: Hi Walter, I have just one doubt, and it is with page 46. Do you mean Record versions visibility? Regards, Alexey
Re: [firebird-support] Re: Awaiting Garbage Collector
Hi Walter, On slide 46 of http://www.slideshare.net/ibsurgeon/3-how-transactionswork we consider how transaction 20 view record versions. It's important to note that transaction 20 is a snapshot. Tx16 did the INSERT? Yes, it created original version of Record 1. Tx12 can do a COMMIT although it had started before Tx16 and Tx18 is still active? Sure, why not? Tx25 can change what Tx14 did although Tx14 is still active? Yes, it looks a bit confusing, but this is a snapshot view which highlights that Tx 20 CANNOT see record versions from a) active transactions, b) transactions with Number 20. It means that for snapshot transaction 20 all transactions above its number look like active, and as a result, it cannot view record versions from both from Tx 14, which was active at the moment when snapshot copy of TIP for Tx25 was taken, and it also cannot view record version from Tx 25, which, obviously was created after Tx 14 was committed. But, again, for Tx 20 these both record versions are invisible. Tx20, as a snapshot, thinks that Tx is active, but in reality it was committed. Regards, Alexey Kovyazin IBSurgeon Hi Alexey Yes, that's right, I can not understand well the page 46. I suppose that R1 means record version 1, R2 means record version 2, etc. Tx16 did the INSERT? Tx12 can do a COMMIT although it had started before Tx16 and Tx18 is still active? Tx25 can change what Tx14 did although Tx14 is still active? These things had confused me. Of course, I think that I am not understanding rightly the graph, that's why some words can help to do it clear.
Re: [firebird-support] Re: Awaiting Garbage Collector
Hello Alexey Your presentation is an excellent work, as ever. I had wrote an article in my blog about it: https://firebird21.wordpress.com/2015/03/23/presentacion-sobre-transacciones-de-alexey-kovyazin/ You had explained very well everything and all can be easily understood. Thank you very much for such presentation. I have just one doubt, and it is with page 46. Can you explain me that page, please? Thanks in advance. Walter. On Mon, Mar 23, 2015 at 8:27 AM, Alexey Kovyazin a...@ib-aid.com [firebird-support] firebird-support@yahoogroups.com wrote: Hi, Unfortunately, your experiments are not useful at all, since you are using complex GUI tools, which run background queries in the frames of implicit transactions to get metadata information, etc. If you really want to do clean experiments with Firebird transactions, use only isql.exe, and run queries to your tables and MON$ tables there. Also, look into this presentation http://www.slideshare.net/ibsurgeon/3-how-transactionswork Regards, Alexey Kovyazin IBSurgeon Regarding the Awaiting GC issue I've done another test: 1- Connect to the database in a test environment, isolated from the rest of users from production environment. with IBExpert or another database manager. Only one connection. 2- Monitor tha database with Sinatica Monitor to get number of active transactions, attachments and statements. At this moment only 1 connection is showed in Sinatica. 2 statements that are querys to system tables, I supose form IBExpert connection, 0 awaiting GC and 1 awaiting Sweep. 3- Run a query SELECT * FROM CALENDAR WHERE EVENT_ID=132465 which only returns a record. I did not COMMIT that. 4- Now SINATICA shows how AWAITING GC is increasing by 1 or 2 every second. In a minute it shows more than 100 Awaiting GC. 5- COMMIT and now SINATICA shows AWAITING GC is again 0. I did the same thing with EMS SQL MANAGER and the result is the same. Leaving an interesting transaction on a single record table generates a big amount of garbage. Is that normal?
Re: [firebird-support] Re: Awaiting Garbage Collector
Ok, many thanks.
[firebird-support] Re: Awaiting Garbage Collector
Regarding the Awaiting GC issue I've done another test: 1- Connect to the database in a test environment, isolated from the rest of users from production environment. with IBExpert or another database manager. Only one connection. 2- Monitor tha database with Sinatica Monitor to get number of active transactions, attachments and statements. At this moment only 1 connection is showed in Sinatica. 2 statements that are querys to system tables, I supose form IBExpert connection, 0 awaiting GC and 1 awaiting Sweep. 3- Run a query SELECT * FROM CALENDAR WHERE EVENT_ID=132465 which only returns a record. I did not COMMIT that. 4- Now SINATICA shows how AWAITING GC is increasing by 1 or 2 every second. In a minute it shows more than 100 Awaiting GC. 5- COMMIT and now SINATICA shows AWAITING GC is again 0. I did the same thing with EMS SQL MANAGER and the result is the same. Leaving an interesting transaction on a single record table generates a big amount of garbage. Is that normal?
Re: [firebird-support] Re: Awaiting Garbage Collector
Hi, Unfortunately, your experiments are not useful at all, since you are using complex GUI tools, which run background queries in the frames of implicit transactions to get metadata information, etc. If you really want to do clean experiments with Firebird transactions, use only isql.exe, and run queries to your tables and MON$ tables there. Also, look into this presentation http://www.slideshare.net/ibsurgeon/3-how-transactionswork Regards, Alexey Kovyazin IBSurgeon Regarding the Awaiting GC issue I've done another test: 1- Connect to the database in a test environment, isolated from the rest of users from production environment. with IBExpert or another database manager. Only one connection. 2- Monitor tha database with Sinatica Monitor to get number of active transactions, attachments and statements. At this moment only 1 connection is showed in Sinatica. 2 statements that are querys to system tables, I supose form IBExpert connection, 0 awaiting GC and 1 awaiting Sweep. 3- Run a query SELECT * FROM CALENDAR WHERE EVENT_ID=132465 which only returns a record. I did not COMMIT that. 4- Now SINATICA shows how AWAITING GC is increasing by 1 or 2 every second. In a minute it shows more than 100 Awaiting GC. 5- COMMIT and now SINATICA shows AWAITING GC is again 0. I did the same thing with EMS SQL MANAGER and the result is the same. Leaving an interesting transaction on a single record table generates a big amount of garbage. Is that normal?
