mirall: (job)
Некоторое время назад потребовалось сделать бэкап базы данных на RAC. Задача, на самом деле, вполне тривиальная, если бы не несколько но: у заказчика паранойя по поводу безопасности (не удивительно и понятно), у заказчика нет своего DBA (ну так уж вышло) и у меня есть доступ только к консоли сервера с базой данных. Таким образом, пришлось отказаться от использования красивого и удобного Enterprise Manager и придумать банальные консольные скрипты. И вот тут-то и возникла загвоздка.

Стандартное решение: написать скрипты бэкапа, настроить cron, который будет их вызывать по расписанию, и на этом успокоиться до тех пор, пока база таки не упадёт. Но поскольку мы имеем дело с кластером из нескольких нод, встал вопрос, на которой из них дёргать бэкап. На всех - как-то многовато. На одной - а что, если именно она-то и упадёт, а все остальные останутся в строю? По очереди - а что, если упадёт именно та, чья очередь делать бэкап как раз и наступила? На каком-нибудь третьем сервере - нету лишней железки для дополнительной базы данных.

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

Понятно, что изобретённое решение - это нецелевое использование любопытной фичи. Но получилось забавно.

Примерно так )
mirall: (job)
    Что-то это всё мутно.
    Документация предлагает следующую процедуру.
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'OSS';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL; DELETE ARCHIVELOG ALL;
    Если я что-нибудь в чём-нибудь понимаю, то это image copy backup. Он медленнее и занимает в разы больше места на диске, чем обычный. Кроме того, вызывает сомнения команда RECOVER COPY OF DATABASE WITH TAG 'OSS';. Судя по всему, сначала имеющийся бэкап куда-то восстанавливается. Вопрос, он восстанавливается прямо на standby или всё-таки куда-нибудь в recovery catalog. Если прямо на standby, то следующий закономерный вопрос: что будет, если во время снятия бэкапа навернётся primary database? Куда тогда переключаться и вообще, что делать? Далее, почему архивлоги бэкапятся прямо на ленту в то время как датафайлы — только на диск. Или в BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE; архивлоги включены по умолчанию? Обычно это опция.
    Также большие сомнения вызывают следующие пункты. Во-первых, как оценить время, за которое будет сниматься бэкап. Если это image copy, то долго — это не то слово. Во-вторых, как оценить необходимый объём дискового пространства? Опять же, image copy — это очень много. С учётом рекомендуемой политики хранения бэкапов (recovery window of n days), получается вообще запредельно. В разы больше, чем, собственно, объём датафайлов плюс архивлоги. А если база терабайтная? Это же в лучшем случае часы работы и нереальная куча места.
    И почему нельзя снимать обычный бэкап, желательно ещё и сжатый? Или можно, но такая опция просто не описана в официальной документации.
    Короче, вся эта бодяга требует кучу времени на исследования, включающие регулярное убийство то primary, то standby, их восстановления, проверки сценариев failover и сохранности данных.
mirall: (job)
    Маленькая тонкость. Бэкап снимался на базе 32bit, а разворачивался на 64bit. Аукнулось уже когда всё развернулось и восстановилось. Симптом - ошибка ORA-06553: PLS-801: internal error [56319] при попытке коннекта любым пользователем, кроме sys.
    Лекарство.
sql> connect / as sysdba
sql> shutdown immediate
sql> startup migrate
sql> @$ORACLE_HOME/rdbms/admin/utlirp.sq
sql> shutdown immediate
sql> startup
sql> @$ORACLE_HOME/rdbms/admin/utlrp.sql
sql> connect system/password
    Первый скрипт переводит все объекты базы в статус invalid, воторой их перекомпилирует, если я ничего не путаю.
mirall: (job)
    Условие задачи.
    Требуется развернуть копию базы на другом сервере. На target сервере расположение дисков отлично от source сервера. Имеется бэкап, сделанный с помощью RMAN. Это если в общем.
    Дальше умеренно подробно и неинтересно )
    Подозреваю, что сегодня произошёл очередной левелап :)
mirall: (job)
    Запарило каждый раз судорожно вспоминать, как это делается.
  1. oradim –new –sid <target db name> -syspwd <sys password> -startmode manual
  2. Провести все манипуляции из бэкапа управляющего файла.
  3. Возможно, придётся поправить ошибку ORA-30012: undo tablespace 'UNDOTBS2' does not exist or of wrong type: ALTER SYSTEM SET undo_tablespace='UNDOTBS1';
mirall: (job)
    Ядерная смесь, что давным давно известно. Однако, имеем, что имеем. В первую очередь, похоже, потому что наши админы шарят в виндах получше, чем в линуксах или солярисе.
    Связка под названием Oracle Business Intelligence. По отзывам коллег, система глюковатая. Я ею и не занимаюсь, однако мне было поручено смастрячить бэкап базы. Выдана сетевая папка, всё как у людей.
    Oracle, сцуко, по умолчанию запускается под локальным пользователем, прав на сетевую папку не имеет и бэкап rman-ом, естественно, не пишет, восклицая "Access denied". Стандартное решение — запускать базу и листенер под доменным пользователем и подправить sqlnet.ora (SQLNET.AUTHENTICATION_SERVICES = (NONE)). Однако, коллеги утверждают, что после подобных манёвров перестаёт работать весь BI. Я сама править побаиваюсь, ибо как минимум не знаю, где и что надо проверить после перезапуска сервисов, помимо возможности подключиться к базе напрямую.
    Тупым ножиком по сердцу решение бэкапить на локальный сервер, а потом копировать на удалённый.
    Мерзость.
mirall: (job)
    Сценарий. Умирает сервер с базой по имени MYDB. Имеется бэкап средствами RMAN на диске на соседнем сервере. Требуется в максимально сжатые сроки сделать новый сервер и завести базу. Тестировалось на ОС Windows XP (нет у меня под рукой сервера, есть только локальная и пара виртуальных машин).

    Решение. под катом )
mirall: (job)
    Упёрто.
    Долго я не могла догнать, как организовать полноценный cold backup. Вернее, как его потом восстановить, ибо снять бэкап RMAN-ом — дело нехитрое.
    Итак, по простому.

    Backup.
connect target /
configure controlfile autobackup on;
/* Без этого у меня ничего не получилось. Т.е. я пыталась бэкапить управляющий файл другими методами: принудительно, включала в комаду backup database, но не смогла потом корректно поднять базу. Не нравится мне это. Буду дальше исследовать. */
shutdown immediate
startup mount
backup database;
alter database open;







    Recover.
shutdown immediate;
startup nomount;
restore controlfile from autobackup;
alter database mount;
restore database;
alter database open resetlogs;
/* Без resetlogs ничего не выйдет, ибо RMAN не бэкапит online redo логи.*/







    Источник знаний.
mirall: (job)
RMAN-03002: сбой команды restore в 03/06/2008 11:30:08
ORA-19870: ошибка при считывании фрагмента резервной копии D:\ORACLE\BACKUP\BKP\
ORA-19573: невозможно получить место в очереди exclusive для файла данных 1


Ошибку удалось побороть только закрыв базу.
Процесс тренировки навыков резервного копирования и восстановления идёт полным ходом.
Page generated Sep. 25th, 2017 06:04 am
Powered by Dreamwidth Studios