Recovery Manager (RMAN)
Recovery manager is a platform independent utility for coordinating your backup and restoration procedures across multiple servers. The reporting features alone mean that you should never find yourself in a position where your data is in danger due to failed backups.
The functionality of RMAN is too diverse to be covered in this article so I shall focus on the basic backup and recovery functionality. I shall also assume you are planning to use a recovery catalog, but this is not necessary, although some recovery functionality is lost if you are not using one.
Create Recovery Catalog
Create a user to hold the recovery catalog. This should be on a separate server to any databases you are planning to backup.
Create the recovery catalog.
Register Database
Each database to be backed up by RMAN must be registered with the catalog.
Existing user-created backups can be added to the catalog using the CATALOG command.
Full Backup
Configure the relevant persistant parameters for this instance.
Perform a complete database backup using a single command.
The recovery catalog should be resyncronized on a regular basis so that changes to the database structure and presence of new archive logs is recorded. Some commands perform partial and full resyncs implicitly, but if you are in doubt you can perform a full resync using the following command.
Restore & Recover The Whole Database
If the controlfiles and online redo logs are still present a whole database recovery can be achieved by running the following script.
This will result in all datafiles being restored then recovered. RMAN will apply archive logs as necessary until the recovery is complete. At that point the database is opened. If the tempfiles are still present you can issue a command like the following for each of them.
If the tempfiles are missing they must be recreated as follows.
Restore & Recover A Subset Of The Database
A subset of the database can be restored in a similar fashion.
Incomplete Recovery
As you would expect, RMAN allows incomplete recovery to a specified time, SCN or sequence number.
The incomplete recovery requires the database to be opened using the RESETLOGS option.
Disaster Recovery (Catalog)
In a disaster situation where all files are lost you can only recover to the last SCN in the archived redo logs. Beyond this point the recovery would have to make reference to the online redo logs which are not present. Disaster recovery is therefore a type of incomplete recovery. To perform disaster recovery connect to RMAN.
Once in RMAN do the following.
From SQL*Plus as SYS get the last archived SCN using the following.
Back in RMAN do the following.
If the UNTIL SCN were not set the following type of error would be produced once a redo log was referenced.
With the database open all missing tempfiles must be replaced.
Once the database is fully recovered a new backup should be performed.
The recovered database will be registered in the catalog as a new incarnation. The current incarnation can be listed and altered using the following commands.
Disaster Recovery (No Catalog)
Create a dummy PFILE.
Start the database in NOMOUNT mode.
Create a new PFILE from the backup SPFILE.
Edit the contents of the newly created «initorcl.ora» file if necessary.
Start the database using the new PFILE.
Restore the controlfile and mount the database.
Restore and recover the database.
Lists And Reports
RMAN has extensive listing and reporting functionality allowing you to monitor you backups and maintain the recovery catalog. Here are a few useful commands.
It’s worth spending some time looking at all the reporting capabilities whilst deciding whether you should switch from shell scripting to RMAN. It might just influence your decision.
Утилита RMAN (Recovery Manager)
RMAN — (утилита для резервного копирования и восстановление данных).
Команда Restore выполняет восстановление файлов из бекапа. Данные восстанавливаются на момент создания бекапа.
Команда Recover — применяет к восстановленной из бекапа базе данных сохраненные архивные журналы, чтобы база данных была актуальна на какой-то более приемлемый момент времени, нежели чем на момент создания бекапа. Если архивных журналов нет, то и применять нечего.
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 — явно может быть вирусом, если только вы сами лично не ставили себе ПО для удаленного управления ПК. Про вирус можете почитать здесь.
План действий — проверяем ПК не только утилитой от Доктора Веба, но и еще двумя лучшими утилитами:
- Dr.Web CureIt! — мощный инструмент против опасных вирусов типа троянов, ботнетов, майнеров. Скачивается уже с антивирусными базами, поэтому может весить примерно 100 мб. Длительность проверки может зависеть от количества файлов на диске. По окончании требует перезагрузку. Скачиваем утилиту здесь.
- AdwCleaner — утилита против рекламного и шпионского ПО, проверяет реестр, планировщик задач, браузер и его расширения, ярлыки, автозагрузку. Перед сканированием загружает антивирусные базы. Скачать можно тут.
- HitmanPro — похожа на AdwCleaner, принцип работы одинаков, только использует более тщательное сканирование. Может находить угрозы даже в куки-файлах. Работает быстро. Качаем здесь.
Важно! Если у вас нет нормального антивируса, тогда советую поставить бесплатную версию Каспера, а именно Kaspersky Free — базы обновляет, вирусы находит, ПК не грузит (было время тестировал).
Ручное удаление
Внимание! Пере ручным удалением создаем точку восстановления!
Способ нашел на форуме Virusinfo:
- Останавливаем службу TektonIT R-Server. Зажмите Win + R, появится окошко Выполнить, вставляем команду services.msc и нажимаем ОК. Находим службу > нажимаем два раза > в Тип запуска выставляем Отключена, а потом нажимаем кнопку Остановить.
- Удаляем данные в реестре. Открываем реестр: 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
- Необязательно. При наличии папки C:\Windows\SysWOW64\vipcatalog — удаляем ее полностью (vipcatalog). Если будут проблемы с удалением vipcatalog, тогда используйте Unlocker. Возможно что без удаления можно обойтись, но если папка есть, то советую ее все таки удалить.
- Выполняем перезагрузку.
- Удалить вручную остатки вируса. Среди файлов — зажимаем Win + E, выбираем Мой компьютер, потом в левом верхнем углу будет текстовое поле поиска — пишем туда rutserv и ищем остатки. В реестре: зажимаем Win + R > команда regedit > зажимаем Ctrl + F > вставляем в поле rutserv и нажимаем Найти далее. Когда нашлось — удаляем и продолжаем поиск кнопкой F3, пока не будет сообщение что поиск закончен.
Важно! Искать остатки можно не только по слову rutserv, но и по rfusclient, Remote Manipulator System, RMANService, TektonIT. Но смотрите внимательно что удаляете!
Rman service что это
Во время выполнения задач резервного копирования и восстановления можно загружать и выгружать базу данных Oracle не выходя из клиента RMAN. Для выполнения этих действий используются аналоги команд SQL*Plus STARTUP и SHUTDOWN.
Старт базы данных
Для старта базы данных используется команда RMAN startup. Так же как и её аналог из SQL*Plus она может использоваться с различными опциями. Если опции не указываются, то команда осуществляет автоматическое монтирование и открытие базы данных:
Использование опций в команде STARTUP из RMAN клиента позволяет сделать процесс восстановления базы данных гибче. В следующем примере можно наблюдать, как происходит восстановление в RMAN по шагам, начиная от старта базы данных в NOMOUNT режиме и заканчивая открытием базы данных с опцией RESETLOGS:
Для того чтобы вышеуказанный пример получился, резервная копия, с которой происходит восстановление контрольного файла, должна быть создана с предварительно включенным параметром CONTROLFILE AUTOBACKUP:
Опцию NOMOUNT команды STARTUP можно так же использовать, если серверный (или инициализационный) файл параметров потерян и требуется его восстановление из резервной копии. Следующий пример демонстрирует этот процесс по шагам.
Для начала, переименуем файл параметров, имитируя его потерю:
Если сейчас попробовать стартовать экземпляр, то он запросит файл параметров:
Утерянный файл параметров имеется в резервной копии RMAN, но для того чтобы восстановить его, надо запустить базу данных в NOMOUNT режиме. Поэтому, используем для старта базы данных фиктивный файл параметров.
Перед стартом обязательно устанавливаем идентификатор базы данных, так как мы не подключаемся к каталогу восстановления:
Стартуем экземпляр с фиктивным файлом параметров:
Попробуем восстановить файл параметров из резервной копии:
Восстановление закончилось неудачей. Почему? Чтобы ответить на этот вопрос, вспомним, что экземпляр базы данных запускался с фиктивным файлом параметров. В нём нет указаний на путь к директории флэш-области восстановления, которая содержит резервные копии. RMAN просто не может их найти. Значит, придётся задавать расположение флэш-области вручную. В нашем случае путь к директории флэш-области складывается из значений двух параметров db_recovery_file_dest и db_name, которые можно определить прямо в команде восстановления файла параметров:
Как видно RMAN нашел резервную копию и восстановил из неё файл параметров. Проверим наличие файла в операционной системе:
Файл параметров действительно присутствует. Теперь можно стартовать базу данных:
Файл параметров восстановлен, и база данных открыта. Причём сделано это всё было только в клиенте RMAN.
Остановка базы данных
Для закрытия базы данных и остановки экземпляра, в клиенте RMAN можно использовать команду SHUTDOWN. Команда поддерживает в синтаксисе те же самые опции, что и её аналог в SQL*Plus. В следующем примере показано, как используя только RMAN клиент, можно остановить базу данных, стартовать её в смонтированном режиме, сделать резервную копию и открыть базу данных для использования:
Стоит отметить, что команды STARTUP и SHUTDOWN в клиенте RMAN имеют ограничения. Так, с их помощью нельзя закрыть и стартовать экземпляр каталога восстановления. Данные команды относятся только к целевой базе данных. Поэтому, если всё же потребуется остановить или стартовать экземпляр каталога из клиента RMAN, необходимо подключиться к нему как к целевой базе данных, и только затем использовать команды STARTUP и SHUTDOWN.
3-12. Проверка синтаксиса RMAN команд
В RMAN имеется возможность проверки синтаксиса вводимых команд. Для входа в этот режим необходимо запустить клиента RMAN с аргументом командной строки checksyntax. После этого, можно проверять синтаксис команд, вводя и запуская их в оболочке клиента или подгружая файл скрипта с содержащимися в нём командами. Сами команды исполняться при этом не будут.
Следующий пример демонстрирует проверку синтаксиса единственной команды:
Как видно из примера, ошибок в синтаксисе этой команды не обнаружено.
Кроме проверки синтаксиса отдельных команд, в RMAN можно проверить синтаксис команд целого скрипта. Для этого надо указать файл скрипта в качестве аргумента командной строки при запуске клиента:
В примере мы видим, что в синтаксисе третьей команды скрипта имеется ошибка.
Использование аргумента checksyntax позволяет предотвратить появление грубых ошибок во время выполнения командного скрипта RMAN. Рекомендуется всегда использовать данную проверку, когда скрипт модифицируется.
3-13. Сокрытие паролей при подключении к RMAN
Запуск клиента RMAN часто сопровождается указанием в аргументах командной строки параметров подключения, таких как база данных, имя и пароль пользователя. В результате, в различные логи операционной системы могут попадать данные, которые содержат командную строку запуска RMAN с паролём пользователя в открытом виде. Существует два способа избежать этого. Первый – это указывать в командной строке только имя пользователя. Клиент RMAN сам запросит пароль. Вводимые символы при этом отображаться не будут:
Если же требуется выполнить командный скрипт RMAN и при этом необходимо избежать указывания пароля в командной строке, то можно поместить команду подключения CONNECT с именем и паролём пользователя в самое начало файла скрипта. При выполнении такого скрипта RMAN клиент сделает подключение, заменив в выводе имя пользователя и пароль звёздочками:
В последнем случае стоит ограничить доступ другим пользователям к файлу сценария на уровне операционной системы, так как в нём будет указаны параметры подключения в открытом виде.
3-14. Идентификация серверных сеансов RMAN
Для выполнения задач резервного копирования и восстановления, RMAN образует с целевой базой данных или каталогом восстановления сеансы. Иногда возникают случаи, когда необходимо прервать работу одного из таких сеансов. Ниже на примерах будет показано, как можно идентифицировать такие сеансы в системе, для того чтобы их в дальнейшем можно было уничтожить.
Определение колличества сеансов
Узнать количество сеансов RMAN можно с помощью следующей формулы:
Количество сеансов = C+N+2
- C – количество выделенных каналов;
- N – число опций CONNECT, используемых в командах выделения каналов (если не определено, то равно 1);
Если используется каталог восстановления, всегда имеется, по крайней мере, два сеанса, один к каталогу восстановления, другой по умолчанию к целевой базе данных. Сеанс по умолчанию необходим для того, чтобы выполнить такие задачи, как применение архивных журналов во время процесса восстановления.
Идентификация сеансов
Если RMAN клиент запускается на сервере базы данных (unix), то для того чтобы отобразить список серверных процессов относящихся к сеансам RMAN достаточно выполнить следующую команду:
Из примера видно, что был запущен клиент RMAN c идентификатором процесса PID равным 3743. Ищем процессы имеющие идентификаторы родительского процесса PPID равным этому значению:
Найденные процессы и будут принадлежать сеансам запущенного клиента RMAN. По их PID можно легко найти идентификаторы (SID, SERIAL#) сеансов и уничтожить их с помощью команды ALTER SYSTEM … KILL SESSION.
Идентификатор сеанса SID так же можно встретить и в выходной информации RMAN:
В этом примере мы видим, что для резервного копирования базы данных был применён канал ORA_DISK_1, который использует сеанс с идентификатором SID = 145.
Если клиент RMAN подключается к базе данных удалённо, то определить такие сеансы через команды операционной системы будет затруднительно. В этом случае придётся обращаться к системному представлению V$SESSION и идентифицировать сеансы либо по названию программы клиента, либо по терминалу. В остальном сеансы RMAN не несут никаких отличительных признаков по сравнению с другими сеансами:
3-15. Удаление базы данных из клиента RMAN
Если требуется удалить базу данных, то сделать это можно с помощью утилиты SQL*Plus. Но если нет возможности в её использовании, то удаление можно провести и в RMAN клиенте.
Для удаления базы данных, надо:
Запустить базу данных в смонтированном эксклюзивном режиме:
Использовать команду DROP для удаления базы:
RMAN потребует подтверждение на удаление. Необходимо ввести YES:
Можно использовать ключевое слово noprompt в команде DROP для предотвращения диалога запроса на удаление. Это может пригодиться в случае составления командного скрипта RMAN.
Стандартная команда DROP DATABASE удаляет только файлы данных, файлы онлайн журналов, и контрольные файлы. Но в RMAN эта команда имеет расширенный синтаксис. Используя дополнительные ключевые слова, можно с помощью этой команды дополнительно избавиться и от всех резервных копий сделанных ранее RMAN: