Oracle-club: FAQ - backup


Новости | FAQ | Ссылки | Темы | Утилиты | Documentation | Семинары
: Каждую ночь трудолюбивый крон запускает скрипт по бэкапу базы.
           : Делаю так -
           : ...
           : connect internal
           : shutdown immediate
           : connect internal
           : startup
           : shutdown normal
           : ...
           : Копирую все файлы базы и снова запускаю.

           : Для прикола попробовал восстановиться со вчерашней копии с накатом
           : архив-логов.
           : Остановил базу, скопировал файлы назад. Кроме контрол-файлов. сконнектился,
           : смонтировал
           : базу без открытия. Сказал RESTORE DATABASE UNTIL CANCEL
           : И... ошибка на первом же архив-логе!
           : Потребовала последовательность, которой не было ни в одном архив-логе. Ни в
           : том что Оракл предложил ни в предыдущем. Типа она в середине между файлами.
                                                               ^^^^^^^^^^^^^^^^^^^^^^^^
                                                                           ????
           : Архив логов накопилось гдето за месяц уже! А толку!

           : Где я на грабли встал?

           : Марк

По моему если я правильно понял ты скопировал вчерашний
            архив и хочешь накатить на него позавчерашние архив-логи.
            Так зачем? По моему это неправильно! Оракл ведь ясно
            говорит что нужные ему последние изменения лежат в
            оперативном журнале, а не в архивном.


           Вам нужно восстановить базу ВМЕСТЕ с контрол-файлами и сделать RECOVER
           DATABASE с ключиком USING BACKUP CONTROLFILE.  AUTOMATIC или UNTIL CANCEL -
           это как хотите. Если со времени последнего backup-а не было добавлено ни
           одного datafile, то проблем быть не должно.

: Можно вопрос.
           : Посмотрел трассировку для своего контрол_файла так
           : там вроде нет номера последней последовательности.
           : Зачем ему их (контрол_файлы) восстанавливать?

           : Павел.

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

А как насчет online redo log файлов? Вы их востановили или
           оставили текущие? И было-ли переключение online redo log файла
           после последнего backup-а ?

