powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / невосстанавливаемый backup базы с computed by полями
19 сообщений из 19, страница 1 из 1
невосстанавливаемый backup базы с computed by полями
    #40024220
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приветствую знатоков!

WI-V3.0.7.33374 Firebird 3.0

Столкнулся с проблемой.

Есть таблица:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
create table tbl (
fld varchar(4000) character set utf8,
cmp1 computed by (fld),
cmp2 computed by (fld),
cmp3 computed by (fld),
cmp4 computed by (fld),
cmp5 computed by (fld));



с пустой записью:

Код: plsql
1.
insert into tbl(fld) values (null);



Таблица прекрасно создается, никаких претензий не возникает.

Смотрю статистику:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Analyzing database pages ...
TBL (128)
    Primary pointer page: 163, Index root page: 164
    Total formats: 1, used formats: 1
    Average record length: 254.00, total records: 1
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 16002.00, compression ratio: 63.00
    Pointer pages: 1, data page slots: 1
    Data pages: 1, average fill: 2%
    Primary pages: 1, secondary pages: 0, swept pages: 0
    Empty pages: 0, full pages: 0
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 0

Статистика нормальная, запись в норму (65К) влезает - Average unpacked length: 16002.00 .

Делаю backup - прекрасно. Делаю restore - облом:

Код: plaintext
1.
2.
3.
4.
5.
6.
This operation is not defined for system tables.
     unsuccessful metadata update.
     new record size of  96016  bytes is too big.
     TABLE TBL.
     Exiting before completion due to errors.
Restore completed. Current time: 13:27:54. Elapsed time: 00:00:00

Размер записи подрос, уже не влазит. Как понимаю, проблема связана с этим:

https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1276267&msg=22127534

Единственным решением вижу подсчет на уровне приложения размера записи с учетом computed by полей и втыкание проверок в разных местах, чтобы не напороться на невосстанавливаемый backup.

Может у кого есть другие соображения на этот счет?
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024232
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryСтатистика нормальная, запись в норму (65К) влезает - Average unpacked length: 16002.00.
да плевать влезает или не влезает. считается максимальное, сколько может влезть.
4000 символов в ютф8 это 16к байт.
16к * 5 = 80000 байт.
Так что таблица, по идее, не должна была создаться исходно, из-за того что буфер для хранения выходных значений превышает 80к байт.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024240
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvТак что таблица, по идее, не должна была создаться исходно, из-за того что буфер для
хранения выходных значений превышает 80к байт.

Лимит на буфер был снят как минимум в четвёрке. За тройку не уверен.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024257
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv

считается максимальное, сколько может влезть.


Я привел из статистики значение "unpacked length". Как понимаю, это и есть максимум.

kdv

Так что таблица, по идее, не должна была создаться исходно


Я же написал - таблица прекрасно создается, никаких претензий не возникает.

Dimitry Sibiryakov

Лимит на буфер был снят как минимум в четвёрке. За тройку не уверен.


Проверил на WI-V4.0.0.2269 Firebird 4.0 Release Candidate 1 - ситуация такая же.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024261
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Надо ждать Влада. А то память мне скорее всего опять изменяет, но восстановление
вычисляемых полей как обычных с последующим переводом в вычисляемые было сделано как
багфикс. Хотя беглый поиск в багтрекере ничего не обнаружил.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024264
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

не был. Снят только на вьюхах

ggreggory,

