Rman service что это

rutserv.exe — что это за процесс и как удалить? (RManService)

Приветствую друзья! Мы продолжаем разбираться с неизвестными процессами. Сегодня к нам попал rutserv.exe — постараемся узнать что это, насколько опасный, а также можно ли его удалить.

rutserv.exe — что это такое?

Процесс от ПО Remote Manipulator System (RMS) для удаленного управления компьютером. Данное ПО также используется для создания вируса Program.RemoteAdmin.684.

Также может быть служба TektonIT — RMS Host (RMANService), которой судя по всему и принадлежит процесс rutserv.exe:

Суть: rutserv.exe это может быть спокойно вирус удаленного управления, который построен на легальном ПО (аналог TeamViewer), поэтому антивирусы могут не видеть угрозы.

Процесс может запускаться из папки:

C:\Program Files (x86)\Remote Manipulator System — Server\

C:\Program Files (x86)\Remote Utilities — Host

Однако возможно это имеет отношение к обычной версии Remote Manipulator System, не вирусной. Потому что если вирусная модификация, то процессы могут запускать из этих папок:

Сразу видно — специально, чтобы пользователь подумал что это системные файлы. Кроме этого — служба процесса тоже может быть замаскирована и иметь отображаемое название — Quality Windows Audio Video Experience Devices.

Кроме rutserv.exe у вас также может быть и rfusclient.exe, это все одна компашка.

Что еще интересно — может маскироваться даже под некую утилиту обновления драйверов (при этом значок Realtek):

Данное окошко — запрос от встроенного фаервола Windows, который контролирует сетевую активность программ. Простыми словами фаервол сообщает что процесс rutserv.exe хочет установить соединение с интернетом.

rutserv.exe — вирус?

Получается не вирус, а легальное ПО. Но которое может использоваться для удаленного доступа к компьютеру без согласия пользователя.

Однако если использовать легальное ПО в таких незаконных целях — то это будет расцениваться как вирус.

Само по себе Remote Manipulator System (RMS) — не вирус, а программа для удаленного управления ПК. Например чтобы помочь кому-то через интернет или получить доступ к своему же ПК. Аналоги — TeamViewer, AnyDesk.

rutserv.exe — как удалить вирус?

Данный вирус присутствует в базе Dr.Web под названием Program.RemoteAdmin.684, а это говорит о том, что их утилита спокойно справиться с удалением вируса.

Если посмотреть страницу вируса с описанием, то все становится очевидно:

rutserv.exe — явно может быть вирусом, если только вы сами лично не ставили себе ПО для удаленного управления ПК. Про вирус можете почитать здесь.

План действий — проверяем ПК не только утилитой от Доктора Веба, но и еще двумя лучшими утилитами:

1. Dr.Web CureIt! — мощный инструмент против опасных вирусов типа троянов, ботнетов, майнеров. Скачивается уже с антивирусными базами, поэтому может весить примерно 100 мб. Длительность проверки может зависеть от количества файлов на диске. По окончании требует перезагрузку. Скачиваем утилиту здесь.
2. AdwCleaner — утилита против рекламного и шпионского ПО, проверяет реестр, планировщик задач, браузер и его расширения, ярлыки, автозагрузку. Перед сканированием загружает антивирусные базы. Скачать можно тут.
3. HitmanPro — похожа на AdwCleaner, принцип работы одинаков, только использует более тщательное сканирование. Может находить угрозы даже в куки-файлах. Работает быстро. Качаем здесь.

Важно! Если у вас нет нормального антивируса, тогда советую поставить бесплатную версию Каспера, а именно Kaspersky Free — базы обновляет, вирусы находит, ПК не грузит (было время тестировал).

Ручное удаление

Внимание! Пере ручным удалением создаем точку восстановления!

Способ нашел на форуме Virusinfo:

1. Останавливаем службу TektonIT R-Server. Зажмите Win + R, появится окошко Выполнить, вставляем команду services.msc и нажимаем ОК. Находим службу > нажимаем два раза > в Тип запуска выставляем Отключена, а потом нажимаем кнопку Остановить.
2. Удаляем данные в реестре. Открываем реестр: Win + R > команда regedit. Удаляем папку RManService в этих разделах реестра: HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services , HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services , HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Также удаляем папку Remote Manipulator System в разделе HKLM\SYSTEM
3. Необязательно. При наличии папки C:\Windows\SysWOW64\vipcatalog — удаляем ее полностью (vipcatalog). Если будут проблемы с удалением vipcatalog, тогда используйте Unlocker. Возможно что без удаления можно обойтись, но если папка есть, то советую ее все таки удалить.
4. Выполняем перезагрузку.
5. Удалить вручную остатки вируса. Среди файлов — зажимаем Win + E, выбираем Мой компьютер, потом в левом верхнем углу будет текстовое поле поиска — пишем туда rutserv и ищем остатки. В реестре: зажимаем Win + R > команда regedit > зажимаем Ctrl + F > вставляем в поле rutserv и нажимаем Найти далее. Когда нашлось — удаляем и продолжаем поиск кнопкой F3, пока не будет сообщение что поиск закончен.

