Тайно и незаметно скопировать базу ORACLE

Несколько дымовых шашек и шумовых гранат, брошенных в серверную, на какое-то время помогут отвлечь внимание админов.

Схоронил :)

База куда-нибудь бэкапится дупликацией? На сервере бэкапа отключаешь дупликацию, копируешь, включаешь дупликацию снова.

Или вовсе не отключая дупликацию на сервере бэкапа, бэкапишь там же копию на лету.

На сервер бэкапа никто не смотрит, это же не продакшен.

В квотезы сразу.

На сервер бэкапа никто не смотрит, это же не продакшен.

Хороший админ обязан быть параноиком, и глядеть на бекап сервера тоже.

А зачем собственно незаметно копировать БД? Это попахивает преступлением, а дающие советы - соучастники :) По теме, будь мужиком, подойди к руководству и честно заяви, мол хочу вашу базу ))

Хотбэкап. В логах оракла сея деяние записывается.

Тут может быть другая ситуация. Человек хочет знать о такой возможности и предотвратить утечку базы.

Человек хочет знать о такой возможности и предотвратить утечку базы.

На ЛОРе? Ню-ню.

su - oracle

export ORACLE_SID=<SID>

rman target / nocatalog

set controlfile autbackup on

set DEVICE TYPE TO DISK;

set CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backups/oracle/%F.bkp;

set DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;

set CHANNEL DEVICE TYPE DISK FORMAT '/backups/oracle/data_%d_%u_%s.bkp';

set ENCRYPTION FOR DATABASE OFF;

backup database plus archivelog all;

Бэкап найдешь в /backups/oracle

Очень может быть

А можно немного best practice'а, вы как у себя бекапите оракловые базы? rman по крону? А если база на винде крутится?

А если база на винде крутится?

... rman по виндовому шедулеру

Точнее, 6 rman'ов в день. Один полный + архивлоги и 5 только архивлоги.

Да, rman лучше всегда дергать из скрипта/bat'ника

то есть

backup database plus archivelog;

а потом

backup archivelog all;

а можете show all показать. Или может тогда лучше сам батник? :)

Интересуюсь только лишь ради совершенствования своего решения - у меня батник по виндовому шедулеру так же.

А как часто у вас redo log'и свитчатся и какой их размер?

Снять dump базы?

В обязательном порядке

crosscheck backup; crosscheck all;

Далее по ситуации

backup database plus archivelog all;

или

backup archivelog all delete all input;

Примерно так:

CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\backups\cfa_%F.bkp';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   'D:\backups\backupdata_%d_%u_%s.bkp';

CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;

Батник не покажу - безопасники на г..но изойдут. Но если вкратце, то там делается синхронизация бэкапов с рядом стоящей машиной. Ну и понятно, что согласно с нашей политикой, у нас получится восстановиться по состоянию «не далее чем на два дня назад и до текущего момента с допустимой потерей данных до 4 часов». За удаление архивлогов соответственно отвечает rman.

Редо на разных объектах разные, частота переключения сильно зависит от нагрузки объекта (и соответственно от объема изменений). Нагрузка у нас идет волнами, поэтому частота также меняется от времени суток и дня (рабочий/выходной), интервалы от 10 минут до 4 часов (автоматический свич логфайла при начале бэкапа).

Дамп неконсистентный по умолчанию, а консистентный это жестоко, особенно на больших базах и/или большой нагрузке.

На какой-нибудь жаве наваяй софтину, которая по всем таблицам будет идти и делать select * и вычитывать-сохранять потихоньку. Только уровень транзакций поставь самый слабый, чтобы таблицы не лочились. Курсор forward only. По идее такое на сервере ресурсов занимать практически не будет, нагрузка только на сетевое соединение с базой, там сам скорость можешь ограничить, чтобы канал не забивать.

На сервер бэкапа никто не смотрит, это же не продакшен.

Хороший админ обязан быть параноиком, и глядеть на бекап сервера тоже.

Я вообще не понимаю, что значит backup - не продакшен? O_o

Тут может быть другая ситуация. Человек хочет знать о такой возможности и предотвратить утечку базы.

Если бы он этого хотел, он бы прямо так и сказал

Я вообще не понимаю, что значит backup - не продакшен? O_o

Я попробую догадаться, что автор имел ввиду. Скорее всего речь о том, что за сервером где хранятся резервные копии а не реплицируемый резервный сервер.

Ну варианты могут быть разные. Сами понимаете. Что значит будь мужиком? Мы же не в детском саду с вами, зачем сразу в такие крайности, если не знаете для чего задан вопрос)) По-факту есть просто ТЕХНИЧЕСКИЙ вопрос, а не заявление о немерении совершить преступление, без конкретизации целей, все остальное-ваши личные домыслы)

Базы за терабайт.

Если бы он этого хотел, он бы прямо так и сказал

Нет, мне необходимо мнение и мышление людей, которые представили себя в роли похищающих базу, а не тех кто ее защищает. Это несколько различный подход для анализа уязвимостей, например так.

На какой-нибудь жаве наваяй софтину, которая по всем таблицам >будет идти и делать select * и вычитывать-сохранять >потихоньку. Только уровень транзакций поставь самый слабый, >чтобы таблицы не лочились. Курсор forward only. По идее такое >на сервере ресурсов занимать практически не будет, нагрузка >только на сетевое соединение с базой, там сам скорость можешь >ограничить, чтобы канал не забивать.

Вариант хороший. А если на сервере нет столько места чтобы базу агрегировать? Можно еще и по-сети потихоньку сплавлять.

Ну, если бы мне надо было тихонько слить чужую базу, я бы сделал так:

# su - oracle
oracle$ export ORACLE_SID=<sid>
oracle$ sqlplus / as sysdba
# переводим БД в begin backup
sql> alter system switch logfile;
sql> begin
for i in (select name from v$datafile) loop
   execute immediate 'alter datafile '''||i.name||''' begin backup';
end loop;
end;
/
sql> quit
# копируем датафайлы
$ cp $ORACLE_HOME/../oradata/$ORACLE_SID/* /mnt/mydevice
sql> alter system switch logfile;
sql> quit
# Копируем архивлоги
$ cp $ORACLE_HOME/../flash_recovery_area/$ORACLE_SID/* /mnt/mydevice
sql> alter system switch logfile;
sql> begin
for i in (select name from v$datafile) loop
   execute immediate 'alter datafile '''||i.name||''' end backup';
end loop;
end;
/
sql> quit
$ exit
#

Ну и потом просто пересоздал контролфайл через create database reuse ..., сделал recover automatic database using backup controlfile until cancel и потом open resetlogs.

Или, если важны сами данные а не работоспособная база, просто запустил бы EXP (переименовав бинарник в TesClientApp.exe, чтобы в логах сессий он «светился» благовидно). Да, потом у меня были бы косяки с включением сылочных констрейнтов, но сами данные у меня были бы.

Если «базы за терабайт» - то стоит сразу сказать, хочется ли сединоросить данные, или нужна работоспособная копия. Возможные механизмы сильно разнятся при этих задачах

хочется ли сединоросить данные

just lol. thanks.

записывается в контрольник