|
|
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KА для других типов в пределах транзакции до ее окончания память не выделяется?Массивы и блобы - близнецы братья (в этом смысле). Для остальных типов данных нет нужды что-то ещё учитывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:05 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory K> Во-первых в руководстве явно указано про неоднозначность сочетания -c -r, Gregory K> а вот про -с -rep я не увидел. Упоминается лишь про то, что -rep пришло на смену -r. Неоднозначность та же самая, пришло на смену вместе с ней. Gregory K> Я считал, что -c я восстановлю базу, а -rep - это Gregory K> ответ на вопрос что делать, если база уже существует. Ну или -rep или лучше -r o (так явнее ИМХО). > почему бы об этом сразу в консоли не сказать? Если ты о справке, то IIRC в 2.5 (или 2.1 не помню) это поправили. Если же ты про результат работы утилиты - он ошибку выдаёт только если она возникает, а не что-то ему не нравится :) Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:13 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KВ-третьих непонятно с чего вы решили, что я ресторю в боевую базу? Я намерено не стал грузить окружающих полной логикой работы всей системы. На самом деле, если интересно, оперативная запись данных идет в текущую месячную базу. Но поскольку индексов в ней нет, я по ночам делаю бэкап и последующий рестор в другую базу, назовем ее operate.gdb. Она всегда так называется и поэтому ее надо всегда перезаписывать без вопросов... на мой взгляд если не жалко места на диске, лучше восстанавливать в opearte.new.gdb и в случае удачи переименовывать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:41 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovУ тебя база read-only? База не read-only, хотя и планировалось Система ещё строится и могут быть изменения структуры и логики хранимых процедур. Но данные в ней не меняются после завершения месячного накопления ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:42 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
hvladМассивы и блобы - близнецы братья (в этом смысле). Для остальных типов данных нет нужды что-то ещё учитывать. К сожалению предположение с блобами смогу проверить только послезавтра. Но ручки чешутся) С другой стороны, бэкап тоже в рамках транзакции делается, но с ним такой проблемы нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:48 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KС другой стороны, бэкап тоже в рамках транзакции делается, но с ним такой проблемы нетБекап не создаёт блобы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:55 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory Kоперативная запись данных идет в текущую месячную базу. Но поскольку индексов в ней нет, я по ночам делаю бэкап и последующий рестор в другую базу, назовем ее operate.gdb. Она всегда так называется и поэтому ее надо всегда перезаписывать без вопросов. По ней же и строю индексы и утром получаю состояние на вчерашний день со всеми индексами и прочими плюхами. Ужоснах. Более неуклюжую попытку завести аналитическую базу трудно представить. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 17:59 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov> Ужоснах. Более неуклюжую попытку Dimitry Sibiryakov> завести аналитическую базу трудно представить. Да ладно, я тупо ресторил свежую/вчерашнюю БД, не заморачиваясь над репликаторами и пр. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:08 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KВ-третьих непонятно с чего вы решили, что я ресторю в боевую базу? да хоть в какую. -rep это как плохая привычка - обязательно вылезет в самый неподходящий момент, просто потому что ВЫ привыкли так делать. Как следствие - холодный пот на лбу, ужас в глазах, и так далее. Gregory KВо-вторых если это сочетание недопустимо надо читать документацию и статьи, а не лепить в командной строке что попало. допустимость указания обоих опций не извиняет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:27 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
kdv, а по существу проблемы есть идеи? Или останавливаемся на блобах как на источнике проблем? Хорошо, когда есть достаточно оперативы, но вдруг завтра надо будет миллиард записей восстановить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:45 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory KХорошо, когда есть достаточно оперативы, но вдруг завтра надо будет миллиард записей восстановить Прикупишь ещё оперативы. Она дешевле чем DBA и разработчик БД вместе взятые. БД перестаёт быть маленькой, когда backup-restore с помощью gbak перестаёт укладываться в технологическое окно. После этого следует переход на использование nbackup. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:51 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovУжоснах. Более неуклюжую попытку завести аналитическую базу трудно представить. Ну что есть, то есть. Делает что нужно, денег не просит. Буду пилить, может быть что-то путное родится. Готов выслушать про менее неуклюжий вариант С трудом представляю откуда вы знаете исходную задачу и преследуемую цель И вообще это офтоп вроде как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:54 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory Kа по существу проблемы есть идеи? по существу уже все сказал hvlad. до кучи Gregory KBLOB SUB_TYPE 1 SEGMENT SIZE 16 , http://www.ibase.ru/ibfaq.htm#bss ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 18:56 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory Kkdv, а по существу проблемы есть идеи? Или останавливаемся на блобах как на источнике проблем? Хорошо, когда есть достаточно оперативы, но вдруг завтра надо будет миллиард записей восстановить есть выход, delete * и что-нить по типу ibpump ( помнится раньше такой был ) ;) ИМХО можно заняться патчем, добавляющим функционал gbak ( ещё один ключ ), что-то вроде количества строк в таблице, после которого идёт commit ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 19:08 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
NikolayV81> ИМХО можно заняться патчем, добавляющим функционал gbak ( ещё один ключ ), NikolayV81> что-то вроде количества строк в таблице, после которого идёт commit +1 Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 19:31 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Еще раз всем спасибо за участие. По результатам отпишусь. С наступающим рождеством. Пошел смотреть великого уравнителя) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.01.2015, 19:37 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Изменил тип поля с varchar на varchar и fb при ресторе память жрать перестал. Проблема решена. В общем блобы при криворуком использовании - это зло. Еще раз всем спасибо. В особенности hvlad-у ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 12:40 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Gregory K> Изменил тип поля с varchar на varchar C БЛОБ на варчар Вы хотели сказать? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 14:58 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Гаджимурадов Рустам C БЛОБ на варчар Вы хотели сказать? Да, конечно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 18:13 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
с версии 2.1 или 2.5 минимальный размер страницы - 4к. сам недавно напоролся на это, кхм, нехорошее ограничение, долго не мог понять, почему не работает указание в 1к при ресторе hvladБекап не создаёт блобы.не нужно недооценивать пользователей 14893468 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 18:14 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
fd00ch, а нафига тебе нужно меньше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 18:59 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, чтобы хранить кучу мелких блобов без большого оверхеда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 19:26 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
fd00chкхм, нехорошее ограничение очень хорошее ограничение. Потому что даже на базе в 100мб страница 4к уже много лет работает быстрее, чем 1 и 2 к. Это факт для подавляющего большинства баз данных. p.s. с ФБ 2.0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 21:49 |
|
||
|
Использование памяти при восстановлении больших таблиц gbak
|
|||
|---|---|---|---|
|
#18+
kdv, вот только мне нужен минимальный размер БД, а не максимальное быстродействие ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2015, 21:52 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38850317&tid=1563101]: |
0ms |
get settings: |
6ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
88ms |
get topic data: |
34ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 455ms |

| 0 / 0 |
