Начало » Использование СУБД » Firebird, HQbird, InterBase » Падение fb3 при параллельном подключении (firebird, nbackup, mklink)
| Падение fb3 при параллельном подключении [сообщение #5541] |
Tue, 08 October 2024 23:07  |
shavluk
Сообщений: 82
Зарегистрирован: June 2022
Географическое положение: Одеса
|
Member |
|
|
У меня часто возникает потребность работать с большими базами (20-40 Gb).
Типичная моя работа выглядит так:
1. Делаю рестор базы data.fdb
2. После рестора делаю файловую копию в data-0.fdb
3. Проверяю, делаю модификации. У меня есть эталонная БД с которой можно сравнивать данные и метаданные.
4. Если запорол БД, то вместо повторного рестора, я копирую data-0.fdb в data.fdb
При таком подходе все нормально, кроме того, что копирование занимает много времени и базы занимают много места.
Сейчас я решил сэкономить место таким подходом:
1. Делаю рестор базы data.fdb
2. Блокирую файл базы
nbackup -L data.fdb -user SYSDBA -password masterkey
mklink /h data-0.fdb data.fdb
4. Делаю копию файла data.fdb.delta в data-0.fdb.delta
5. Опционально. Архивирую data.fdb.delta в data-0.fdb.delta для возможности легко вернуться в исходное состояние
Таким образом у меня есть "общее тело" базы данных и независимые дельты.
При необходимости вернуть БД в исходное состояние, копируем только дельту, копия базы не занимает дополнительного места, "копий" можно сделать неограниченно много.
Минусы такого подхода:
1. Подключаться только через Classic или SuperClassic
2. Если каким-то образом разблокировали любую из БД, в лучшем случае остальные БД превращаются в тыкву.
Но такой подход в моих условиях очень удобен.
А теперь собственно ошибка.
В IBExpert
1. Подключаюсь к обеим БД одновременно.
2. Просматриваю любую таблицу в первой БД
3. Пытаюсь просмотреть любою таблицу во второй БД и получаю падение сервера с сообщением
Цитата:Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
connection shutdown.
------------------------------------------------------------ -------------------------------------------------
SQLCODE: -902
SQLSTATE: 08003
GDSCODE: 335544856
Connection will be closed immediately.
В firebird.log пусто
Такое поведение повторяется всегда сразу после рестора. Может повторяться еще несколько раз, потом прекращается. И все работает стабильно
Если подключаться/отключаться к БД по очереди ошибки не возникает.
Можно повторить на любой БД хоть employee.fdb
3.0.11 x64 Win10
[Обновления: Tue, 08 October 2024 23:35] Известить модератора |
|
|
|
|
|
|
|
|
|
| Re: Падение fb3 при параллельном подключении [сообщение #5546 является ответом на сообщение #5545] |
Wed, 09 October 2024 15:04  |
shavluk
Сообщений: 82
Зарегистрирован: June 2022
Географическое положение: Одеса
|
Member |
|
|
basid писал(а) Wed, 09 October 2024 09:27Сразу после восстановления все страницы базы помечены как "потенциально грязные"
Было у меня такое подозрение.
Только чего, если собирают "потенциальный мусор" используют блокировки с одинаковым именем?
Цитата:и немного поменять страниц(у/ы) в дельте.
Но дельты у меня это физически разные файлы. Здесь нет проблемы
[Обновления: Wed, 09 October 2024 15:25] Известить модератора |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Падение fb3 при параллельном подключении [сообщение #5554 является ответом на сообщение #5553] |
Thu, 10 October 2024 09:47 |
basid
Сообщений: 166
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
Не можно. Любые варианты ссылок не отменяют того факта, что доступ идёт к одному и тому же файлу.
Рабочий вариант - разместить файл исходной базы на виртуальном диске и (для только что восстановленной базы) выполнить первичную сборку мусора.
Потом этот диск надо отмонтировать, создать на основе его файла два (или больше) разностных виртуальных диска и работать с базами на этих (разностных) виртуальных дисках.
Если не выполнять массивных вставок/обновлений и не создавать гигантских временных блобов, то изменения будут небольшими и не займут много места.
[Обновления: Thu, 10 October 2024 09:48] Известить модератора |
|
|
|
|
|
|
|
|
|
|
|
| Re: Падение fb3 при параллельном подключении [сообщение #5560 является ответом на сообщение #5559] |
Thu, 10 October 2024 14:00 |
hvlad
Сообщений: 364
Зарегистрирован: August 2022
|
Senior Member |
|
|
shavluk писал(а) Thu, 10 October 2024 13:16hvlad писал(а) Thu, 10 October 2024 09:38Если "идея" состоит в том, что оригинальная БД работает с оригинальной дельтой,
а хардлинк на БД "работает" с новой дельтой - то это не возможно. Никак.
Да, идея состоит как раз в этом. В принципе, можно доработать движок так, чтобы было возможно работать с такими клонами БД.
Но я не уверен, что такая фича будет широко востребована.
Есс-но, хардлинки тут по-прежнему не нужны.
Кроме того, по мере роста изменений в дельте, может начать падать производительность IO.
Это предварительная оценка, не факт.
shavlukЦитата:PS 40ГБ это точно "большая" БД ? Я бы понял, если бы речь шла о 400ГБ...
Ну у меня таких БД много
Не думаю, что нужно работать с десятками таких БД одновременно.
Или даже в течение одного дня.
А 100 неактивных БД - мало кого волнуют, независимо от их размера 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Падение fb3 при параллельном подключении [сообщение #5598 является ответом на сообщение #5597] |
Mon, 21 October 2024 11:43 |
shavluk
Сообщений: 82
Зарегистрирован: June 2022
Географическое положение: Одеса
|
Member |
|
|
Задача, да, такая. Например, оптимизация скорости выполнения. Тестирую различные варианты процедур, индексов.
И намного удобнее, когда можно мгновенно откатить изменения БД. Такая себе "транзакция 2 порядка".
При использовании различных дельт к одной БД можно проверить несколько решений одновременно, не держа много копий базы.
Как таковой проблемы почти и нет. При моем способе все работает, но на свежеотрестореной валится, затем "самоисправляется".
Действительно, 20-40 гб туда-сюда копировать мне не быстро. Вариант с хардлинками всем удобен и быстр. Но валится ))
По большому счету, различий для сервера не должно быть так и много, "тело базы" неизменно, туда ничего не пишется. И разницы, кроме занимаемого места, кажется, что почти и нет
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Падение fb3 при параллельном подключении [сообщение #5606 является ответом на сообщение #5604] |
Tue, 22 October 2024 15:03 |
basid
Сообщений: 166
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
SD писал(а) Tue, 22 October 2024 19:081. GetFinalPathName + выколупывание GUID тома из полученной строки с последующим получением идентификатора файла любым из следующих методов.
2. GetFileInformationEx для получения 64-х разрядного серийного номера тома и 128-ми битного идентификатора файла.
3. GetFileInformation для получения 32-х разрядного серийного номера тома и 64-х битного идентификатора файла. Вариант три, насколько я понимаю, и есть LegacyFileID. Ломается, например, на снимках файловых систем, создаваемых хранилищем. Для воспроизведения бага использовались виртуальные диски на копиях vhd-файла.
"Выколупывать GUID тома" требуется для получение гарантированно уникального (в данном запуске ОС) идентификатора тома. Насколько я понимаю, представляет часть "корректного варианта".
|
|
|
|
Переход к форуму:
Текущее время: Sun Dec 22 06:27:10 GMT+3 2024
Общее время, затраченное на создание страницы: 0.01116 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