вычисляемые поля это зло. Лично моё мнение, что если что-то требуется вычислять столбец не по месту (в запросах), то лучше сделать вьюху, чем вычисляемое поле. В вычисляемых полях можно делать только что-то уж совсем простое
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024265
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryЯ привел из статистики значение "unpacked length". Как понимаю, это и есть максимум.
да при чем тут это. unpacked length, packed length - это информация о среднем размере данных, которые хранятся.
Максимум возможного хранения тут не хранится (он вычисляется только по максимально объявленному формату в rdb$relation_fields и rdb$formats).
Если вы аллокировали в программе буфер размером 16к, значит влезет туда только 16к, но хранить-то вы в нём не обязательно будете 16к, а может быть и меньше. Но больше 16к вы впихнуть туда не сможете.
Вот и Firebird именно так и хранит данные на диске (внезапно). Объявлено 16к, в среднем 4к, о чем вам и сообщает gstat.
Но когда серверу надо передать вам данные, то выделяется буфер максимального размера, по объявленной длине строки. Потому что сервер понятия не имеет, сколько вы там на диск напихали.
Вдруг там во всех строках по 16к? Ну и клиент, соответственно, тоже должен аллокировать у себя такой же фиксированно-максимальный буфер, чтобы иметь возможность принимать данные любого размера в пределах объявленного.

А в максимальный размер записи 64к (до ФБ4) входит, естественно, еще и всякий оверхед. Ваши же голые 96к (я в предыдущем сообщении ошибся, умножил 16к на 5 столбцов, а у вас их 6) далеко за пределом даже голого 64к.
Возможность создания такой таблицы в ФБ 3 - просто баг.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024267
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

вычисляемость столбца на сервере еще можно пережить, ссылаясь на оригинальное значение. Но передать сервер клиенту ссылки на оригинал (вместо значений) не может, поэтому должен заполнить буфер записи полностью.
Ну и, в конце-концов, программист ведь может залудить конкатенацию всех этих столбцов на сервере. И опять же получится облом.
Даже если использовать только те столбцы, "из которых состоит такая таблица".
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024270
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvОбъявлено 16к, в среднем 4к, о чем вам и сообщает gstat.
я тут не про то, с utf8 смысл несколько другой. Объявлено 4к строка, хранится 16к байт, значит строка на диске заполнена максимально.
Но это ХРАНИМАЯ часть таблицы. Вычисляемые столбцы не хранятся, понятно. Но тут речь не про хранение, а передачу содержимого записи клиенту. А там уже никаких вычисляемых столбцов нет. Клиент вычислять по правилам сервера ничего не может, а значит должен данные получить полностью сформированные.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024274
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисне был. Снят только на вьюхах

Если быть точным, то был снят лимит на ширину выборки (что включило вьюхи). Лимит на
ширину записи, да, остался.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024286
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
Максимум возможного хранения тут не хранится (он вычисляется только по максимально объявленному формату в rdb$relation_fields и rdb$formats).


Ок, спасибо, буду иметь ввиду, показатель "unpacked length" для меня новый, в Firebird 1.5 его не было. Сейчас проверил на нескольких базах,

Код: plsql
1.
2.
select r.rdb$relation_name, sum(f.rdb$field_length) from rdb$relation_fields r join rdb$fields f on
(r.rdb$field_source = f.rdb$field_name) where f.rdb$computed_source is null group by 1



выдает примерно то же самое, что и статистика "unpacked length", но есть отличия += 1% где-то.

kdv
А в максимальный размер записи 64к ( до ФБ4 ) входит, естественно, еще и всякий оверхед. Ваши же голые 96к (я в предыдущем сообщении ошибся, умножил 16к на 5 столбцов, а у вас их 6) далеко за пределом даже голого 64к.
Возможность создания такой таблицы в ФБ 3 - просто баг.


Я написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024295
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryЯ написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия.
опять мочало про релиз-кандидат полугодовой давности? выкиньте его уже, честное слово...
ggreggoryпоказатель "unpacked length" для меня новый, в Firebird 1.5 его не было.
а record length и version length раньше не было, что-ли? Или они показывали максимальный объявленный размер записи?
Нет же, речь всегда только про хранимые данные. Вычисляемые столбцы - НЕ ХРАНИМЫЕ.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024301
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
ggreggoryЯ написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия.

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

V4.0.0.2269 я скачивал две недели назад. Сейчас там 2287, пока не скачивал, думаете, стоит проверить?