Попробовал так, все так же. С тем же успехом.
            Такое впечатление, что процесс ARCH не успевает скопировать текущий реду-лог
            в архив в момент
            шатдауна. Рековер требует последовательность 241610. А как раз на ней я и
            сделал SHUTDOWN NORMAL.
            Т.е. она находится в реду-логе. Почему же Оракл сам не может ее оттуда
            применить?
            Ну хорошо, сказал ему, чтобы брал из этого реду-лог файла. Имя посмотрел в
            Алерт-трэйсе.
            Оракл применил одно изменение и сказал что все, медиа рекавери закончена. А
            десятка полтора следующих архив-логов? Их как применить? Запускаю еще раз.
            Опять, говорит, нужен файл с последовательностью 241610. Я дал. Опять,
            говорит, применил, медиа рекавери закончена. Счетчик изменений (CHANGE)
            увеличивает все время на единицу. Раз тридцать так сделал, но на новый файл
            архив-лога так и не перешел. С AUTOMATIC та же песня. Только молча. Т.е.
            применяет только
            один архив лог файл, который я сделал ему из активного на момент шатдауна
            реду-лога.
            А дальше никак!
            Как _правильно_  делать холодный бэкап и рекавер с накатом архив логов?

            Марк

            ЗЫ
            Вот чего в трэйс\Алерт на момент начала бэкапа написано,

            ..... неинтересное вырезано
            Mon Nov 23 03:31:19 1998 ----------------------------------- Начала
            последовательность
            Thread 1 advanced to log sequence 241609
              Current log# 2 seq# 241609 mem# 0: C:\DATABASE\LOG2ORCL.ORA
              Current log# 2 seq# 241609 mem# 1: D:\DATABASE\LOG2ORCL.ORA
            Mon Nov 23 04:00:01 1998
            --------------  Это я в первый раз глушу базу немедленно
            Shutting down instance (immediate)
            ..... неинтересное вырезано
            Thread 1 closed at log sequence 241609
              Current log# 2 seq# 241609 mem# 0: C:\DATABASE\LOG2ORCL.ORA
              Current log# 2 seq# 241609 mem# 1: D:\DATABASE\LOG2ORCL.ORA
            ..... неинтересное вырезано
            -------------- Это я снова запускаю, чтобы заглушить нормально
            Starting up ORACLE RDBMS Version: 7.3.4.0.0.
            ..... неинтересное вырезано
            ARCH started
            Mon Nov 23 04:00:17 1998
            ..... неинтересное вырезано
            alter database  mount exclusive
            Mon Nov 23 04:00:18 1998
            Successful mount of redo thread 1.
            Mon Nov 23 04:00:18 1998
            Completed: alter database  mount exclusive
            Mon Nov 23 04:00:18 1998
            alter database open
            Mon Nov 23 04:00:22 1998
            ------------Это она подхватила оборванную последовательность
            Thread 1 opened at log sequence 241609
              Current log# 2 seq# 241609 mem# 0: C:\DATABASE\LOG2ORCL.ORA
              Current log# 2 seq# 241609 mem# 1: D:\DATABASE\LOG2ORCL.ORA
            Successful open of redo thread 1.
            Mon Nov 23 04:00:22 1998
            SMON: enabling cache recovery
            Mon Nov 23 04:00:24 1998
            ---------------------------------------  Начала новую последовательность
            Thread 1 advanced to log sequence 241610
              Current log# 5 seq# 241610 mem# 0: C:\DATABASE\LOG5ORCL.ORA
              Current log# 5 seq# 241610 mem# 1: D:\DATABASE\LOG5ORCL.ORA
            Mon Nov 23 04:00:26 1998
            Completed: alter database open
            ----------------------------------------Это я во второй раз глушу базу
             нормально)
            Shutting down instance (normal)
            ..... неинтересное вырезано
            Starting up ORACLE RDBMS Version: 7.3.4.0.0.

            После этого все файлы бэкапятся

Во всех мануалах говорится, что рековер с опцией using backup
           controlfile,
           рекомендуется использовать в последнюю очередь, после того как
           обломились
           попытки восстановиться с текущим контролом, или создать его. Тк в
           случае,
           с использованием бэкапных контролов, не известен последний SCN, которые
           и хранятся в них, для каждого файла....
           Правда чем выгоднее создавать контролы, чем брать бэкапный, мне
           лично непонятно.
           Также после такого восстановления необходимо использовать опцию
           RESETLOG в опене на базу...


1. А база в ARCHIVE LOG ?
                 2. Посмотри в табличку V$LOG_HISTORY. По ней для свежих SCN
                 можно найти соответствующий архив. Если в том архиве, что указан
                 в этой таблице, для промежутка SCN, покрывающего твой,
                 нужного тебе SCN нету, то у тебя не бэкап, а мусор.
                 3. Полноценный бекап включает в себя не только файлы данных,
                 но еще редологи и контрол-файлы.
                 4. Перед сливанием редо-логов рекомендуют делать switch log file.
                 5. Поищи примеры скриптов, которые бэкапят базу и разберись,
                 где ошибся.

           -- 
1. RECOVER DATABASE без USING BACKUP CONTROLFILE
                           накатывает изменения на базу не дальше (позже),
                           чем SCN в CONTROLFILE, который смонтирован.
                           Используя RECOVER DATABASE UNTIL (CANCEL/TIME/SCN)
                           можно прервать RECOVER __только__ раньше.

                           2. RECOVER DATABASE USING BACKUP CONTROLFILE
                           поэволяет скормить последовательно любое количество REDO
                           вне зависимости от записи SCN в CONTROLFILE и DATAFILES.

