Стендбай что это такое
СТЭНД-БАЙ
Смотреть что такое «СТЭНД-БАЙ» в других словарях:
Стэнд-бай — условия кредитного договора, в соответствии с которыми банк резервирует к установленному сроку оговоренную сумму, а клиент использует ее в зависимости от потребностей в кредите. По английски: Standby См. также: Кредитные соглашения Финансовый… … Финансовый словарь
СТЭНД-БАЙ — условие кредитного договора, в соответствии с которым банк резервирует к установленному сроку оговоренную сумму, а клиент использует ее частично или полностью в зависимости от потребностей в кредите … Энциклопедический словарь экономики и права
СТЭНД-БАЙ — условия кредитного договора (контракта), в соответствии с которым банк резервирует к установленному сроку оговоренную сумму, а клиент использует ее полностью или частично в зависимости от потребности в кредите … Большой экономический словарь
стэнд-бай — условия кредитного договора, в соответствии с которыми банк резервирует к установленному сроку оговоренную сумму, а клиент использует ее частично или полностью в зависимости от потребностей в кредите … Словарь экономических терминов
СТЭНД-БАЙ КРЕДИТ — условия кредитного договора, предоставляемого странами членами Международного валютного фонда на срок до одного года, в соответствии с которыми банк резервирует к установленному сроку оговоренную сумму, а клиент использует ее частично или… … Экономический словарь
Кредит стэнд-бай — (англ. Stand by credit) кредит, который с 1952 г. предоставляется странам членам МВФ для определенных, согласованных с МВФ целей на основе соглашений «стэнд бай». Банк резервирует к установленному сроку оговоренную сумму, а клиент … Википедия
Соглашение стэнд-бай — соглашение между МВФ и страной членом МВФ, согласно которому страна имеет право взять в долг у МВФ согласованное количество иностранной валюты для финансирования дефицита платежного баланса. По соглашению стэнд бай страна получает право… … Финансовый словарь
КРЕДИТ СТЭНД-БАЙ — вид кредита, который предоставляется странам членам Международного валютного фонда для определенных согласованных с МВФ целей на основе соглашений стэнд бай на срок до 12 месяцев (в отдельных случаях до 3 лет). По соглашению стэнд бай страна член … Большой экономический словарь
Кредит Стэнд-Бай — специальный кредит, предоставляемый государствам членам МВФ на согласованные проекты сроком до одного года. Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов
Режим ожидания Standby, или Держите аппаратуру включенной [перевод]
Вы замечали, что большинство кнопок «power» на передней панели оборудования на самом деле не включают и не выключают питание? Большинство из них — это кнопки режима ожидания «Standby» — они включают индикацию на передней панели и поддерживают устройства в режиме ожидания. Чаще всего это нужно, чтобы держать наготове достаточно схем для работы пульта дистанционного управления. Если вы совсем выключите питание, пульт ничего не сможет сделать.
Много лет назад все продукты оснащались механическими выключателями питания и кнопками на передней панели. Но только не устройства PS Audio. Мы были одной из первых компаний, встроивших функции режима ожидания в нашу продукцию. И это было задолго до того, как у кого-то появился пульт дистанционного управления. Некоторые из вас, возможно, помнят, что пульты ДУ в 1970-х годах были неуклюжими устройствами и использовались в основном для телевизоров. Я помню наш первый пульт — приходилось давить на переключатель каждой команды, чтобы заставить его работать. Усилие было необходимо, потому что пульт генерировал ультразвук, который воспринимал телевизор.
Нет, мы не добавили наш уникальный режим ожидания только для того, чтобы использовать пульт дистанционного управления. Мы сделали это, чтобы удостовериться, что наши продукты звучат лучше, несмотря на привычки наших покупателей.
Наши продукты стали одним из первых в отрасли, которые продавались с гарантией возврата денег (money back). Вспомните, это ведь было еще в 1973 году и никакое Hi-Fi-оборудование, которое я знаю, не имело такой гарантии. Это был смелый шаг, благодаря ему мы процветали (и процветаем сегодня). Из многих тысяч фоно-предусилителей, которые мы отгрузили, наверное, всего 10 или 20 вернули нам с возвратом денег. Один из них вернулся от человека, который был расстроен тем, что когда он подключал предусилитель-корректор в свою систему, его колонки, казалось, «исчезали». Он уже больше не мог закрыть глаза и точно указать пальцем на левый или правый канал; настолько явно они были слышны до появления нашего продукта. И он потребовал свои деньги назад. Мы с удовлетворение вернули ему деньги, в восторге от признания того, что наш тяжелый труд по приданию колонкам «невидимости» окупился.
Когда он вернул нам устройство, оказалось, что он перерезал шнур питания и вставил небольшой проходной выключатель. Это было довольно странно, поэтому мы позвонили ему и спросили, зачем он это сделал.
«Я не могу терпеть и смотреть, как этот свет все время горит». Мы уточнили, связана ли его ненависть с заботой об экономии энергии, на что он ответил: «Нет, просто я не могу видеть этот проклятый свет». Ночью в его системе все должно быть выключено. И он был не одинок в своих капризах — весьма распространенная жалоба тогда среди наших клиентов, они требовали спокойствия. Мы, с другой стороны, не могли вынести мысль, что люди регулярно выключают питание системы каждый вечер, только чтобы звук вновь оказался холодным и не захватывающим при очередном включении.
Я уверен, что вы понимаете, как это происходит. С этого дня каждый продукт PS Аудио, за исключением наших усилителей мощности, имеет кнопку на передней панели с надписью «Power». Но кнопка не выключает питание. Она лишь приглушает звук на выходах устройства и выключает все световые индикаторы на передней панели. А чтобы мы были счастливы, питание при этом оставалось включенным, и устройство всегда было готово выдать отличный звук.
В более поздних моделях мы почувствовали себя слегка виноватыми, называя эту кнопку «Power», и поменяли ее на «Input» (или «Off», которая делал то же самое).
К нам никогда не было претензий, и у нас было много клиентов, пораженных тем, что наши устройства всегда звучали идеально, даже когда они якобы были «холодными» (не прогретыми).
Мы просто улыбались в ответ и говорили спасибо.
Держите аппаратуру включенной
По поводу прогрева или приработки, чтобы аппарат зазвучал с течением времени лучше, не утихают споры, и мнения встречаются самые разные. Настолько разные, что порой они напоминают байки о том, что делают медведи в лесу, горят ли внутри холодильника лампочки, когда он выключен, или что происходит с деревьями, когда они падают.
Вот вам мое мнение: за небольшими исключениями, такими как ламповые устройства и усилители мощности, которые сильно греются, свободно оставляйте свое оборудование включенным в режиме 24 часа/7 дней в неделю. Для этого есть несколько причин.
Больше всего электроника страдает от процесса включения/выключения, чем от постоянной работы. Скачок напряжения, поступающий в технику, может иметь во много раз более разрушительные последствия, нежели вы оставите оборудование включенным в течение длительного периода времени. Более того, если вы не прожжете большую дыру в вашем бюджете платой за электричество, то расходы, связанные с этим, практически отсутствуют. Современное оборудование с каждым годом становится все более эффективным по потреблению в режиме ожидания или холостого хода. Новые европейские правила требуют потребления предельно низкого тока в режиме Standby, и большая часть оборудования не потребляет много энергии из розетки ни при каких обстоятельствах.
Это не относится к усилителям, работающим в классе А, ламповым приборам и всему, что производит много тепла, поскольку их эффективная долговечность заметно сокращается от перегрева конденсаторов и прочих болезней.
В то же время в пользу постоянного включения оборудования есть много аргументов. Никто не сможет убедить меня в том, что система, которая была включена и проработала в течение нескольких дней подряд, станет от этого звучать хуже, чем та, которая только что претерпела холодный запуск. Я бы осмелился предположить, что, если вы с этим не согласны, значит, вы действительно мало слушали аудиосистемы с высоким разрешением. Но я знаю, что некоторые люди в ответ сразу «ощетинятся всеми иголками», поэтому лучше промолчу.
Лучший совет, который я могу вам дать: держите аппаратуру включенной. Поддерживайте огонь в своем домашнем очаге.
Это самый простой путь к лучшему звуку.
Об авторе: Пол МакГоуэн (Paul McGowan) – директор (CEO) и сооснователь компании PS Audio Inc. из города Боулдер, Колорадо, конструирующей и выпускающей High End-аудио продукты и сервисы.
Стендбай что это такое
Откройте возможности нейронного машинного перевода PROMT
PROMT.One (www.translate.ru) – бесплатный онлайн-переводчик на основе нейронных сетей (NMT) для азербайджанского, английского, арабского, греческого, иврита, испанского, итальянского, казахского, китайского, корейского, немецкого, португальского, русского, татарского, турецкого, туркменского, узбекского, украинского, финского, французского, эстонского и японского языков.
Смотрите перевод слов и устойчивых выражений, транскрипцию и произношение в онлайн cловаре. Словари PROMT для английского, немецкого, французского, русского, испанского, итальянского и португальского языков включают миллионы слов и словосочетаний, самую современную разговорную лексику, которая постоянно отслеживается и пополняется нашими лингвистами.
Изучайте времена и формы глаголов в английском, немецком, испанском, французском и русском языках в разделе Спряжение и склонение. Учите употребление слов и выражений в разных Контекстах. Мы собрали для вас миллионы примеров перевода на разные языки, которые помогут вам в изучении иностранных языков и подготовке домашних заданий.
Еще раз про Oracle standby
Перед тем, как мы начнем, стоит немного сказать о тех принципах организации БД Oracle, которые понадобятся нам для понимания механизма работы резервного копирования и восстановления данных в СУБД Oracle.
Экземпляр БД Oracle содержит следующие виды файлов:
Управляющие файлы (Control files) — содержат служебную информацию о самой базе данных. Без них не могут быть открыты файлы данных и поэтому не может быть открыт доступ к информации базы данных.
Файлы данных (Data files) — содержат информацию базы данных.
Оперативные журналы (Redo logs) — содержат информацию о всех изменениях, произошедших в базе денных. Эта информация может быть использована для восстановления состояния базы при сбоях.
Существуют другие файлы, которые формально не входят в базу данных, но важны для успешной работы БД.
Файл параметров — используется для описания стартовой конфигурации экземпляра.
Файл паролей — позволяет пользователям удаленно подсоединяться к базе данных для выполнения административных задач.
Архивные журналы — содержат историю созданных экземпляром оперативных журнальных файлов (их автономные копии). Эти файлы позволяют восстановить базу данных. Используя их и резервы базы данных, можно восстановить потерянный файл данных.
Главная идея при создании standby экземпляра состоит в том, чтобы с помощью выполнения транзакций, сохраненных в оперативных или архивных журналах основной БД, поддерживать резервную БД в актуальном состоянии (такой механизм для Oracle называется Data Guard).
Отсюда следует первое требование к нашей основной базе — она должна быть запущена в archivelog mode.
Вторым требованием является наличие файла паролей. Это позволит удаленно подключаться к нашей БД в административном режиме.
Третье требование — это режим force logging. Этот режим нужен для принудительной записи транзакций в redo logs даже для операций, выполняемых с опцией NOLOGGING. Отсутствие этого режима может привести к тому, что на standby базе будут повреждены некоторые файлы данных, т.к. при «накатке» архивных журналов из них нельзя будет получить данные о транзакциях, выполненных с опцией NOLOGGING.
Также необходимо отметить, что если вы используете Oracle ниже 11g, то необходимо, чтобы сервера для основной базы и для standby имели одинаковую платформу. Т.е., если ваша основная база работает на Linux-сервере, то standby-сервер не может быть под управлением Windows.
Все примеры в этой статье будут ориентиваны на unix-системы, однако, их отличие от случая Windows-систем, в основном, состоит только в способе написания путей к файлам.
Не забываем также, что обмен данными между основным и standby серверами будет происходить по SQL-Net, поэтому необходимо, чтобы соединения на соответствующий порт (как правило, 1521 tcp) было открыто в обоих направлениях.
Будем считать, что наша база называется test. Мы будем так настраивать конфигурацию основной и standby базы, чтобы в любой момент мы могли поменять их роли местами (switchover). Мы планируем, что наша система будет использовать Data Guard protection mode, который называется MAXIMUM PERFORMANCE.
Итак, поехали.
Для начала поверяем соответствие нашей БД необходимым требованиям.
1. Смотрим, в каком режиме работает наша основная БД:
SQL> select name, open_mode, log_mode from v$database;
Если вы не видите значения ARCHIVELOG в поле LOG_MODE, выполняем следующие команды:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
2. Проверяем наличие файла паролей:
SQL> select * from v$pwfile_users;
Если вы не видите этот результат, создаем необходимый файл:
$ orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxxxxxxx force=y
Вместо ‘xxxxxxxx’ необходимо вставить текущий пароль пользователя SYS.
3. Включаем режим force logging:
SQL> alter database force logging;
Переходим к конфигурированию нашей системы. Для начала выполним необходимые настройки на основной базе. Будем сохранять все данные в каталоге /data/backup.
Создаем standby redo logs. Они нужны только на standby базе для записи данных, сохраняемых в redo logs на основной базе. На основной базе они нам понадобятся, когда мы будем переключать ее в режим standby и при этом использовать real-time apply redo. Файлы standby redo logs должны быть такого же размера как и online redo logs. Посмотреть размер online redo logs можно с помощью команды:
SQL> select bytes from v$log;
BYTES
———-
52428800
52428800
52428800
Смотрим, какие группы для redo logs есть в нашей базе:
SQL> select group# from v$logfile;
Создаем standby redo logs:
SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.
Создаем файл с параметрами нашего экземпляра (pfile). Мы будем учитывать, что наша основная база может быть переключена в режим standby, а это требует задания параметров, которые будут использоваться только в standby режиме.
SQL> create pfile=’/data/backup/pfilePROD.ora’ from spfile;
Нам необходимо добавить некоторые параметры в получившийся файл, если их там нет:
db_name=’test’ — это имя нашей базы (одинаковое для основного и standby экземпляра).
db_unique_name=’testprod’ — а это уникальное имя для каждого экземпляра, оно не будет изменяться при смене ролей со standby на production.
log_archive_config=’dg_config=(testprod,teststan)’ — определяем имена экземпляров, между которыми будет происходить обмен журналами.
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ – когда экземпляр является основной базой (PRIMARY_ROLE), мы будем передавать архивные журналы на standby сервер с помощью процесса LGWR. Параметр ASYNC указывает, что данные, сгенерированные транзакцией, не обязательно должны быть получены на standby до завершения транзакции – это не приведет к остановке основной базы, если нет связи со standby.
log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’ – здесь мы указываем каталог, куда будут локально сохранятся архивные журналы (для основной базы) или куда будут складываться пришедшие с основной базы журналы (для standby базы).
log_archive_dest_state_1=ENABLE – включаем запись архивных журналов в log_archive_dest_1. Пока мы не создали standby базу, этот параметр можно поставить в значение DEFER, если мы не хотим видеть лишние сообщения о недоступности standby базы в alert_log.
log_archive_dest_state_2=ENABLE – включаем запись архивных журналов в log_archive_dest_2.
fal_client=’testprod’ – этот параметр определяет, что когда экземпляр перейдет в режим standby, он будет являться клиентом для приема архивных журналов (fetch archive log).
fal_server=’teststan’ – определяет FAL (fetch archive log) сервер, с которого будет осуществляться передача архивных журналов. Параметры fal_client и fal_server работают только когда база запущена в standby режиме.
standby_file_management=’AUTO’ – задаем режим автоматического управления файлами в standby режиме. При таком значении параметра все создаваемые или удаляемые файлы основной базы будут автоматически создаваться или удаляться и на standby базе.
Если мы все-таки хотим разместить нашу standby базу в каталогах, отличных от тех, в которых размещена основная база, нам понадобятся дополнительные параметры:
db_file_name_convert=’/oradata_new/test’,’/oradata/test’ – этот параметр указывает, что в именах файлов данных, которые будут создаваться в standby базе (т.е. когда наш основной экземпляр начнет работать в режиме standby), необходимо изменить пути с ‘/oradata_new/test’ на ‘/oradata/test’.
log_file_name_convert=’/oradata_new/test/archive’,’/oradata/test/archive’ – этот параметр указывает, что в именах журнальных файлов, которые будут создаваться в standby базе, необходимо изменить пути с ‘/oradata_new/test/archive’ на ‘/oradata/test/archive’.
В итоге файл параметров для основной базы помимо всего прочего должен иметь следующие записи:
# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’testprod’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’testprod’
fal_server=’teststan’
standby_file_management=’AUTO’
Если есть такая возможность, перезапускаем основную базу с новыми параметрами и создаем новый spfile на основе переработанного нами pfile:
SQL> shutdown immediate;
SQL> startup nomount pfile=’/data/backup/pfilePROD.ora’;
SQL> create spfile from pfile=’/data/backup/pfilePROD.ora’;
SQL> shutdown immediate;
SQL> startup;
Если у нас нет возможности остановить основную базу на время наших манипуляций, то придется вносить изменения в текущую конфигурацию с помощью ALTER SYSTEM.
Тут надо учитывать, что нам не удастся сменить db_unique_name на работающей базе. Поэтому, нам придется в конфигурации использовать то имя, которое есть на данный момент. Посмотреть его можно с помощью команды:
Задаем необходимые параметры:
SQL> alter system set log_archive_config=’dg_config=(test,teststan)’;
System altered.
Задаем места для записи архивных журналов. На работающей базе мы не сможем поправить параметр log_archive_dest_1, если он задан. Поэтому только добавляем направление копирования в standby базу:
SQL> alter system set log_archive_dest_2=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=teststan’;
System altered.
SQL> alter system set log_archive_dest_state_2=ENABLE;
System altered.
SQL> alter system set FAL_SERVER=teststan;
System altered.
SQL> alter system set FAL_CLIENT=test;
System altered.
SQL> alter system set standby_file_management=’AUTO’;
System altered.
Добавляем в tnsnames.ora запись о standby базе:
TESTSTAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)
Пришло время создать backup-ы (если их нет). Для этого мы будем пользоваться утилитой rman.
Необходимо, чтобы место, где располагается бэкап, из которого мы будем разворачивать standby базу, было точно таким же, как и место, куда мы этот бэкап сохраняли. Т.е. если мы складываем бэкап в каталог ‘/data/backup’, то при восстановлении базы на standby-сервере rman будет искать данные бэкапа в таком же каталоге. Для решения этой задачи есть два очевидный пути: скопировать данные бэкапа с основного сервера на standby в точно такой же каталог, созданный там, или использовать для бэкапа сетевой ресурс, который одинаково монтируется на обоих серверах.
Запускаем rman на основном сервере:
$ rman target /
Создаем контрольный файл для standby базы:
RMAN> backup current controlfile for standby format ‘/data/backup/standbycontrol.ctl’;
Создаем бэкап нашей основной базы и архивных журналов:
RMAN> run
2> <
3> allocate channel c1 device type disk format ‘/data/backup/%u’;
4> backup database plus archivelog;
5> >
Здесь нас может поджидать неприятность, если по каким-то причинам у нас нет полного набора архивных журналов (например, они были удалены). Тогда rman выдаст ошибку:
RMAN-20242: Specification does not match any archivelog in the recovery catalog
Для исправления ситуации необходимо проверить и изменить статусы архивных журналов в репозитории rman. Для этого выполним следующую команду:
RMAN> change archivelog all crosscheck;
Если бэкап прошел успешно, копируем содержимое каталога /data/backup/ на standby сервер (если мы не использовали общий сетевой ресурс для бэкапа) и приступаем к созданию экземпляра на standby сервере.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = teststan)
(ORACLE_HOME = /oracle)
(SID_NAME = test)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)
Следует заметить, что параметр SID_NAME в данном случае чувствителен к регистру, т.к. listener будет искать файл паролей с именем orapw$SID_NAME.
Кстати, сейчас самое время скопировать файл паролей ($ORACLE_HOME/dbs/orapw$ORACLE_SID) с основного сервера на standby.
Нам также следует прописать нашу основную и standby базы в tnsnames.ora:
TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)
TESTPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))
)
(CONNECT_DATA =
(SID = test)
)
)
Т.к. подразумевается, что приложения «знают» нашу базу под именем test, то и для standby базы мы задаем SID test.
Не забываем перестартовать listener:
$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start
Также нам необходимо создать на основе файлов параметров основной базы файл параметров для standby. Для этого перепишем на standby сервер файл pfilePROD.ora, переименовав его в pfileSTAN.ora, и внесем необходимые исправления в ту его часть, которую мы редактировали ранее:
# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’teststan’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’testprod’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’teststan’
fal_server=’testprod’
standby_file_management=’AUTO’
При размещении standby базы в других каталогах также добавляем необходимые параметры:
Пришло время стартовать standby экземпляр базы:
SQL> startup nomount pfile=’/data/backup/pfileSTAN.ora’;
SQL> create spfile from pfile=’/data/backup/pfileSTAN.ora’;
SQL> shutdown immediate;
SQL> startup nomount;
Разворачиваем standby базу из бэкапа. Для этого переходим на основной сервер и запускаем rman.
Подключаемся к будущей standby базе и выполняем дуплицирование (мы помним, что бэкап данных и контрольный файл у нас лежат в каталоге, который и с основного сервера и со standby виден как /data/backup):
RMAN> connect auxiliary sys@teststan
RMAN> duplicate target database for standby nofilenamecheck dorecover;
Параметр nofilenamecheck нам нужен, чтобы rman не ругался на повторяющиеся имена файлов (если мы используем одинаковую структуру каталогов на основном и standby серверах).
Если все прошло успешно, то переводим систему в режим автоматического применения транзакций на standby базе.
Переключаем журнальный файл и смотрим последний номер архивного журнала на основной базе:
SQL> alter system switch logfile;
System altered.
SQL> select max(sequence#) from v$archived_log;
Теперь переходим на standby сервер.
Проверяем состояние базы:
SQL> select name,open_mode,log_mode from v$database;
SQL> select max(sequence#) from v$log_history;
Мы видим, что последний примененный лог на standby отстает от основной базы, а также, что процессы ARCH не работают.
Проверяем наличие standby redo logs:
SQL> select * from v$standby_log;
Если их нет – создаем:
SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.
SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.
Переводим нашу standby базу в режим Real-time apply redo:
SQL> alter database recover managed standby database using current logfile disconnect;
Смотрим, что получилось:
SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
————————
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
SQL> select max(sequence#) from v$log_history;
Как видим, все работает.
Если мы не хотим использовать режим Real-time apply redo, а хотим дожидаться когда будет закончено формирование очередного архивного журнала на основном сервере и он будет передан на standby для применения сохраненных в нем транзакций, то нам необходимо переводить нашу standby базу в режим redo apply командой:
SQL> alter database recover managed standby database disconnect;
Если что-то пошло не так, то для решения проблемы в первую очередь необходимо остановить «накатку» логов:
SQL> alter database recover managed standby database cancel;
Возможно, что в процессе дуплицирования на standby сервер были переданы не все архивные журналы. Тогда их надо вручную скопировать на standby сервер (в нашем случае в каталог /oradata/test/archive), произвести ручную «накатку»:
SQL> recover standby database;
и после этого опять запустить режим Real-time apply redo:
SQL> alter database recover managed standby database using current logfile disconnect;
Процессы переключения ролей между экземплярами (switchover) и перевода standby базы в режим primary в случае падения основной базы (failover) имеют множество своих подводных камней, поэтому это тема отдельной статьи.