|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Приветствую знатоков! WI-V3.0.7.33374 Firebird 3.0 Столкнулся с проблемой. Есть таблица: Код: plsql 1. 2. 3. 4. 5. 6. 7.
с пустой записью: Код: plsql 1.
Таблица прекрасно создается, никаких претензий не возникает. Смотрю статистику: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Статистика нормальная, запись в норму (65К) влезает - Average unpacked length: 16002.00 . Делаю backup - прекрасно. Делаю restore - облом: Код: plaintext 1. 2. 3. 4. 5. 6.
Размер записи подрос, уже не влазит. Как понимаю, проблема связана с этим: https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1276267&msg=22127534 Единственным решением вижу подсчет на уровне приложения размера записи с учетом computed by полей и втыкание проверок в разных местах, чтобы не напороться на невосстанавливаемый backup. Может у кого есть другие соображения на этот счет? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 13:39 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggoryСтатистика нормальная, запись в норму (65К) влезает - Average unpacked length: 16002.00. да плевать влезает или не влезает. считается максимальное, сколько может влезть. 4000 символов в ютф8 это 16к байт. 16к * 5 = 80000 байт. Так что таблица, по идее, не должна была создаться исходно, из-за того что буфер для хранения выходных значений превышает 80к байт. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 14:22 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
kdvТак что таблица, по идее, не должна была создаться исходно, из-за того что буфер для хранения выходных значений превышает 80к байт. Лимит на буфер был снят как минимум в четвёрке. За тройку не уверен. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 14:28 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
kdv считается максимальное, сколько может влезть. Я привел из статистики значение "unpacked length". Как понимаю, это и есть максимум. kdv Так что таблица, по идее, не должна была создаться исходно Я же написал - таблица прекрасно создается, никаких претензий не возникает. Dimitry Sibiryakov Лимит на буфер был снят как минимум в четвёрке. За тройку не уверен. Проверил на WI-V4.0.0.2269 Firebird 4.0 Release Candidate 1 - ситуация такая же. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 14:54 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Надо ждать Влада. А то память мне скорее всего опять изменяет, но восстановление вычисляемых полей как обычных с последующим переводом в вычисляемые было сделано как багфикс. Хотя беглый поиск в багтрекере ничего не обнаружил. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:03 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, не был. Снят только на вьюхах ggreggory, вычисляемые поля это зло. Лично моё мнение, что если что-то требуется вычислять столбец не по месту (в запросах), то лучше сделать вьюху, чем вычисляемое поле. В вычисляемых полях можно делать только что-то уж совсем простое ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:05 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
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 - просто баг. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:15 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Симонов Денис, вычисляемость столбца на сервере еще можно пережить, ссылаясь на оригинальное значение. Но передать сервер клиенту ссылки на оригинал (вместо значений) не может, поэтому должен заполнить буфер записи полностью. Ну и, в конце-концов, программист ведь может залудить конкатенацию всех этих столбцов на сервере. И опять же получится облом. Даже если использовать только те столбцы, "из которых состоит такая таблица". ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:18 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
kdvОбъявлено 16к, в среднем 4к, о чем вам и сообщает gstat. я тут не про то, с utf8 смысл несколько другой. Объявлено 4к строка, хранится 16к байт, значит строка на диске заполнена максимально. Но это ХРАНИМАЯ часть таблицы. Вычисляемые столбцы не хранятся, понятно. Но тут речь не про хранение, а передачу содержимого записи клиенту. А там уже никаких вычисляемых столбцов нет. Клиент вычислять по правилам сервера ничего не может, а значит должен данные получить полностью сформированные. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:25 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Симонов Денисне был. Снят только на вьюхах Если быть точным, то был снят лимит на ширину выборки (что включило вьюхи). Лимит на ширину записи, да, остался. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 15:34 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
kdv Максимум возможного хранения тут не хранится (он вычисляется только по максимально объявленному формату в rdb$relation_fields и rdb$formats). Ок, спасибо, буду иметь ввиду, показатель "unpacked length" для меня новый, в Firebird 1.5 его не было. Сейчас проверил на нескольких базах, Код: plsql 1. 2.
выдает примерно то же самое, что и статистика "unpacked length", но есть отличия += 1% где-то. kdv А в максимальный размер записи 64к ( до ФБ4 ) входит, естественно, еще и всякий оверхед. Ваши же голые 96к (я в предыдущем сообщении ошибся, умножил 16к на 5 столбцов, а у вас их 6) далеко за пределом даже голого 64к. Возможность создания такой таблицы в ФБ 3 - просто баг. Я написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:00 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggoryЯ написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия. опять мочало про релиз-кандидат полугодовой давности? выкиньте его уже, честное слово... ggreggoryпоказатель "unpacked length" для меня новый, в Firebird 1.5 его не было. а record length и version length раньше не было, что-ли? Или они показывали максимальный объявленный размер записи? Нет же, речь всегда только про хранимые данные. Вычисляемые столбцы - НЕ ХРАНИМЫЕ. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:12 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
kdv ggreggoryЯ написал выше, что в FB4 ситуация такая же. Правда у меня не самая последняя версия. опять мочало про релиз-кандидат полугодовой давности? выкиньте его уже, честное слово... V4.0.0.2269 я скачивал две недели назад. Сейчас там 2287, пока не скачивал, думаете, стоит проверить? kdv ggreggoryпоказатель "unpacked length" для меня новый, в Firebird 1.5 его не было. а record length и version length раньше не было, что-ли? Или они показывали максимальный объявленный размер записи? Нет же, речь всегда только про хранимые данные. Вычисляемые столбцы - НЕ ХРАНИМЫЕ. Извините, я реплику вашу не понял. Как раз в самом первом топике я показал, что статистика "unpacked length" показывает информацию об одном единственном хранимом поле 16К. Вы написали - не туда смотришь, ок, это понятно. Об учете размеров НЕ ХРАНИМЫХ полей в статистике или еще где я не писал. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:33 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggoryдумаете, стоит проверить? Лично я думаю, что надо идти прямо в трекер. Так или иначе, но невосстановимый бэкап это нехорошо. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:38 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggory kdv пропущено... опять мочало про релиз-кандидат полугодовой давности? выкиньте его уже, честное слово... V4.0.0.2269 я скачивал две недели назад. Сейчас там 2287, пока не скачивал, думаете, стоит проверить? нет. Там были изменения по поводу ALTER SESSION RESET. Глобальных изменений, особенно касающихся ODS на стадии Beta -> RC не будет. Расширение лимита на запись таблицы обещали в 5-ке. А выйдет она ой как нескоро, потому что следующая версия будет 4.1. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:46 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggoryИзвините, я реплику вашу не понял. Как раз в самом первом топике я показал, что статистика "unpacked length" показывает информацию об одном единственном хранимом поле 16К. тогда я не понял. Вы привели информацию, что вот у вас данные в таблице 16к, а сервер ругается на 96к. Типа, почему? Ну я и объяснил, почему. Теперь, вы говорите что ЗНАЛИ об этом. Но тогда исходный вопрос вообще обнуляется. Не? В статистике-то всего лишь, раньше record length было среднее запакованное, теперь пишет среднее распакованное. Ну, можно сказать что "офигеть какое достижение". И мне непонятно, почему вы на это специально указываете. Типа, раньше вы unpacked не видели, и в результате что? Вы не знали о том, что записи в ФБ упаковываются? ggreggoryЯ же написал - таблица прекрасно создается, никаких претензий не возникает. как раз претензия возникает, потому что допускается создание таблицы, у которой размер буфера записи получается больше 64к. И которую потом невозможно использовать, например, при select * from table. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 16:53 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
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.
kdv Типа, почему? Ну я и объяснил, почему. Теперь, вы говорите что ЗНАЛИ об этом. Знал и в заглавном топике привел свою версию причины. А вашу версию, что это из-за того что буфер для хранения выходных значений превышает 80к байт , считаю неверной, сняли в 3-ей версии лимит на выбираемые записи. Но думаю, что тратить время и спорить нам по этому поводу не стоит. Появятся разработчики, может черканут пару строк по этой теме. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 17:23 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov память мне скорее всего опять изменяет, но восстановление вычисляемых полей как обычных с последующим переводом в вычисляемые было сделано как багфикс. Хотя беглый поиск в багтрекере ничего не обнаружил. не изменяет, так и было ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 17:45 |
|
невосстанавливаемый backup базы с computed by полями
|
|||
---|---|---|---|
#18+
ggreggoryНаписали же выше, сняли в 3-ей версии лимит на выбираемые записи у меня профессиональный склероз. кроме того, я такой фигни как у вас в таблице и в запросе писать никогда не буду. Конечно, это, может быть, "препятствует развитию firebird", но мне оно препятствует наступанию на грабли. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.12.2020, 21:52 |
|
|
start [/forum/topic.php?fid=40&fpage=10&tid=1560176]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
177ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
others: | 261ms |
total: | 540ms |
0 / 0 |