собствеено сабж, фаяберд 3.0, железо норм ссд, можно как-то ускорить? при этом gbak на ту же бд зависает на записи одной таблицы и пишет по 5 часов 10к записей, размер базы 9гб

Database "C:\BASES\LF\STORAGE__.FDB"
Gstat execution time Mon Nov 16 22:52:12 2020

Database header page information:
Flags 0
Generation 247453033
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 63297581
Oldest active 247384064
Oldest snapshot 247384064
Next transaction 247384066
Sequence number 0
Next attachment ID 214353
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSV
C
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 12, 2020 1:51:42
Attributes force write

Variable header data:
Sweep interval: 20000
*END*


Database file sequence:
File C:\BASES\LF\STORAGE__.FDB is the only file

I/O error during "CreateFile (open)" operation for file "C:\BASES\LF\STORAGE__.F
DB"
-Error while trying to open file
-Процесс не может получить доступ к файлу, так как этот файл занят другим процес
сом.
Gstat completion time Mon Nov 16 22:52:12 2020

Dimitry Sibiryakov,

можете подсказать за что пинать

hvlad,

Database "C:\BASES\LF\STORAGE__.FDB"
Gstat execution time Mon Nov 16 23:34:05 2020

Database header page information:
Flags 0
Generation 247453033
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 63297581
Oldest active 247384064
Oldest snapshot 247384064
Next transaction 247384066
Sequence number 0
Next attachment ID 214353
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSV
C
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 12, 2020 1:51:42
Attributes force write

Variable header data:
Sweep interval: 20000
*END*


Database file sequence:
File C:\BASES\LF\STORAGE__.FDB is the only file

Unable to complete network request to host "localhost".
-Failed to establish a connection.
Gstat completion time Mon Nov 16 23:34:07 2020

я сервер выключил чтоб сделать gbak если что

я не понимаю, gbak сутки на ссд чето там гбачит, трындец какойто всего 9гб, за это время можно переписать вручную всю бд в тетрадку в клеточку... тут походу разрабов фб надо пнуть

hvlad,

а смысл указывать -g? ни один запрос не выполняется все висит
-se не указана сервер локальный

Dimitry Sibiryakov,
везде любой запрос начинается со starttransaction и заканчивается commit/rollback

Dimitry Sibiryakov,

почему глупость? а чем должен заканчиваться запрос?

Dimitry Sibiryakov,

Dimitry SibiryakovВо-вторых, отквоченные цифры утверждают противоположное

Для того, чтобы подвинуть "вверх" номер Oldest Interesting Transaction (Oldest transaction в gstat -h). Дело в том, что единственные транзакции, которые приводят к "залипанию" Oldest на месте, это транзакции, которые завершились Rollback, и для которых сервер не смог отменить все изменения по сохраненным в памяти savepoints. То есть, пока все версии, созданные этой транзакцией не будут отменены, ее состояние нельзя перевернуть в committed. А транзакции snapshot оценивают состояния конкурирующих транзакций и возможность модификации записей именно от Oldest transaction до Next transaction. Собственно, при чтении версий, номер транзакций которых меньше Oldest transaction, сервер даже не проверяет наличие версий, потому что таковых нет и быть не может, а кроме того, все транзакции меньше Oldest обязательно находятся в состоянии committed (т. е. их версии можно читать).

http://www.ibase.ru/sweep/

как раз таки об этом

Dimitry Sibiryakov,

Dimitry SibiryakovУ вас в базе проведено 250 миллионов транзакций за четыре дня

да там очень быстрый поток данных и сильно меняющийся во времени

Dimitry Sibiryakov,

да уже понятно что файберд не справился с задачами и субд заменим, все таки с сабжем чем-то поможете? вторые сутки -sweep никак не родит, а то как обычно ушли в дебри пинания архитекторов, программистов, создателя программистов и всего прочего вопрос то был можно как-то ускорить -sweep и что он таки делает вторые сутки даже перебирая 250млн мусорных записей это всего 9гб данных можно было уже по байту все перебрать

fraks,

спасибо добрый человек за запросы, будем тыкать

hvlad,

да щастье мое, усе сделал, программистов потыкал

tromani,

разобрались что вешало
суть вот в чем: есть таблица1 которая много и часто обновляется
и есть запрос который выводит некую сводную по этой таблице суммирует данные и т.д. а результат в DBGrid
в которой участвуют записи от первой до последней из таблицы1

так вот, и последний вопрос в каком режиме запустить транзакцию этого запроса чтоб оно выполнилось и не плодила версий даже если после этого некоторый данные в таблице1 изменятся? или в контексте DBGrid и компонентов IB вопрос не имеет смысла?

Dimitry Sibiryakov,

я архитектор и админ по вынужденности, хотя от админа у меня мало опыта, у вас конечно тут подход что на любой проект мало-мальский только на одну БД надо 17 человек это ж не везде возможно, посоветуете аутсорсинговый сервис по админке фаябердных бд с саппортом 24/7 и за небольшие деньги? вот и я не знаю, приходится админить то что наархитектил

Gstat execution time Tue Nov 17 14:16:37 2020

Database header page information:
Flags 0
Generation 16438551
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 2728724
Oldest active 2728725
Oldest snapshot 2728725
Next transaction 16420357
Sequence number 0
Next attachment ID 77647
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSV
C
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 17, 2020 9:07:26
Attributes force write

