Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Имеется сервер SCO unix openserver 5.0.5 + Informix Dynamic Server Version 7.31.UC2 несколько баз данных размер которых постоянно растет. Как я понял на файловой системе стоит ограничение на размер файлов 2гб. То есть, если таблица (dbexport) будет выгружена в текстовый формат и размер файла *.unl будет больше этого предела - экспорт не пройдет:-(. onbar и ontape тоже столкнутся с этими проблемами? Может как то возможно при резервном копировании разбивать файл бэкапа частями по 2 гб? Или имеет смысл переходить на другую платформу? посоветуйте что-нибудь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 12:44 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
с бэкапом через ontape у вас проблем не будет с любым объемом данных. dbexport для бэкапа вообще лучше не использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 14:03 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
разумеется если вы ontape как положено на ленту делаете :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 14:06 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Рекомендую почитать следующие ветки из форумов: http://groups.google.com/groups?hl=en&lr=lang_en|lang_ru&ie=UTF-8&th=9b4568e6cfd85e51&rnum=1 http://groups.google.com/groups?hl=en&lr=lang_en|lang_ru&ie=UTF-8&th=5d07b577415cefef&rnum=1 http://groups.google.com/groups?hl=en&lr=lang_en|lang_ru&ie=UTF-8&th=1e05dc227b1e5c16&rnum=1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 14:26 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
А вот ленты нет, нет ни ленточной библиотеки, нет ни стриммера. Есть только файловая система:-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 15:04 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
man ulimit ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.06.2004, 16:32 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Да не получится наверное - вот что написано в документации SCO к операционной системе: If you need to use files larger than 1GB on an SCO OpenServer system, change the definition of ULIMIT from ``2097151'' to a value of up to ``4194303'' in the two configuration files where it is defined. The system-wide limit defined by the Link Kit is in /etc/conf/cf.d/config.h, and the limit imposed by login(M) is defined in /etc/default/login. The maximum size supported is 2GB. http://osr5doc.sco.com:1997/FEATS/RNlimFileSize.html Наверное один выход - менять платформу..... Может кто -то еще что-то подскажет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2004, 09:24 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
По поводу onbar-ontape. Они поддерживают многотомные архивы, так что никакой проблемы нет. На счет dbexport, его проблему можно отодвинуть раз в 10 с помощью сжатия бекапируемых данных. http://groups.google.com/groups?hl=uk&lr=&ie=UTF-8&th=2b4fbbfbbddf3b4a&rnum=3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2004, 10:39 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Да, многотомный архив от ontape в файл - вот и выход, а насчет сжатия - так ведь для восстановления данные разжимать надо. Кстати, вывод от ontape тоже можно сжимать на лету - tapedev назначить на именованный pipe, на вход которого посадить tar-gzip. Если кто интересуется, есть рабочий backup-скрипт на основе скриптов из IIUG, который архивирует как БД, так и журналы транзакций по мере их заполнения в качестве ALARMPROGRAM, вроде удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.06.2004, 22:50 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Можно посмотреть скрипт? kirill110@rambler.ru Буду очень благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2004, 06:48 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
Вот еще способ - использовать unload из dbaccess. Это спасет, т.е. можно сделать так: unload to 'file1.unl' select * from bigtable where id<=NNN1 unload to 'file2.unl' select * from bigtable where id>NNN1 and id<=NNN2 unload to 'file3.unl' select * from bigtable where id>NNN2 and id<=max(id) Таким образом будет выгружена таблица в несколько файлов. За мир во всем Мире! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2004, 09:49 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
А еще можно использовать команду split, которая разделит входящий поток на несколько файлов заданного размера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2004, 15:35 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
В свое время столкнулся с той же проблемой 2Gb. Правда, backup (помимо архива 0-го уровня на ленту) делал в файл onunload'ом... ulimit рапортовал о том, что типа ограничений никаких нету. Так вот, вывод onunload перенаправлялся в именнованный канал (как уже писал Julian), на котором его ожидал compress... в результате получался сжатый файл архива нужной мне базы. Количество получаемых файлов = количеству выгружаемых баз. Операция восстановления из такого файла достаточно очевидна, проблема была решена, т.к. в моем случае пока не предвидится раздутия самого запакованного файла до 2 Gb, хотя и это решаемо. Процесс выгрузки/загрузки базы получился достаточно быстрым благодаря распараллеливанию собственно выгрузки и сжатия. Ув. Kirill Cherkasov, если заинтересовало, могу выслать рабочие скрипты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2004, 17:15 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
В свое время столкнулся с той же проблемой 2Gb. Правда, backup (помимо архива 0-го уровня на ленту) делал в файл onunload'ом... ulimit рапортовал о том, что типа ограничений никаких нету. Так вот, вывод onunload перенаправлялся в именнованный канал (как уже писал Julian), на котором его ожидал compress... в результате получался сжатый файл архива нужной мне базы. Количество получаемых файлов = количеству выгружаемых баз. Операция восстановления из такого файла достаточно очевидна, проблема была решена, т.к. в моем случае пока не предвидится раздутия самого запакованного файла до 2 Gb, хотя и это решаемо. Процесс выгрузки/загрузки базы получился достаточно быстрым благодаря распараллеливанию собственно выгрузки и сжатия. Ув. Kirill Cherkasov, если заинтересовало, могу выслать рабочие скрипты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2004, 17:17 |
|
||
|
Как поступить с backup?
|
|||
|---|---|---|---|
|
#18+
roos если можно вышли на kirill110@rambler.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2004, 06:25 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=32587712&tid=1609242]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 161ms |

| 0 / 0 |