kdv
ggreggoryпоказатель "unpacked length" для меня новый, в Firebird 1.5 его не было.

а record length и version length раньше не было, что-ли? Или они показывали максимальный объявленный размер записи?
Нет же, речь всегда только про хранимые данные. Вычисляемые столбцы - НЕ ХРАНИМЫЕ.

Извините, я реплику вашу не понял. Как раз в самом первом топике я показал, что статистика "unpacked length" показывает информацию об одном единственном хранимом поле 16К. Вы написали - не туда смотришь, ок, это понятно. Об учете размеров НЕ ХРАНИМЫХ полей в статистике или еще где я не писал.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024302
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryдумаете, стоит проверить?

Лично я думаю, что надо идти прямо в трекер. Так или иначе, но невосстановимый бэкап это
нехорошо.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024305
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggory
kdv
пропущено...

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


V4.0.0.2269 я скачивал две недели назад. Сейчас там 2287, пока не скачивал, думаете, стоит проверить?


нет. Там были изменения по поводу ALTER SESSION RESET.
Глобальных изменений, особенно касающихся ODS на стадии Beta -> RC не будет.
Расширение лимита на запись таблицы обещали в 5-ке. А выйдет она ой как нескоро, потому что следующая версия будет 4.1.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024306
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryИзвините, я реплику вашу не понял.
Как раз в самом первом топике я показал, что статистика "unpacked length" показывает информацию об одном единственном хранимом поле 16К.
тогда я не понял. Вы привели информацию, что вот у вас данные в таблице 16к, а сервер ругается на 96к. Типа, почему?
Ну я и объяснил, почему. Теперь, вы говорите что ЗНАЛИ об этом. Но тогда исходный вопрос вообще обнуляется. Не?
В статистике-то всего лишь, раньше record length было среднее запакованное, теперь пишет среднее распакованное.
Ну, можно сказать что "офигеть какое достижение". И мне непонятно, почему вы на это специально указываете.
Типа, раньше вы unpacked не видели, и в результате что? Вы не знали о том, что записи в ФБ упаковываются?
ggreggoryЯ же написал - таблица прекрасно создается, никаких претензий не возникает.
как раз претензия возникает, потому что допускается создание таблицы, у которой размер буфера записи получается больше 64к. И которую потом невозможно использовать, например, при select * from table.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024314
ggreggory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
kdv
И которую потом невозможно использовать, например, при select * from table.


Написали же выше, сняли в 3-ей версии лимит на выбираемые записи. Сделайте запрос и убедитесь сами:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
select cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8),
cast(null as varchar(8000) character set utf8)
 from rdb$database



kdv
Типа, почему?
Ну я и объяснил, почему. Теперь, вы говорите что ЗНАЛИ об этом.


Знал и в заглавном топике привел свою версию причины. А вашу версию, что это из-за того что буфер для хранения выходных значений превышает 80к байт , считаю неверной, сняли в 3-ей версии лимит на выбираемые записи. Но думаю, что тратить время и спорить нам по этому поводу не стоит. Появятся разработчики, может черканут пару строк по этой теме.
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024319
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
память мне скорее всего опять изменяет, но восстановление
вычисляемых полей как обычных с последующим переводом в вычисляемые было сделано как
багфикс. Хотя беглый поиск в багтрекере ничего не обнаружил.

не изменяет, так и было
...
Рейтинг: 0 / 0
невосстанавливаемый backup базы с computed by полями
    #40024390
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggreggoryНаписали же выше, сняли в 3-ей версии лимит на выбираемые записи
у меня профессиональный склероз. кроме того, я такой фигни как у вас в таблице и в запросе писать никогда не буду.
Конечно, это, может быть, "препятствует развитию firebird", но мне оно препятствует наступанию на грабли.
...
Рейтинг: 0 / 0
19 сообщений из 19, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / невосстанавливаемый backup базы с computed by полями
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]