Variable header data:
Sweep interval: 20000
*END*


Database file sequence:
File C:\BASES\LF\STORAGE.FDB is the only file

Analyzing database pages ...
POOLBETS (149)
Primary pointer page: 274, Index root page: 275
Total formats: 1, used formats: 1
Average record length: 74.10, total records: 710742
Average version length: 9.00, total versions: 5595281, max versions: 7433
Average fragment length: 7.32, total fragments: 271, max fragments: 1
Average unpacked length: 214.00, compression ratio: 2.89
Pointer pages: 5, data page slots: 14824
Data pages: 14824, average fill: 87%
Primary pages: 4997, secondary pages: 9827, swept pages: 4778
Empty pages: 7, full pages: 14815
Fill distribution:
0 - 19% = 8
20 - 39% = 0
40 - 59% = 0
60 - 79% = 3936
80 - 99% = 10880

Index PK_POOLBETS (0)
Root page: 103484, depth: 2, leaf buckets: 259, nodes: 710742
Average node length: 5.89, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.32
Average prefix length: 2.95, average data length: 1.00
Clustering factor: 13934, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 258

Index POOLBETS_IDX1 (1)
Root page: 103743, depth: 2, leaf buckets: 222, nodes: 710742
Average node length: 5.04, total dup: 627337, max dup: 49
Average key length: 2.15, compression ratio: 1.84
Average prefix length: 3.82, average data length: 0.13
Clustering factor: 46284, ratio: 0.07
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 221

Index POOLBETS_IDX2 (2)
Root page: 103965, depth: 2, leaf buckets: 218, nodes: 710742
Average node length: 4.89, total dup: 710736, max dup: 608970
Average key length: 2.00, compression ratio: 0.57
Average prefix length: 1.14, average data length: 0.00
Clustering factor: 16348, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 7
60 - 79% = 1
80 - 99% = 210

Index POOLBETS_IDX3 (3)
Root page: 104180, depth: 2, leaf buckets: 234, nodes: 710742
Average node length: 4.91, total dup: 708562, max dup: 38795
Average key length: 2.02, compression ratio: 6.29
Average prefix length: 12.69, average data length: 0.02
Clustering factor: 51260, ratio: 0.07
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 37
60 - 79% = 2
80 - 99% = 195

Index POOLBETS_IDX4 (4)
Root page: 104396, depth: 2, leaf buckets: 215, nodes: 710742
Average node length: 4.89, total dup: 710740, max dup: 572639
Average key length: 2.00, compression ratio: 0.90
Average prefix length: 1.81, average data length: 0.00
Clustering factor: 9798, ratio: 0.01
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 1
80 - 99% = 213

Index POOLBETS_IDX5 (5)
Root page: 104611, depth: 2, leaf buckets: 217, nodes: 711504
Average node length: 4.89, total dup: 711499, max dup: 354429
Average key length: 2.00, compression ratio: 1.00
Average prefix length: 2.00, average data length: 0.00
Clustering factor: 11229, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 5
60 - 79% = 1
80 - 99% = 211

Index POOLBETS_IDX6 (6)
Root page: 104826, depth: 2, leaf buckets: 371, nodes: 710742
Average node length: 4.89, total dup: 709648, max dup: 3314
Average key length: 2.00, compression ratio: 1.50
Average prefix length: 2.99, average data length: 0.00
Clustering factor: 581020, ratio: 0.82
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 314
60 - 79% = 0
80 - 99% = 57

Index POOLBETS_IDX7 (7)
Root page: 105041, depth: 2, leaf buckets: 395, nodes: 710742
Average node length: 8.61, total dup: 3152, max dup: 14
Average key length: 5.73, compression ratio: 1.78
Average prefix length: 7.42, average data length: 2.76
Clustering factor: 124409, ratio: 0.18
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 31
60 - 79% = 1
80 - 99% = 363

Gstat completion time Tue Nov 17 14:17:38 2020

на данный момент вот так? это норм или все плохо?

Симонов Денис,

это после свипа и б/р поработало 4 часа

hvlad,

о спасибо я хоть понял че куда смотреть, последний час воздействие волшебного пинания привело к тому что max versions: 1-4 держится а всего 80-90

fraks,

да, спасибо уже все исправили, проблема была в читающей висящей транзе, а данные выводились в дбгрид, теперь коммитится сразу по завершению запроса кому надо обновляет и все щасливы. данные исходные онлайн и проблема в том что там несколько стадий у них создание-подтверждение и бывает иногда последующее переподтверждение, все эти данные вносятся беспрерывно 150-200 клиентами еще и пачками, а начальство мониторит общий отчет где все это суммируется вычитается и перемножается.

ЗЫ. Ну т.е. начальство смотрело отчет и оставляло его висеть часов 10 а за это время там все обновлялось и обновлялось

Дегтярев Евгений,

ой, о таком не говорят в приличном обществе) там боты

Vlad F,

лол, вот за 6 лет создал пару тем когда проблемы появлялись, в остальном было все ок, поэтому и не писал) а насчет спецов так я писал про аутсорсинг жи

Vlad F,

да знаю я где ссылка kdv, думаю мы прийдем неизбежно к этому так или иначе