Симонов ДенисAndrey_Но возможно это моя вина, я мог запутаться и подключиться к базе тройки с сервера 2.5.Это не возможно. А вот перепутать локальный протокол с embedded можно.Сам перечитал, что написал. В общем ничего криминального вроде не делал. Вряд ли это описание принесет пользу, но чтобы не забыть как что было, оставлю его тут.
Что я делал:
Ставил FB 3 из дистрибутива Firebird-3.0.0.32483_2_x64, при инсталяции он правильно определил, что у меня установлен 2.5 и отказался выполнять э...начальные настройки.
Сервер запускал с ключем -a (это dev-машина и я предполагал что потребуется частое переключение между 2.5 и 3.0, а настраивать их одновременную работу не хотелось т.к. они нужны поочереди)
На клиенте использовал fbclient.dll из WOW64
Строка подключения всегда была вида 127.0.0.1:D:\и т.д. (с новыми протоколами пока не разбирался, попробовал что так работает и ладно)
Базу бекапил клиентом и сервером 2.5, ресторил клиентом и сервером 3.0
В firebird.conf менял только ServerMode, игрался с разными вариантами (восновном Super и SuperClassic, непомню запускал ли я тест на Classic или нет.)
Клиентское приложение стартовало 43 потока, каждый выполнял коннект к базе (10 инсерт-потоков, 10 апдейтящих по одной рандомной записи, 3 апдейтящих одну и ту же рандомную запись, 20 читающих эту же рандомную запись). 2 раза в секунду во все потоки приходил ивент по которому они все стартовали транзакцию, выполняли кто-что должен и коммитились. Это не моя идея такого теста, я бы проеверял, как всегда, скорость отклика на N-условно паралельных запросов.
При завершении работы приложения я старался корректно выполнять disconnect, но часто некоторые потоки зависали из-за эксепшенов (те самые лок конфликты) и я приложение срубал через Ctrl+F2 из Delphi или в диспетчере задач когда standalone.
То есть, при срубании могло оставаться 1-4 коннекта с открытыми транзакциями.
Тестовых запусков приложения было порядка 15. Восновном они были короткие т.к. происходило зависание потоков. Но были и тесты крутившиеся несколько минут.
Других коннектов к серверу (IBExpert например) небыло.
Краш был обнаружен на утро следующего дня. Не уверен что это важно, вроде в FB нет шедулеров работающих с диском по таймеру. Ну кроме управляемого MaxUnflushedWriteTime, но этот параметр я не трогал.
Ошибка выдается при запросе select * from "Table1"
статистика базыDatabase "D:\DB\RDBTEST_3.0.FDB"
Database header page information:
Flags 0
Generation 29095
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 28854
Oldest active 28901
Oldest snapshot 28901
Next transaction 28902
Sequence number 0
Next attachment ID 612
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jul 26, 2016 18:33:10
Attributes force write
Variable header data:
Sweep interval: 20000
*END*
Database file sequence:
File D:\DB\RDBTEST_3.0.FDB is the only file
Analyzing database pages ...
Expected data on page 177
Table1 (128)
Primary pointer page: 163, Index root page: 164
Pointer pages: 1, data page slots: 1632
Data pages: 1632, average fill: 78%
Primary pages: 1295, secondary pages: 337, swept pages: 621
Empty pages: 5, full pages: 1344
Fill distribution:
0 - 19% = 176
20 - 39% = 69
40 - 59% = 20
60 - 79% = 90
80 - 99% = 1276
Index PKTable1 (0)
Root page: 1006, depth: 2, leaf buckets: 13, nodes: 35444
Average node length: 5.30, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.27
Average prefix length: 2.82, average data length: 1.00
Clustering factor: 2786, ratio: 0.08
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 11
Table2 (129)
Primary pointer page: 167, Index root page: 168
Pointer pages: 1, data page slots: 1608
Data pages: 1608, average fill: 80%
Primary pages: 1312, secondary pages: 296, swept pages: 632
Empty pages: 3, full pages: 1354
Fill distribution:
0 - 19% = 143
20 - 39% = 72
40 - 59% = 20
60 - 79% = 89
80 - 99% = 1284
Index FKTable2Table1 (1)
Root page: 1015, depth: 2, leaf buckets: 19, nodes: 36000
Average node length: 5.16, total dup: 7996, max dup: 27
Average key length: 2.85, compression ratio: 1.34
Average prefix length: 3.01, average data length: 0.81
Clustering factor: 20372, ratio: 0.57
Fill distribution:
0 - 19% = 0
20 - 39% = 5
40 - 59% = 8
60 - 79% = 0
80 - 99% = 6
Index PKTable2 (0)
Root page: 597, depth: 2, leaf buckets: 13, nodes: 35445
Average node length: 5.30, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.27
Average prefix length: 2.82, average data length: 1.00
Clustering factor: 2927, ratio: 0.08
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 11
И да, господа, я знаю что прежде чем говорить "я тестировал" нужно разобраться в инструменте который тестируешь. Давайте сейчас это не будем обсуждать, цель - найти последовательность действий для краша базы, а не наставить меня на путь истинный по поводу использования дефолтного конфига.
И еще, не трогайте пожалуйста меня за двойные кавычки. Я сам их терпеть не могу, но опять же, корпоративный CodeStyle.
