|
|
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Пытаемся средствами через dump создать архив базы 1С-8, но вываливается ошибка: Код: plaintext 1. 2. 3. Код: plaintext 1. Что можно сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 16:04:25 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
архив (сжатый) около 3 гигов? сколько же тогда 'весит' база? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 20:45:07 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
попробовал на рабочих базах - никаких проблем с дампом (но они у меня пока небольшие). сделал тестовую базу на 3 гига (притом с одной таблицей на 2 гига) - сдампилась нормально, размер бэкапа менее 500Мб. "поедания" памяти в процессе обнаружено не было. приведите конфиг постгреса, может быть там что интересное есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 21:02:02 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Архив не сжатый, pg_dump не дает делать сжатые - говорит что не поддерживается компрессия, видать из-за того, что сборка PG-SQL от фирмы 1С. Сама база не превышает пять гигов, судя по размерам каталога PGDATA, но выгрузка pg_dump-ом затыкается на трех с небольшим гигах. Средствами 1С выгрузить базу тоже не удается. В лог PGSQL вываливается следующее: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 21:32:32 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
погуглил - вполне вероятно повреждение базы. начать стоит с того, чтобы остановить postgres, сделать простую копию каталога с данными (на тот случай, если дальнейшие попытки совсем обрушат базу). далее можно попробовать сделать vacuum full, reindex database. вдруг поможет ;) можно попробовать сделать частичный бэкап - найти то место, на котором "обламывается" dump и забэкапить всё, кроме него. ну и искать источник проблем. как минимум - запустить (не менее, чем на сутки) тест памяти. погонять туда-суда по дискам большие файлы, а потом сверить md5. если по железу ничего не находится - отписаться в соответсвующей рассылке, скорее всего разработчики обратят внимание и примут участие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 23:14:16 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Нет, база похоже не повреждена. Выгрузка затыкается постоянно на одной и той-же таблице, в этой таблице 1С хранит вложения файлов ко всяким документам. Сама база еще похоже рабочая, в нее можно зайти, потестировать, переиндексировать. Вот конфиг pgsql, он почти дефолтный, что-то там давно менялось но что именно - не помню. Памяти на сервере 2Гб всего, память в порядке, тестировалась, система Вин-2003SP2-R, версия PG-SQL 8.2.6: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2008, 23:37:21 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
я не знаю, в каких единицах измеряется work_mem :) скорее всего это килобайты, получается уже гигабайт, ИМХО перебор. может быть стоит явно написать: shared_buffers =512MB work_mem = 64MB maintenance_work_mem = 256MB ps: если на сервере больше ничего не крутится - я бы ещё поднял effective_cache_size до 1024MB. хотя к исходному сообщению это отношения не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 00:43:42 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Сегодня попробовал выгрузить дамп на машину с линуксом - но с тем же успехом, дамп обломился. Попробовал выгрузить через EMS SQL Manager for PostgreSQL - там можно типа экспортнуть таблицу кусками по одной записи - но тоже случился облом. В итоге - после очистки злополучной таблицы, содержащей бинарные объекты - дамп пошел. Интересно - какие тогда ограничения у PG-SQL на размеры данных, хранящихся в таблицах? И почему тогда получается, что сохранить в PG-SQL крупные блобы можно, но вот сдампить их для архива - не выйдет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 20:04:14 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
а какого размера были те самые бинарные объёкты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 20:27:06 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
eddieа какого размера были те самые бинарные объёкты? Размеры разные, в этой табличке хранятся прицепленные к документам файлы, среди них были и объемом более ста мегабайт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2008, 22:22:07 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
ещё раз, повторю eddie : Вы work_mem уменьшили ? Вы знаете что это такое ? это сколько памяти можно использовать в запросе. причём work_mem при выполнение _одного_ запроса, в зависимости от запроса, может быть использовано целиком несколько раз. у Вас work_mem - один гигабайт, дамп осуществляется обычными sql командами, которые естественно могут использовать work_mem. авторкакие тогда ограничения у PG-SQL на размеры данных, хранящихся в таблицах?это написано в документации, http://www.postgresql.org/docs/faqs.FAQ.html#item4.4 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. авторИ почему тогда получается, что сохранить в PG-SQL крупные блобы можно, но вот сдампить их для архива - не выйдет?потому что Вы некорректно настроили сервер - разрешили ему сожрать всё виртуальное адресное пространство процесса, и даже больше. любую базу можно сдампить если она не повреждена. -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 08:56:48 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
ЁшВы work_mem уменьшили ? Я специально увеличил ворк-мем в надежде, что дамп таки выгрузится. На компе кроме PG-SQL ничего нету, и кроме как pg-dump никто к серверу не обращается. Потом добавил еще пару планок мозгов - в итоге их стало в общем зачете три гига с копейками - но и это не помогло. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 09:27:35 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
если хотите - можете посчитать, приблизительно: 32-х битный виндовс по умолчанию обычно выделяет 2 гигабайта под пользовательское адресное пространство в процессе. у Вас следующие настойки: Код: plaintext 1. добавьте ещё сюда размер страниц под выполняемый код + данные (.exe .dll) + стек - пусть будет 100 мегабайт итого ~ 1,8 гигабайта (если work_mem заполнится целиком только один раз, что совершенно не обязательно). у Вас осталось в запасе - 200 мегабайт. ещё раз выделить work_mem УЖЕ невозможно. то есть с текущими настройками Вам нужно сидеть и молиться что бы work_mem заполнялся целиком только максимум один раз на запрос, что совсем не обязательно. :) А если вспомнить что адреса выделяются не по порядку, с нуля, а несколько "хаотично", например под .exe обычно выделяется адрес начиная с 0x00400000. а .dll отображается в адресное пространство не обязательно сразу после .exe или до. получается фрагментация адресного пространства которая "сожрёт" и гораздо больше тех оставшихся 200-т мегабайт просто под "дырки" между выделенными адресами. и выделить тот гигабайт work_mem одним куском - не получается... всё тоже самое относится и к maintenance_work_mem, только она используется при восстановлении дампа (индексы, vacuum) -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 09:50:25 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
ImNeedHelpЯ специально увеличил ворк-мем в надежде, что дамп таки выгрузится.Вам надо не увеличивать, а уменьшать. Оно у Вас и так не влезает в два гигабайта. ImNeedHelpНа компе кроме PG-SQL ничего нету, и кроме как pg-dump никто к серверу не обращается.это не имеет значения, если физической памяти не хватит - будет использован свап файл. ImNeedHelpПотом добавил еще пару планок мозгов - в итоге их стало в общем зачете три гига с копейками - но и это не помогло.это не имеет значения. виндовс выделяет 2 гигабайта под страницы пользователя. Вы можете поставить хоть 8 планок физической памяти по гигабайту, это не изменит лимит в два гигабайта под страницы пользователя на процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 09:55:28 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Прописал как советовали: Код: plaintext 1. 2. Как же все-таки вытащить дамп без очистки этой большой таблицы? Может - какой-то фикс запустить или проверку? Есть какая-нибудь утилита? Запускал pg-resetxlog.exe - но это очевидно из другой оперы и не помогает. Ваккумизация с полным анализом - тоже не помогает. Что можно сделать еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 12:37:16 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
сервер перезапускали после изменения конфигурации ? если да - попробуйте вообще закоментировать work_mem и maintenance_work_mem, что бы значения по умолчанию остались. авторМожет - какой-то фикс запустить или проверку? Есть какая-нибудь утилита?есть, если у Вас select * from problem_table и vacum full analyze работают без сообщений об ошибках (смотреть в логах) - значит скорее всего у Вас всё в порядке. авторЗапускал pg-resetxlog.exe - но это очевидно из другой оперы и не помогает. о боже, это ещё зачем !? всю базу разнесли, или что-то осталось ? :) если ничего не помогает - обращайтесь в 1С - пусть они разбираются что они там напатчили и почему _у них_ дамп не работает. -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 14:12:21 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Ёшсервер перезапускали после изменения конфигурации ? Канечно - PG-SQL на лету эти опции не прочитывает и не изменяет. Ёшпопробуйте вообще закоментировать work_mem и maintenance_work_mem, что бы значения по умолчанию остались. Пробовал - тот же результат. Ёш если у Вас select * from problem_table и vacum full analyze работают без сообщений об ошибках (смотреть в логах) - значит скорее всего у Вас всё в порядке. select * from problem_table выдает клиенту out of memory for query result Ёш о боже, это ещё зачем !? всю базу разнесли, или что-то осталось ? Да пофиг - я все равно не рабочую базу терзаю, скопировал каталог PGDATA на другой комп - и там уже душу. Ёш обращайтесь в 1С - пусть они разбираются что они там напатчили и почему _у них_ дамп не работает. Несмотря на то, что 1С официальна куплена - обращатся за помощью в их супорт считаю бессмысленной тратой времени, они начнут лепить отмазы типа: у вас версия не самая последняя, доставайте базу из архива и т.п. - в общем - разведут гнилые базары на целый месяц, а реальной помощи не будет - это мы уже проходили. А если посмотреть на то, что через какой анус у них организована работа с SQL - уже станет плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 18:21:24 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
киньте структуру "больной" таблицы, попробую повторить у себя что-то типа pg_dump -s -t bad_table bad_db ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 18:37:18 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
авторselect * from problem_table выдает клиенту out of memory for query resultвот этого по идеи не должно быть... хм... -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:26:40 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Вот структура: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:28:39 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
скажите ещё пожалуйста, какое-то конкретное поле содержит большие блобы или оно размазано по всем полям bytea ? -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:35:29 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Возьмите конфиг по умолчанию постгреса используемой вами версии, перезагрузитесь и запустите дамп. Если снова не получится, перезагрузитесь и дампайте сначала все таблицы, кроме проблемной, а потом отдельно проблемную таблицу. О результатах отпишитесь. P.S. Перезагружаться под виндой обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:49:47 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. -- „Истина — это вовсе не то, что можно убедительно доказать, это то, что делает всё проще и понятнее“ — Антуан де Сент-Экзюпери ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:50:23 |
|
||
|
Не выполняется дамп
|
|||
|---|---|---|---|
|
#18+
MBGВозьмите конфиг по умолчанию постгреса используемой вами версии, перезагрузитесь и запустите дамп. Если снова не получится, перезагрузитесь и дампайте сначала все таблицы, кроме проблемной, а потом отдельно проблемную таблицу. О результатах отпишитесь. P.S. Перезагружаться под виндой обязательно.мне кажется бессмыслено мучить pg_dump если простой select * from problem_table выдает клиенту out of memory for query result... надо имхо сначала разобраться с этим. очень похоже на ошибку или повреждение базы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2008, 21:54:20 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=118&tid=1998281]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
78ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
82ms |
get tp. blocked users: |
2ms |
| others: | 232ms |
| total: | 447ms |

| 0 / 0 |
