|
|
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
эксперементируем с базой, и нам желательно все перезаписывать Не распарсил, Вы бэкапы удаляете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 14:38 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
автор я скриптами делаю фул бэкап на другой сервак и там восстанавливаю 2 раза в день. Таким образом при проблеме с основой - просто меняем ip адрес на бэкап сервере. И все. SERVICE_NAME - такой же. Проблема в том, что rman сильно тормозит работу с базой во время бэкапа. К тому же обеденного времени уже не хватает. Архив весит 500 гб. Вот думаю что можно сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 15:08 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
Почему я написал этот вопрос про SSD и RMAN. На днях посмотрел брошюрку https://www.oracle.com/webfolder/s/delivery_production/docs/FY16h1/doc26/6-Storage-Engineered-Systems.pdf В этих системах SSD используется как для read cashe так и для write cashe (на стр 17 Прогрессивный механизм кеширования). Я и подумал - Нельзя ли провести аналогию с FRA - которая суть кэш для формирования бэкапа. И соответственно ускорить бэкап. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 15:33 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
Дык инкрементально-обновляемый - это тот же бэкап, только изменения накатываются на предыдущие версии файлов(грубо), что из себя представляет полноценный бэкап Восстанавливаетесь с него, докатываете архивлоги и имеете БД Только по времени - обновление быстрее, чем полный бэкап Только один раз делаете долго, а потом "быстро" обновляете свой бэкап, с которого можете восстанавливаться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 15:34 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
авторДык инкрементально-обновляемый - это тот же бэкап, только изменения накатываются на предыдущие версии файлов(грубо), что из себя представляет полноценный бэкап Восстанавливаетесь с него, докатываете архивлоги и имеете БД Только по времени - обновление быстрее, чем полный бэкап Только один раз делаете долго, а потом "быстро" обновляете свой бэкап, с которого можете восстанавливаться Вот есть у меня основной сервер и сервер бэкапа, на котором я восстанавливаю базу. И сделал я бэкап уровень 0 в одну ночь, затем начал заливать кумулятивный уровень 1 на следующую. А следующим днем - программисты для тестирования поудаляли данные с бэкап сервера. Ночью я залил очередную порцию кумулятивного уровень 1 бэкапа с основного сервера. Вопрос - а на бэкап сервере перезатрутся данные, которые были сделаны на нем днем, данными, которые переброшены кумулятивным бэкапом с основного сервера? Сейчас, когда я переливаю полный бэкап и восстанавливаю его - все перезатирается авторconnect target / run{ #set dbid=311433411; crosscheck archivelog all; crosscheck backup; delete NOPROMPT archivelog all; delete NOPROMPT backup; catalog start with 'f:\backups' noprompt; startup force nomount; SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'F:\backups\cf_esdcontrol_%F'; RESTORE CONTROLFILE FROM autobackup; alter database mount; restore database; recover database; alter database open resetlogs; } exit ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 17:13 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
alex_lipУточняю - я делаю бэкап 2 раза в день. И делаю скриптом в шедулинге. Ночью и в обед. Ночью проблем нет. Про инкрементальный бэкап читал. Но дело в том, что мы иногда на втором(бэкап) сервере эксперементируем с базой, и нам желательно все перезаписывать. Кстати насколько я понимаю section size для фул бэкапа не работает. А никто не тестил как компрессия влияет на скорость работы, если на плате 2 процессора Xeon x5690 по 6 ядер(12 потоков) каждый ? Оперативки 48 гигов. А вы делаете несжатый бэкап ? В настройках rman опция не стоит? show all; ... CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET ; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 13:52 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
>>программисты для тестирования поудаляли данные с бэкап сервера Бэкап - это копия продуктивной БД с которого можно восстановиться Программисты удалили данные с инстанса, который восстановлен из бэкапа(инкрементальной копии БД) Если вы восстановите БД для программистов(которые поудаляли данные в своей БД/инстанса) из бэкапа(инкрементальной копии, которая у вас обновляется , например, раз в сутки) - то там будут данные как на продуктиве на момент создания бэкапа продуктива(инкрементально обновленной копии) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 14:29 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
С инкрементально- обновляемой копии вы можете: 1. восстановить БД и докатить логи, открыть БД(как с обычным бэкапом), дальше обновлять ваш бэкап и опять восстанавливать БД по требованию 2. Можете сразу создать контрольники, докатить логи и открыть с resetlogs - только в этом случае у вас бэкапа уже не будет(кстати - это один из способов перенести БД на другой сервер с минимальным downtime) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 14:39 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
alex_lip, Посмотрите в сторону Guaranteed Restore Points. Перед тем, как отдавать разработчикам, делаете GRP. Когда они наигрались, возвращаетесь на нее и накатываете инкрементальный бэкап / архивные логи. Rinse, repeat. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 17:43 |
|
||
|
Увеличение скорости работы RMAN
|
|||
|---|---|---|---|
|
#18+
Больше 600 Мбайт/с скорость бекапа мне получить не удалось., при том что тесты ввода вывода( фулсканами и добавлением датафалов ) показывают 2.4 Гбайт/с. Тоже самое происходит при ресторе стендбая из активной бд, больше 600 Мбайт/с не получается, хотя тесты показывают реальную пропускную способность сети 1.0Гбайт/с ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 19:40 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39397267&tid=1886513]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
160ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 493ms |

| 0 / 0 |