> У меня вопрос по поводу оптимального размера журнальных файлов. В > одних источниках рекомендуется чтобы группы журналов переключались > каждые 30-60 минут, по другим - наоборот, как можно чаще, чтобы > минимизировать потери при возможном крахе. А как надо (из вашего > практического опыта) ? > Сейчас у меня размер журналов 512K. И сброс в архив в какие-то моменты > происходит с частотой 10-15 за минуту (не слишком ли часто?). IMHO, удобно иметь 10-15 переключений в сутки. Я размер файлов подбирал исключительно из удобства (читай, приемлемого времени поиска) их складирования на ленту, а вовсе не минимизируя потери. Я просто делаю каждые 15 минут checkpoint (log_checkpoint_timeout=900, checkpoint_process=true). У меня файлы 500 М.

Вопрос:

>Хочу попробовать восстановить БД. >Для этого просто удаляю один из файлов данных. >Но после этого не могу войти OEM (БД смонтирована, >но не открыта) - ORACLE 8 for NOVELL

Ответ:

Условия восстановления одного файла данных: 1. База должна работать в режиме ARCHIVELOG 2. Должен быть сделан полный бэкап после перевода в ARCHIVELOG. 3. Должны быть в наличии все архивные логи. Действия по восстановлению: 1. Скопировать соответвующий файл из бэкапа на место битого. 2. Запустить SVRMGR SVRMGR> connect internal SVRMGR> startup mount SVRMGR> recover database ..... SVRMGR> alter database open noresetlogs; SVRMGR>exit;

Вопрос:

возникла следующая проблема: я потер redo log файлы для нашего Оракла, и теперь сервер при стартапе не открывает базу ругаясь на их отсутствие. DROP и CLEAR LOGFILE работают только при открытой базе, а мне бы их сбросить до открытия. Вопрос в следующем, можно ли как-нибуль сказать Ораклу, что бы он открыл базу не глядя на redo? Данными, которые могут быть под redo я готов пожертвовать. Был бы очень благодарен за любые советы. База стоит, а недавних бэкапов нет :(

Ответ 1:

Формально, если база не archive log, надо откатиться на последний backup. а реально есть недокументированые инструкции для решения подобных проблем. У меня это было давно и на 7.3, так что в чем-то могу и ошибиться. в init.ora ставишь недокументированный параметр _allow_resetlogs_corruption=TRUE (?) [allow resetlogs even if it will cause corruption] , а дальше в обычном режиме. Полный список недок параметров с кратким описанием можно найти в файле документации :-) oracleXX.exe имеется ввиду исполняемый файл oracle Server.(.exe естественно относится к NT) Щаз посмотрю под Linux... Точно есть ...\product\8.0.5\bin - исходники же одни... Короче ,поищи клавишей F7 _allow_reset...

Ответ 2:

Если это про восстановление битых реду -логов то есть стандартные способы восстановления. Все зависит от режима работы БД. 1.Зеркалированые реду-логи, имеется хоть один целый элемент группы - - уничтожить поврежденный файл и добавить новый. 2.Потеря всей группы неактивной база еще работает - ALTER DATABASE CLEAR LOGFILE если была IO ошибка, то создать дополнительный файл(элемент группы) и удалить поврежденный файл база уже стоит колом - 1. shutdown abort 2. startup mount 3. Если эта группа была архивирована - ALTER DATABASE CLEAR LOGFILE не была архивирована - ALTER DATABASE CLEAR UNARCHIVED LOGFILE если была IO ошибка, то создать дополнительный файл(элемент группы) и удалить поврежденный файл 3.потеря активной группы база еще работает и битая группа не является CURRENT - ALTER SYSTEM CHECKPOINT при удачном завершении выполнить действия как для неактивной группы. если не получилось или база уже висит - попытаться исправить сбой носителя либо - - если БД в NOARCHIVELOG - рекавер с полной резервной копии. - если БД в ARCHIVELOG - сделать неполное восстановление до последнего перед поврежденным журналом. - открыть базу с RESETLOGS Довольно сложно, но можно. Марк

Ответ 3:

Если база данных в Consistent state то можно ALTER DATABASE OPEN RESETLOGS.

Новости | FAQ | Ссылки | Темы | Утилиты | Documentation | Семинары