Важно! Искать остатки можно не только по слову rutserv, но и по rfusclient, Remote Manipulator System, RMANService, TektonIT. Но смотрите внимательно что удаляете!

Еще раз про Oracle standby

Представим себе ситуацию, когда наш проект, использующий в качестве СУБД Oracle, неожиданно (или с надеждой ожидаемо) стал критически важным для бизнеса (соответственно, появилась готовность выделять средства на обеспечение надежности системы).
До этого момента мы вполне обходились ежедневным или даже еженедельным бэкапом («горячим» или «холодным» копированием, а может и просто экспортом данных) и нас устраивало время восстановления системы порядка суток (будем считать, что данных у нас на пару терабайт).
И вот оказалось, что на восстановление системы нам отводится не более часа, и никакие данные нам терять нельзя.
Итак, все указывает на то, что нам придется поднимать standby сервер.
В принципе, большая часть из того, о чем говорится в этой статье, описано в «Oracle Data Guard Concepts and Administartion», а также в куче мест на просторах Сети, но, по большей части, это инструкции, содержащие последовательность команд, без особого описания их смысла и, главное, без рекомендаций, что делать, если что-то идет не так.
Я постараюсь описать процесс развертывания физической standby базы максимально подробно с указанием тех грабель на которые когда-либо натыкался.
Указание на случайно не обнаруженные мной проблемы, а также любые уточнения и дополнения всячески приветствуются.

В дальнейшем, когда в тексте будут приводиться примеры команд и запросов, я буду использовать следующие обозначения:
$ — команда вводится в командной строке операционной системы под пользователем oracle.
SQL> — команда вводится в sqlplus. В этой статье везде, где это не определено явно, подразумевается, что sqlplus запущен в административном режиме (sqlplus / as sysdba), а экземпляр базы задан через переменную $ORACLE_SID.
RMAN> — команда вводится в rman. Здесь также, если явно не определено что-то другое, подразумевается, что rman запущен командой rman target /, а экземпляр базы задан через переменную $ORACLE_SID.

Перед тем, как мы начнем, стоит немного сказать о тех принципах организации БД 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;

NAME OPEN_MODE LOG_MODE
——— ———- ————
TEST READ WRITE ARCHIVELOG

Если вы не видите значения 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 /

Интересный момент для случая, когда Oracle установлен на Linux. Если у вас установлен пакет PolyglotMan (RosettaMan), то при попытке выполнить
$ rman target /
может возникнуть ошибка:
rman: can’t open target
Эта ситуация возникает в случае, если путь до исполняемого файла rman этого пакета — (например, /usr/X11R6/bin/rman) в переменной окружения $PATH располагается раньше, чем путь до ораклового rman. Т.е. мы пытаемся запустить rman из пакета PolyglotMan и передать ему в качестве параметра файл 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 сервере.

Для начала нам необходимо установить Oracle на standby-сервере без создания экземпляра БД. Для облегчения дальнейшей жизни пути к $ORACLE_HOME на standby-сервере должны быть такими же, как и на основном. Также устанавливаем все патчи, которые были установлены на основном сервере, для полного соответствия версий Oracle.
Создаем конфигурацию listener-а и net service names.
Так как для разворачивания копии основной базы на standby сервере мы будем использовать rman, запущенный на боевом сервере, а при этом standby экземпляр базы у нас будет находится в nomount режиме, то нам необходимо явно прописать сервис в listener.ora, иначе все попытки подключиться из rman к будущему standby как к auxiliary будут блокироваться.
В итоге listener.ora должен выглядеть приблизительно так:

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

Теперь создаем структуру каталогов для нашей базы. Тут важно не забыть, что нужно создать все каталоги для хранения файлов данных и журналов, а также каталоги adump, bdump, cdump, dpdump, udump, располагающиеся обычно в $ORACLE_HOME/admin/$ORACLE_SID.
Если вы не хотите сохранять на standby структуру каталогов основной базы, то необходимо создать каталоги в соответствии со значениями параметров db_file_name_convert и log_file_name_convert.

