Увеличится ли скорость бэкапирования базы если FRA разместить на SSD ?

авторМожет у него один из файлов огромный, и время выполнения backup определяется только им

База данных в основном состоит из BLOB с документами(сканы, word, exel и т.д.)
Сам скрипт простой



общий размер бэкапа 500 Гб. В принципе можно попробовать на SSD часть базы перенести.

А если Бэкап делать на SSD ? Места хватит.

Спасибо.

Диски разные. Блобы на одном, обычные данные на другом, бэкап на третьем.

авторесли задача бэстро сделать бэкап - посмотрите в эту сторону
http://www.oracle.com/technetwork/database/availability/vldb-br-128948.pdf

Спасибо за гайд!
На самом деле все от бедности и отсутствия специалистов. Я понимаю, что идеальный вариант - стенд-бай - но чтобы его переключить в примари нужно хоть что-то понимать в oracle. А я единственный в этой конторе, который чуть чуть знает Oracle. Поэтому я скриптами делаю фул бэкап на другой сервак и там восстанавливаю в ноль 2 раза в день. Таким образом при проблеме с основой - просто меняем ip адрес на бэкап сервере. И все. SERVICE_NAME - такой же. Проблема в том, что rman сильно тормозит работу с базой во время бэкапа. К тому же обеденного времени уже не хватает. Архив весит 500 гб. Вот думаю что можно сделать.

Уточняю - я делаю бэкап 2 раза в день. И делаю скриптом в шедулинге. Ночью и в обед. Ночью проблем нет. Про инкрементальный бэкап читал. Но дело в том, что мы иногда на втором(бэкап) сервере эксперементируем с базой, и нам желательно все перезаписывать. Кстати насколько я понимаю section size для фул бэкапа не работает.
А никто не тестил как компрессия влияет на скорость работы, если на плате 2 процессора Xeon x5690 по 6 ядер(12 потоков) каждый ? Оперативки 48 гигов.

авторЕсли тормозит чтение базы, то увеличение скорости записи не поможет и SSD будет бесполезен. В документации есть рекомендации по оценке скорости чтения: http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmtunin.htm#BRADV89858 (запуск backup validate будет делать чтения без записи и по времени можно оценить пропускную способность)

Спасибо. Проверю.

автор я скриптами делаю фул бэкап на другой сервак и там восстанавливаю 2 раза в день. Таким образом при проблеме с основой - просто меняем ip адрес на бэкап сервере. И все. SERVICE_NAME - такой же. Проблема в том, что rman сильно тормозит работу с базой во время бэкапа. К тому же обеденного времени уже не хватает. Архив весит 500 гб. Вот думаю что можно сделать.

Почему я написал этот вопрос про 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 - которая суть кэш для формирования бэкапа. И соответственно ускорить бэкап.

авторДык инкрементально-обновляемый - это тот же бэкап, только изменения накатываются
на предыдущие версии файлов(грубо), что из себя представляет полноценный бэкап
Восстанавливаетесь с него, докатываете архивлоги и имеете БД
Только по времени - обновление быстрее, чем полный бэкап
Только один раз делаете долго, а потом "быстро" обновляете свой бэкап, с которого можете восстанавливаться

Вот есть у меня основной сервер и сервер бэкапа, на котором я восстанавливаю базу.
И сделал я бэкап уровень 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