1

Topic: The status sweep on Firebird 2.5.2

Good afternoon.
Windows Server 2008 R2, Firebird 2.5.2 SuperClassic.
There is a database in the size of 355 Gb. On Friday on August, 3rd has been launched manual sweep in the evening. Two days parallely with sweep' the database worked on reading with enough considerable quantity of users. Since yesterday evening works in an exclusive mode.
If I am not mistaken, in 2.5.2 about sweep the beginning and the end is written to a broad gull only. I try to estimate approximate progress  to indirect signs. In MON$IO_STATS found the data on launched gfix-sweep, and there was a following question.
So, a DB - 355 Gb (the exact size - 355 359 793 152). Page size - 8192 byte. That is in basis should be 43 378 881 pages. The same number can be seen in MON$PAGES in table MON$DATABASE.
MON$IO_STATS On gfix' with  shows MON$PAGE_READS 254 000 000 (approximated) pages. That is gfix-sweep read much more pages, than contains in a database. fb_lock_print shows the big activity. Whether it is normal, what MON$PAGE_READS for process  shows such great number of pages and whether it means, what  went in cycles and for any reason reads basis many times successively empty?
Many thanks in advance.

2

Re: The status sweep on Firebird 2.5.2

Igor Ivkin wrote:

whether it is normal that MON$PAGE_READS for process  shows such great number of pages

Happens

Igor Ivkin wrote:

whether it means that  went in cycles

Is not present

Igor Ivkin wrote:

for any reason reads basis many times successively

Yes. All depends from kol-va , lengths of their chains, kol-va indexes and the size  (which it is rather small at SC)

Igor Ivkin wrote:

empty

Is not present

3

Re: The status sweep on Firebird 2.5.2

It turns out, what on ours 2.5.2 indirect means not to define current progress ?
Simply a little I worry, because sweep threshes the third days though by the form fb_lock_print and on the general activity of process of the server, there is very active reading and the active disk writing, and except  with basis now nobody works.

4

Re: The status sweep on Firebird 2.5.2

Igor Ivkin wrote:

It turns out, what on ours 2.5.2 indirect means not to define current progress ?

to Remove statistics (gstat-r) and to look on reducing kol-in versions
There are still events  in , sm http://tracker.firebirdsql.org/browse/CORE-3656

5

Re: The status sweep on Firebird 2.5.2

Igor Ivkin;
Passing remarks
2.5.2 it is not so good. It is desirable to familiarize in  with the list of corrected bugs, up to 2.5.8.
Even in 2.5.3 that is corrected a lot of bad.
Considering the size of basis, it is necessary to struggle not with durable sweep, and with long transactions.

6

Re: The status sweep on Firebird 2.5.2

Igor Ivkin, kdv
We open RN and it is visible https://www.firebirdsql.org/file/docume … s-253.html

wrote:

The scan for limbo transactions at the end of a sweep has been improved.

It is remembered here considered, quite probably the HARDWARE got on it. So it will be updated it is necessary.

7

Re: The status sweep on Firebird 2.5.2

Denis wrote:

Igor Ivkin, kdv
We open RN and it is visible https://www.firebirdsql.org/file/docume … s-253.html
it is passed...
It is remembered here considered, quite probably the HARDWARE got on it. So it will be updated it is necessary.

It is necessary to be updated, but it is not assured that my case is connected to limbo-transactions. At me is not present two-phase  and if I correctly understand accordingly and transactions in limbo should not be. Though can, and it is unimportant, there are they or not if scanning becomes anyway.

8

Re: The status sweep on Firebird 2.5.2

Igor Ivkin;
Presence limbo transactions not mandatory. Here a counter in their search.
Here that arguing http://www.sql.ru/forum/965029-1/ne-ost … xt-142-mln
And here the description in  http://tracker.firebirdsql.org/browse/CORE-3994

9

Re: The status sweep on Firebird 2.5.2

Igor Ivkin;
One remark this bug will be swept only if at you rupture in some millions was formed. If is not present, it not your case. And it like directly is not connected to readings.
.. In 3.0  not mandatory to read all basis

10

Re: The status sweep on Firebird 2.5.2

Denis wrote:

Igor Ivkin;
One remark this bug will be swept only if at you rupture in some millions was formed. If is not present, it not your case. And it like directly is not connected to readings.
.. In 3.0  not mandatory to read all basis

Yes, it is very similar on wash a case. Rupture makes 2 000 000 transactions, works the third days.
Whether it is safe to stop in that case gfix-sweep which is launched from command line (we tell, through Ctrl+C)? If it is safe, probably it will be cleverest to be updated and restart sweep.

11

Re: The status sweep on Firebird 2.5.2

Igor Ivkin wrote:

Yes, it is very similar on wash a case. Rupture makes 2 000 000 transactions, works the third days.
Whether it is safe to stop in that case gfix-sweep which is launched from command line (we tell, through Ctrl+C)? If it is safe, probably it will be cleverest to be updated and restart sweep.

Already experimented on a small local database, through Ctrl+C gfix-sweep to stop senselessly since despite process end gfix, in the list of connections it remains and continues to work.
Thus, the question is formulated a little differently - whether it is possible to stop safely somehow manual gfix-sweep?

12

Re: The status sweep on Firebird 2.5.2

Igor Ivkin wrote:

Rupture makes 2 000 000 transactions, works the third days.

Abruptly. I thought such only the Tabloid can arrange :-) with a view of testing

13

Re: The status sweep on Firebird 2.5.2

Igor Ivkin wrote:

whether it is possible to stop safely somehow manual gfix-sweep?

Try through monitoring if it does not turn out: gfix-shut-force 0

14

Re: The status sweep on Firebird 2.5.2

Thanks all respected  for councils and the help.
In general, I decided to wait, while  , and here it finished operation, in 3.5 days. I am updated to 2.5.8.
Once again thanks.