Также нам необходимо создать на основе файлов параметров основной базы файл параметров для 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;

NAME OPEN_MODE LOG_MODE
——— ———- ————
TEST MOUNTED ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;

11 rows selected.

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

11 rows selected.

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) имеют множество своих подводных камней, поэтому это тема отдельной статьи.

Rman service что это

Владимир Пржиялковский,
координатор Евро-Азиатской Группы Пользователей Oracle,
преподаватель УКЦ Interface Ltd.

• Введение
• Возможности RMAN
• Пример копирования и восстановления базы данных
  • Упрощения в версии 9

  Введение

  Программа RMAN появилась в версии 8 СУБД Oracle как единое для всех платформ средство организации резервного копирования и восстановления данных на физическом уровне. По отношению к традиционным базовым возможностям резервирования и восстановления в Oracle, у программы RMAN есть некоторые преимущества, делающие ее в некоторых ситуациях (например, при больших объемах данных) практически незаменимой. К сожалению, наличие этих преимуществ не лишает RMAN и ряда существенных недостатков: собственной системы понятий, собственного командного языка и интерфейса общения с администратором. И то, и другое, и третье выполнено в плохих традициях разработчиков Oracle – не вполне логично, запутано и непоследовательно, – что затрудняет освоение этой программы. Назначение этой статьи – помочь перешагнуть через эти недостатки ради выгод, которые можно извлечь из RMAN.

  Возможности RMAN

  Возможности RMAN включают следующее:

  —	выполнение полного резервирования и резервирования изменений
  —	выполнение холодного/горячего резервирования, причем во втором случае табличные пространства не переводятся в режим backup, что позволяет избежать дополнительной нагрузки на журнал
  —	обнаружение поврежденных блоков
  —	параллельное выполнения операций ввода/вывода
  —	автоматическое протоколирование операций копирования и восстановления

  Уровни выполнения резервного копирования/восстановления с помощью RMAN:

  • база данных
  • табличные пространства
  • файлы табличных пространств
  • служебные файлы БД (контрольные, архивные)

  В число основных понятий RMAN входят следующие:

  —	Канал (channel). Серверный процесс, возникающий при установлении связи с устройством ввода/вывода (диск или магнитная лента) для записи или чтения файлов резервирования
  —	Целевая БД (target database). БД, для которой снимается резервная копия, или которая восстанавливается по ранее снятой копии
  —	Каталог (recovery catalog). Отдельная схема в БД (чаще в отдельной БД), которую можно заводить для хранения служебная информации о целевых базах, снятых копиях и процедурах восстановления. Альтернативой каталогу является индивидуальная работа с каждой целевой БД, когда служебная информация помещается в контрольный файл этой БД.
  —	Копия (RMAN backup). Резервная копия какого-нибудь элемента БД, получаемая командой RMAN backup.
  —	Резервный набор (backup set). Логически именует набор файлов, сформированных во время резервного копирования.
  —	Резервный файл (backup piece). Двоичный файл с резервной информацией.

  Синтаксис командного языка RMAN в версии 9 имеет определенные отличия от версии 8, но все основные конструкции сохранены. Кроме этого, в RMAN для версии 9 допускается целый ряд упрощений записи команд.

  Возможность работы с RMAN включена также в последние версии OEM без необходимости знания командного языка.

  В тексте ниже для лаконичности предпочтение будет отдаваться синтаксису версии 9. Кроме этого для простоты рассматривается работа без каталога RMAN.

  Пример копирования и восстановления базы данных

  Простейший пример снятия резервной копии (холодное копирование – вся БД – работа без каталога) иллюстрируется следующей последовательностью команд (здесь команда CONNECT TARGET соединяет RMAN с СУБД версии 8):

  RMAN NOCATALOG
  RMAN> CONNECT TARGET internal/oracle
  RMAN> SHUTDOWN IMMEDIATE
  RMAN> STARTUP MOUNT
  RMAN> RUN <
  2> ALLOCATE CHANNEL d1 TYPE DISK;
  3> BACKUP FULL FORMAT ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus’
  4> DATABASE;
  4> >
  RMAN>

  В каталоге D:\ORACLE\ORADATA\TEACHER\RMAN-BACKUP появился файл RMAN_ TEACHER _02DGA6F0_1_1.BUS (реальное имя может варьироваться). Теперь можно удалить файлы с табличными пространствами и выполнить восстановление:

  RMAN> RUN <
  2> ALLOCATE CHANNEL d1 TYPE DISK;
  3> RESTORE DATABASE;
  4> RECOVER DATABASE;
  5> ALTER DATABASE OPEN;
  6> >

  База восстановлена и открыта.

  Упрощения в версии 9

  В версии RMAN для версии 9 описанное выше резервирование можно было бы выполнить так:

  RMAN> BACKUP DATABASE FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus’;

  а восстановление так:

  RMAN> RESTORE DATABASE;
  RMAN> RECOVER DATABASE;
  RMAN> ALTER DATABASE OPEN;

  Здесь подразумевается использование неявного канала по умолчанию, так что объявлять его стало необязательно.

  Кроме этого в версии 9 появилась команда CONFIGURE, с помощью которой (помимо прочего) можно связать с каналом направление и маску имени файлов для резервного набора:

  RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%U.bus’;

  В этом случае команда снятия резервной копии может выглядеть еще проще:

  RMAN> BACKUP DATABASE;

  Резервирование файлов базы данных

  Горячее полное резервирование БД

  —	может выполняться в состоянии СУБД OPEN
  —	может выполняться только при включенном режиме архивирования журналов

  Если выполнено и то, и другое, сами действия по резервированию выглядят как обычно. Пример в синтаксисе версии 9.0:

  RMAN> BACKUP DATABASE FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus’;

  Полное резервирование табличного пространства

  Пример в синтаксисе версии 9.0:

  RMAN> BACKUP TABLESPACE system, users FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus’;

  Полное резервирование отдельных файлов табличного пространства

  Пример в синтаксисе версии 9.0:

  RMAN> BACKUP DATAFILE 1, 2;

  RMAN> BACKUP FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%d_%t_%U.bus’
  3> ‘d:\oracle\oradata\teacher\system01.dbf’,
  4> ‘d:\oracle\oradata\teacher\users01.dbf’;

  Резервирование временного табличного пространства

  Если временное табличное пространство локально управляемо, оно автоматически не резервируется. Восстанавливать (воссоздавать) при необходимости его придется самостоятельно.

  Резервирование контрольного файла

  Обычное резервирование контрольного файла приходится выполнять отдельно. Пример явного резервирования в синтаксисе версии 9.0:

  RMAN> BACKUP CURRENT CONTROLFILE;

  В версии 9 можно, однако, перевести RMAN в режим, когда копии контрольного файла будут сниматься автоматически при всякой выдаче команд BACKUP или COPY:

  RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

  Резервирование оперативных файлов журнала

  Оперативные (онлайновые) файлы журнала автоматически не резервируются. Для сохранения либо следует их

  а) копировать отдельно, либо
  б) перед полным резервированием БД отправлять в архив.

  Резервирование архивных копий журнала

  Файлы архивных копий журнала резервируются всегда в отдельные от прочих файлы резервного набора и в общем случае их нужно резервировать отдельной командой. Пример в синтаксисе версии 9.0:

  RMAN> BACKUP ARCHIVELOG ALL;

  Пример того, как в версии 9.0 архивные файлы можно включить в состав резервного набора БД:

  RMAN> BACKUP DATABASE FORMAT
  2> ‘d:\oracle\oradata\teacher\rman-backup\rman_%U.bus’ PLUS ARCHIVELOG;

  Резервирование изменений (неполное резервирование)

  Для резервирования изменений в Oracle используется традиционная многоуровневая модель с конкретным числом уровней копии 5 (от 0 до 4). Точкой отсчета для копирования изменений обязана стать снятая ранее полная копия БД уровня 0.

  Пример резервирования блоков, изменившихся со времени резервирования на уровнях 3, 2, 1 и 0 (разностное, «дифференциального» резервирование) в синтаксисе версии 9:

  RMAN> BACKUP INCREMENTAL LEVEL 3 DATABASE;

  Пример резервирования блоков, изменившихся со времени последнего резервирования на уровнях 2, 1 и 0 (разностно-накопительное, «кумулятивное» резервирование) с пропуском табличных пространств, закрытых для записи (синтаксис версии 9):

  RMAN> BACKUP INCREMENTAL LEVEL 3 CUMULATIVE DATABASE
  2> SKIP READONLY;

  Разностно-накопительное (кумулятивное) резервирование уровня N отличается от разностного (дифференциального) тем, что резервирует изменения произошедшие после выполнения резервирования всех уровней < N, в то время как просто разностное – изменения, произошедшие после резервирования уровней <= N.

  Выдача справочной информации

  Выполняется специальными командами LIST и REPORT, а также разновидностью команды RESTORE. Примеры приводятся ниже.

  Выдача подробного списка всех снятых копий:

  RMAN> LIST BACKUP;

  Выдача списка резервных наборов, содержащих табличное пространство SYSTEM:

  RMAN> LIST BACKUP OF TABLESPACE system;

  Вариант выдачи того же самого, но в обобщенном виде (версия 9):

  RMAN> LIST BACKUP OF TABLESPACE system SUMMARY;

  Выдача информации о копиях, снятых с архивов журналов:

  RMAN> LIST BACKUP OF ARCHIVELOG ALL;

  Выдача резервных копий, оказавшихся устаревшими:

  RMAN> REPORT OBSOLETE;

  Выдача файлов с данными БД, для восстановления которых потребуются архивы журналов 2-х дневной давности и более:

  RMAN> REPORT NEED BACKUP DAYS 2 DATABASE;

  Те же сведения, но только для пространства SYSTEM:

  RMAN> REPORT NEED BACKUP DAYS 2 TABLESPACE system;

  Выдача информации о том, годны ли файлы резервного набора для восстановления:

  Удаление резервных копий

  Выполняется командой DELETE. В простейшем варианте удаление устаревших копий может выглядеть так:

  RMAN> DELETE OBSOLETE;

  Обратите внимание, что RMAN удалил ненужные файлы резервных наборов. Вам не нужно автоматизировать удаление старых файлов, как раньше!

  Файлы резервных наборов могут оказаться испорченными или поврежденными. Это можно отметить в справочнике (в контрольном файле или в каталоге RMAN) с помощью команды CROSSCHECK, в результате чего они будут помечены там как EXPIRED. Последующая команда DELETE EXPIRED удалит ставшие ненужными из-за этого файлы:

  RMAN> CROSSCHECK BACKUP;
  …
  RMAN> DELETE EXPIRED BACKUP OF DATABASE;
  …
  RMAN> DELETE BACKUP OF DATABASE;

  Более сложный пример удаления устаревших резервных копий:

  RMAN> DELETE OBSOLETE RECOVERY WINDOW OF 14 DAYS;

  Восстановление данных

  NOMOUNT: для восстановления контрольных файлов БД (фактически – СУБД)

  MOUNT: для восстановления БД целиком или табличного пространства SYSTEM

  OPEN: для восстановление табличных пространств, помимо SYSTEM (в этом случае перед процедурой восстановления само табличное пространство потребуется перевести в состояние OFFLINE).

  Восстановление до момента сбоя («последнего момента»)

  Некоторые примеры восстановления:

  RMAN> RECOVER DATABASE;

  RMAN> RECOVER TABLESPACE users;

  RMAN> RECOVER DATAFILE ‘d:\oracle\oradata\teacher\users01.dbf’;

  RMAN> RESTORE CONTROLFILE;

  RMAN> RUN <
  2> SET ARCHIVELOG DESTINATION TO ‘d:\oracle\oradata\archive’;
  3> RESTORE ARCHIVELOG ALL; >

  Восстановление пространств, закрытых на запись:

  RMAN> SQL "ALTER TABLESPACE lookup_data OFFLINE";
  RMAN> RECOVER TABLESPACE lookup_data;
  RMAN> SQL "ALTER TABLESPACE lookup_data ONLINE";

  Восстановление до указанного момента в прошлом

  БД, работающую в режиме архивирования журнала, можно восстанавливать до определенного указанного момента с помощью фраз UNTIL . Пример:

  RMAN> RESTORE DATABASE; # восстановили файлы
  RMAN> RECOVER DATABASE UNTIL SCN 375831; # восстановили БД
  RMAN> ALTER DATABASE OPEN RESETLOGS; # сбросили журнал

  Восстановление БД (вторая и третья строчки выше) можно выполнить и в SQL*Plus:

  SQL > RECOVER DATABASE UNTIL CANCEL;
  SQL> ALTER DATABASE OPEN RESETLOGS;

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

  Автоматизация задач

  Автоматизировать выполнение задач с RMAN можно как внешними средствами (язык командной оболочки), так и внутренними. Внутренние средства RMAN допускают указание файла сценария при вызове этой программы, а также организацию хранимого сценария.

  Пусть в файле listbackup.rcm находятся строки:

  CONNECT TARGET /
  LIST BACKUP;
  EXIT

  Тогда следующие два эквивалентные по результату обращения в ОС приведут ко входу в RMAN, выполнению этого сценария и выходу:

  RMAN CMDFILE=listback.rcm NOCATALOG

  RMAN @listback.rcm NOCATALOG

  При использовании каталога RMAN возможно к тому же использование хранимого сценария:

  Похожие публикации:

  1. Soax m exe что это
  2. Solution center что это за программа
  3. Speccy что это за программа
  4. Sppextcomobjhook dll что это